Regulations
R155 is often summarised as “you need a CSMS”. The harder part is showing that the management system produced real engineering decisions across the vehicle lifecycle.
· AutoSec Engineering Team · 2 min read
UN Regulation No. 155 introduced two distinct obligations that are easy to conflate. The first concerns the organisation: a manufacturer must operate a Cyber Security Management System, or CSMS, and hold a valid certificate of compliance for it. The second concerns the vehicle: each vehicle type must be approved on the basis of evidence that cybersecurity risks have been identified, assessed, and treated. Passing the first does not satisfy the second.
In practice, teams that struggle at assessment usually have the process documentation in place. What they lack is the connective tissue between the documented process and the engineering artefacts a specific vehicle type produced.
The CSMS has to cover the full lifecycle, including development, production, and the post-production phase. The post-production element is the one most often underestimated. It requires an organisation to demonstrate that it can monitor for new threats, assess whether those threats affect vehicles already in the field, and respond where necessary. That is an operational capability, not a document.
For a specific vehicle type, the approval authority is looking for a coherent argument. Risks were identified through analysis, those risks led to cybersecurity goals, the goals led to requirements, the requirements were implemented, and the implementation was tested. Each link in that chain needs an artefact behind it.
This is where traceability stops being an administrative preference and becomes the substance of the submission. If a threat scenario in the risk analysis cannot be followed through to a control and a test result, the argument has a gap that an assessor will find.
Most vehicle functions are delivered by suppliers, but the approval obligation sits with the manufacturer. This makes interface agreements a cybersecurity artefact rather than a commercial one. The agreement should state which party performs which activity, what evidence is handed over, and how findings on either side are communicated.
Ambiguity here surfaces late and expensively. A common failure is both parties assuming the other is responsible for penetration testing a shared interface, which is then discovered weeks before a release gate.
Organisations rarely get to begin with a clean process. A more realistic sequence is to establish a repeatable risk analysis method first, since everything downstream depends on it; then fix traceability from goals to requirements; then close the verification evidence gap; and only then formalise post-production monitoring. Attempting all four simultaneously usually produces documentation that satisfies nobody.
Written by
Automotive cybersecurity engineering
Engineers working on vehicle cybersecurity concepts, requirements, embedded implementation, and verification across OEM and supplier programmes.
More from this authorSecure Updates
Most engineering organisations already update vehicle software safely. Far fewer can reconstruct, months later, exactly what was delivered to which vehicle and why it was considered safe.
· AutoSec Engineering Team · 1 min read
Read articleVSOC
An enterprise SOC watching vehicle telemetry without vehicle context produces alerts nobody can act on. The gap is domain knowledge, not tooling.
· AutoSec Engineering Team · 2 min read
Read articlePenetration Testing
CAN has no built-in authentication, which is well known. The interesting findings are rarely about the bus itself — they are about what sits on it and how it was configured.
· AutoSec Security Research · 2 min read
Read articleIf this applies to a programme you are working on, we are happy to talk it through.
