In a carmaker the identities that can unlock, locate or start a vehicle are not only in the car: they sit in dealer portals, employee support tools, owner apps, supplier accounts and back-end service credentials. Public research in 2024 and 2025 showed that a weakness in a dealer portal or an internal support portal could give remote commands over vehicles across whole model ranges, and the 2025 Jaguar Land Rover incident showed how an enterprise IT compromise can stop vehicle production for weeks. This guide covers identity security across the automotive enterprise: workforce and supplier access, dealer and partner identities, vehicle owner accounts and ownership changes, and the machine identities behind connected services. It is for CISOs, IAM leads and product security teams at manufacturers, large dealer groups and mobility providers. Vehicle-level engineering, UN R155 and R156 and V2X PKI are covered in the Automotive Cybersecurity Guide and the Connected and Autonomous Vehicle Security Guide; this page links rather than repeats them.
Key takeaways
- Back-office portals are vehicle controls. Any portal that can add a user to a vehicle or send a remote command must be protected like a privileged access system, with server-side authorisation and phishing-resistant MFA.
- Ownership is an identity lifecycle. Sale, lease return, rental and fleet transfer must remove previous users, keys and app links, and the current owner must be told when anyone is added.
- Dealers and suppliers are your largest external workforce. Their accounts need named owners, expiry and access reviews, because stale third-party credentials are a recurring entry point.
- Machine credentials outnumber people. Telematics API keys, service accounts, signing keys and per-vehicle certificates need inventory, rotation and the NHTSA principle that one vehicle's credential must not open another.
- Plan for enterprise identity failure. Manufacturing, dealer and connected services depend on the same directory and SSO; recovery planning must include rebuilding identity safely.
The automotive identity landscape
An automotive group runs several identity populations with very different risk. The table maps each to what it can reach and the main control.
| Identity population | Typical systems | What compromise allows | Primary control |
|---|---|---|---|
| Employees and contractors | Directory and SSO, engineering tools, plant IT, collaboration tools such as Jira | Data theft, ransomware, production stoppage | Phishing-resistant MFA, privileged access management, strong help desk verification |
| Customer support and internal admin staff | Connected services admin portals | Lookup of owners, vehicle location, remote commands | Treat as privileged access: server-side MFA, just-in-time elevation, per-action logging |
| Dealers and service partners | Dealer portals, warranty, diagnostics, vehicle enrolment | Adding users to vehicles, owner PII, reprogramming | Federated dealer identity, per-dealership scoping, expiry on staff accounts |
| Suppliers and engineering partners | Source repositories, PLM, test fleets, OT remote access | Source code and secrets exposure, plant access | Third-party access governance, secret scanning, brokered remote access |
| Vehicle owners and drivers | Owner app, connected services account, digital keys | Unlock, start, track the vehicle | Strong customer authentication, owner notification, ownership transfer process |
| Fleet and mobility customers | Fleet APIs, telematics integrations, insurers | Bulk location and command access | Scoped OAuth clients, separate read and command scopes |
| Machine identities | Vehicle and telematics certificates, service accounts, API keys, code signing keys | Impersonation of vehicles or services, malicious updates | Inventory, unique per-unit keys, HSM-held signing keys, rotation |
Dealer and internal portals: the highest-impact identities
Two disclosed research cases show the pattern. In research published in September 2024, Sam Curry and colleagues reported that a Kia dealer-facing portal and its APIs did not properly restrict access, allowing remote lock, unlock, start and location functions, retrieval of owner name, phone, email and address, and silently adding an attacker as a secondary user, on hardware-equipped vehicles from model years 2014 to 2025 whether or not a subscription was active. They reported it to Kia on 11 June 2024; Kia said it had remediated the issue by 14 August 2024, and the researchers state it was never exploited maliciously. In January 2025 the same researchers published findings on Subaru's STARLINK admin portal for employees: a password reset that did not require a valid confirmation step and a two-factor check enforced only in the browser. Access would have allowed remote commands, current location, a year of location history and customer contact details. Subaru fixed it within a day of the 20 November 2024 report, and the researchers report no malicious use.
The lessons are identity lessons, and they apply to every manufacturer:
- Enforce authentication server-side: MFA checked only in the client is not MFA. Test that every API behind the portal rejects requests from sessions that skipped a factor.
- Harden account recovery: password reset for staff with vehicle-command rights must require proof of the existing factor or a verified identity check. See the Account Recovery and Help Desk Security Guide.
- Authorise every object: a dealer account should only see vehicles and customers linked to its dealership and only during an active service or sale. Self-registration for dealer accounts must require approval by the manufacturer or dealer principal.
- Separate lookup from command: support staff who answer owner questions rarely need to send remote commands. Make commands a separate, approved and logged privilege.
- Notify the owner: adding a secondary user, a new digital key or a new app login should trigger a notification to the primary owner through an existing channel, which turns silent account takeover into a visible event.
- Rate-limit and alert on bulk use: a staff or dealer account touching hundreds of VINs in an hour is a signal, whatever its permissions.
Owner identity and the ownership lifecycle
A vehicle may have five or more owners over its life, plus drivers, lessees and rental customers. The connected services account must follow the vehicle, not the person who first registered it.
| Lifecycle event | Identity risk | Control |
|---|---|---|
| First registration | Someone other than the buyer claims the VIN | Proof of possession (in-vehicle confirmation or dealer-verified sale) before activation |
| Adding drivers and shared keys | Over-broad, permanent access | Time-limited, feature-limited sharing; the CCC Digital Key ecosystem describes owner-controlled sharing of duration and features, such as limiting a key to the boot |
| Private sale | Previous owner keeps app control and location | Ownership transfer that revokes all users and keys; FTC consumer guidance tells sellers to disconnect manufacturer apps and cancel or transfer connected services, so do not rely on the seller remembering |
| Lease return, rental and fleet rotation | Earlier drivers retain access | Automatic revocation at check-in through fleet APIs; reset of in-vehicle profiles |
| Account takeover | Credential stuffing or SIM swap gives vehicle control | Passkeys or strong MFA for command functions, step-up before unlock or start, notification of new devices. See the Account Takeover Prevention Guide |
| Scrappage or total loss | Telematics unit remains active with credentials | Deactivate and revoke the device certificate |
Delegated access (a family member, a fleet manager, a carer) is a recognised customer identity pattern; see Delegated and Proxy Access in CIAM. Connected car data is also personal data under privacy law; the Connected Car Privacy Guide covers that side.
Workforce, supplier and production identity
The Jaguar Land Rover cyberattack began on 31 August 2025; production paused from 1 September and a phased restart began on 8 October. The Cyber Monitoring Centre estimated the UK economic cost at £1.9bn. JLR has not disclosed the entry point: reports that staff were phoned for credentials have been disputed by its former group CISO. A separate March 2025 breach of JLR's Jira server used valid credentials belonging to a third-party employee that, according to Hudson Rock, had been harvested by infostealer malware years earlier and never changed.
- Third-party accounts: every supplier and contractor account needs a named internal owner, an expiry date and periodic review. See the Third-Party Access Guide.
- Infostealer exposure: monitor for employee and contractor credentials in infostealer logs and force resets and session revocation. See the Infostealer Logs Response Guide.
- MFA beyond email: apply phishing-resistant MFA to collaboration, source code and engineering tools, not only email and VPN. See the Phishing-Resistant MFA Guide.
- Source code and repositories: automotive source has leaked through weak repository identity. The Nissan Source Code Leak involved a Git server left on admin/admin, and the Mercedes-Benz Source Code Leak came from open GitLab registration. Disable self-registration and default accounts on every engineering platform.
- Plant access: remote access to manufacturing OT should go through a broker with per-session approval, separate from the IT directory where practical. See the Manufacturing Identity and OT Access Guide.
- Recovery: production, dealer and connected services often share one identity provider. Keep a tested plan to rebuild the directory and privileged accounts from a clean state, since containment that disables identity also stops the business.
Machine identities in connected services
NHTSA's Cybersecurity Best Practices for the Safety of Modern Vehicles (2022) sets several identity principles: [T.1] developer-level access should be limited or eliminated where there is no foreseeable operational reason; [T.4] credentials for elevated access should be protected from disclosure or modification; [T.5] a credential obtained from one vehicle should not provide access to other vehicles; [T.8] global symmetric keys for diagnostic access should be minimised; [T.9] tools that can perform diagnostics and reprogramming should have controlled access; and [G.42] connections to third-party devices should be authenticated with limited access.
- Back-end keys: the Toyota T-Connect Key Exposure left an access key on public GitHub for five years, and the Mercedes-Benz GitHub Token Exposure opened internal source through one employee's repository. Run secret scanning across your own and suppliers' repositories. See the Secrets Management Guide.
- Engineering clouds: the Tesla Kubernetes Cryptojacking case exposed cloud credentials through an unauthenticated console. Test and telemetry environments need production-grade identity.
- Fleet and partner APIs: one OAuth client per integration, separate read and command scopes, short-lived tokens. See the API Key Management Guide and the Connected Fleet and Telematics Security Guide.
- Vehicle and charger certificates: plan issuance at end of line, over-the-air renewal and revocation at decommission. See the Device and IoT Identity Guide, the Machine Identity, PKI and Certificate Lifecycle Guide and the EV Charging Security Guide.
Regulation and where identity sits in it
| Requirement | Identity relevance | Where to read more |
|---|---|---|
| UN Regulation No. 155 (CSMS) | Threats to back-end servers and unauthorised access are part of the risk assessment the regulation expects | UNECE R155 CSMS Guide |
| ISO/SAE 21434 | Threat analysis covers credentials, diagnostics and back-end interfaces through the lifecycle | ISO/SAE 21434 Guide |
| NHTSA Cybersecurity Best Practices (2022) | T.1, T.4, T.5, T.8, T.9, G.42 as above (non-binding US guidance) | NHTSA publication |
| US connected vehicles ICTS rule | Supply chain restrictions on connected vehicle software and hardware | US Connected Vehicles ICTS Rule Guide |
| Privacy law (for example GDPR) | Owner and location data access must be limited and accountable | Connected Car Privacy Guide |
How to implement
The steps below are NHI Mgmt Group recommendations.
- Map who can command a vehicle: list every portal, API and tool that can add users, locate, unlock or start a vehicle, with the identity types that use each. This list is your privileged access scope.
- Fix authentication on that list first: server-side MFA, hardened recovery, removal of self-registration, object-level authorisation tests. Use penetration testing or a bug bounty focused on these portals.
- Add owner notifications and step-up: pilot notifications for new secondary users and keys on one brand or market, then roll out.
- Build the ownership transfer process: integrate with dealer sale systems and fleet APIs so transfer revokes previous access automatically; offer a self-service route for private sales.
- Govern dealer and supplier identities: federate where possible, set expiry, run quarterly reviews with dealer principals and supplier managers.
- Inventory and rotate machine credentials: start with keys that grant command or location access, then signing keys and service accounts.
- Test recovery: run an exercise that assumes the corporate identity provider is unavailable; confirm how plants, dealers and connected services operate and how identity is rebuilt. Each change above should have a rollback, for example disabling a new notification rule by feature flag.
Decision guidance
- Manufacturers: own the full list; treat connected services admin, dealer enrolment and diagnostics as privileged access with PAM-grade controls.
- Dealer groups: focus on staff joiners and leavers across the manufacturer portals you use, shared logins on service desks, and customer handover at sale.
- Fleet, leasing and rental: automate revocation on every vehicle return and keep separate API clients per customer.
- Suppliers: expect manufacturers to require MFA, secret scanning and named accounts; build them in before contract renewal.
Detection and measurement
- Command-capable accounts with phishing-resistant MFA: target 100 percent of staff and dealer accounts.
- Secondary user additions without owner acknowledgement: count and investigate.
- Transfer revocation time: hours from registered sale or return to removal of previous access.
- Third-party accounts past expiry or without owner: target zero.
- Bulk VIN access alerts: accounts exceeding a per-hour threshold of distinct vehicles queried or commanded.
- Exposed credentials: time from a secret scanning or infostealer hit to rotation.
Common failure patterns
- Client-side security on internal portals: MFA or role checks enforced only in the browser.
- Open dealer self-registration: anyone who reaches the portal can become a dealer user.
- Silent secondary users: no owner notification when access is added.
- Ownership that never transfers: previous owners keep app control after a sale.
- Stale contractor credentials: as in the JLR Jira breach, unchanged credentials from an old infection stay valid.
- Secrets in repositories: back-end keys in public code, as in the Toyota and Mercedes-Benz cases.
Framework mapping
| Framework | Reference | Application |
|---|---|---|
| NIST CSF 2.0 | PR.AA-01, PR.AA-05, GV.SC-07 | Identities for users, services and hardware; least privilege; supplier risk |
| NIST SP 800-53 Rev. 5 | AC-2, AC-6, IA-2, IA-3, IA-5 | Account management, least privilege, user and device authentication, authenticators |
| ISO/IEC 27001:2022 | Annex A 5.16, 5.17, 5.19, 8.5 | Identity management, authentication information, supplier relationships, secure authentication |
| MITRE ATT&CK | T1078 Valid Accounts, T1199 Trusted Relationship, T1552.001 Credentials In Files, T1098 Account Manipulation | Stolen staff and partner credentials, supplier access, leaked keys, adding users to accounts |
Practitioner checklist
- List every system that can add users to, locate, unlock or start a vehicle.
- Enforce server-side, phishing-resistant MFA for all staff and dealer accounts on that list.
- Require identity verification for password and MFA resets of privileged staff.
- Remove self-registration and default accounts from dealer and engineering platforms.
- Notify the primary owner whenever a user, key or device is added.
- Automate revocation of previous users at sale, lease return and rental check-in.
- Give every supplier and contractor account an owner and expiry date.
- Monitor infostealer and secret scanning sources and rotate exposed credentials quickly.
- Ensure no credential from one vehicle opens another (NHTSA T.5).
- Exercise rebuilding the corporate identity provider after a destructive incident.
Standards and references
- NHTSA: Cybersecurity Best Practices for the Safety of Modern Vehicles (2022)
- Car Connectivity Consortium: Digital Key
- US Federal Trade Commission: Selling your car? Clear your personal data first
- Sam Curry: Hacking Kia, remotely controlling cars with just a licence plate
- Sam Curry: Hacking Subaru, tracking and controlling cars via the STARLINK admin panel
- NIST: SP 800-53 Rev. 5
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: Automotive Cybersecurity Guide · Connected and Autonomous Vehicle Security Guide · Vehicle Security Operations Centre Guide · Third-Party Access Guide · Customer IAM (CIAM) Guide