Tier-1 Automotive Cybersecurity for ISO 21434 — one case, ~80% reuse on the second program
You already run BMW's Word template, Stellantis's custom XML, and Volvo's quarterly portal review — against the same ECU family. ThreatZ stores the work as a knowledge graph and projects it into each OEM customer's template, methodology, and cadence. Same engineering team. Mostly already done. Private cloud or on-premise.
You're not running one cybersecurity program. You're running four in parallel.
Four OEMs, four programs
BMW sends a Word template. Stellantis sends custom XML against their supplier-portal schema. Volvo runs quarterly cybersecurity reviews inside their portal — their cadence, their reviewer set, their definition of "residual risk acceptable". And that's one ECU family across three customers.
Six tools, one CFO question
TARA + SBOM + GRC + test management + collaboration + the integration vendor who makes them talk. €300k–€1.5M/year in licences; integration cost often exceeds licence cost. Reported by Tier-1 cybersecurity teams in our scoping engagements.
TARA at zero, every program
Word + SharePoint don't carry forward. TARA at program N+1 starts at 0% even though you ship the same ECU family. Senior engineers retire with the institutional knowledge. 60–70% of cybersecurity engineering time goes to redoing existing work — reported across Tier-1 engagements.
The consolidation that compounds across programs
Not five disconnected tools with a dashboard on top. One knowledge graph, six work-streams unified on it, federated outward to your OEM customers.
Six tools → one platform
TARA, SBOM, Testing, GRC, Collaboration, and the integration vendor consolidated into one platform on one knowledge graph. Six contracts, six renewals, six vendor relationships become one. Eight workflows on one tenant: Design, Governance, TARA, SBOM, Testing, Compliance, Collaboration, Operations.
Reuse, by design
Your TARA isn't a Word doc — it's a sub-graph: assets, damage scenarios, threat scenarios, attack paths with the 5 ISO 21434 feasibility factors, CAL 1–4, controls, claims, tests. Clone the sub-graph for a new program. Re-bind to the variant. Delta-analyze the difference. ~80% carries forward on the second program; outcomes vary by ECU-family overlap.
OEM process on your platform
Your OEM customer authors their templates, methodology, and review cadence in their tenant. ThreatZ replicates that workflow into your supplier workspace. You execute against their methodology in your environment; they see live status without standing up yet another portal for you. Federated — not exported.
Engineering hours, not redoing hours
Cybersecurity hours go into the new variant's actual delta: the new MCU, the new external interface, the new functional behavior. Not retyping last program's residual-risk acceptance into a different Word table. We do TARA when a new program kicks off, a new variant launches, or a new OEM joins — and the platform delta-analyzes the difference.
Margin protection
Cybersecurity is among the largest cost lines in software-loaded ECU programs. You can't pass it through to the OEM — they fixed your price two years before the variant ships. Every program after the first costs a fraction of what competitors still pay because their TARA still starts at zero.
Private cloud or on-premise
OEM source code, OEM-licenced network signal definitions, OEM-confidential CAL ratings on prototype ECUs — that data doesn't belong in a multi-tenant cloud. ThreatZ runs in your private cloud or on-premise. Air-gapped supported. Your data plane, your identity provider, your audit log.
Bring one real OEM template to the call
We walk your ECU through the chain. You'll see whether the ~80% figure holds for your portfolio.
“Three OEM customers, three different TARA templates, one ECU family. ThreatZ projects the work product into each customer's format without my team retyping anything. The reuse argument was the CFO conversation; the federation argument was the procurement conversation.”
Named references under NDA after the scoping call. Outcomes vary by starting CSMS maturity, tool-integration scope, and OEM-customer template overlap.
One cybersecurity case. Many programs. Many OEM templates.
Four steps once the graph exists.
Author at product-line level
One ADAS controller family, one BMS family, one gateway family. Architecture in the Design workflow, threats via STRIDE + automotive categories, CAL 1–4 from the 5 feasibility factors, controls from the org Security Catalog. Once.
Variant + release baseline scoping
Weakness tree unique per project, variant, and release baseline. Same ADAS controller with L2 stack for Customer A and L2+ stack for Customer B — ThreatZ scopes the variant, doesn't fork the document. Drift detection within ~1 hour.
Project per OEM template
The Compliance workflow auto-generates §9 Goals, §10 Requirements, §11 Controls, §12 Verification, §13 Validation, §15 TARA into each OEM customer's required template — PDF, Word, HTML. Authored once, projected into N customer formats.
Clone & re-bind for next program
Next ECU variant, next program win, next OEM joining. Clone the sub-graph; re-bind to the new variant; the platform shows you the delta — new interfaces, new threat scenarios, retired controls. Engineering hours on the delta only.
Your OEM customer's process, running on your platform
OEMs spend years building internal CSMS programs — templates, methodologies, review cadences, supplier-management workflows, type-approval evidence flows. None of that goes away because a Tier-1 picked a new platform.
ThreatZ inverts the usual flow. The OEM authors their process in their tenant — their TARA template, their methodology, their cadence, their definition of "treatment defined" vs "mitigated". ThreatZ replicates that workflow into your supplier workspace as a scoped sub-process. You execute against their methodology, with their fields, in your environment. They see live status without your team logging into yet another portal.
RBAC enforces at organisation, project, and entity level: Customer A's project leads see only Customer A's scoped sub-process; Customer B never knows Customer A exists. SAML / OIDC SSO so your engineers don't carry another password. REST and GraphQL APIs so the OEM's internal portal can pull live status without screen-scraping.
This is also why the same platform appears on the OEM CSMS Teams page — ThreatZ is the platform on both ends of the federation. The OEM page describes authoring; this page describes execution.
MATLAB function plane and ARXML network plane — orthogonal, joined at the TARA graph
ARXML never carries functional decomposition or behavior. MATLAB never carries network signals. They are orthogonal ingest planes — not substitutes. ThreatZ joins them at the asset and TARA graph layer, so the damage scenario, the threat scenario, and the attack feasibility all reference the same underlying ECU model.
One chain, authored once, projected into every OEM template
Asset (Design workflow) → Damage Scenario (4 impact dimensions S / F / O / P) → Threat Scenario (TARA workflow: STRIDE + automotive categories) → Attack Path → Feasibility (5 ISO 21434 factors: Elapsed Time, Expertise, Knowledge, Window, Equipment) → CAL 1–4 (Cybersecurity Assurance Level) → Impact (S0–S3 / F0–F3 / O0–O3 / P0–P3) → Risk (Impact × Likelihood) → Cybersecurity Goal (§9) → Requirement (§10, DOORS / Codebeamer bidirectional) → Control (§11, Security Catalog) → Claim → Test (Testing workflow: PenTest, VulnScan, SAST, Config Review, Functional Security) → Verification (§12) / Validation (§13) → Work Product (Compliance workflow, auto-generated per OEM template) → Field Monitoring (Operations workflow, R155 Annex 5) → Incident → (loop back to Threat Scenario).
Authored once. The Compliance workflow projects the relevant work products into each OEM customer's required template. Open-format export at every node: ReqIF, ARXML, CycloneDX, SPDX, CSV. The AI Recommender (keyed to the project knowledge graph, not a generic LLM) suggests damage and threat scenarios — humans approve.
Get a federation walkthrough for your OEM customer mix
30-min session. We scope against the actual OEM templates your portfolio carries.
Six questions your OEM customer will ask at the next gate
OEM-supplier-audit questions, not regulator-side ones. The ones you've answered manually for years.
| OEM customer question | Current setup answer | ThreatZ answer |
|---|---|---|
| Cybersecurity case for ECU variant X, build Y, date Z | Pull TARA Word doc from SharePoint, cross-reference build number against Jira release notes, hunt the matching SBOM in the scanner. 3–5 days, two senior engineers. | Variant + release baseline scoping returns the chain for that exact build — assets, threats, risks, controls, tests, work products — one query. Minutes. |
| Full damage → risk → control chain for this ECU's most critical CAL-3 threat | The damage scenario is in column F of the TARA spreadsheet; the control is named differently in the Jira ticket; the test is named differently again on the HIL (Hardware-in-the-Loop) bench. | Click the threat node. The graph returns the path: Damage → Risk → Goal → Requirement → Control → Claim → Test → Verification. With node-level evidence links. |
| How does your supplier-side TARA feed our OEM-level TARA — and where does the CIA / DIA flow? | The CIA (Cybersecurity Interface Agreement) is a PDF; the DIA (Data Interface Agreement) is an annex; supplier-side TARA results are mailed up as a separate Word doc. Reconciliation lives in the program manager's head. | Federated workflow projects your supplier-side TARA into the OEM's TARA graph at the agreed interface. CIA / DIA scope is a graph relationship, not a PDF. |
| Who accepted this residual risk — date, criteria, authority? | Find the email. Or the meeting minutes. Or the signed PDF. Hope the role is named clearly. Hope the criteria document hasn't been versioned since. | Risk acceptance is a typed graph entity with role, timestamp, criteria version (Policy Manager), and signing authority. Audit log immutable. Exportable. |
| For CVE-YYYY-NNNNN, which ECU variants in which production builds — across all our programs? | SBOM scanner says component X is affected. Cross-reference by hand against deployment spreadsheet, per program. 1–2 weeks per Zero Day, per OEM asking. | CycloneDX / SPDX components are graph nodes linked to system-model components linked to ECU variants linked to release baselines. One query returns every affected ECU and build dates. Hours; outcomes vary by SBOM coverage. |
| R155 Annex 5 monitoring evidence for ECUs already in production | Threat-intel feed in one tool, incident tickets in another, field-data analysis in a third — no closed loop back to the original TARA assumptions. | Operations workflow ingests threat intel and feeds incidents back into the risk model. MTTR (Mean Time To Resolution) tracked per severity. The loop is closed in-product. |
Keep it. Run ThreatZ behind it.
APIs first, UI optional
REST + GraphQL APIs expose every entity in the graph. SAML / OIDC SSO delegates identity to your existing IdP. Audit-log export for your SIEM. Git Sync versions documentation alongside your code branches.
On-premise or private cloud
Customer-owned data plane. Air-gapped supported. Procurement-friendly for sovereignty-sensitive programs. Your portal stays the user-facing surface; ThreatZ owns the model behind it.
What ThreatZ is not
Not a replacement for Enterprise Architect
We import from EA via Architecture Mapping Studio. We don't try to be UML modelling.
Not an SBOM scanner
We consume CycloneDX and SPDX from your scanner of choice. The vulns-scanner service matches components against feeds; it doesn't generate the SBOM.
Not exploit generation
No automated PoC pipelines, no offensive tooling. Defensive cybersecurity engineering data, not red-team operational tooling.
Not a CI/CD pipeline
Integrates via Git Sync, Codebeamer, DOORS. ALM (Application Lifecycle Management) and pipeline tools stay where they are.
Not a mandatory user-facing portal
Can run behind your internal CSMS portal as the model layer. APIs first; UI optional.
Not multi-tenant for your vehicle data
Private cloud or on-premise — air-gapped supported. Procurement-friendly for sovereignty-sensitive programs and China deployments.
From teams running the parallel-OEM problem
“The CVE-to-ECU question used to take a week and three people. The graph answers it directly — which variants in which build dates ship the affected component, across every program. The OEM customer notices.”
“Our internal CSMS portal didn't move. ThreatZ sits behind it. The audit response time dropped because the model behind the portal finally exists.”
Named references under NDA after the scoping call. First-cycle numbers reflect the program in which ThreatZ was first deployed; reuse compounds from the second program onward.
The connected CSMS knowledge graph — not slides
Eight workflows on one platform: Design, Governance, TARA, SBOM, Testing, Compliance, Collaboration, Operations. The product is real. The graph is queryable. Every claim has a graph link the auditor can follow.
Live status across every project, every variant, every supplier — on your tenant. Bring your architecture to a 30-min mapping call and we walk it together.
Show me the reuse math — 30 minutes.
Each OEM template you maintain by hand is roughly two engineer-weeks per release. Multiply by your OEM customer count, multiply by your release cadence, multiply by your fully-loaded senior-engineer rate. Pick your number. Bring one real OEM template to the call. We walk the chain against your ECU and you'll see whether the ~80% figure holds for your portfolio.