Variant handling & delta analysis
Only affected scenarios flagged on change — per OEM fork.
~/solutions/tier-1-suppliers
Write the TARA once.
Ship it four times.
Clone, re-bind, delta-analyze. One process instead of one per OEM — each customer gets their format from the same graph. ~80% reuse on program two, with the delta on every fork.
Running the program instead? OEM CSMS teams · The ThreatZ platform · Pricing
- ~80%TARA reuse across OEMs
- 6→1tools consolidated
- 500+ECUs under management
- per-serialECU security profiles
Multi-OEM TARA before and after ThreatZ
// tara_final_v3_FINAL(2).xlsx
- Many tools — and a different process per OEM
- Same TARA re-typed into four OEM templates
- One interface change → re-review all 142 scenarios
- Incident response reconstructed vehicle by vehicle
- No security profile per shipped ECU serial number
// threatz.fork(master_tara)
- One graph, one process — each OEM’s format on export
- Variant handling with delta analysis: review 12 scenarios, not 142
- Security Blueprints turn your proven ECU architecture into a reusable template
- Act on incidents with per-vehicle response, traced end-to-end
- Live security profile per ECU serial number, from build to field
Straight from the tool.
// full_tour → threatz.ioPer-serial security profiles
Track every shipped ECU from build to field — respond per vehicle.
Questions Tier-1 teams ask.
// docs → threatz.ioHow does a Tier-1 supplier reuse a TARA across multiple OEM programs?
ThreatZ stores TARA work as a sub-graph: assets, damage scenarios, threat scenarios, attack paths with the 5 attack-potential factors used in the attack feasibility rating (ISO/SAE 21434 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. Roughly 80% carries forward on the second program; outcomes vary by ECU-family overlap.
How does a Tier-1 supplier project one cybersecurity case into multiple OEM templates?
Author the master cybersecurity case at product-line level. Compliance Reporting auto-generates ISO/SAE 21434 §15 TARA, §9 Concept, §10 Product Development, §11 Validation, §12 Production, §13 Operations, and §7 Distributed Activities work products into each OEM customer required template — PDF, Word, HTML. The chain is authored once and projected into N customer formats; the underlying claim is the same node in the graph.
How does OEM-process federation work for Tier-1 suppliers?
Your OEM customer authors their templates, methodology, and review cadence in their tenant. ThreatZ replicates that workflow into your supplier workspace as a scoped sub-process. You execute against their methodology in your environment; they see live status without your team logging into another portal. RBAC enforces at organization, project, and entity level.
How does ThreatZ handle CVE response across the Tier-2 supplier chain?
Federation runs downward too. Your Tier-2 suppliers operate on your tenant the same way you operate on your OEM. When a CVE drops, the chain from Tier-2 component to your ECU to your OEM vehicle program runs along one graph — the response window collapses to hours rather than 1-2 weeks per zero-day per OEM asking.
Does ThreatZ replace existing Tier-1 cybersecurity tools?
ThreatZ consolidates the typical Tier-1 cybersecurity stack — TARA + SBOM + GRC + test management + collaboration + the integration vendor — into one platform on one knowledge graph. Six contracts, six renewals, six vendor relationships become one. EUR 300k to EUR 1.5M per year in licenses plus integration cost that often exceeds license cost in scoping engagements we have seen.
Can a Tier-1 keep their existing internal CSMS portal?
Yes. ThreatZ is not a mandatory user-facing portal. A REST API and webhooks expose the graph to your own systems, and SAML 2.0 SSO delegates identity to the IdP your portal already uses. Every governance action is written to an insert-only, HMAC-chained audit log. On-premise option if data-residency requires it. Air-gapped deployment supported.