UN R155 has made cybersecurity a precondition for type approval. What many in the industry still underestimate as a consequence: the regulation does not describe a one time product sign off. It mandates a management approach that has to guarantee cybersecurity across the entire vehicle lifecycle. That generates costs which cannot be cleanly attributed to “the product” in the traditional sense. Industry players in an already battered sector are now operating under efficiency pressure and facing a structural problem at the same time. Here is an attempt to unpack it.
Philipp Veronesi
“Cybersecurity costs money.” This smallest common denominator has, however reluctantly, taken hold across the vehicle and automotive industry fairly quickly.
Some would say it is both true and untrue.
It is true because the investments are real. Cybersecurity engineers, in-house competence, tooling, audits, secure hardware, monitoring infrastructure.
It is untrue because the statement implies that the price tag is known and that security relevant decisions can therefore be budgeted for. Neither is currently the case to the degree that clean planning would actually require.
Making things harder, cybersecurity spend is fundamentally preventive in nature. It is meant to ward off the things that would cost significantly more if they actually happened. A security incident. A lost customer program. A denied type approval. And what is successfully prevented cannot, by definition, be measured.
Anyone trying today to put a number on the total cost of regulatorily defensible vehicle cybersecurity across the full product lifecycle will find very little reliable data and will keep running into structural ambiguities along the way.
That is where the real problem sits. Not in the technology, and not even primarily in the regulation, but in how the industry has so far handled this still fairly new cost block called product cybersecurity.
Most players in the vehicle industry treat cybersecurity primarily as a development line item, a project bound one time effort.
But anyone familiar with UN R155 and its companion standard ISO/SAE 21434 knows: that framing is not compliant.
What UN R155 and ISO/SAE 21434 actually require in terms of security cost, and what it means economically
UN R155 and its sibling UN R156 (Software Update Management) form a regulatory twin pair within type approval law. Both management systems are prerequisites for obtaining type approval.
What these regulations require today for every newly registered vehicle goes well beyond a one shot product audit.
The Cybersecurity Management System (CSMS) under UN R155 has to cover development, production, and the so called post production phase. Processes for monitoring, attack detection, and incident response have to be maintained continuously, and they have to include vehicles already in the field. The CSMS certificate itself is not valid indefinitely, since UN R155 requires a renewal every three years.
So in regulatory terms, cybersecurity is not a one time SOP check. It is a recurring evidence and audit obligation.
End of life cybersecurity in the automotive industry: a conflict of interest?
For the cost logic, the definition of the post production phase is the critical piece. It begins when a vehicle type is no longer being produced and only ends with the end of life of every vehicle of that type. That is a substantially longer horizon than the classical warranty or guarantee windows the industry has historically used for planning.
It is not the warranty expiration that defines the cybersecurity support obligation. It is the last vehicle of that type still on the road (per the current regulatory reading).
That is exactly where the economic conflict comes from, and it shapes one of the central industry debates right now.
The German industry association VDA argues that this long post production obligation effectively creates an active support commitment with no clear time limit. They have proposed a formal “End of Cybersecurity Support” (EoCSS) concept: an active maintenance phase up to EoCSS, followed by a passive observation phase running until the vehicle’s actual end of life.
The currently enforced rule is the long one. What is being debated is whether a formal transition from active maintenance to passive observation should be introduced.
In practical terms, that transition decides billions in lifecycle cost, even if public coverage rarely names it that explicitly.
Worth flagging: this cost reality does not sit only at the OEM. It runs through the entire supply chain. Tier 1 and Tier 2 suppliers also have to absorb the cost of long term cybersecurity obligations internally and pass them on somewhere. How, and to whom, is still unresolved in many supplier relationships.
It is worth comparing this to other industries where support lifecycles have been established for longer. In the enterprise OS segment, for example, extended support windows of ten years or more are defined and end of support dates are communicated years in advance, because enterprises need planning certainty for their infrastructure, compliance, and IT budgets. Smartphone manufacturers now actively compete on update guarantees, because consumers have learned that missing security updates represent a real risk.
In both cases, the same rule applies: the manufacturer does not just have to provide the product, they also have to maintain the infrastructure that makes updates possible. Development environments, security infrastructure, test processes, support channels.
Those structures have, until now, been missing from the automotive context as a defined planning parameter.
The challenge: while a smartphone simply gets replaced after a few years, and an enterprise server system can be retired after a defined lifecycle date, a vehicle stays in operation significantly longer on average. And it is physically, legally, and safety critically connected in a way that does not allow unsupported continued operation without consequences.
That is exactly what makes the EoCSS debate so important within the layered automotive supplier landscape. This is not about avoiding responsibility. It is about structuring cybersecurity obligations so that they remain actually deliverable over the long term.
Security costs that do not show up on the BOM
Another challenge: the cost structure of automotive cybersecurity is distributed very unevenly along the vehicle lifecycle.
In the development phase, one time but volume relevant expenditures dominate.
Specifically, the costs tied to whatever a holistic cyber risk assessment surfaces under the established Threat Analysis and Risk Assessment (TARA) methodology. Security requirements on the product, the cybersecurity concept, verification and validation. Full supplier management with respect to cybersecurity. All work products and documentation.
In production, three further cost areas come in, and they are worth distinguishing cleanly:
- First, development costs in the form of engineering hours, for specifying secure manufacturing processes, ensuring production is audit ready, and building the key management concept.
- Second, hardware costs that hit the bill of materials directly, namely secure hardware, Hardware Security Modules, and Secure Elements. UN R155 explicitly names HSMs as an example of a type approval relevant mitigation.
- Third, operational production costs, such as key injection infrastructure, secured flash stations, and process controls.
All three are real, but in operational practice they typically sit under different budget owners, which makes any clean total cost view much harder to pull together.
Out in the field, the logic shifts toward ongoing operational expenditure. Monitoring, PSIRT work, vulnerability management, OTA campaigns including the server and backend infrastructure required to support them, cloud and connectivity operations, tooling for update distribution and regression testing.
Large suppliers are increasingly describing this long tail commitment with mixed feelings. Software can be optimized over the full lifecycle via over the air (OTA) updates, but at the same time it is a real challenge to keep software updatable many years after the original development effort.
Software updates do save expensive recall costs, but they also generate new permanent operating costs across cloud, connectivity, test, and regulatory evidence work.
Bottom line: long term cybersecurity is not a side service. It is a standalone cost and capability block with its own requirements.
The asymmetric burden across the vehicle supply chain
For suppliers, the current state of play on vehicle cybersecurity cost is particularly contradictory.
Type approval authorities issue CSMS and SUMS certificates to vehicle manufacturers, not to component suppliers. (Even though component suppliers love to display all kind of security certifications in their marketing material.)
At the same time, OEMs have to demonstrate during type approval how they have managed their supply chain and how supplier components are integrated into the cybersecurity architecture.
So the OEM does not just have to build and audit proof its own CSMS (at significant cost). It also has to consistently ensure that its entire supply chain reaches and demonstrably holds the required security standard.
The supply chain management overhead created here “just” by cybersecurity is not to be underestimated.
The result is an indirect but hard regulation of suppliers, expressed through detailed requirements specifications, dedicated Cybersecurity Interface Agreements, release evidence, and a whole range of (ideally collaborative) cybersecurity touchpoints.
Putting numbers on automotive cybersecurity costs for suppliers
The VDA’s Cybersecurity Interface Agreement framework (VDA CSIA) tries to make this role split concrete:
- On the OEM side: overall TARA, security goals, vehicle type validation.
- On the supplier side: component specification, verification and integration reports, vulnerabilities surfaced during development, production control plans, an established and activatable incident response process, continuous cybersecurity activities, and processes for communicating the end of cybersecurity support.
Like the regulation itself, this framework essentially confirms one thing: supplier cybersecurity is not a discrete project. It is a process apparatus that spans development, production, operation, and end of support.
The underestimated supply chain costs
Practical experience and early industry analyses both suggest that Tier suppliers in particular tend to underestimate the business and cost impact of automotive cybersecurity.
The post sale phase especially is often organizationally neglected, because updates and testing, particularly after the warranty expires, are perceived as expensive.
That is exactly where the real cost challenge sits: less in the initial implementation, more in the long tail of maintenance.
Suppliers do not just carry compliance costs. They also carry standby costs. Old build environments, cryptographic material, intermediate software states, qualified personnel, often years after the actual series business has ended. It is worth picturing this concretely. Even NASA had to recall already retired specialists to recover historical knowledge and security relevant details.
Efficiency under efficiency pressure
The automotive industry is in a contradictory position. On one side, alternative powertrains and the broader digitalization push keep advancing, which means the cybersecurity footprint keeps growing. On the other side, the business climate is deep in the red, margins are sliding, and the cost of capital is up.
Within that, several large Tier suppliers are running restructuring programs in parallel. Workforce reductions in the high hundreds to low thousands, divestments of automotive businesses, cost reduction targets in the hundreds of millions. These are no longer edge cases. They are the current baseline.
Against that backdrop, cybersecurity budgets and resources, and not least the carefully built up expertise, have to be defended today.
Right now, that means money for cybersecurity competes directly with money for electrification, software platforms, and restructuring. That is not a theoretical issue. It is a real allocation conflict being fought out daily in most organizations.
On top of that comes the current regulatory sprawl. UN R155 (alongside GB 44495, AIS 189, the Korean security regulation, and others), the Cyber Resilience Act, and NIS 2 do not hit the industry in isolation.
They hit simultaneously, with partially overlapping and partially contradictory requirements.
Industry associations at both national and European level are, rightly, calling for clearer mappings between these frameworks, fewer duplicate reporting obligations, and a regulatory architecture that puts compliance effort and actual security gain into a sensible ratio. Because uncertainty is not the only thing that costs money. Bad regulatory architecture costs money too.
Where the efficiency potential lies, and why unlocking it is not free
Another economic challenge: expensive does not equal more security. Expensive usually means poorly organized security.
That sounds trivial, but it is currently one of the biggest fields of action when building, expanding, or restructuring automotive cybersecurity functions.
The historical logic of the automotive industry, with project bound budgets and proprietary platform landscapes, makes genuine multi year planning of cybersecurity costs difficult.
There are no historical benchmarks, the target values are unclear, there are countless variants, standardization is missing, support obligations are murky. The underlying conditions turn the exercise into an obstacle course.
At the same time, the realization is gradually setting in: the real price of a supposedly cheap solution shows up later, and it tends to be substantially higher when it does.
What needs to change, and what that already means for cybersecurity management in automotive today
What follows from the above is not a list of technical actions. It is decisions about governance, contract architecture, and strategic prioritization that simply have to be made for effective vehicle cybersecurity.
A few examples worth naming:
- Security support obligations have to be written into product and supplier contracts before the first vehicle leaves the line. Not later, when a vulnerability creates renegotiation pressure. The OEM and supplier role split can be structured and contractually anchored across the full lifecycle (concept, development, production, operation, end of support). Where that gets skipped, technical problems are not what shows up. Commercial ones do.
- Monitoring and OTA costs are not an after sales residual. They are predictable operating costs. As such, they need to be made explicit in the budget and they should not disappear into vague “warranty” or “service” line items. Anyone who does not plan these costs explicitly is implicitly planning either cost spikes or skipped updates. Both are more expensive than the alternative.
- Distinguishing critical from non critical functions is not a technical detail. It is a strategic decision. UN R155 explicitly leaves room for the CSMS to define specific processes for end of support, including which functions can be deactivated under which conditions. Whoever makes that call early keeps room to maneuver. Whoever avoids it hands the call to the regulator or the market later.
- And finally, the most fundamental shift: cybersecurity is not a compliance cost center. It is part of product strategy, platform strategy, and after sales economics, with real trade offs that can actually be modeled. OTA saves recall costs but creates ongoing operating costs. Secure hardware raises unit costs but lowers the risk of expensive field incidents. Longer support strengthens trust and residual values, but extends the tail of older architectures.
These trade offs are not an argument for hesitation. They are the reason cybersecurity costs have to be modeled strategically, with the same tools and the same seriousness as any other long term investment decision in a vehicle program.
Conclusion: critical questions about cybersecurity cost in automotive
The real price of automotive cybersecurity is the price of durability, in an industry historically optimized around one time unit cost logic. UN R155 is forcing a paradigm shift on the sector at a moment when every euro is already being counted twice.
That is exactly why questions about how cybersecurity costs are organized and distributed are no longer technical questions. They are strategic ones.
A few to think on:
- How far does your company’s support obligation actually extend under current contracts? Does it line up with what UN R155 demands in regulatory terms?
- Are the cybersecurity costs of the post production phase planned as their own budget line? Or do they disappear into warranty, after sales, or unplanned residuals?
- How is the OEM and supplier RACI for vulnerability handling, retesting, and EoCSS communication contractually defined? Has that definition been reconciled with the actual technical scope?
- Which vehicle functions would still require active maintenance after a hypothetical EoCSS? Which ones could be deactivated under defined conditions?
- Is your cybersecurity architecture set up so that software updates and security patches can still be safely built, tested, and rolled out ten years from now?
- …and there are quite a few more questions worth raising and answering, and worth talking through with the right experts.
