Automotive Cybersecurity Assurance Cases: A Practical Guide to Claims, Arguments, Evidence

Automotive cybersecurity teams generate large volumes of evidence: TARAs, architecture models, cybersecurity goals, requirements, test reports, penetration-test findings, SBOMs, vulnerability decisions, supplier declarations, software-update records, and incident reports. Yet a large evidence collection does not automatically explain why a vehicle, ECU, or software platform is adequately secure.

That explanation is the purpose of an automotive cybersecurity assurance case.

An assurance case connects three things: a claim about the security of a defined system, an argument explaining why the claim is reasonable, and evidence that supports each step of the argument. It also records assumptions, operating conditions, residual risks, confidence, and the limits of what has been demonstrated.

This is more than a polished compliance report. A well-designed assurance case becomes a reusable engineering structure. Tier-2 suppliers can provide component sub-cases. Tier-1 suppliers can combine them with integration evidence. OEMs can assemble vehicle-level arguments without rebuilding every supplier assessment from raw files. When software, architecture, vulnerabilities, or operational conditions change, the affected claims can be identified and reassessed.

This guide explains how to build that operating model without duplicating a general ISO/SAE 21434 implementation guide or an audit checklist. The focus is the reasoning structure that turns disconnected work products into a defensible, maintainable cybersecurity argument.

What is an automotive cybersecurity assurance case?

An automotive cybersecurity assurance case is a structured, evidence-supported argument that a vehicle item, component, function, or system achieves an acceptable level of cybersecurity within a defined context.

A simple example might begin with the top-level claim:

The telematics platform is adequately protected against unauthorized remote control throughout its supported lifecycle.

That claim is too broad to accept on its own. The argument must decompose it into smaller claims, such as:

• Externally reachable interfaces are identified and protected.
• Device and backend identities are authenticated.
• Privileged commands are authorized and constrained.
• Software integrity is protected from build through installation.
• Security controls have been verified in representative environments.
• Vulnerabilities and field incidents are monitored and handled.
• Residual risks are known, approved, and bounded by explicit assumptions.

Each sub-claim is then supported by evidence. Evidence may include architecture baselines, interface inventories, threat analysis, security requirements, implementation records, test results, signed release manifests, penetration-test reports, vulnerability records, and monitoring procedures.

The case should also state its scope. “Secure” is meaningless without boundaries. A defensible case identifies the exact product, hardware and software versions, variants, suppliers, operating conditions, support period, deployment environment, and exclusions to which the argument applies.

Evidence is not the same as an argument

Many organizations call a folder of work products a cybersecurity case. The folder may be complete, but the reviewer still has to infer how the pieces fit together.

Consider a penetration-test report that shows no exploitable issue in a diagnostic interface. That report is evidence, but it does not by itself prove the interface is adequately protected. The argument must establish:

1. Why this interface matters to the top-level claim.

1. Which threats and attack paths the test covered.

1. Which configuration and version were tested.

1. Whether the test method was appropriate for the expected attacker.

1. Which controls were exercised.

1. What limitations or untested conditions remain.

1. Whether the result is still valid after later changes.

Without that reasoning, evidence can be technically impressive yet irrelevant to the claim.

The opposite problem also occurs. A report may contain strong narrative statements but weak proof. “Secure boot prevents unauthorized software” is an argument fragment, not evidence. The supporting evidence could include the boot-chain design, trust-anchor provisioning, signature-validation test results, negative tests, key-management controls, and release records for the actual product baseline.

A mature assurance case makes the distinction explicit: claims say what is believed, arguments explain why, and evidence shows what was observed or implemented.

The core building blocks

Claims

Claims are clear, testable statements about security, process, or evidence quality. They should be specific enough that a reviewer can decide whether they are supported.

Useful claim patterns include:

• A defined asset is protected against a defined threat class.
• A risk has been reduced below the organization’s acceptance threshold.
• A control is implemented for every applicable variant.
• A requirement has been verified by current evidence.
• A supplier component satisfies stated security properties under documented assumptions.
• A post-production process is capable of detecting and responding to relevant vulnerabilities.

Avoid absolute claims such as “the vehicle cannot be hacked.” Assurance is contextual and evidence-based, not a guarantee of zero risk.

Arguments

Arguments connect claims logically. Common strategies decompose a top-level claim:

• By architecture: vehicle, domain, ECU, software unit, interface.
• By lifecycle: concept, development, production, operation, maintenance, decommissioning.
• By threat: spoofing, tampering, privilege abuse, denial of service, information disclosure.
• By control objective: prevent, detect, contain, recover.
• By supplier responsibility: OEM, Tier-1, Tier-2, cloud provider, service operator.
• By operating state or variant: manufacturing, workshop, customer use, degraded mode, regional configuration.

