What automotive already learnt, and the rest of industry will learn by 2027
The automotive sector was the first forced to treat cybersecurity as a product property across the life cycle, with UNECE R155/R156 and ISO/SAE 21434. Vehicles are outside the CRA precisely because of this, and it is also why they serve as a preview.
- Published
There is one sector where the central ideas of the Cyber Resilience Act (security as a product property, risk management across the life cycle, managed updates, manufacturer responsibility after the sale) are not a 2027 novelty. They have been a type-approval obligation since 2022. We worked in that sector, and it is that experience that most informs how we read the CRA.
The automotive regime in two pieces
UNECE R155 makes vehicle type approval conditional on the manufacturer holding a certified Cyber Security Management System (CSMS): organisational processes covering the identification and management of the vehicle’s cybersecurity risks, from the development phase to the post-production phase, including threat monitoring and incident response for the fleet on the road. No new vehicle gets type-approved in the EU without this; the requirement became applicable to all new vehicles sold from July 2024.
UNECE R156 does the same for software updates: a Software Update Management System (SUMS), with version control, impact assessment for each update (including on the type approval) and, for over-the-air updates, guarantees of safe execution.
Beneath the two, ISO/SAE 21434 supplies the engineering: threat analysis and risk assessment (TARA), cybersecurity requirements cascaded down the supply chain, validation, and post-development monitoring and response activities.
Anyone who knows Annex I of the CRA recognises the map: product risk assessment, essential design requirements, vulnerability handling throughout the support period, secure updates. The structure is the same; what changes is the scale and the vocabulary. And it is because vehicles already have their own regime that the CRA expressly excludes them from its scope, as it excludes medical devices and aviation, the other sectors with pre-existing product regulation.
Five lessons that cost automotive dearly
The value of looking at automotive lies less in the theory than in the mistakes the industry has already paid for and the rest of the market can avoid:
- The supply chain is the project. An OEM does not write most of the car’s software; the Tier 1s and 2s do. R155 forced cybersecurity requirements down through supply contracts, and the lesson was that doing it late is extremely expensive. Under the CRA, the equivalent is due diligence on third-party components: the manufacturer answers for the whole product, including what it did not write.
- A TARA is only useful if it is alive. The first automotive risk analyses were type-approval documents, done once. The ones that work are maintained artefacts, updated when the architecture changes or a new class of attack appears.
- Post-sale monitoring needs its own organ. R155 forced manufacturers to build a permanent threat-watch capability over product in the field, the embryo of the PSIRT. It is exactly the capability Article 14 of the CRA presupposes when it gives 24 hours for the early warning.
- Updating a fleet is a product in itself. Automotive learnt that OTA is not a feature, it is an infrastructure with key management, staged rollout, rollback and success telemetry. Any IoT manufacturer that declares five years of support is going to rediscover this.
- Certifying processes is different from guaranteeing products. The CSMS certifies that the organisation has processes; it does not prevent a bad product. The temptation to run compliance as a documentation exercise exists under every regime, and the CRA’s market surveillance, unlike type approval, can knock on the door after the sale.
What this means for manufacturers
For a manufacturer outside automotive, the practical reading: the CRA asks for nothing that an entire industry has not already operationalised, mid-sized suppliers included. That is the good news. The bad news is the corollary: the impossibility arguments (“you cannot manage vulnerabilities for years”, “you cannot demand SBOMs from suppliers”) have already been refuted in practice by a sector with tight margins and supply chains far more complex than those of most IoT products.
The advantage of starting now: you can copy the final form without paying for the iterations. A living TARA, requirements cascaded through contracts, a permanent response capability, updating as infrastructure. Automotive took a decade to get here, and the blueprint is public.
Sources
- UNECE, Regulation No. 155 — Cyber security and cyber security management system — https://unece.org/transport/documents/2021/03/standards/un-regulation-no-155-cyber-security-and-cyber-security
- UNECE, Regulation No. 156 — Software update and software update management system — https://unece.org/transport/documents/2021/03/standards/un-regulation-no-156-software-update-and-software-update
- ISO/SAE 21434:2021, Road vehicles — Cybersecurity engineering — https://www.iso.org/standard/70918.html
- Regulation (EU) 2024/2847, Article 2 (scope exclusions, incl. vehicles under Reg. (EU) 2019/2144) — https://eur-lex.europa.eu/eli/reg/2024/2847/oj