Tier-1 CSMS without restarting TARA every program
One CSMS case, every OEM program. ~80% of the cybersecurity case carries forward to program two — projected into each customer's required evidence format. ThreatZ runs in your private cloud or on-premise; air-gapped supported.
One ECU family, one OEM template, the rest of your stack untouched.
In plain terms: ThreatZ helps you stop rebuilding the same cybersecurity case for every OEM customer. Model once, reuse across variants, and project the evidence each OEM expects — without restarting from Word, Excel, and SharePoint.
Author once. Project into every OEM customer's required template.
What changes when the CSMS chain compounds across programs
Four operational outcomes Tier-1 product cybersecurity teams report from program two onward — once the master cybersecurity case exists in the graph.
You are not running one cybersecurity process. You are running every OEM's process in parallel.
Four OEM customers means four templates, four methodologies, four review cadences — against one ECU family. TARA in Word, SBOM in a scanner, controls in a wiki nobody updates after the program ships. When the next OEM asks for the same chain in a new format, the team starts again.
Four OEMs, four programs
BMW has one evidence structure. Stellantis has another schema. Volvo has its own review cadence. Each OEM expects evidence in its own format, even when the underlying ECU family is similar.
Six tools, one CFO question
TARA + SBOM + GRC + test management + collaboration + the integration vendor who makes them talk. €300k–€1.5M/year in licenses; integration cost often exceeds license 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 — from Uraeus scoping engagements; outcomes vary by program portfolio complexity.
One ECU family, four customers — and four different ways to prove the same cybersecurity case. The cost lands on engineering margin.
The risk is not missing documents. The risk is rebuilding the same TARA for every customer.
The next OEM wins the bid, the next variant launches, the next platform refresh lands. Without a graph that remembers the prior work, every program starts at zero — and Tier-1 margin pays for the rework.
| Step | Current setup — manual rebuild | ThreatZ — one connected model |
|---|---|---|
| Program kick-off | Open last program’s TARA Word doc; copy-paste; rename. Senior engineer reconstructs context from memory. | Clone the product-line sub-graph; re-bind to the new variant; the platform surfaces the delta. |
| OEM customer template | Reformat for the new customer schema by hand. Re-enter the same controls in the new field structure. | The Compliance workflow projects §8–§15 work products into each customer template — PDF, Word, HTML. |
| SBOM & vulnerability sync | Re-export CycloneDX; re-map components per program; chase Tier-2 suppliers for updates. | Components bound to the ECU graph once. Tier-2 deltas propagate to every program that ships the component. |
| Margin impact, program N+1 | ~60–70% of cybersecurity hours on rework. Cost cannot pass to the OEM — price was fixed two years ago. | Hours land on the actual delta. Reusable work compounds. Margin protected as variant cadence accelerates. |
ThreatZ turns cybersecurity work into a reusable CSMS knowledge graph
One automotive-native CSMS backbone that connects TARA, SBOM, vulnerabilities, controls, tests, incidents, and compliance reports — instead of rebuilding work per OEM. The traceable chain runs from asset to evidence; AI-assisted review and gap detection accelerate work; engineers approve.
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 attack-potential factors (Annex G), 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-licensed 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.”
Practitioner quoted under NDA. Named references available after the scoping call.
~80% TARA reuse on program two: author once, clone, re-bind, delta-analyze
Four steps once the graph exists.
Author product-line case
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 attack-potential factors (Annex G), controls from the org Security Catalog. Once.
Scope variant / release
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 into OEM template
The Compliance workflow auto-generates §8 TARA, §9 Concept, §10 Product Development, §11 Validation, §12 Production, §13 Operations, §15 Distributed Activities into each OEM customer's required template — PDF, Word, HTML. Authored once, projected into N customer formats.
Clone and 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.
| Scenario | TARA reuse |
|---|---|
| Same OEM, same ECU family | ~70–80% |
| New OEM, same ECU family | ~50–60% (methodology delta erodes reuse) |
| Same OEM, new ECU family | ~25–35% (security catalog reuse) |
| New OEM, new ECU family | ~15–25% |
Execute their process. On your platform. Without another disconnected portal.
OEMs spend years building CSMS programs — templates, methodologies, review cadences, evidence flows. None of that goes away because you picked a new platform. ThreatZ replicates their workflow into your supplier workspace as a scoped sub-process. Live status, not quarterly PDFs.
How it works
OEM authors templates, methodology, review cadence, and evidence schema in their tenant. ThreatZ replicates that workflow into your scoped sub-workspace. RBAC enforces at organization, project, and entity level — Customer A never sees Customer B exists.
What you execute
Your engineers work against the OEM's methodology, with their fields, in your environment. SAML / OIDC SSO so nobody carries another password. Tier-2 supplier deltas propagate up the same chain — one graph, end-to-end.
What the OEM sees
Live status — not a quarterly PDF reconciliation. REST and GraphQL APIs so their internal portal pulls real-time without screen-scraping. The OEM page describes authoring; this page describes execution — same platform on both ends of the federation.
Federation runs both directions. OEM customers project their methodology down into your Tier-1 workspace; your Tier-2 suppliers project their deltas up into yours. One graph — the CVE-to-vehicle chain collapses to hours, not weeks.
CIA / DIA: a graph relationship, not a PDF
The Cybersecurity Interface Agreement (CIA) and Development Interface Agreement (DIA) are the central §15 deliverable that the OEM audit will ask for. In ThreatZ, the CIA / DIA scope is a graph relationship between OEM and supplier entities, not a PDF you re-author every program. Active Tier-2 collaboration for software / middleware partners; passive CycloneDX + VEX ingestion for silicon vendors (NXP, Infineon, ST, Renesas) who deliver via their own PSIRT cadence.
Same platform appears on the OEM CSMS Teams page. The OEM page describes authoring; this page describes execution.
Keep the tools that work. Connect the CSMS logic behind them.
ThreatZ is not a rip-and-replace platform. Enterprise Architect, ARXML, MATLAB/System Composer, DOORS, Codebeamer, Jira, SBOM scanners, test tools, V-SOC/SIEM, SharePoint, and GRC can stay. ThreatZ provides the connected cybersecurity model and reporting layer above them.
Top: your portals stay. Middle: federation primitives. Bottom: the CSMS graph that ties asset to evidence — surrounded by the engineering tools that already feed it.
Top layer — your portals & dashboards
Internal CSMS portal, GRC stack, OEM customer review dashboards stay where they are.
Federation layer
REST + GraphQL APIs; SAML / OIDC SSO; LDAP / AD identity; Git Sync; audit-log export to your SIEM.
ThreatZ CSMS graph
The connected model behind the portal. Surrounding connectors: EA, ARXML, MATLAB, DOORS, Codebeamer, Jira, SBOM scanners, V-SOC/SIEM, test tools. Full integration list →
MATLAB function plane and ARXML network plane — orthogonal, joined at the TARA graph
ThreatZ understands engineering data, not only compliance documents. For technical stakeholders: MATLAB/System Composer and ARXML/AUTOSAR are two ingest planes feeding the same asset and 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. Supported on the network plane: AUTOSAR Classic 4.2.x / 4.3.x / 4.4.x System Description + ECU Extract; AUTOSAR Adaptive SOME/IP service descriptions; DBC fallback for legacy CAN. Bus types: CAN, CAN-FD, FlexRay, Ethernet/SOME-IP, LIN.
Trace the full ISO/SAE 21434 evidence chain without asking five teams for exports
Authored once. The Compliance workflow projects the relevant work products into each OEM customer's required template — PDF, Word, HTML. Open-format export at every node: ReqIF, ARXML, CycloneDX, SPDX, CSV. Field monitoring ingests CVE intel from NVD, CISA KEV (Known Exploited Vulnerabilities), EUVD (ENISA EU Vulnerability Database), Auto-ISAC advisories, and vendor PSIRT feeds; VEX (Vulnerability Exploitability eXchange) statements consumed alongside SBOM. Disclosure flow aligned with ISO/IEC 29147 (coordinated vulnerability disclosure) and ISO/IEC 30111 (vulnerability handling processes), OEM customer’s PSIRT cadence preserved. The AI Recommender (keyed to the project knowledge graph, not a generic LLM) suggests damage and threat scenarios; humans approve. AI Recommender runs in customer tenant; no telemetry or training data egress in private-cloud / on-prem / air-gapped deployments.
Private cloud, on-premise, or air-gapped — OEM-confidential data stays inside your control
OEM source code, OEM-licensed network signal definitions, OEM-confidential CAL ratings on prototype ECUs — that data does not belong in a multi-tenant cloud. ThreatZ ships in the deployment posture your customer’s procurement file requires.
| Capability | Private Cloud | On-Premise | Air-Gapped | China-Resident |
|---|---|---|---|---|
| Identity | SAML / OIDC against your IdP | SAML / OIDC / LDAP / AD | Local LDAP / AD | SAML / OIDC, in-country IdP |
| Audit logs | Export to your SIEM | Your SIEM, your retention | On-box, exportable | In-country SIEM |
| Data plane ownership | Customer tenant | Customer infrastructure | Customer infrastructure, isolated | China-resident, customer tenant |
| OEM customer federation | Federated sub-workspaces | Federated via VPN / DMZ | Federated via offline package exchange | Federated, in-country |
| Compliance package generation | ISO/SAE 21434, R155, EU CRA | All regions | All regions, offline rendering | GB 44495, R155 projection |
For Tier-1 procurement teams with AWS commitments: ThreatZ Team and Pro tiers are available via AWS Marketplace as a procurement channel (EDP burndown eligible). Same ThreatZ, two deployment modes: AWS Marketplace for authoring and pilots, private cloud or on-premise wherever vehicle data lives. Enterprise programs remain direct.
UNECE R156 (Software Update Management System / SUMS) is the matched twin VTA to R155. ThreatZ supports R156 evidence — release-baseline binding, update-impact analysis, and OTA campaign audit trail — alongside R155 evidence projected into each OEM customer’s required format.
Air-gapped federation with OEM customers and Tier-2 suppliers via signed CycloneDX + VEX bundle exchange + tagged JSON evidence packages; manual import scheduled by site cybersecurity officer.
| Available today | Scoped per customer |
|---|---|
| TARA workflows + risk-relationship graph | Enterprise Architect integration (XMI + MDG) |
| SBOM ingestion (CycloneDX, SPDX) | MATLAB / System Composer model mapping |
| R155 + ISO/SAE 21434 + GB 44495 compliance reporting | DOORS / Codebeamer / Polarion bidirectional sync |
| Federated supplier execution + RBAC | Jira / ALM workflow sync |
| Risk + evidence linking | V-SOC / SIEM integration |
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 chain answers each one from the same graph — current setup vs. ThreatZ, side by side.
| 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. |
Focused, not fragmented
Six categories ThreatZ deliberately doesn’t live in. We trust the EA, SBOM scanner, ALM, and SIEM your engineering already runs on — ThreatZ federates with them and stores the cybersecurity model above.
Not a replacement for Enterprise Architect
We import from EA via Architecture Mapping Studio — XMI 2.4 export + MDG technology, with auto-suggested system-node bindings (brownfield projects start at 30–40% match and improve as schema profile establishes; ~80% on clean greenfield models). We don't try to be UML modeling.
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.
What Tier-1 cybersecurity leadership tells us
“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.”
Practitioners quoted under NDA. Named references available after the scoping call. Outcomes vary by program scope, supplier mix, and existing toolchain.
The graph is real. The reuse is queryable.
Eight workflows, one connected model. Click an ECU variant, see every threat, control, test, and OEM customer template downstream. Bring your portfolio and we walk the reuse chain in 30 minutes.
Program-level status per ECU variant and OEM customer, the queryable asset–threat–control–test–evidence chain, CVE–to–build-date impact, and each OEM template ready to project — one tenant. Book a Traceability Review on your tenant →
Bring one ECU program. We will show the reuse potential.
In a 30-minute session, Uraeus maps one ECU family, one OEM evidence template, and the current tool flow. The goal is to identify duplicated work and estimate where ThreatZ can reduce manual CSMS effort.
- Where your team duplicates TARA, SBOM, test, and evidence work today.
- Which parts of the cybersecurity case can be reused.
- How ThreatZ connects TARA, SBOM, testing, incidents, and compliance evidence.
- Whether the reuse case is strong enough for a focused pilot.
Illustrative numbers. We run this with you in the Traceability Review, against your portfolio.
Procurement-friendly: ThreatZ Team ($17,868/yr) and Pro ($31,680/yr) are available on AWS Marketplace — EDP / spend-commit eligible. Same ThreatZ, two deployment modes: AWS Marketplace for authoring and pilots, private cloud or on-premise wherever vehicle data lives.