Device Identity at Manufacturing Scale

A deployment of one device with one credential is an engineering exercise. A deployment of a million devices, each with a non-clonable identity, each provisioned on a factory line, each able to rotate credentials in the field without recall, is an architectural problem with a small set of correct answers and a large set of expensive wrong ones. This is the engineering walk-through of the correct answers, from the personalisation line through OTA rotation to revocation across connectivity tiers, and the convergence between V2X, eSIM, and embedded IoT credential lifecycles.

If you have provisioned hardware at any volume, the surface symptoms of getting this wrong are familiar: a forensic investigation reveals plaintext keys in a manufacturing log; an OTA rotation campaign drops 12% of devices for reasons no one can reconstruct; a CRL bloats past the working memory of the verifier population; a regulator asks how per-device identities are protected on the line and the procurement team has nothing in writing. This piece is the architecture that prevents those outcomes.

Why scale changes the architecture

One device with one certificate is a manageable problem. Hundreds is still manageable. The constraints that fall out at six figures and above stop being engineering preferences and start being hard requirements.

1. Per-device uniqueness. No shared master key across the population. Extracting one device must not yield the cryptographic material that protects another. This is not a preference; it is the failure mode that took down enough deployments in the last fifteen years to settle the architectural question.
2. Issuance throughput. The personalisation line has to inject identities at production cadence (seconds per device, often parallelised across multiple SE programmers). The pipeline from HSM-side key derivation to SE-side persistence has to be designed for that throughput, not retrofitted onto it.
3. Field rotation without recall. A field-deployed device that requires a return-to-base for credential renewal is a deployment with a built-in attrition curve. Every operational credential lifecycle has to support over-the-air rotation under cryptographic continuity — the new credential proves itself using material the device already trusts.
4. Revocation across connectivity tiers. Always-connected fleets can poll; intermittent fleets refresh on next contact; offline fleets (notably V2X OBUs verifying PC5 sidelink) need pre-distributed revocation that has already arrived before the verification is needed. One revocation architecture, three distribution channels.
5. Audit and forensics. Every per-device injection has to leave an append-only, tamper-evident trace tying serial to identity to operator to timestamp. The trace is what makes the deployment defensible in a security review or regulatory audit.

The personalisation line

Every cryptographic property of a deployed device traces back to a moment on the personalisation line when key material was injected and the device was attested. Get the line right and the deployment has a defensible identity story for its lifetime. Get it wrong and no amount of operational hardening recovers the deployment.

// Personalisation line — defensible architecture

  ┌──────────────────────────────────────────────────────────────────┐
  │                       Manufacturing site                          │
  │                                                                   │
  │  ┌────────────┐    ┌──────────────────┐    ┌──────────────────┐  │
  │  │   HSM      │    │ Personalisation  │    │   SE programmer  │  │
  │  │   (cluster)│    │   host           │    │   (1..N parallel │  │
  │  │            │    │                  │    │    stations)     │  │
  │  │ holds:     │    │  receives:       │    │                  │  │
  │  │ - issuer   │◄───┤ wrapped APDU     │◄───┤  applies APDU    │  │
  │  │   keys     │    │ from HSM         │    │  to SE under     │  │
  │  │ - per-     │    │                  │    │  SCP03 session   │  │
  │  │   device   │    │ forwards         │    │                  │  │
  │  │   derivation│   │ wrapped APDU     │    │  SE generates    │  │
  │  │   logic    │    │ to SE programmer │    │  per-device key  │  │
  │  │            │    │                  │    │  inside boundary │  │
  │  │ split-     │    │ logs serial,     │    │                  │  │
  │  │ knowledge  │    │ operator,        │    │  returns         │  │
  │  │ custody    │    │ timestamp        │    │  attestation     │  │
  │  └────────────┘    └──────────────────┘    └──────────────────┘  │
  │         │                                                         │
  │         ▼                                                         │
  │  ┌────────────────────────────────────────────────────────────┐  │
  │  │   Append-only audit log                                     │  │
  │  │   (one entry per injection: serial, AID, key handle,       │  │
  │  │    operator badge, HSM session, station ID, timestamp,     │  │
  │  │    attestation hash)                                       │  │
  │  └────────────────────────────────────────────────────────────┘  │
  └──────────────────────────────────────────────────────────────────┘

Five properties separate a defensible line from an indefensible one. None are exotic; all of them are missed often enough that the failures are predictable.

1. Per-device keys are derived in the HSM, not generated on the host

The HSM holds the issuer keys and the per-device derivation function. The personalisation host never sees a plaintext per-device key. It receives an SCP03-wrapped APDU from the HSM and forwards it to the SE programmer; the unwrap happens inside the SE, under its base keys. The host’s exposure is bounded to ciphertext.

2. Key generation happens inside the SE for high-value keys

For keys the deployment must guarantee never existed outside the tamper boundary — the per-device device key, the V2X enrolment key — the SE generates the key pair inside itself in response to an APDU. The HSM contributes a derivation seed or a key handle assignment; the actual key never appears anywhere. For lower-value session derivation or wrapping keys, HSM-side generation followed by SCP03 transport is acceptable.

