OEM CSMS for ISO 21434, UNECE R155 & GB 44495 — the operating system your vehicle program runs on
Eight workflows — Design, Governance, TARA, SBOM, Testing, Compliance, Collaboration, Operations — on one knowledge graph. Your suppliers execute your CSMS process on your tenant. Type approval months ahead of schedule; CVE-to-V‑SOC (Vehicle Security Operations Centre) in under four hours. Private cloud or air-gapped on-premise.
Type approval in three regions. Evidence in five formats. No end-to-end traceability.
Three regions, three timelines
UNECE R155 type approval, GB 44495 for the China market (mandatory now), EU CRA full conformity assessment landing December 2027. Same evidence, three regulator formats, three audit cadences.
Five evidence formats, no chain
TARA in Word, risk register in Excel, SBOMs from forty suppliers in CycloneDX exports, residual-risk acceptance in a SharePoint folder, controls in a wiki page nobody updates after the audit closes.
Two weeks per Zero Day
A CVE drops Tuesday. UNECE R155 §7.3 demands a disclosure assessment. By Friday: emails to 200 suppliers, manual SBOM joins, attack paths reconstructed from memory. Two weeks later, you have a partial answer for one region.
Five pillars. One cybersecurity operating system.
Each pillar pairs the position with what delivers it in the product. Outcomes vary by program scope.
Operating system, not tool
Eight marketing workflows — Design, Governance, TARA, SBOM, Testing, Compliance, Collaboration, Operations — on one knowledge graph. One tenant, one model, one identity surface. Versus the typical OEM stack of five disconnected vendors plus the integration tax that exceeds licence cost.
Architecture-centric
Import your system model once. ARXML (network plane) and MATLAB System Composer + Simulink (function + behavior plane) ingest as orthogonal sources joined at the asset graph. TARA, SBOM, test coverage and compliance reporting all derive from the same model.
Federated supplier execution
Your suppliers don't just receive your templates. They receive a workspace inside your tenant, scoped by RBAC at org / project / entity. Your methodology, your review cadence, your evidence schema — live status, not quarterly PDFs.
CVE response under four hours
First-cycle programs report ~14 days collapsing to under 4 hours: PURL / CPE / SHA-256 match against SBOM, component-to-ECU-to-variant binding, risk re-score, and R155 §7.3 + GB 44495 disclosure packages drafted for cybersecurity sign-off. Outcomes vary by supplier mix.
Sovereignty by deployment
Private cloud or air-gapped on-premise. Customer-owned data plane. China-resident deployment for GB 44495. Air-gapped option for defence-loaded programs. SAML / OIDC / LDAP / AD for identity. Audit-log export to your SIEM. See /security/.
AI that traces, doesn't generate
The AI Recommender doesn't generate a TARA opinion. It traces relationships in your knowledge graph — CVE to component to ECU to variant to threat scenario to control to test. AI accelerates. Humans approve. Every claim has a graph link the auditor can follow.
Bring your current evidence flow to a 30-min map
No slides. We walk your architecture and show where the chain breaks for the assessor.
“ThreatZ eliminated the duplication and gave us confidence that both documentation sets were consistent and complete. We achieved European type approval months ahead of schedule.”
Named references under NDA after the scoping call. Outcomes vary by program scope, supplier mix, and existing toolchain.
CVE to V‑SOC. From 14 days to under 4 hours.
A new vulnerability drops. Walk the chain. Every node is an actual module; every edge is an actual graph relationship.
Ingest
CVE published in NVD or a configured vuln feed.
SBOM match
PURL, CPE, SHA-256 / MD5 match across supplier-delivered CycloneDX + SPDX.
Binding
Component → ECU → variant → release baseline, via Architecture Mapping Studio.
Re-score
Feasibility (5 ISO 21434 factors) × Impact (Safety / Financial / Operational / Privacy) → CAL (Cybersecurity Assurance Level) re-check.
AI trace
Recommender surfaces affected threat scenarios & attack paths from the knowledge graph — humans approve.
Decide
Mitigate / accept / disclose — recorded with role & timestamp under your Policy Manager rules.
Publish
R155 §7.3 + GB 44495 disclosure packages drafted per region for cybersecurity sign-off.
Your suppliers execute your process. On your platform. Federated to your tenant.
How it works
A Tier-1 is invited via the Supplier Manager persona. RBAC scopes them to one project (or one entity inside it). Your methodology, TARA templates, Risk Treatment policy, and Security Catalog of controls are pre-loaded.
What they deliver
CycloneDX or SPDX SBOM ingested directly. Threat scenarios in your STRIDE + automotive taxonomy. Attack paths scored against the 5 ISO 21434 feasibility factors you mandated. Tests linked to your requirements and controls.
What you see
Live status across every supplier and every program. The R155 type approval evidence packet auto-assembles from supplier-delivered evidence as it lands — with the lineage the assessor needs, ready for cybersecurity sign-off.
One tenant, scoped sub-workspaces, one auditable graph
Suppliers don't email PDFs — they receive a workspace inside your tenant, RBAC-scoped to their entity. Your methodology, your templates, your review cadence. Live status. Audit evidence auto-assembles in one graph.
From asset to incident. Every clause linked.
The chain the assessor walks. Every node is a real module in the product, not a slide-ware label.
Asset (Design module) → Damage Scenario → Threat Scenario (STRIDE + CAN Bus / ECU / OTA / Sensor / V2X) → Attack Path → Feasibility (Elapsed Time 0–19, Expertise 0–8, Knowledge 0–11, Window 0–10, Equipment 0–9) → CAL 1–4 (Cybersecurity Assurance Level) → Impact (Safety S0–S3 / Financial F0–F3 / Operational O0–O3 / Privacy P0–P3) → Risk → Goal (§9) → Requirement (§10) → Control (§11, from Security Catalog) → Claim → Test (Testing module: PenTest, VulnScan, SAST, Config Review, Functional Security) → Verification (§12) / Validation (§13) → Work Product (Compliance, auto-generated) → Field Monitoring (R155 Annex 5) → Incident → loop back to Risk.
Every → is a queryable edge. The chain isn't a diagram on a slide — it's the data model.
Internal CSMS portal? Keep it.
APIs first, UI optional
REST and GraphQL APIs expose every entity in the graph. SAML / OIDC SSO federation against your IdP. Audit-log export to your SIEM. Git Sync for documentation versioning. RBAC at org / project / entity.
On-premise or air-gapped
Customer-owned data plane. China-resident deployment for GB 44495. Air-gapped option for defence-loaded programs. Your portal stays the user-facing surface; ThreatZ owns the model behind it.
Federate your supplier base on your own tenant
30-min walkthrough — we scope it against your supplier mix and identity provider.
Six questions your R155 assessor will ask
| Assessor question | Current setup answer | ThreatZ answer |
|---|---|---|
| Cybersecurity case for variant X, build Y, date Z (§6.4.9) | Senior engineer reconstructs from Git history, SharePoint, and three TARA spreadsheets. 5–10 days. | Variant + release baseline scoping: weakness trees unique per project/variant/release. Time-travel query against the graph. Minutes. |
| Walk me through one §15 chain end-to-end | The chain exists across four tools and one shared drive. Reconstruction = email thread + screenshots. | Asset → Damage → Threat → Attack Path → Feasibility → CAL → Risk → Goal → Requirement → Control → Claim → Test → Verification. Click any node. |
| How is each supplier's CIA (Cybersecurity Interface Agreement) / DIA (Data Interface Agreement) rolled into the OEM case? | Suppliers email signed PDFs. OEM cybersecurity engineer manually maps to the OEM case. Quarterly. | Supplier executes in your tenant. CIA / DIA artefacts live as graph objects, bound to components, version-controlled, signed. |
| Residual-risk acceptance record: who, what role, when? | Email approval, sometimes a PDF signature, often missing for risks accepted three years ago. | Policy Manager defines who can accept which risk class. Acceptance is a typed event in the graph: role, identity, justification, timestamp. Immutable. |
| R155 Annex 5 monitoring evidence, past 12 months, with dispositions | Pulled together from ticketing, V-SOC notes, and CVE response emails. Coverage gaps are common. | Operations workflow links incidents to component, severity, MTTR (Mean Time To Resolution), disposition; feeds back into the risk model. |
| Project the cybersecurity case into the GB 44495 package format for China homologation | Six weeks of consulting to reformat into the Chinese regulatory schema. Whole-team task. | One model, many projections. GB 44495 templates ship with the platform; the package renders from the same graph that fed your R155 file. China-resident deployment supported. |
What ThreatZ is not
Six categories ThreatZ deliberately doesn't live in. We'd rather be precise than be everything.
Not a replacement for Enterprise Architect
ThreatZ imports software architecture from EA. We don't try to be UML modelling. Architecture Mapping Studio is the bridge.
Not an SBOM scanner
ThreatZ consumes CycloneDX and SPDX. The vulns-scanner service matches components to feeds; we don't generate the bill itself.
Not exploit generation
Defensive cybersecurity engineering data, not red-team automation. No PoC pipelines, no offensive tooling.
Not a CI/CD pipeline
Integrates via Git Sync, Codebeamer, DOORS — doesn't run your build. ALM (Application Lifecycle Management) and pipeline tools stay where they are.
Not a mandatory user-facing portal
Can run behind your internal portal as the model layer. APIs first; UI optional.
Not multi-tenant for your vehicle data
Private cloud or on-premise — air-gapped supported. Customer-owned data plane. Procurement-friendly for sovereignty-sensitive programs.
What OEM cybersecurity leadership tells us
“ThreatZ replaced four separate spreadsheets and a Jira board. The architecture-mapping piece — auto-suggesting bindings from our EA model — saved weeks per program.”
“ThreatZ eliminated the duplication and gave us confidence both documentation sets were consistent and complete. We achieved European type approval months ahead of schedule.”
Named references under NDA after the scoping call. Outcomes vary by program scope, supplier mix, and existing toolchain.
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.
Keep exploring
The ThreatZ platform
Eight workflows in product depth — modules, knowledge graph, AI Recommender, Architecture Mapping Studio.
Build vs current setup
The honest comparison: Excel + SharePoint + Jira vs. a knowledge-graph CSMS. Where the current setup breaks before audit.
TARA pilot — 6–8 weeks
One vehicle program. One supplier slice. End-to-end traceable chain proven before any platform commitment.
Integrations
ARXML, MATLAB System Composer, Simulink, CycloneDX, SPDX, Enterprise Architect, Codebeamer, DOORS, Git Sync, SAML / OIDC.
Sovereignty & on-prem
Private cloud, on-premise, air-gapped. SAML / OIDC SSO. SIEM export. Encryption posture. Data residency.
Vendor maturity
Who VxLabs is, how the platform is built, the team behind it. For the procurement file.
Map your CSMS evidence flow — 30 min.
Type approval is binary. GB 44495 is mandatory now. The EU CRA full conformity assessment lands December 2027 (reporting obligations from September 2026). Bring one program. We trace your current evidence flow end-to-end on a whiteboard, show exactly which links are missing for the assessor, and quote what a federated tenant looks like for your supplier set.