Mandatory cybersecurity standard for connected vehicles in force in China

A connected vehicle is no longer a mechanical product but a system operating on a network. Remote update, telematics and driver-assistance functions make the vehicle's safety inseparable from software.

This is why major markets are making vehicle cybersecurity part of conformity assessment. This approach, carried out in China through a mandatory national standard, adds the cybersecurity dimension to the vehicle's type-approval chain.

The common trait of such standards is that they require a management system rather than individual functions: risk assessment, secure development, vulnerability monitoring and incident response. In other words, the certificate becomes evidence of a process, not a test.

The supply chain also falls within scope. The manufacturer of a control unit or telematics module inside the vehicle must pass its own security evidence on to the OEM.

The international reference in vehicle cybersecurity is UNECE Regulations R155 (cybersecurity management system) and R156 (software update management system); they are widely used in the sector together with the ISO/SAE 21434 process standard.

A management system built according to these frameworks does not start from zero in meeting the requirements in China: most of the same process evidence can be reused. However, a separate gap analysis is needed for the local standard's own requirements.

This article concerns how the frameworks operate; for the standard's number, effective date and scope, the official announcement and the notification from the certification body you work with should be taken as the basis.

Cybersecurity in a connected vehicle carries a risk structure different from classic product safety. A brake hydraulic fault affects a single vehicle; a remotely exploitable software vulnerability, however, can affect an entire fleet of the same model simultaneously. This difference in scale also changes the regulator's approach.

This is why the approach adopted worldwide has shifted from testing the product one by one to auditing the MANUFACTURER'S SYSTEM: whether threat analysis and risk assessment are carried out, whether security requirements flow into the design, whether vulnerability disclosures are monitored, and whether software updates are distributed securely.

The second axis is software update management. Remote update is both the fastest way to close a security gap and the most dangerous channel if misused: integrity and source verification of the update chain is therefore regulated as a separate requirement.

The vehicle manufacturer is the addressee of type approval, but most vulnerabilities come from electronic units in the supply chain and third-party software components. This is why the obligation is passed downward through contracts.

The typical items required from the supplier are: an inventory of the software components and versions used, unit-level threat analysis, verification evidence of security requirements, and a commitment to vulnerability disclosure throughout the product's lifetime.

The component inventory is the most overlooked item and the most critical one: the question of which vulnerability exists in which unit cannot be answered without an inventory, and therefore vulnerability management cannot be operated.

The logic of cybersecurity requirements is similar across markets, but implementation diverges: which documents are to be submitted in which language, who will conduct the audit, and additional rules on data localisation and map/location data come from national regulations.

This is why a management system established in one market may not be directly accepted in another; the system itself is not rebuilt, but the evidence file is recompiled in the form the target market requires.

The most time-consuming items in planning are the audit appointment and the translation of documentation into the local language; when the technical work is finished, the process waits on these two items.