Mutual authentication with one shared client certificate across a vehicle fleet — what does it actually buy?

## The claim the verifier actually learns Mutual authentication means both ends prove an identity to each other. The word says nothing about **which** identity. With one credential shared across every unit, the strongest true statement the backend can make about a connection is *the peer possesses the fleet credential*. Everything the design wants to say — this vehicle, this customer, this region — is inference layered on an identity that does not support it. This matters because a threat model is a set of claims about what an attacker cannot do. Writing "mutual TLS" in the mitigation column asserts that impersonation is answered. With a shared credential, impersonation of a *specific unit* is not answered at all; only impersonation by a complete outsider is. ## The attacker position this scenario assumes Not an anonymous internet attacker and not a network eavesdropper: someone who **legitimately possesses one unit**. They bought a vehicle, or a scrapyard did. Physical possession of a device whose key is not held in hardware is a recovery problem, not a cryptography problem, and threat models that quietly assume the device is not opened are assuming away the attacker who is easiest to become. The asset at stake is credentials and keys — and derivatively whatever the fleet channel controls: telemetry that must be attributable, commands, remote diagnostics, over-the-air update eligibility. ## The three consequences to name **1. Blast radius.** One extraction yields an identity valid for every unit. A per-unit identity turns the same extraction into the compromise of one vehicle: the attacker can lie about their own unit, which is usually a containable fraud problem instead of a fleet-wide one. **2. Revocation is all-or-nothing.** With a shared credential, the only revocation available invalidates every unit simultaneously. That lever is so expensive that no one will ever pull it, so the honest entry in the model is *no effective revocation*. Per-unit identity makes revocation a routine, boring operation — and boring operations are the ones that actually get used during an incident. **3. Attribution disappears.** The backend cannot attach a message to a unit, so per-unit rate limits, duplicate-use detection and behavioural anomaly detection have no key to work with. Detection controls that would otherwise compensate for a weak identity are exactly the ones a shared identity disables — the failure modes compound rather than offsetting each other. ## What per-unit identity costs, honestly This is a tradeoff question, so present the cost side rather than declaring the answer: - **Provisioning.** Each unit needs a distinct key generated and an identity bound to it, at manufacture or first enrolment, which touches the production line and a supply chain you may not fully control. - **Key protection.** A distinct key in software on an openable device only raises the attacker's per-unit effort. Hardware-backed storage that makes the key non-exportable is what turns per-unit identity into real containment, and it is a bill-of-materials decision made years before the software ships. - **Lifecycle over bad links.** Renewal, rotation and revocation distribution have to work for units that are offline for weeks, in tunnels, in a container ship, or parked in a garage for a season. - **Running issuance.** Someone must operate the issuing authority for the life of the product, which for vehicles is longer than most backend services survive. ## Framing the decision The judgment to demonstrate is that identity granularity is chosen to match an **accepted blast radius**, and the choice is written down with the accepted risk beside it. A defensible outcome looks like one of these: - Per-unit identity with hardware-backed keys for anything that authorises commands or moves money; - A shared credential retained for a low-value read-only telemetry path, with a stated ceiling on what that path may assert and a plan for what happens the day a key surfaces publicly; - A staged position: per-unit identity from the next hardware revision, the existing fleet limited to what the weaker claim can support, and compensating detection in the meantime. **Compensating detection** for the interim is worth being concrete about, without over-promising: constrain what the shared identity is permitted to assert; require a second, separate factor for the small set of high-impact actions; and look for signals that are inconsistent with a single physical unit, such as the same identity appearing in two implausible places at once or at implausible volume. None of these restores identity — they buy time and evidence, and the model should say so rather than logging them as a mitigation. ## The general lesson A control is not a mitigation until the model states **what identity it proves, how the secret behind it is protected, and how it is revoked for one party**. Presence of the mechanism is the easiest thing to review and the least informative. On any machine-identity question — fleets, embedded devices, appliances, anything shipped rather than deployed — those three questions separate a design that will survive its first compromised unit from one that will not.