A modern vehicle is a data center on wheels, running tens of millions of lines of code across dozens of electronic control units, most of it supplied by a deep tier structure of vendors rather than written by the automaker. That structure is precisely what makes the automotive software supply chain hard: an OEM is accountable for security it did not author, delivered by Tier 1 and Tier 2 suppliers who in turn depend on open-source and commercial components several layers down. In 2026, regulators have made that accountability explicit, and it now gates whether a vehicle can be sold at all.
The regulatory drivers
The defining requirements come from the United Nations Economic Commission for Europe. UN Regulation No. 155 (R155) mandates a certified Cybersecurity Management System covering the vehicle's entire lifecycle, and UN Regulation No. 156 (R156) mandates a Software Update Management System for delivering updates safely, including over the air. Since July 2024, these apply to all new vehicles registered in the many markets that follow UNECE type-approval, not just new vehicle types, which means a manufacturer without a demonstrable CSMS cannot bring product to market in those jurisdictions.
The technical backbone that manufacturers use to meet R155 is ISO/SAE 21434, the standard for road-vehicle cybersecurity engineering, which frames security as a discipline running from concept through decommissioning and explicitly reaches into the supply chain. ISO 24089 complements it for software update engineering. On the assurance side, the TISAX framework governs how suppliers demonstrate information-security maturity to OEMs. The practical consequence of all this is SBOM flow-down: to prove control of their own supply chain, OEMs increasingly require suppliers to deliver a software bill of materials and a vulnerability-management process for every component they ship.
What an automotive program needs
The lifecycle length is what sets automotive apart. A vehicle built today may be on the road for fifteen years, so a component that is safe now must remain manageable long after its developers have moved on.
The program needs a component inventory that spans the tier structure, aggregating supplier SBOMs into a picture the OEM can actually query. It needs continuous monitoring, because R155's CSMS obligation does not end at production; postmarket vulnerability monitoring is central. It needs exposure-based prioritization, since a vehicle program cannot issue an over-the-air campaign for every advisory and must focus on what is genuinely reachable and safety-relevant. And it needs evidence that maps to R155, R156, and ISO/SAE 21434 for type-approval and audit.
Practical controls
Require an SBOM and a coordinated vulnerability-handling process from every supplier, and store those SBOMs where you can reconcile them against current vulnerability data across the whole vehicle program. For software developed in-house, generate a signed SBOM on every build. Establish provenance and integrity for build pipelines, pin CI/CD actions to immutable hashes, and use short-lived, scoped credentials, because the pipeline that signs firmware is a high-value target.
Put policy gates in the pipeline that block a build carrying a known-exploited or malicious component, and route findings through reachability analysis so engineering effort and any update campaign target vulnerabilities that actually reach exploitable code. Maintain a postmarket monitoring and update process, as R155 and R156 require, so a vulnerability discovered years after production can be triaged and, where warranted, remediated over the air with a documented trail.
How Safeguard helps
Safeguard gives automotive teams the aggregation and prioritization the tier structure demands. Our software composition analysis inventories every direct and transitive dependency and applies reachability analysis, turning a raw list of component vulnerabilities into the subset whose code is actually reachable, which is what lets a program decide where a costly update campaign is justified.
SBOM Studio generates and version-controls SBOMs for in-house software and ingests supplier SBOMs and AIBOMs across the tiers, giving the OEM the aggregated, queryable inventory that R155 and SBOM flow-down assume. Because it version-controls those SBOMs, you retain a historical record for the full vehicle lifecycle rather than a single snapshot. When remediation is warranted, Griffin AI generates and validates the fix and opens it as a reviewable pull request, keeping human oversight while shortening the path from disclosure to a deployable update.
For type-approval and audit, the compliance module maps findings and controls to R155, R156, and ISO/SAE 21434 expectations and exports evidence, so demonstrating a functioning CSMS is a matter of retrieval. And because automotive engineering data and firmware are sensitive intellectual property, Safeguard deploys as SaaS, self-hosted, or fully air-gapped, keeping source and SBOMs inside the manufacturer's boundary. See how the pieces fit your program on the solutions overview, or start a trial.
Frequently Asked Questions
Are R155 and R156 mandatory for every new vehicle now? Since July 2024, R155 and R156 apply to all new vehicles registered in markets that follow UNECE type-approval, extending beyond the earlier scope that covered only new vehicle types. A manufacturer must be able to demonstrate a certified Cybersecurity Management System and Software Update Management System to bring product to market in those jurisdictions.
How do supplier SBOMs fit into an OEM's CSMS? R155 makes the OEM accountable for managing cybersecurity risk across its supply chain, which is difficult without visibility into what suppliers ship. Aggregating supplier SBOMs into a queryable inventory lets the OEM identify, when a new vulnerability is disclosed, which components and which vehicles are affected, and document that it is monitoring risk postproduction.
Does the long vehicle lifecycle change the tooling requirements? It does. A vehicle can be in service for well over a decade, so SBOMs and evidence need to be version-controlled and retained across that span rather than captured once at production. Safeguard's SBOM Studio version-controls the inventory so postmarket monitoring can reference exactly what shipped in each build years later.
Can Safeguard run without exposing our firmware and engineering data? Yes. Safeguard supports self-hosted and fully air-gapped deployment alongside SaaS, so proprietary source, firmware, and SBOMs can remain entirely within the manufacturer's controlled environment.
Explore Safeguard's software composition analysis, SBOM Studio, Griffin AI, and compliance evidence, or read the documentation to get started.