KBA Type Approval for Cybersecurity: How Technical Services Assess R155 and R156

If your vehicle types are approved in Germany, the cybersecurity part of the approval goes through the Kraftfahrt-Bundesamt (KBA) and one of the technical services it has designated. The regulations, UNECE R155 for cybersecurity and R156 for software updates, set out what must be true. They say much less about who checks it, in what order, and what evidence the checker expects. This post covers that structure as the regulations and KBA’s published guidance describe it: the two certificates, the two levels of assessment, where supplier evidence comes in, and what continues after approval. It summarises public sources as of October 2026 and is not legal advice.

Who Does What: KBA and the Technical Services

KBA is Germany’s type-approval authority. On its cybersecurity and software-update page, KBA lists its own tasks: designating the technical services, carrying out its own audits of the management system and, where applicable, of the product, issuing, suspending or withdrawing the certificates, and granting type approvals. Together with the Federal Office for Information Security (BSI), it also evaluates reports of incidents that affect vehicle cybersecurity.

The technical services do most of the assessment. In KBA’s description, a technical service generally audits the management system (CSMS or SUMS) and the approval object, then sends its test reports and the relevant manufacturer information to KBA. R155 itself (paragraph 5.3.1) requires both the authority and its technical services to have competent staff with cybersecurity skills and specific knowledge of automotive risk assessment.

KBA has designated several organisations for R155 and R156 since 2021. Trade press reported TÜV Rheinland and GTÜ’s subsidiary Ateel in April 2021 and TÜV SÜD in June 2021, and DEKRA announced its designation in August 2021. Designations change, so check the current list with KBA before you plan around a particular service.

Two practical points come from KBA’s guidance. Application and description documents can be submitted in English, although German is preferred. And KBA publishes its catalogue of requirements for auditing CSMS and SUMS, along with checklists for process verification, test procedure and risk analysis, and guidelines on manufacturer reporting. Reading them before the first audit is the cheapest preparation available.

R155 Is Assessed in Two Steps

UN Regulation No. 155 treats the organisation and the product separately. First the manufacturer earns a certificate for its management system. Then each vehicle type is approved on its own evidence. The two are linked: a vehicle type cannot be approved without a valid certificate, and if the certificate lapses, every type that depends on it is affected.

Step 1: The CSMS Certificate of Compliance

The manufacturer applies with documents describing its CSMS and a signed declaration (paragraphs 6.2–6.3). The assessor checks that the CSMS exists and complies (7.2.1), that it covers the development, production and post-production phases (7.2.2.1), and that it contains processes for each of the following (7.2.2.2):

• managing cybersecurity within the organisation;
• identifying risks to vehicle types, considering the Annex 5 Part A threats and any other relevant threats;
• assessing, categorising and treating those risks;
• verifying that the identified risks are properly managed;
• testing the cybersecurity of a vehicle type;
• keeping the risk assessment current;
• monitoring for, detecting and responding to cyber-attacks, threats and vulnerabilities, and checking that existing measures still work against new ones;
• providing the data needed to analyse attempted or successful attacks.

Two more requirements reach into the supply chain. Monitoring must be continual and must include vehicles after first registration (7.2.2.4). The manufacturer must also show how the CSMS handles dependencies on contracted suppliers, service providers and its own sub-organisations (7.2.2.5). The certificate is valid for a maximum of three years (6.7), and the authority may check at any time that the requirements are still met (6.8). The manufacturer must apply for renewal early enough for the authority to finish its assessment (6.10). If the certificate expires or is withdrawn, that is treated as a modification of every vehicle-type approval that relies on it (6.11).

Step 2: The Vehicle Type

With a valid certificate (7.3.1), the manufacturer applies for approval of a vehicle type, and the obligations become specific. The manufacturer must manage supplier-related risks for the type (7.3.2). It must identify the critical elements and run an exhaustive risk assessment that considers all Annex 5 Part A threats (7.3.3). It must put proportionate mitigations in place, including the relevant Annex 5 Part B and C measures or justified alternatives (7.3.4), and secure any dedicated environments for aftermarket software (7.3.5). Before approval it must test that the security measures are effective (7.3.6). The type also needs measures to detect and prevent attacks, support monitoring and enable forensic analysis (7.3.7), and its cryptographic modules must follow consensus standards or be justified (7.3.8).

R155 also sets out how the assessor checks this. Document checks cover supply-chain information, the risk assessment, test results, mitigations, detection and logging (5.1.1). The assessor also tests a vehicle of the type, either alone or together with the manufacturer, by sampling that focuses on, but is not limited to, risks assessed as high (5.1.2). Approval must be refused if the risk assessment did not consider all Annex 5 Part A threats, if testing was not appropriate and sufficient (5.1.3), or if the assessor did not receive enough information to assess the type (5.1.4).

R156 Runs in Parallel: SUMS and the Vehicle Type

UN Regulation No. 156 follows the same pattern for software updates. It applies to vehicles in categories M, N, O, R, S and T that permit software updates. The SUMS certificate of compliance is also valid for a maximum of three years (6.6). At the initial assessment, the assessor checks the processes behind it (7.1.1):

• documentation that is held securely and available to the authority;
• unique identification of software versions and their integrity data;
• RXSWIN management and consistency checks;
• identification of interdependencies between systems;
• identification of target vehicles and compatibility checks;
• an assessment of whether an update affects type-approved systems or adds or changes functions.

