ThreatZ for truck, bus andoff-highway cybersecurity
ThreatZ runs the cybersecurity engineering of a commercial-vehicle program the same way it runs a passenger-car program: one program with many variants and markets, a project per ECU or system, TARA, SBOM and CVE matching, incident command, a supplier workspace and ISO/SAE 21434 work products. The platform is vehicle-class agnostic. What it does not do is decide which regulation applies to your category in your market: vocational and off-highway vehicles may sit outside UN R155 scope, no coverage is implied, and scope per category is confirmed per market before anyone relies on it.
1 · VEHICLE CLASSES
Vehicle classes and regulatory scope
The platform does not change by class; the obligations do. The table below is the vehicle-class matrix as signed off for this site, hedges included. Where a cell says "to be confirmed", that is the state of the claim, not a placeholder: it is confirmed with your homologation or type-approval lead, per market, before anyone relies on it.
| Class | Typical framing | What it means for the program |
|---|---|---|
| M1 passenger cars | Highest volume, shortest cycle | UN R155 / R156 in scope; largest variant and market fan-out. Listed here as the reference row the commercial classes are compared against — confirm no target market carves out M1. |
| M2 / M3 buses and coaches | Passenger-carrying, fleet-operated | Same regulatory framework as M1 — category applicability and timelines to be confirmed per market. The operator is a third party who asks questions; availability pressure is theirs and yours. |
| N1–N3 trucks, LCV to HGV | Long service life, fleet-operated | Longer support obligation — category specifics to be confirmed; telematics and remote-diagnostics exposure; downtime carries a direct revenue cost. |
| O trailers | Routinely forgotten | Addressed where fitted with at least one ECU — weight class and market to be confirmed. Easy to under-declare. |
| Vocational / off-highway | Special bodies, low volume | May sit outside R155 scope. Coverage is not implied; category and market are confirmed before reliance. |
Scope per category is confirmed per market before reliance. Nothing in this table states parity between classes, attaches an EU CRA duty to a type-approved vehicle, or says whose obligation a completed multi-stage vehicle is — those are questions the page poses in the sections below, not answers it gives. Full matrix and sign-off notes: vehicle classes on the systems-suppliers page.
2 · WORKFLOWS
Workflows that apply to commercial-vehicle programs
Six places where a truck, bus or trailer program leans on the platform harder than a passenger-car program does. Each describes what ThreatZ does today, as documented on the OEM, Tier-1, modeling, supply-chain and incident-response pages. Where the regulatory answer is open, it is written as a question.
One program, many variants and markets
A program groups the security projects that make up a vehicle program; a project is the analysis scope of one ECU or system, drawn as a boundary on the program-level architecture. Variants and customer programs are forks of a baseline: re-bind, analyse only what differs. Type approval is granted against a specific configuration, and baselines make "what exactly was approved" a retrievable state — with a four-eyes gate on the approval itself.
Long service life and the support window
An N-category vehicle stays in service longer than a car, and the signed-off matrix records a longer support obligation — category specifics to be confirmed. How long that window runs, and under which instrument, is a question we ask per market: is it a UN R156 software-update duty, and does any EU CRA support period attach to the type-approved vehicle at all, or only to separately placed digital products such as a telematics unit? This page does not answer that. What the platform does is keep the SBOM per software unit versioned per baseline, diff each re-import against the last delivery and match components against vulnerability feeds for as long as the program is kept open.
Multi-stage manufacture and body builders
A truck or bus chassis is frequently completed by a body builder or second-stage manufacturer. The cybersecurity evidence for a subsystem is therefore handed through two manufacturers before an authority reads it — and who holds the obligation for the completed vehicle is a live question we pose, not one the platform settles. What ThreatZ offers that reader is a record built to be read cold, by a party who was never in the room: a named anchor, per-row authorship, an append-only history and a declared ending, rendered per audience preset.
Telematics and remote diagnostics as exposure in the TARA
Fleet-operated vehicles carry telematics and remote-diagnostics interfaces by default, and the matrix lists that exposure against the N categories. In ThreatZ the telematics control unit is a project like any other ECU: its interfaces and signals become TARA assets, attack path analysis rates the paths reaching it, and feasibility can be rated by attack potential, CVSS or attack vector over the same paths. Nothing on this page claims a connection to a telematics backend or an ingest of fleet telemetry: the exposure is analysed here, not operated.
Supplier evidence across OEM programs
A Tier-1 supplying the same ECU family into several commercial-vehicle OEMs models it once as a Security Blueprint and clones it per customer program, analysing the delta. On the OEM side, suppliers execute inside the OEM's process: an advisory dispatches a child incident to the affected project carrying the OEM's directive and declared criteria, the supplier works it in their own project, and the program is the only gate out. Entity-level RBAC keeps one customer's work invisible to another's in the same tenant.
Fleet map: from part number to registered vehicles per market
A supplier declares the ECU part numbers it ships against a project baseline; ThreatZ matches them to the part numbers the program holds per VIN. A finding then has a trace path — software component → software unit → system component → part number — and from there to the vehicles deployed in each market. The Fleet & Risk Map shows vehicles, active CVEs and a risk band per market (US, DE, CN, JP, BR, AE; anything else grouped under Other); the Traceability Map drills a market down to its affected VINs. Both are Enterprise-tier views.
3 · WORKED EXAMPLE
A worked example: one heavy-truck program, one telematics ECU, one advisory
Illustrative — not a customerThe figures below are made up to show the shape of the chain. They are not a customer's data, and the market clocks are deliberately left as "per confirmed instrument": which regulation applies to an N3 vehicle in a given market, and on what timeline, is confirmed by the homologation lead, not assumed by this example.
| Step | What happens on the platform | Example figure (illustrative) |
|---|---|---|
| 1 · Program | One N3 heavy-truck program. Each ECU or system is a project; the telematics control unit (TCU) is one of them, supplied by a Tier-1 who works in a federated project. | 6 variants (3 cabs × 2 powertrains), 11 ECU projects, registered fleet in 2 mapped markets (DE, BR) |
| 2 · Part numbers | The Tier-1 uploads the TCU part numbers against its baseline. ThreatZ matches them, exactly and case-insensitively, to the program's part numbers per VIN. | 2 revisions: TCU rev B matched to 9,800 VINs, rev C to 5,700 VINs |
| 3 · Advisory lands | A CVE is published for a TLS library. The deterministic SBOM join finds it in the rev B software unit only; the exact join is not stretched to fit rev C. A named engineer confirms the anchor, and the confirmation is recorded with who and when. | 1 CVE, 1 software unit, rev B only |
| 4 · Affected variants and markets | From the confirmed anchor the chain runs software unit → system component → part number → VINs per market. The Fleet & Risk Map lights the two markets; the Traceability Map lists the VINs. | 4 of 6 variants; 9,800 vehicles: 7,900 in DE, 1,900 in BR |
| 5 · Clocks | Clocks are armed per regulation, per market, from the registered fleet — where an instrument applies to this category in that market. A market with no reporting instrument is recorded as having none, which is a different fact from "not applicable". | Per confirmed instrument per market — not assumed here |
| 6 · Severity | Computed from the anchored tie across four impact axes. Where the reachable set rates none of them, the record states that severity was not computed and names what was missing. | Computed for rev B; no guess entered for rev C |
| 7 · Remediation | A child incident is dispatched to the Tier-1's project carrying the program's directive and criteria. The fix is proven by a re-imported bill of materials showing the library moved to a version that clears the finding; evidence is validated fail-closed before it is stored. | 1 child incident; 1 CycloneDX re-import; 1 component changed |
| 8 · Ending | The incident closes into one of four endings declared in advance — fixed, mitigated, deferred, not applicable. Reports render per audience preset, including an authority pack, from the same append-only record. | Ending: fixed; 2 report presets rendered |
Every mechanism in this table is described on the incident-response page and the supply-chain page; only the numbers are invented. The example does not say whether the DE or BR fleet falls under a particular instrument for N3 — that is the question step 5 leaves to the homologation lead.
4 · SCOPE LIMITATIONS
Scope limitations
Read these before the walkthrough. They are the claims this page deliberately does not make.
- Off-highway and vocational vehicles may sit outside UN R155 scope. No coverage is implied. Which types are excluded, in which markets, and whether a chassis-plus-special-body split leaves partial obligations on the chassis manufacturer, are confirmed per market before reliance.
- No truck-specific protocol packs are claimed. This page does not claim a J1939, ISOBUS or other heavy-vehicle protocol library, and it does not claim a telematics or fleet-management integration. The system model is built from the imports listed on the modeling page or drawn on the canvas.
- Agricultural and construction-machinery standards are not addressed. ThreatZ maps its work products to ISO/SAE 21434, UN R155/R156, GB 44495 and, where the instrument applies, EU CRA Art. 14 reporting timelines. No mapping to agricultural or off-highway machinery standards is claimed.
- Per-category timelines are confirmed per market. M2/M3 applicability and timelines, N1–N3 category specifics and the O-trailer weight-class floor are all stated as "to be confirmed" in the signed-off matrix, and this page keeps them that way. No EU CRA duty is attached to the type-approved vehicle here.
- Type-approval authority relationships are out of scope. ThreatZ produces the record a manufacturer's evidence draws on. It is not a certification, it does not file anything with any authority, and it does not say which manufacturer in a multi-stage build holds the obligation for the completed vehicle.
5 · FAQ
Frequently asked questions
Does ThreatZ cover trucks, buses and trailers under UN R155?
ThreatZ is vehicle-class agnostic: the program, project, TARA, SBOM and incident workflows run the same way for an N3 truck as for an M1 car. Whether UN R155 or R156 applies to your category in your market, and on which timeline, is confirmed by your homologation lead per market. The platform does not decide applicability, and this page does not claim it.
Is off-highway or agricultural equipment in scope?
Vocational and off-highway vehicles may sit outside UN R155 scope, and no coverage is implied. You can still model the machine, run a TARA and track its SBOM as an engineering exercise, but ThreatZ does not map that work to agricultural or off-highway standards, and this page claims no such mapping. Category and market are confirmed before reliance.
Does ThreatZ ship a J1939 or ISOBUS protocol library?
No such library is claimed. The system model is built from the imports listed on the modeling page, such as ARXML, System Composer, EA XMI, ODX/PDX/CDD and DBC, or drawn on the canvas. Buses, interfaces and signals from those sources become TARA assets. Protocol-specific truck or agricultural packs are not part of what this page describes.
Who holds the obligation when a body builder completes the chassis?
That is a question we pose, not one the platform answers. A truck or bus chassis is frequently completed by a second-stage manufacturer, so evidence passes through two manufacturers before an authority reads it. What ThreatZ provides is a record that a party who never opened your platform can read cold: a named anchor, per-row authorship and a declared ending.
How does the fleet map reach a registered vehicle?
A supplier uploads ECU part numbers against a project baseline, and ThreatZ matches them, exactly and case-insensitively, to the part numbers the program holds per VIN. A finding then traces from software component to software unit to system component to part number, and on to the vehicles in each market. The Fleet and Risk Map is an Enterprise-tier view.
Bring a truck or bus program.
We run the chain on your shape.
Bring the variant count, the markets you register in and one ECU you worry about. We walk from the advisory to the registered fleet on a running build — and we leave the regulatory applicability questions where they belong, with your homologation lead.