The chosen decomposition should match how risk and evidence are actually managed. A beautiful diagram that does not map to engineering ownership will become stale.

Evidence

Evidence should be identifiable, attributable, versioned, and linked to the claim it supports. Typical evidence includes:

• Item definitions and architecture baselines.
• Asset, damage-scenario, threat, attack-path, and risk records.
• Cybersecurity goals, requirements, controls, and implementation claims.
• Design reviews and code-analysis results.
• MIL, SIL, HIL, vehicle, fuzzing, and penetration-test evidence.
• SBOMs, VEX statements, vulnerability records, and remediation decisions.
• Secure-build, signing, release, and software-update records.
• Supplier certificates, evaluation reports, and assumptions of use.
• Incident-response exercises and post-production monitoring evidence.
• Audit logs, approvals, deviations, and residual-risk acceptance.

Evidence quality matters more than file count. A result with no product version, configuration, date, owner, method, or expected outcome may be difficult to rely on.

Context and assumptions

Every claim depends on context. Examples include:

• A hardware security module is provisioned with OEM-controlled keys.
• Debug interfaces are disabled in production.
• A backend service enforces multi-factor authentication for privileged users.
• The vehicle is operated within specified environmental or network conditions.
• A supplier patch is integrated without changing a protected interface.

Assumptions should be visible and testable. Hidden assumptions are a major source of assurance failure. When an assumption no longer holds, the affected claims should automatically enter review.

Justifications and residual risks

The case should explain why a particular argument strategy, test depth, or risk decision is acceptable. It should also identify residual risks rather than burying them in a separate register.

A residual-risk statement should name the remaining exposure, affected scope, compensating controls, monitoring, decision owner, approval date, and conditions that trigger reconsideration.

Start with the decision the case must support

An assurance case should be built for a real decision, not as an abstract documentation exercise. Typical decisions include:

• Approving an ECU for an OEM program gate.
• Accepting a supplier component for integration.
• Demonstrating readiness for type approval.
• Authorizing a software release or OTA campaign.
• Accepting a residual risk.
• Determining whether a vulnerability affects a deployed fleet.
• Showing an assessor that required cybersecurity properties are implemented and verified.

The decision determines the scope, audience, level of detail, and evidence freshness required.

For example, a sourcing decision may rely heavily on component-security properties, development-process evidence, certification, assumptions of use, and supplier support commitments. A release decision needs exact configuration, test results, unresolved findings, approved deviations, and deployment scope. A field-vulnerability decision needs SBOM linkage, exploitability context, attack paths, controls, fleet exposure, and remediation evidence.

Trying to use one static report for all of these decisions produces either an unreadable document or an argument too generic to be useful.

Build a claim architecture before collecting more documents

The fastest way to improve an assurance case is often to stop collecting evidence temporarily and design the claim structure.

A practical top-down process is:

1. Define the item and decision boundary.

1. Write one top-level claim in plain language.

1. Identify the major argument strategies needed to support it.

1. Decompose each strategy into reviewable sub-claims.

1. Attach the evidence that already exists.

1. Mark unsupported, partially supported, stale, or assumption-dependent claims.

1. Assign owners and closure actions.

This creates an evidence demand model. Instead of asking teams to upload everything, the organization can ask for the exact proof needed for an unsupported claim.

A telematics assurance case might use six top-level strategies:

• Architecture and attack surface are understood.
• Security risks are identified and treated.
• Trust, access, and software integrity controls are implemented.
• Controls are verified against representative attack paths.
• Supplier and operational dependencies are governed.
• Vulnerabilities and incidents are managed throughout support.

Each strategy can then be expanded only as far as the risk and decision require.

Modular assurance cases across the supply chain

The automotive supply chain makes monolithic assurance cases inefficient. A Tier-2 supplier may provide a secure element, operating system, communications stack, sensor, or library used across many ECUs and vehicle programs. Repeating the same evaluation for every integration wastes time and introduces inconsistency.

A modular model treats the supplier’s argument as a sub-case that can be composed into a larger case.

A component sub-case should include:

• The target of evaluation and exact version.
• Claimed security properties.
• Threats and attacker assumptions considered.
• Security functions and boundaries.
• Evaluation and test evidence.
• Known vulnerabilities and residual risks.
• Required environmental controls.
• Integration guidance and prohibited uses.
• Validity conditions, support period, and change-notification rules.

The Tier-1 does not simply attach the certificate or report. It adds an integration argument showing that the component is used within its evaluated conditions, configured correctly, and combined with the required surrounding controls.

The OEM then adds vehicle-level evidence for cross-domain attack paths, variant behavior, supplier interactions, diagnostics, backend services, updates, and post-production operation.

This preserves intellectual property. Suppliers can expose a bounded claim and evidence package without handing over every design detail. The receiving organization still gets enough information to evaluate applicability and integration risk.