3. SCP03 protects every key-injection APDU

GlobalPlatform 2.3.1 Secure Channel Protocol 03 is the wire-level discipline: every APDU between the host and the SE is wrapped under session keys derived from card-resident base keys, with MAC and encryption applied per-command. A passive line-tap recovers only ciphertext; an active line-tap is detected by MAC failure on the SE side.

4. Per-device serial is authoritative and monotonic

The line has an authoritative serial counter (typically HSM-side) that increments per injection. The serial is part of the per-device derivation input, so the HSM cannot accidentally repeat an injection without producing a duplicate-serial alert. The audit log indexes by serial.

5. The audit log is append-only and tamper-evident

One entry per injection, never updated or deleted. Tamper-evidence via hash-chaining the log: each entry includes the hash of the previous entry, so tampering with any past entry invalidates every subsequent one. The log is the artefact a forensic audit will examine years after the deployment ships.

The smart-card personalisation solution page covers the operational mechanics of running such a line at production volume. The credential lifecycle management post covers the broader programme design that the line sits inside.

What gets injected, what gets generated

Not every key on a deployed device comes from the same place. A well-designed personalisation flow distinguishes three classes.

The architecturally important class is the manufacturer attestation key. It is the device’s lifetime trust anchor; it never rotates; it never leaves the SE. Every subsequent credential the device receives over the air authenticates through it. Get that key’s generation and protection right and the rest of the lifecycle has a foundation to build on.

OTA credential rotation

A factory-injected credential is the start of the lifecycle, not the end. The operational credentials evolve in the field. Three rotation patterns recur across deployments.

Pattern A: short-lived credentials with refresh

Used by V2X (PC batches refreshed every few weeks), eSIM (operational profiles refreshed on operator change), and some IoT mTLS deployments (short-lived certificates rotated on a daily/weekly cadence). The device authenticates with its long-lived identity, requests a new operational credential, installs it, and starts using it. The old credential expires under its own validity window.

Pattern B: re-keying with overlap

Used where credential lifetimes are months to years and an abrupt swap would risk fielded device failure. The new credential is issued with a validity window overlapping the old; both are active simultaneously for a few days; the verifier accepts either until the old expires. The device switches signing key at first verifier acknowledgement.

Pattern C: re-enrolment

Used for the long-lived identity itself — V2X EC re-enrolment before expiry, eUICC profile renewal. The device authenticates with the current long-lived credential, receives a new one, and persists it. The trust anchor underneath (the manufacturer attestation key) does not change; only the credential layered on top does.

All three patterns share the cryptographic-continuity property: the new credential proves itself using material the device already trusts. There is no "trust the network" hop. If a man-in-the-middle could intercept the rotation and substitute a credential the device would accept, the rotation is broken.

Revocation across connectivity tiers

A fleet revocation architecture has to work across three connectivity profiles. The cryptographic identity stays in the secure element; only the distribution channel for revocation status differs.

// Revocation by connectivity tier

  Always-connected (fleet trackers, smart meters with backhaul)
  ┌────────────────────────────────────────────────────┐
  │ • OCSP-style status check, or                       │
  │ • Short-lived certificates that expire faster      │
  │   than the revocation propagation window            │
  │                                                    │
  │ Latency: bounded by polling cadence                │
  └────────────────────────────────────────────────────┘

  Intermittent (industrial IoT, in-vehicle telematics)
  ┌────────────────────────────────────────────────────┐
  │ • CRL refresh on next connectivity event           │
  │ • Verifier maintains last-known CRL in SE; uses    │
  │   it until next refresh                            │
  │                                                    │
  │ Latency: bounded by connectivity reliability       │
  └────────────────────────────────────────────────────┘

  Offline (V2X OBU on PC5 sidelink, mesh sensors)
  ┌────────────────────────────────────────────────────┐
  │ • Pre-distributed CRL via infrastructure broadcast │
  │ • Linkage-based revocation: one seed revokes a     │
  │   whole batch of pseudonymous credentials          │
  │ • RSU rebroadcasts CRL to passing OBUs             │
  │                                                    │
  │ Latency: bounded by infrastructure encounter rate  │
  └────────────────────────────────────────────────────┘

The architectural lesson is that revocation is a distribution problem more than a cryptographic problem. The signing of the CRL by the issuing authority is mechanical. The hard work is getting the CRL to every verifier in the fleet within a bounded window, against any connectivity profile the deployment has to support. Pseudonymous certificates and privacy covers the linkage-based revocation mechanism in more detail.

eSIM / V2X / IoT convergence

The three credential-lifecycle architectures most production engineering teams encounter today — eSIM SGP.32 for IoT connectivity, V2X EA/AA for safety messaging, and embedded IoT identity for the rest of the fleet — converge architecturally. They solve the same shape of problem under different protocol surfaces.

