Type approval / homologation

Type approval (homologation) is the regulatory process certifying that a vehicle type meets all applicable technical requirements before it may be sold or registered in a market. Rather than testing every individual vehicle, an authority approves the type — a design plus its documented variants — and the manufacturer then certifies that each produced vehicle conforms to it. In the EU and the broader UNECE framework, an approval issued by one member’s authority is recognized across the others; the US instead uses manufacturer self-certification against FMVSS rules.

Software changed what homologation covers. Approval requirements now include the manufacturer’s cybersecurity management system (R155), its software update management system (R156), and increasingly the behavior of driver-assistance features that can change after sale. An OTA update that alters a regulated function can invalidate an approval if not handled through the defined processes.

How the system works

The EU’s framework is Regulation (EU) 2018/858, which applies since September 2020 and defines the roles. Each member state designates an approval authority — well-known examples include Germany’s KBA and the Netherlands’ RDW — which grants, extends and can withdraw approvals. Testing and assessment are largely carried out by technical services, independent organizations designated and supervised by the authorities. A manufacturer can seek approval from any EU authority, and the resulting whole-vehicle type approval is valid across the single market.

Whole-vehicle type approval is itself an assembly: dozens of separate system-level approvals — braking, lighting, emissions, and now cybersecurity and software updates — stack into one certificate for the complete vehicle. On top of the initial grant sit two continuing obligations: conformity of production, proving that vehicles coming off the line still match the approved type, and market surveillance, strengthened considerably in 2018/858 after the diesel-emissions scandal exposed the weakness of approve-and-forget.

Internationally, the UNECE 1958 Agreement provides mutual recognition of approvals issued against UN regulations among its contracting parties — which is how a single set of UN rules such as R155 and R156 can gate market access across the EU, the UK, Japan and South Korea at once.

Two regulatory philosophies

The type-approval world and the US self-certification world embody different theories of control. Under type approval, a third party checks compliance before market entry; under FMVSS self-certification, the manufacturer declares compliance and NHTSA polices the market afterward through investigations and recalls. Neither is strictly stricter — the US recall system has real teeth — but the difference matters enormously for software. Approval regimes must decide in advance how changeable software fits into a fixed approved type; a self-certification regime pushes that question into after-the-fact enforcement. This is why the UNECE bloc produced R155 and R156 while the US, so far, has not adopted equivalents.

The software turn

For most of its history, homologation assumed the approved artifact was stable: the vehicle tested was, in every relevant respect, the vehicle sold and driven for fifteen years. Software broke that assumption, and the regulatory response came in layers. The EU’s General Safety Regulation, Regulation (EU) 2019/2144, pulled the UN cybersecurity and software-update regulations into the mandatory approval scope from July 2022 (new types) and July 2024 (all new registrations), and added requirements for a growing list of software-heavy assistance systems.

The result is that approval now attaches partly to processes rather than only to the artifact: the manufacturer’s ability to manage security risk and software change over the vehicle’s life is itself an approval condition. When software relevant to a regulation changes, R156’s identification mechanism (RXSWIN) signals it, and the manufacturer must judge — defensibly, with documentation — whether the change is covered by existing evidence or requires an extension of the approval.

Common misconceptions

Type approval is often confused with certification of an individual car; it is the design that is approved, with conformity of production bridging to the vehicles actually built. A second misconception is that approval ends at start of sales — the continuing obligations, from production conformity to post-production cybersecurity monitoring, now run for the life of the type. A third is that homologation is a purely European concern: through the 1958 Agreement and parallel adoption in Japan and South Korea, UN-regulation approvals shape global platform engineering, and even manufacturers focused on the US market build to them when the same platform sells elsewhere.

Homologation as an engineering discipline

For software-defined vehicle programs, the practical consequence is that homologation stopped being a one-time gate at the end of development and became a continuous discipline running alongside it. Every planned OTA release carries a regulatory classification; approval evidence must be versioned with the software it describes; and the compliance function needs tooling and cadence matched to the release train, not to an annual model-year rhythm. Feature velocity in regulated markets is limited less by what software teams can build than by what can be proved compliant — which is why compliance throughput has quietly become a competitive variable among OEMs.

What to watch

The pressure point is cadence. Approval processes built for occasional hardware changes are being asked to absorb continuous software change, and regulators are working on how to handle software-only updates with less per-change friction without weakening the gate. Adjacent regulation keeps widening the surface: assistance and automation features bring approval requirements that reach into how software behavior is validated, and data-access rules such as the EU Data Act add obligations that intersect with approved telematics and diagnostic designs. The open question for the second half of the decade is whether type approval adapts into something closer to continuous conformity — or remains a gate that SDV programs must repeatedly re-enter.