How component certification can support the case

Component evaluation schemes such as GlobalPlatform SESIP are relevant because they emphasize defined security targets, assurance levels, profiles, composition, and reuse. A certified component can provide credible evidence for part of the vehicle argument.

However, certification is not a substitute for vehicle-level TARA or integration assurance.

A certificate may show that a component implemented and evaluated defined security functions. It does not automatically prove:

• The OEM configured those functions correctly.
• Required keys and identities were securely provisioned.
• The surrounding software invokes the functions safely.
• Assumptions of use are satisfied.
• Integration did not introduce a new attack path.
• The evaluated version is the version actually deployed.
• Operational monitoring and update processes remain effective.

Use component certification as an evidence module. Map each certified property to the vehicle-level claim it supports, record the assumptions, and add integration-specific evidence. This allows reuse without overstating what the certification proves.

As automotive work on Cybersecurity Assurance Levels and Targeted Attack Feasibility evolves, organizations should expect more structured discussion about matching assurance effort to risk. The practical principle is already useful: apply stronger evidence, independence, test depth, and configuration control to claims whose failure could create greater impact or whose attack feasibility demands greater confidence.

Confidence: how strong is the evidence?

A binary supported/unsupported status is often too crude. Two claims may both have evidence, but one is backed by an independent laboratory test on the production baseline while the other relies on an old design review for a similar variant.

An assurance-confidence model can consider:

• Relevance: Does the evidence directly address the claim?
• Scope: Does it cover the actual product, variant, and configuration?
• Rigor: Was the method appropriate to the attacker and risk?
• Independence: Was the evidence generated or reviewed independently where needed?
• Freshness: Is it still valid after changes and new vulnerabilities?
• Integrity: Can the evidence and provenance be trusted?
• Completeness: Are significant conditions or attack paths missing?
• Repeatability: Can the result be reproduced or independently inspected?

Confidence should not become an arbitrary score that hides engineering judgment. Use clear criteria and link every rating to the underlying evidence and limitations.

Treat changes as assurance-impact events

Static assurance cases decay quickly in software-defined vehicles. A change can invalidate only one branch of the argument or undermine the entire top-level claim.

Events that should trigger impact analysis include:

• Architecture, interface, or trust-boundary changes.
• Hardware or software version changes.
• New supplier or sub-supplier components.
• Security-control configuration changes.
• Failed or expired test evidence.
• New vulnerabilities or threat intelligence.
• Changed assumptions of use.
• New operational environments or vehicle variants.
• Incidents, anomalous field behavior, or recall findings.
• End-of-support or unavailable remediation.

The assurance model should identify which claims depend on the changed entity. A new vulnerability in a cryptographic library should lead to the affected components, ECUs, controls, tests, deployed variants, supplier claims, and top-level arguments. Teams can then review the impacted branch rather than reopening the entire case manually.

This is the difference between a living assurance case and a report generated at a milestone.

Design evidence acceptance criteria

Evidence should pass defined quality gates before it can support a claim. A reusable acceptance checklist can require:

• Unique evidence identifier.
• Product and configuration scope.
• Source organization and responsible owner.
• Method, tool, and environment.
• Date and validity period.
• Expected and observed result.
• Raw artifact or protected source reference.
• Review and approval status.
• Linked requirement, control, threat, risk, or claim.
• Limitations and deviations.
• Integrity or signature information where appropriate.

Supplier contracts should specify these fields and the exchange format. “Provide a penetration-test report” is not enough. The agreement should state the target baseline, coverage expectations, severity handling, evidence retention, remediation workflow, and what must be updated after a change.

Common assurance-case failure modes

The document dump

Hundreds of files are delivered without a navigable argument. Reviewers reconstruct the reasoning themselves, increasing cost and inconsistency.

Circular reasoning

A claim is supported by a requirement, and the requirement is considered satisfied because it exists. The case must include implementation and verification evidence, not only specification.

Certification overreach

A component certificate is treated as proof that the complete ECU or vehicle is secure. Integration assumptions and cross-component behavior are ignored.

Uncontrolled reuse

Evidence from another program is copied without proving that architecture, configuration, threat context, and assumptions are equivalent.

Stale evidence

The test passed two releases ago, but the claim still appears green after relevant changes.

Invisible assumptions

The argument depends on secure provisioning, backend controls, workshop policy, or operator behavior that is not represented in the case.

Evidence without negative testing

Only expected behavior is tested. The case lacks proof that unauthorized, malformed, replayed, expired, or out-of-sequence actions are rejected safely.

No owner for the top-level claim

Individual teams own artifacts, but nobody is accountable for deciding whether the combined argument is adequate.

A practical 12-week implementation roadmap

Weeks 1-2: Select one decision and one item

