UN R155 CSMS gap analysis: where automotive evidence pipelines break
Geert WarmenbolApril 29, 2026
Key takeaways
UN R155 CSMS type approval requires vehicle-type-specific evidence -- TARA outputs, cybersecurity goals, security requirements, and test records tied to the specific vehicle architecture. Platform-level documentation does not satisfy the evidence standard regardless of how well it is structured.
The most common pipeline failure in UN R155 CSMS programs is that threat analysis tooling and vulnerability scanners generate outputs that are not connected to the evidence artifacts type approval reviewers request -- the data exists in disparate systems and cannot be assembled into a coherent submission without manual reconstruction.
Supplier cybersecurity documentation is the bottleneck that automated CSMS programs cannot resolve: tooling can manage OEM-side evidence collection, but tier-1 and tier-2 suppliers developing components under different processes and timelines require a governance mechanism that most OEM CSMS architectures have not built.
UN R155 Article 4.3 post-production monitoring requires operational capability to detect and respond to cybersecurity events in deployed vehicles -- this is a continuous data pipeline requirement, not a process document requirement, and most CSMS programs have not architected it as one.
Automated TARA tooling produces structured risk assessments faster than manual processes, but the output quality depends entirely on the asset inventory and threat intelligence inputs -- CSMS programs that automate TARA generation without maintaining accurate vehicle architecture data produce faster outputs with higher rates of incomplete coverage.
The gap between a working CSMS and a type-approval-ready CSMS is almost entirely in evidence traceability: whether outputs from each development phase are linked, versioned, and retrievable in the structure a type approval body expects to evaluate.
TL;DR
UN R155 CSMS programs fail type approval because they are built as compliance programs rather than evidence pipelines. The tools are usually in place. The threat analysis runs. The vulnerability scanning runs. The problem is that none of the outputs are connected to each other or tagged to the specific vehicle type being submitted for approval. Building a CSMS that passes type approval requires thinking about evidence architecture before thinking about process design.
What a well-tooled CSMS program still gets wrong
A tier-1 automotive supplier supporting three OEM programs has invested significantly in its CSMS infrastructure. They run automated TARA tooling, maintain a vulnerability management platform with live CVE feeds, operate a ticketing system for security findings, and have completed ISO 21434 training across their development teams. When the first OEM requests CSMS documentation for a type approval submission, the supplier's compliance team discovers that outputs from the TARA tool, the vulnerability tracker, and the test management system are in three separate platforms with no shared identifier linking them to the specific ECU variant the OEM is submitting for approval.
The data to satisfy the evidence requirement exists. It cannot be assembled into a coherent submission in the time available. The TARA outputs reference system architecture version 3.2. The vulnerability tracker references component version 4.1. The test records reference build 4.1.2. Whether version 3.2, 4.1, and 4.1.2 refer to the same system configuration at the time of the security assessment requires manual reconstruction that takes three weeks and produces an evidence package whose traceability the OEM's submission team cannot confidently defend. That is not a tooling failure. It is an evidence architecture failure that the tooling selection never addressed.
What UN R155 actually requires from an evidence pipeline perspective
UN R155 Annex 5 defines the information a manufacturer must provide to a type approval authority to demonstrate CSMS effectiveness. The requirement is not a document checklist -- it is a demonstration that cybersecurity processes were applied to the specific vehicle type being approved, with artifacts proving each stage of that application. The evidence chain runs from initial item definition and architecture description through TARA execution, cybersecurity goal derivation, security requirement specification, implementation, and security testing. Each stage must produce artifacts that reference the same vehicle type and that are traceable to each other. A gap anywhere in the chain breaks the demonstration.
Example
In practice, the traceability requirement means that a vulnerability identified during security testing must be traceable to a threat scenario in the TARA, which is traceable to an asset in the vehicle architecture description, which is traceable to the item definition for the vehicle type being submitted. If the vulnerability tracker entry says 'infotainment system buffer overflow' and the TARA threat scenario says 'ECU-07 unauthorized code execution' and the architecture description uses a different naming convention entirely, a reviewer cannot verify the chain without manual mapping that the manufacturer has to provide. Reviewers ask for this mapping. If it does not exist as a maintained artifact, it has to be reconstructed at submission time -- which is expensive, slow, and introduces errors.
ISO 21434 defines the work products that map most directly to UN R155 Annex 5 evidence requirements: the item definition (work product 9-1), the cybersecurity assessment (work product 15-1), the TARA (work products 15-4 through 15-8), cybersecurity goals (work product 15-6), cybersecurity claims (work product 15-9), and cybersecurity validation (work product 15-11). CSMS programs that define their evidence artifacts against ISO 21434 work product numbers produce submissions that type approval reviewers can evaluate against a known structure. Programs that define their own artifact taxonomy produce submissions that require reviewers to perform the mapping themselves -- which introduces friction and finding risk.
What CSMS program assessments find
Assessment base: Vulnox assessment data, 2024-2025, automotive OEM and tier-1 supplier CSMS programs assessed for UN R155 type approval readiness
Vulnerability management outputs are not connected to TARA risk scenarios
In CSMS gap assessments, the most consistent pipeline gap is the disconnect between vulnerability management platforms and threat analysis outputs. Vulnerability scanners identify CVEs against components. TARA tools generate threat scenarios against system architecture. In most CSMS programs, these two data streams exist in separate systems with no automated link between a vulnerability finding and the threat scenario it evidences or contradicts. At submission time, demonstrating that vulnerability management activities addressed TARA-identified risks requires manual cross-referencing that is rarely maintained as a live artifact.
A CSMS program where vulnerability management and threat analysis operate as independent pipelines without a shared vehicle-type identifier and artifact linkage mechanism will produce evidence gaps at submission time regardless of how mature either individual process is. The gap is architectural, not operational.
Post-production monitoring is a document, not a data pipeline
UN R155 Article 4.3 requires continuous monitoring of in-field vehicles for cybersecurity threats and vulnerabilities. In CSMS program assessments, this requirement is almost universally addressed by a process document describing how monitoring will be conducted. What exists less commonly is an operational pipeline: telemetry from deployed vehicles feeding into a detection capability, with documented thresholds for escalation and a defined path from detection to the TARA update and security response processes. The document describes what the pipeline should do. The operational infrastructure to run it has not been built or is not connected to the CSMS evidence structure.
Type approval bodies are beginning to ask about post-production monitoring operational capability, not just process documentation. A CSMS that cannot demonstrate an operational monitoring pipeline for vehicles already in production will face increasing scrutiny as type approval bodies develop more specific evidence expectations for Article 4.3.
Security testing records are not version-controlled against architecture state
Security testing under UN R155 must validate that security controls address the risks identified in the TARA. For that demonstration to work, the test records must reference the system state at the time of testing. In CSMS programs where security testing is conducted by a separate team or external provider, test reports frequently reference component versions without capturing the full architecture configuration at test time. When the vehicle type undergoes architecture changes between testing and submission, the relationship between the test evidence and the submitted system configuration becomes ambiguous. Reviewers ask whether the test evidence applies to the system as submitted.
Security test records need to be version-controlled against the architecture baseline they tested, not just the component version. A test report that says 'infotainment module v4.1' without capturing the network topology, inter-ECU communication configuration, and external interface state at test time is not a traceable evidence artifact -- it is a test snapshot with missing context.
More tooling makes the evidence problem harder, not easier
Common belief
Automotive cybersecurity programs that invest heavily in tooling -- automated TARA platforms, vulnerability management systems, security testing frameworks, supplier assessment portals -- tend to approach type approval submissions with confidence. The tools are running, outputs are being generated, findings are being tracked. The program looks mature from inside the organization. The assumption is that more tooling produces better evidence.
What we found
In CSMS readiness assessments, the programs that produce the most submittable evidence packages are not the ones with the most sophisticated tooling. They are the ones where someone made explicit decisions early about how evidence artifacts would be named, versioned, linked, and stored relative to vehicle type and development phase. That decision is an architecture decision, not a tooling decision. It takes a day to make and months to retrofit if it was not made at program inception.
More tooling produces more data in more systems with more naming conventions and more version identifiers that may or may not refer to the same objects. The evidence problem in UN R155 submissions is not a data volume problem -- it is a data coherence problem. A CSMS program running four specialized tools that cannot produce a single coherent evidence chain for a specific vehicle type at a specific point in time is less submittable than a CSMS program running simpler processes with consistent artifact naming and explicit traceability links maintained as a live document. The bottleneck at submission time is always assembly, never data volume.
Where UN R155 CSMS programs miss
The architecture description as a living artifact
UN R155 type approval evidence requires that TARA and security goals reference the vehicle architecture that was assessed. Vehicle architectures change during development. ECUs are added, communication interfaces are modified, software stacks are updated. In most CSMS programs, the architecture description used for the initial TARA is not systematically updated to reflect changes, and the TARA is not re-executed when the architecture changes materially. The submission ends up with a TARA that assessed a vehicle architecture that no longer matches the submitted system. Reviewers flag the discrepancy. The remediation requires reconstructing which architecture changes occurred after the TARA, assessing whether they introduced new threat scenarios, and producing evidence that the assessment was refreshed -- none of which is fast.
Supplier evidence collection timelines versus OEM submission deadlines
OEM type approval submissions require supplier cybersecurity documentation for components in scope. Suppliers operating their own CSMS programs on their own timelines cannot produce evidence packages on demand. In most OEM CSMS programs, supplier evidence collection is managed through a questionnaire and audit process that runs on an annual or project-milestone schedule. When a type approval submission deadline moves up or a supplier deliverable slips, the OEM discovers that the supplier evidence artifacts they need either do not exist yet or were generated against an earlier component version. Building supplier evidence collection into the CSMS as a scheduled, version-tracked pipeline rather than an on-demand request process is the structural fix most programs have not implemented.
CSMS scope definition for connected services and backend infrastructure
UN R155 CSMS scope extends to backend systems that interact with vehicles -- update servers, telematics platforms, remote diagnostics infrastructure. In most CSMS programs, the scope definition addresses on-vehicle systems in detail and treats backend infrastructure as out of scope or as an IT security responsibility handled by a separate team. Type approval reviewers ask about the security of update delivery infrastructure, authentication mechanisms for vehicle-to-backend communication, and the cybersecurity risk management process for backend systems. Programs that have not included backend infrastructure in their CSMS scope produce findings in this area consistently.
Change management triggers for TARA updates
UN R155 requires that cybersecurity risk assessments remain current. In practice, this means having a change management process that identifies when a vehicle architecture change, a new vulnerability affecting in-scope components, or a change in the threat landscape requires a TARA update. Most CSMS programs have a change management process that triggers engineering reviews for functional safety and quality. Cybersecurity triggers for TARA updates are either absent or documented as criteria without a connected workflow that routes relevant changes to the cybersecurity team for assessment. The consequence is TARA drift -- the assessment progressively diverges from current risk as changes accumulate without triggering reassessment.
Where UN R155 tooling and enforcement is heading
A market for machine-readable CSMS evidence packages will emerge within 24 months, driven by type approval bodies requesting structured data rather than document submissions for high-volume evidence categories like vulnerability findings, TARA updates, and security testing records.
Type approval bodies reviewing large submission volumes face the same scaling problem as any compliance reviewer: document-based evidence requires manual evaluation. For evidence categories that are high-volume and structurally consistent -- CVE findings, test results, architecture change records -- machine-readable formats allow automated completeness and traceability checks. The DOE precedent for structured evidence submission in other regulated industries suggests the direction of travel. The first type approval body to publish a structured evidence schema for UN R155 submissions will set a standard that others follow.
Confidence: mediumA published type approval body guidance document or regulation amendment specifying structured data formats for UN R155 evidence submission before 2027The post-production monitoring requirement under Article 4.3 will become the primary source of Certificate of Compliance suspensions within 36 months, as type approval bodies develop specific operational evidence expectations that most certified manufacturers cannot demonstrate.
Article 4.3 monitoring obligations are currently satisfied by process documentation in almost all certified CSMS programs. As type approval bodies gain experience evaluating post-production compliance, they will develop specific expectations for operational evidence -- telemetry coverage, incident detection rates, response timelines. Manufacturers whose monitoring capability is a process document rather than an operational pipeline will not be able to produce this evidence on request. The first suspension will establish what the standard actually requires in practice.
Confidence: highA European type approval authority publishing specific operational evidence criteria for Article 4.3 monitoring compliance before 2027, or a documented suspension citing inadequate post-production monitoring capability
Why CSMS programs should be designed as evidence systems first
Most CSMS programs are designed as security management programs with evidence collection added on top. The tooling selection, process design, and team structure are oriented toward managing cybersecurity risk, with audit readiness treated as a downstream output. That sequence produces programs where the security management is mature and the evidence structure is weak. The more effective design sequence inverts this: decide how evidence will be named, versioned, linked, and stored relative to vehicle type and development phase before selecting tooling or designing processes. Every process and tool choice then gets evaluated against whether it produces evidence in the required structure. The security management capability emerges from the same design. The evidence architecture does not have to be retrofitted later.
Counterargument
The counterargument is that designing for evidence first produces compliance theater -- programs optimized for audit performance rather than actual security. That risk is real if evidence architecture decisions drive out security engineering judgment. The practical design principle is to make evidence architecture decisions about naming, versioning, and storage without constraining what the security engineering processes do -- the two are separable, and treating them as separable is what prevents the compliance theater outcome.
One architecture decision to make before building the CSMS tooling stack
Before selecting TARA tooling, vulnerability management platforms, or test management systems, define the vehicle-type identifier structure that will link artifacts across all three. Decide what field in each system carries the vehicle type designation, how architecture versions are named consistently across systems, and where the traceability link between a vulnerability finding, its corresponding TARA threat scenario, and its security test record is maintained. That decision takes a day. Retrofitting it after the tooling stack is in place takes months and produces a submission evidence package assembled under time pressure rather than generated by a functioning pipeline.
Further Reading
Gap Analysis
framework gap analysisDigital Footprint
digital footprint analysisNIST Vulnerability Assessment Definition
NIST's vulnerability assessment definitionOWASP Web Security Testing Guide
OWASP security testing guideThird-Party Risk Management
managing third-party risk
Frequently Asked Questions
What evidence does a UN R155 CSMS type approval submission actually require?
UN R155 Annex 5 requires vehicle-type-specific evidence of cybersecurity process application across the development lifecycle: item definition, TARA outputs with threat scenarios and risk decisions, cybersecurity goals derived from the TARA, security requirements with implementation traceability, and security testing records validating those requirements against the specific vehicle architecture submitted for approval.
Why do automated TARA tools not solve the UN R155 evidence problem?
Automated TARA tools generate structured risk assessments faster than manual processes, but output quality depends on asset inventory and threat intelligence inputs. More critically, TARA outputs that are not linked to vulnerability management findings and security test records through consistent vehicle-type identifiers and version references cannot produce a traceable evidence chain. The evidence problem is architectural, not a data volume problem that more tooling resolves.
What is the most common UN R155 CSMS gap analysis finding?
The most consistent finding is the disconnect between vulnerability management platform outputs and TARA risk scenarios -- two data streams in separate systems with no automated link between a CVE finding and the threat scenario it addresses or contradicts. At submission time, demonstrating that vulnerability management addressed TARA-identified risks requires manual cross-referencing that most programs do not maintain as a live artifact.
What does UN R155 Article 4.3 require operationally after type approval?
Article 4.3 requires continuous monitoring of deployed vehicle types for cybersecurity threats, vulnerabilities, and attacks, with response obligations when relevant events occur. This requires an operational data pipeline -- vehicle telemetry feeding a detection capability with defined escalation thresholds and a path from detection to TARA update and security response. A process document describing how monitoring will be conducted does not satisfy the operational capability requirement.
How should CSMS evidence artifacts be structured to support type approval?
ISO 21434 work product designations map directly to UN R155 Annex 5 evidence requirements. Structuring CSMS evidence artifacts against ISO 21434 work product numbers -- item definition (9-1), TARA work products (15-4 through 15-8), cybersecurity goals (15-6), and cybersecurity validation (15-11) -- produces submissions that type approval reviewers can evaluate against a known structure without requiring the manufacturer to explain its own taxonomy.
When does a TARA need to be updated for UN R155 compliance?
A TARA requires updating when vehicle architecture changes materially, when new vulnerabilities affect in-scope components, or when the threat landscape changes in ways that affect risk decisions already made. Most CSMS programs have change management processes that route functional changes to engineering review without including cybersecurity triggers that route relevant changes to TARA reassessment. The result is progressive TARA drift from current risk as changes accumulate.
How should backend infrastructure be scoped in a UN R155 CSMS?
UN R155 CSMS scope extends to backend systems interacting with vehicles -- update servers, telematics platforms, remote diagnostics infrastructure. Type approval reviewers ask about update delivery security, vehicle-to-backend authentication, and backend cybersecurity risk management. Programs that scope CSMS to on-vehicle systems only and treat backend as a separate IT security responsibility produce findings consistently in this area.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.