The manufacturer must also show that updates and the update process are protected against manipulation (7.1.3). For over-the-air updates, it must show how safety is handled (7.1.4).

For the vehicle type (7.2), updates must be protected for authenticity and integrity. Each RXSWIN must be uniquely identifiable, readable through a standardised interface (at least the OBD port) and protected against unauthorised modification. Vehicles that update over the air must be able to recover or reach a safe state after a failed update, check that there is enough power before starting, and inform the user. There is one structural difference from R155: under R156, existing type approvals do not lose their validity when the SUMS certificate expires (6.10). KBA also publishes its own categories of software update, grouped by their effect on the type approval. Read them before your first over-the-air campaign after approval. Our UNECE R156 compliance page covers SUMS in more depth.

What an Assessment Typically Reviews

Each technical service applies its own audit methods. KBA’s guidance says technical services are free to choose their means and methods, so the depth and order vary. The areas below are the ones the regulation text and KBA’s guidance point to. Treat them as a map of where the questions will come from, not a fixed script.

Testing: What KBA Says

On testing, KBA’s published FAQ is unusually direct. It calls penetration tests standard tools for cybersecurity verification and says its extended designation rules list them as recommended, not mandatory. Other test methods may meet the same objective, but documentation alone is generally not enough. The FAQ adds that manufacturers can set up their own test programmes, including component tests, and can require suppliers to run specific tests and provide the evidence. So the 7.3.6 evidence is a set of test results tied back to the risk assessment. Our R155 Annex 5 penetration testing checklist shows one way to structure it, and the UNECE R155 compliance page covers the CSMS side.

How Tier-1 Suppliers Feed Evidence In

A Tier-1 is not the applicant. KBA’s FAQ states that Tier suppliers are generally not audited during approvals by KBA or the technical services. Paragraphs 5.1.1(a) and 7.2.2.5 of R155 make the manufacturer, as the approval holder, responsible for supply-chain risk. KBA adds that the OEM can place requirements on Tier-1s and require them to pass those requirements on to Tier-2. A supplier’s evidence therefore reaches the assessor through the OEM’s file, and it has to arrive in a form the OEM can integrate. For a component supplier, that usually means:

• A Cybersecurity Interface Agreement under ISO/SAE 21434 Clause 7 that fixes who does which activity (TARA input, testing, vulnerability handling) and which work products are exchanged.
• Component-level risk analysisbuilt on the OEM’s item boundaries and assumptions, so its threats map onto the vehicle-type risk assessment without translation.
• Verification evidence (ISO/SAE 21434 Clause 10) for the security functions the component provides: test specifications, results, open findings and how each was treated, each referenced to the Annex 5 threats it addresses.
• Vulnerability monitoring and disclosure arrangements(Clause 8) that feed the OEM’s continual monitoring and annual report, with named contacts and agreed response times.
• Software identification and integrity data that the OEM needs for its RXSWIN register and its R156 update processes.

None of this is a separate certification for the supplier. Its value is that the OEM can put it in front of the technical service without rework. Our ISO/SAE 21434 consulting work is mostly about producing these work products so they line up with the OEM’s structure from the start.

Preparation Checklist for an OEM

The sequence below follows the regulations and KBA’s published process. It gives no durations on purpose. Those depend on the programme, how mature the CSMS is, and the technical service’s capacity.

Timeline: Cars Now, Two-Wheelers from 2027

In the EU, R155 and R156 became mandatory through Regulation (EU) 2019/2144: for new vehicle types from 6 July 2022, and for all new cars, vans, trucks and buses from 7 July 2024. The UNECE text of R155 itself covers categories M and N, category O when fitted with at least one ECU, and L6 and L7 vehicles with automated driving from level 3 upwards (paragraph 1).

For the wider L-category, Commission Delegated Regulation (EU) 2025/1455 applies the R155 cybersecurity requirements to L-category vehicles, except L1e vehicles designed to pedal. New types must comply from 11 December 2027 and existing types from 11 June 2029. Motorcycle and three-wheeler manufacturers approved in Germany will go through the same KBA and technical-service structure described above. Our two-wheeler R155 post sets out the L-category roadmap.

Take-Aways

KBA approval for cybersecurity is a sequence, not a single event. It starts with a management-system certificate that has to stay valid, continues with a vehicle-type assessment that the technical service can test by sampling, and carries on with reporting for as long as the type is in the field. Prepare the CSMS and SUMS evidence as records rather than policies, build the vehicle-type file around the Annex 5 risk assessment and real test results, and tell suppliers early what form their evidence must take. For how R155 and R156 sit alongside the Cyber Resilience Act, NIS2 and TISAX, see the automotive cybersecurity regulations map. For the information-security assessment many German OEMs require before sharing development data, see TISAX for automotive suppliers.

Primary sources: UN Regulation No. 155, UN Regulation No. 156, KBA: cybersecurity and software updates, Regulation (EU) 2019/2144, Delegated Regulation (EU) 2025/1455. Paragraph numbers refer to the original R155 and R156 texts; check the consolidated versions for later supplements. This article is not legal advice; confirm specific requirements with KBA and your technical service.

Agnile Technologies provides automotive penetration testing and ISO/SAE 21434 engineering support to OEMs and Tier-1 suppliers, with evidence structured for the technical services that assess vehicle-type cybersecurity. Agnile is not a technical service or an approval authority.