The convergence has two practical consequences for the manufacturing line. First, the same silicon can host applets for all three: a single secure element can hold an eUICC, a V2X EC/PC management applet, and an IoT identity applet in parallel, AID-selectable under GlobalPlatform. One personalisation step, one identity story, three independent fleet authorities downstream. Second, the operational lessons transpose. The patterns that emerged from running SGP.22 / SGP.32 at telecom scale — unattended rotation, mutual-auth profile pull, fleet orchestration via a remote manager — directly inform V2X PC lifecycle and embedded IoT mTLS lifecycle. See the SGP.32 reference for the eSIM side and device identity at scale for the cross-architecture treatment.

Audit and forensics

The personalisation line’s defensibility lives in its audit log. Three properties make a log defensible.

• Append-only. No row updates, no deletions. New entries only. Achieved either through a database whose access controls forbid updates or, more strongly, through a hash-chained log file written to immutable storage.
• Hash-chained. Each entry contains the hash of the previous entry. Tampering with any past entry invalidates every subsequent hash. A periodic notarisation step writes the most recent hash to an external timestamping authority so that even the log’s end cannot be silently truncated.
• Multi-party signed. High-assurance lines have each entry signed by the personalisation host’s key plus a witness key held by a second operator. Removing the witness signature requires a coordinated insider attack rather than a single compromised host.

What the log contains per injection: per-device serial, AID and key handle of the injected key, operator badge (or shift identifier), HSM session ID, programmer station ID, timestamp, attestation hash, and a hash of the previous entry. If a forensic investigator asks "when was device serial X injected, on what station, by whom, and with what attestation" five years from now, the log answers.

Operational numbers from real lines

From production deployments (figures approximate, anonymised):

• Personalisation cycle time per device, single SE programmer: 1.5–3 seconds for a single applet, 4–8 seconds for a four-applet card.
• Parallelism: 8–32 SE programmers per line is typical; throughput scales near-linearly until HSM session limits dominate.
• HSM session pool: 200–1000 concurrent sessions for an enterprise-grade cluster; tune per derivation cost.
• Audit log volume: 1–3 KB per injection; a year of high-volume production produces tens to hundreds of GB.
• Yield loss specifically attributable to personalisation: under 0.5% in a stable line; spikes above 1% indicate an HSM session issue, a programmer firmware mismatch, or a wrapping-key rotation problem.

None of these are aspirational. They are the order of magnitude. Plan for them.

India context

India hosts manufacturing for multiple device classes covered by this architecture: connected vehicles, smart-meter endpoints, fleet trackers, payment terminals. The Telecom Regulatory Authority of India’s Consultation Paper of 30 April 2026 raises questions about how device-identity provisioning should be regulated under the proposed V2X security framework; the paper is a public document, referenced here factually. The architectural answer is the one this piece walks through — hardware-rooted identity, HSM-backed personalisation, OTA rotation, connectivity-tier-aware revocation — applied uniformly across V2X and the adjacent device populations a coherent national approach would address together.

SGP.32 IoT eSIM deployments and V2X PKI deployments share device populations and architectural patterns. A manufacturer running an Indian personalisation line for connected-vehicle SEs benefits from the same line being able to inject eSIM identity, V2X attestation, and IoT mTLS identity in parallel, under one defensible audit story.

What AmbiSecure ships in this architecture

• HSM-backed personalisation lines — the manufacturing-time provisioning infrastructure that satisfies the five properties in section 2. SCP03-equivalent wrapping, per-device serialisation, append-only audit logging, multi-station parallelism.
• IoT Security Co-Processor — the secure-element silicon that the per-device identity is injected into. Underlying SE silicon CC EAL5+ at the chip level.
• JavaCard applets — the applet platform inside the SE. Supports parallel-resident applets for eSIM, V2X EC/PC management, FIDO, PIV under one GlobalPlatform card manager.
• JavaCard development — custom applet engineering for deployments whose credential-management requirements do not fit an off-the-shelf applet.

The explicit boundary, also documented on the trust page: AmbiSecure does not operate the downstream fleet authorities (V2X EA / AA, eSIM SM-DP+ / SM-DS, IoT EST CA). The personalisation line provides defensible identity to whichever authority the integrator chooses. The lifecycle that follows is a separate engagement.

Architectural implication

Device identity at scale is not a feature of the secure element. It is a property of the whole provisioning system — the HSM custody, the personalisation-line discipline, the SE-resident applet logic, the audit log, and the lifecycle authority downstream — designed together. A well-engineered personalisation line on the wrong silicon is no defence; the best silicon on an undisciplined line is also no defence. The architectural answer is the union, not any one piece.

The convergence between V2X, eSIM, and embedded IoT credential lifecycles makes the union increasingly worth designing once. A manufacturer who treats the personalisation line as a single defensible artefact — serving V2X, eSIM, FIDO, and IoT applets in parallel — gets economies of scale that no per-product line achieves. The architecture this piece walks through is what makes that union feasible.

Related reading

• How V2X PKI works — the downstream V2X authority architecture this line serves.
• Secure elements in connected vehicles — the silicon side of the architecture.
• Pseudonymous certificates and privacy — the V2X-specific revocation deep-dive.
• Credential lifecycle management — the general programme-design pattern.
• Why software-only device trust fails — the threat model the architecture answers.
• Solution: device identity at scale · SGP.32 reference · ETSI TS 102 941 reference.