Identity for Automotive: Connected Cars, Dealers, and UN R155

Automotive identity has to serve three very different populations at once: the people who own and drive the car, the dealers and suppliers who sell, service, and build it, and the machines themselves, from the vehicle and its electronic control units (ECUs) to the cloud services they talk to. A failure in any of the three can lead to the same outcome: someone who should not be able to locate, open, or update a vehicle gains that ability. See the automotive vertical page for the sector overview.

Owners, drivers, and the vehicle

A connected-car app looks like ordinary customer identity, but the account is tied to a physical object that changes hands. Cars are sold, leased, rented, shared within families, and run in fleets. Good designs separate three things:

• The person (a customer identity with passkeys or strong MFA).
• The relationship to a vehicle (owner, secondary driver, fleet manager, renter), with a start and end date.
• The vehicle identity itself, anchored in a certificate on the telematics unit.

The relationship is where most problems hide. Binding should require proof of ownership, such as the dealer sale record or an action performed inside the car, and a sale or lease return must remove the previous owner's binding. Remote commands (door release, engine start, locate) deserve step-up authentication and per-user logging, because they carry physical-safety consequences.

Dealers, suppliers, and partners

Manufacturers run large external identity populations: dealership staff with high turnover, independent repairers, parts suppliers, logistics firms, and fleet customers. These users usually reach portals that can look up customers, change vehicle ownership, or issue diagnostic and remote commands.

That access is a direct path to the vehicle. In 2024, researchers Sam Curry and colleagues showed that weaknesses in Kia's dealer-side web infrastructure let them register as a dealer, look up a vehicle from its license plate, and send remote commands such as opening the doors and starting the engine. Kia fixed the issues after the report and said they had not been exploited maliciously. The identity lessons are general: dealer accounts should come from a federated, governed source rather than self-registration, permissions should be scoped to the dealer's own customers and vehicles, and ownership changes made through a dealer portal should notify the current owner.

Practical controls for partner access:

• Federate dealer and supplier identity through SAML 2.0 or OpenID Connect where partners have their own directory, with joiner and leaver events tied to the partner relationship.
• Time-bound, role-scoped access for engineering and diagnostic systems, with privileged access controls for plant-floor and telematics backends.
• Regular access reviews of partner accounts, since stale accounts at former dealers are a recurring weak point.

Machine identity at fleet scale

Each vehicle can contain dozens of ECUs, a telematics unit, and an infotainment system, and talks to backend services for remote commands, maps, payments, and charging. Machine identity, usually X.509 certificates from a manufacturer PKI, authenticates these components to each other and lets the vehicle verify signed software updates. EV charging adds another layer: Plug and Charge under ISO 15118 uses certificates so the car can authenticate to a charger and start billing without a card.

The distinctive constraints are scale and lifetime. Fleets run to millions of vehicles that stay on the road for 15 years or more, so certificate lifecycle automation (issuance at the factory, rotation in the field, revocation when a unit is replaced or compromised) matters more than issuance. Planning for algorithm changes, including post-quantum cryptography, should be part of that design, because keys provisioned today may still be in service in the late 2030s.

UN R155, ISO/SAE 21434, and other rules

UN Regulation No. 155, adopted under the UNECE WP.29 1958 Agreement and in force since January 2021, requires manufacturers to operate a certified cybersecurity management system covering development, production, and post-production, and to demonstrate risk management for each vehicle type. In the EU it applied to new vehicle types from July 2022 and to all newly registered vehicles from July 2024. Its companion, UN Regulation No. 156, covers software update management. ISO/SAE 21434:2021 sets out the cybersecurity engineering process that many manufacturers use as evidence for R155.

Neither text prescribes a specific identity product, but both expect controlled, auditable access to vehicle systems, protected keys, and authenticated updates. Owner and telematics data also falls under privacy law such as GDPR and CCPA/CPRA, and motor vehicle manufacturing is listed among the "other critical sectors" in Annex II of the EU NIS2 Directive. The regulations hub tracks these by country.

Choosing platforms

Automotive identity is rarely one product. Workforce and partner access typically runs on Microsoft Entra or Okta; vehicle and device certificates run on PKI and certificate-lifecycle platforms such as Keyfactor, DigiCert, and Venafi (now Idira Certificate Manager, part of Palo Alto Networks); and owner apps run on a CIAM platform. The machine identity for enterprises ranking compares certificate and machine identity options. Whatever the stack, treat the binding between people, partners, and vehicles as the asset to protect, because that binding is what decides who can open the car.