Choose a real program gate, release, or supplier acceptance decision. Define scope, audience, baseline, and top-level claim.

Weeks 3-4: Build the claim architecture

Decompose the top-level claim into strategies and sub-claims. Record assumptions, contexts, and residual-risk decisions.

Weeks 5-6: Map existing evidence

Link current TARA, requirements, controls, tests, SBOM, supplier, release, and operational artifacts. Classify each claim as supported, partial, unsupported, stale, or not applicable.

Weeks 7-8: Close critical evidence gaps

Prioritize unsupported high-impact claims, invalid assumptions, missing integration evidence, and old test results. Do not try to perfect every low-risk branch first.

Weeks 9-10: Create the supplier sub-case pattern

Define a standard package for one component supplier, including properties, evidence, assumptions of use, version scope, and change obligations. Test whether the Tier-1 or OEM can compose it without exposing unnecessary intellectual property.

Weeks 11-12: Run an independent review

Ask a reviewer who did not build the case to navigate from the top-level claim to evidence and back. Record questions, missing links, ambiguous reasoning, and time to answer. Baseline the case and define update triggers.

The pilot succeeds when a decision-maker can understand why the claim is supported, where confidence is weak, and what would invalidate the conclusion.

Metrics for assurance-case quality

Useful metrics include:

• Percentage of top-level and critical sub-claims with accepted evidence.
• Number of claims supported only by indirect or stale evidence.
• Percentage of evidence linked to an exact configuration baseline.
• Number of unverified assumptions of use.
• Time required to trace a claim to its evidence.
• Time required to identify claims affected by a change or CVE.
• Percentage of supplier sub-cases that meet the standard acceptance schema.
• Reuse rate of valid component sub-cases across programs.
• Number of residual risks without a named decision owner or review date.
• Average age of evidence supporting high-criticality claims.
• Review questions that require manual searches outside the case.
• Percentage of failed tests or incidents that automatically reopen affected claims.

The goal is not to maximize the number of claims. It is to make the reasoning complete, inspectable, current, and proportionate to risk.

How ThreatZ can support a living assurance case

An assurance case is naturally a connected-data problem. Claims depend on risks; risks depend on assets, threats, attack paths, and assumptions; controls implement requirements; tests verify controls; supplier evidence supports component properties; releases define configuration; vulnerabilities and incidents can invalidate prior conclusions.

ThreatZ can represent these relationships in a cybersecurity knowledge graph so the case is generated from current engineering and operational evidence rather than copied into a separate document. Teams can identify unsupported claims, reuse supplier sub-cases, trace evidence in both directions, and see which argument branches are affected by a change.

A strong pilot is one ECU or platform with a clear sourcing or release decision. Build the top-level claim, import existing evidence, expose the unsupported branches, and prove that a supplier or component change can be traced to the exact claims requiring review.

Frequently asked questions

What is the difference between a cybersecurity case and an assurance case?

The terms are often used interchangeably. “Assurance case” emphasizes an explicit claims-arguments-evidence structure. A cybersecurity case that contains only a collection of work products may satisfy a documentation convention but provides weaker reasoning than a structured assurance case.

Does ISO/SAE 21434 require a cybersecurity case?

ISO/SAE 21434 includes the cybersecurity case as a lifecycle work product. The practical quality question is whether the case presents a structured argument supported by current evidence or merely bundles documents.

Can a supplier certificate replace OEM vehicle-level evidence?

No. A certificate can support defined component claims, but the integrator must demonstrate correct configuration, assumptions of use, surrounding controls, version identity, and vehicle-level behavior.

What is a modular assurance case?

It is an assurance case assembled from reusable sub-cases with explicit interfaces and assumptions. A Tier-2 component case can support a Tier-1 system case, which can then support an OEM vehicle case.

How often should the assurance case be updated?

Update it whenever an event can change a claim, assumption, evidence validity, or residual risk. Relevant events include architecture changes, releases, supplier changes, new vulnerabilities, failed tests, incidents, and changed operating conditions.

What is the best first use case?

Choose a product decision with fragmented but available evidence, such as accepting a security-critical component or approving an ECU release. The value becomes visible when the team can move from a top-level claim to exact, versioned evidence without reconstructing the argument in meetings.

Related reading on VxLabs

• ThreatZ Governance
• ISO/SAE 21434 TARA guide
• cybersecurity goals vs requirements

Authoritative references

• ISO/SAE 21434:2021 - Road vehicles - Cybersecurity engineering
• ISO/PAS 5112:2022 - Guidelines for auditing automotive cybersecurity engineering
• Automotive ISAC - Constructive Cybersecurity Assurance Cases
• GlobalPlatform SESIP methodology and resources
• GlobalPlatform - Cybersecurity Vehicle Forum 2026