The modern vehicle is no longer defined only by its mechanical systems. Connectivity, software, electronic control units, cloud services, mobile applications and over-the-air updates increasingly determine how a vehicle operates throughout its life.
This transformation has created a new homologation challenge. A vehicle may be technically compliant when it leaves the production line, yet its cybersecurity exposure can change as new vulnerabilities emerge, connected services evolve and software is updated.
UN Regulations No. 155 and No. 156 respond to this fundamental shift. Together, they introduce regulatory frameworks for vehicle cybersecurity, cybersecurity management and software-update governance — extending conformity from the physical vehicle into the manufacturer’s organizational processes and the vehicle’s continuing digital lifecycle.
Homologation Is No Longer Only About Hardware
Traditional vehicle approval developed around relatively stable physical systems: brakes, steering, lighting, structures, emissions and occupant protection.
Modern vehicles introduce a very different engineering environment. Software increasingly controls safety-critical functions while vehicles communicate continuously with external systems.
Vehicle characteristics remain largely fixed after production, with regulatory assessment concentrated around design approval and conformity of production.
Software, connectivity, backend services and emerging cyber threats can alter the vehicle’s operational environment throughout its service life.
Cybersecurity Becomes Part of Vehicle Type Approval
UN Regulation No. 155 establishes uniform provisions concerning the approval of vehicles with regard to cybersecurity and the Cyber Security Management System — CSMS.
The regulation creates two closely connected layers of assurance.
The manufacturer must demonstrate processes for identifying, assessing, treating and monitoring cybersecurity risks throughout relevant phases of the vehicle lifecycle.
The manufacturer must demonstrate that cybersecurity risks relevant to the vehicle type have been identified and appropriately addressed.
Cybersecurity Must Be Managed as a Lifecycle Process
The Cyber Security Management System changes the compliance model because approval depends partly on organizational capability rather than only on the characteristics of one vehicle.
Processes must identify relevant cybersecurity threats, vulnerabilities and potential attack paths.
Identified risks need to be evaluated according to their potential consequences and likelihood.
Appropriate design, technical and organizational measures are implemented to reduce cybersecurity risk.
Cybersecurity measures need supporting evidence demonstrating that they perform as intended.
New threats and vulnerabilities must continue to be considered after vehicles enter service.
Manufacturers require processes for responding when relevant cybersecurity issues are identified.
Cybersecurity management cannot finish when type approval is granted because the threat environment itself continues to change.
The Vehicle Attack Surface Extends Far Beyond the Vehicle
Connected vehicles interact with multiple internal and external systems. Cybersecurity assessment therefore needs to consider the complete ecosystem rather than only individual electronic components.
Internal communication networks and electronic control units can become potential attack paths.
Cellular, Wi-Fi, Bluetooth and other communication interfaces increase external connectivity.
Service and diagnostic access can introduce cybersecurity risks if inadequately controlled.
Manufacturer servers and connected services can influence vehicle functions and data.
Vehicle-control and user applications can become part of the wider cybersecurity boundary.
Third-party software, libraries, components and suppliers can introduce vulnerabilities outside the OEM’s direct development environment.
Software Updates Become Part of Regulatory Control
UN Regulation No. 156 establishes uniform provisions concerning software updates and the Software Update Management System — SUMS.
Its importance extends far beyond over-the-air updating. The regulation creates a structured framework for controlling software changes that can affect approved vehicle characteristics.
The manufacturer establishes processes for identifying, assessing, controlling, documenting and deploying vehicle software updates.
The vehicle and its update processes must satisfy applicable requirements relating to software identification, integrity and safe update execution.
Its wider purpose is to ensure that software updates are systematically controlled and that approval-relevant vehicle characteristics remain traceable as software changes.
Software Change Requires Governance
The Software Update Management System provides the organizational framework through which manufacturers control software updates affecting vehicles.
Relevant software versions and configurations need to remain identifiable and traceable.
Manufacturers need processes for determining how an update affects approved vehicle characteristics.
Changes must be assessed to determine whether additional testing, approval extension or other regulatory action is necessary.
Software-update packages and deployment processes require protection against unauthorized manipulation.
The vehicle must appropriately manage the installation process and relevant conditions for update execution.
Software changes and their relationship with the approved vehicle configuration require controlled records.
RxSWIN Connects Software to Type Approval
One of the important concepts introduced through the UN R156 framework is the Regulation Software Identification Number — RxSWIN.
Where applicable, RxSWIN provides a regulatory mechanism for linking software relevant to a particular UN Regulation with the vehicle’s approved configuration.
Traditional homologation identifies physical configurations, systems and components associated with an approval.
RxSWIN enables the applicable software configuration to become identifiable within the regulatory framework.
Two physically identical vehicles can behave differently because they contain different software. Regulatory traceability therefore increasingly needs to identify not only the hardware but also the software governing approved functions.
The Vehicle Can Change After It Leaves the Factory
Over-the-air updating allows manufacturers to modify vehicle software remotely without requiring every vehicle to visit a workshop.
The benefits are substantial. Manufacturers can correct faults, improve functionality, address cybersecurity vulnerabilities and deploy new capabilities across vehicle fleets.
But the same capability creates an unprecedented homologation question: what happens when an already-approved vehicle changes after it has entered service?
Determine the existing vehicle configuration and applicable regulatory approvals.
Evaluate whether the proposed update changes approval-relevant characteristics.
Verify that the modified software behaves as intended and continues to satisfy applicable requirements.
Deliver the update through controlled and protected mechanisms.
Ensure the vehicle can safely complete or appropriately manage the update process.
Maintain evidence of the resulting software and regulatory configuration.
Cybersecurity and Software Updates Cannot Be Managed Separately
UN R155 and UN R156 address different regulatory objectives, but operationally they are closely connected.
Identify threats and vulnerabilities, implement appropriate mitigation and continue monitoring cybersecurity throughout the relevant vehicle lifecycle.
Control, assess, document and deploy software updates while maintaining the vehicle’s applicable regulatory conformity.
The connection becomes especially clear when a cybersecurity vulnerability is discovered after vehicles have entered service.
The OEM Cannot Secure the Vehicle Alone
Modern vehicle software and electronic architectures depend on extensive supplier ecosystems. OEMs may integrate hardware, embedded software, operating systems, connectivity modules, cloud infrastructure and third-party services originating from many organizations.
Cybersecurity and software-management expectations need to be incorporated into supplier relationships.
OEMs need appropriate technical evidence from suppliers to support vehicle-level cybersecurity assessment.
Supplier software and component changes need controlled communication where they can affect vehicle conformity.
Newly identified vulnerabilities may require coordinated investigation and mitigation across multiple organizations.
The vehicle manufacturer remains dependent on evidence and cooperation from its supply chain while maintaining responsibility for demonstrating conformity of the vehicle type.
UN R155 and R156 Are Continuing to Evolve
Cybersecurity and software regulation cannot remain static because the technologies and risks they govern are themselves changing.
UNECE’s Working Party on Automated/Autonomous and Connected Vehicles — GRVA — and its specialist cybersecurity and software-update activities continue to develop the regulatory framework.
UN R156 has progressed to a new 01 series of amendments, reflecting continued development of the software-update regulatory framework.
The R156 interpretation document continues to be developed to support consistent application of software-update and SUMS requirements.
Further proposals concerning UN R155 and its cybersecurity-management framework remain under active UNECE consideration.
Cybersecurity and software-update provisions increasingly interact with other regulations governing electronically controlled vehicle functions.
Building Continuous Digital Conformity
R155 and R156 require manufacturers to think beyond individual approval tests and establish repeatable systems capable of supporting compliance throughout the vehicle lifecycle.
Build cybersecurity governance covering development, production, monitoring, incident response and relevant supply-chain activities.
Implement controlled processes for software identification, update assessment, validation, deployment and regulatory traceability.
Understand electronic systems, interfaces, data flows, software dependencies and potential attack surfaces.
Establish evidence, communication and change-control mechanisms across the software and component supply chain.
Maintain traceability between software configurations and the regulations affected by those configurations.
Maintain the ability to identify emerging cybersecurity issues and respond appropriately after vehicles enter service.
The real objective is to create an operating system of governance capable of supporting secure, controlled and demonstrably compliant vehicles as software and cyber risks evolve.
From Type Approval to Continuous Digital Conformity
UN R155 and UN R156 represent more than two additional requirements in the vehicle homologation portfolio.
They reflect a structural change in the relationship between vehicle engineering and regulatory conformity.
Cybersecurity threats can emerge after production. Software can change vehicle behaviour after approval. Vulnerabilities can originate within the vehicle, the supply chain or connected infrastructure. Regulatory evidence therefore has to extend beyond the traditional moment of type approval.
Compliance is concentrated around a relatively stable vehicle configuration.
Cybersecurity and software governance extend conformity into the operational life of the vehicle.