Device identity at scale.
Millions of devices, each with a non-clonable identity, each provisioned at manufacturing, each rotating credentials in the field without recall, each revocable on a per-device basis. The cryptography is settled; what determines whether a deployment survives a decade is the architecture around the keys — the hardware root, the provisioning line, the lifecycle authority, the revocation channel.
Why "issue a certificate" stops being a sentence at six figures.
One device with one certificate is a manageable problem. A pilot of a hundred devices is a manageable problem. The architectures that work at a hundred do not survive a million. At fleet scale, four constraints stop being engineering preferences and start being hard requirements.
Issuance throughput. A connected-vehicle deployment refreshing pseudonymous certificates at the cadence ETSI TS 102 941 contemplates issues credentials at sustained rates that a single CA tier cannot serve. Issuance has to be batched, parallelised, and structurally split between the authority that knows the device and the authority that signs the per-message credential. Section three of this page goes deeper.
Rotation without recall. A field-deployed device that requires a return-to-base for certificate renewal is a deployment with a built-in attrition curve. Every credential lifecycle has to support over-the-air rotation under cryptographic continuity — the new credential proves itself to the device using material the device already trusts.
Revocation across connectivity tiers. Always-connected devices can poll. Intermittent devices need CRL refresh on next contact. Offline-tolerant devices — V2X OBUs verifying PC5 sidelink messages with no backhaul — need pre-distributed revocation material that has already arrived before the verification is needed. One revocation system, three connectivity profiles.
Field-replacement avoidance. The economic case for hardware-rooted identity hinges on the device lasting the depreciation window without being touched. Recalling a million OBUs to replace a secure element costs more than running the deployment. The architecture has to assume the silicon is fixed and the credentials, policies, and trust anchors are the only thing that changes.
The tamper boundary is the architecture.
A device identity is only as strong as the boundary that holds its private key. Everything above the boundary — the host MCU, the OS, the application firmware — is reachable by an attacker with physical access. Everything inside is not. The four properties below are what move a key from "stored in flash" to "held in a hardware root of trust".
Tamper-resistant silicon
Side-channel-hardened analog design, mesh sensors, voltage and clock monitors, glitch detectors. Common Criteria EAL5+ at the chip level is the public mark of this work — the underlying secure-element silicon in AmbiSEC Module carries that certification. Above this layer, claims need their own evidence.
Key isolation
Private keys are generated inside the boundary, never leave it, and are referenced by handle rather than by value. The host MCU asks the secure element "sign this hash with key handle 0x03" and receives a signature; it never sees the key. A compromised host firmware cannot exfiltrate what it never had access to.
Attestation
The secure element can prove its identity to a remote authority before being trusted with a credential. The attestation signature is generated by a manufacturer-injected key inside the boundary, verifiable against a manufacturer certificate chain. This is the gate that decides whether a device is allowed to enrol into a fleet PKI in the first place.
Signed boot
The host MCU starts only if the firmware image's signature verifies against a key the secure element exposes. A modified image stops at boot. This is what makes a stolen device useless rather than a starting point — the keys are intact, but the firmware can no longer use them because the firmware does not boot.
The line is the most sensitive part of the system.
Every cryptographic property of a deployed device traces back to a moment in a controlled environment when key material was injected and the device was attested. Get that moment right and the deployment has a defensible identity story for its lifetime. Get it wrong and no amount of operational hardening recovers the deployment.
The provisioning line is where the four properties above are established for the population. The pattern that survives audit looks the same across industries: an HSM holds the key-derivation material; per-device keys are derived under a key-ceremony procedure with split custody; the secure element accepts a wrapped key-injection APDU under SCP03 or an equivalent secure channel; the manufacturing host sees only ciphertext; the line logs every injection with a per-device serial; the device leaves the line attested.
What changes between industries is the chain that follows. A FIDO authenticator leaves the line with an attestation certificate signed by the manufacturer CA. An eSIM-capable IoT device leaves the line with an eUICC identity that subsequently downloads operator profiles from SM-DP+. A V2X OBU leaves the line with a manufacturer attestation that the Enrolment Authority will subsequently verify before issuing an Enrolment Credential. The provisioning step is identical in structure; the downstream authority differs.
AmbiSecure operates personalisation lines under this discipline. The HSM-backed key custody, SCP03-equivalent wrapping, per-device serialisation, and audit-grade logging are not optional features; they are the baseline. The page on smart-card personalisation covers the operational mechanics; this page treats provisioning as one stage in a longer lifecycle.
OTA credential rotation, policy change, rollover.
A credential injected at the factory is the start of the lifecycle, not the end. The patterns below are the credential-management operations a fleet PKI has to perform indefinitely, on a population it cannot recall.
Mint
Per-device root identity injected once at the factory. Hardware-bound, attested, immovable.
Enrol
Device authenticates to a fleet authority using the factory identity; receives a deployment-scoped credential (operator profile, EC, PIV cert).
Refresh
Short-lived operational credentials (PCs, session keys, ephemeral certs) rotate on a cadence driven by policy, not by recall.
Re-key
Long-lived credentials roll over before expiry or after policy change. New credential proves itself under cryptographic continuity with the previous one.
Revoke
Compromised device is marked in the revocation channel appropriate to its connectivity profile. Lifecycle ends without a return-to-base step.
The five operations are universal across V2X, eSIM, FIDO, and PIV. What differs is the timescale — V2X PCs refresh in minutes, FIDO credentials last the life of the authenticator — and the channel — eSIM uses SM-DP+ HTTPS, V2X OBUs use RSU broadcast for revocation distribution. The architectural shape is the same.
SM-DP+, SM-DS, SGP.32: the telecom rehearsal.
The eSIM Remote SIM Provisioning architecture is the most operationally mature fleet-PKI in production at scale. The patterns that emerged from GSMA SGP.22 (consumer) and SGP.32 (IoT) are now the reference architecture every other fleet credential system gets compared against. Three of them are worth carrying over.
SM-DP+ as the credential preparation service. The Subscription Manager — Data Preparation+ holds the operational profiles to be downloaded into eUICCs. It does not hold device identity. It holds credentials that have been bound to a target device by upstream coordination. The structural analogue in V2X is the Authorisation Authority — an authority that issues operational credentials without itself authenticating the device every time.
SM-DS as the discovery service. The Subscription Manager — Discovery Service lets an eUICC find which SM-DP+ has a pending profile for it. It indexes pending credentials by eUICC identity without storing the credentials themselves. The structural analogue in V2X is the Enrolment Authority — the authority that knows which device is which, but only orchestrates the issuance rather than performing it.
SGP.32 IoT profile. The IoT-specific SGP.32 architecture introduces the eUICC Identifier Manager (IPA) and Profile Provisioning Discovery (PPD) flows tailored for unattended devices that cannot drive a user-interactive profile-download UI. The analogue across automotive and embedded fleets is the OBU or RSU that must enrol and refresh without a human in the loop — identical architectural shape, different protocol surface.
The AmbiSecure eSIM Initiative operates in this domain directly. The lessons rotated through this part of the business inform the V2X and IoT credential-lifecycle work elsewhere on the site. The SGP.32 reference covers the eUICC IoT lifecycle in structured form.
EA, AA, EC, PC: the privacy-aware variant.
V2X PKI takes the fleet-credential architecture and adds a property eSIM does not need: pseudonymity. The authority that signs a per-message credential must not learn which device requested it. The four-letter alphabet below is what makes that work.
Enrolment Authority
Knows which device is which. Verifies hardware attestation, gates entry into the fleet PKI, issues the long-lived Enrolment Credential. Sees the device identity exactly once at enrolment; does not see it again on every signed message.
Authorisation Authority
Issues the short-lived Pseudonymous Certificates the OBU uses to sign V2X messages. Receives a request from a device that has proved possession of an EC; does not learn which EC. Cannot link PC to vehicle, even if compromised together with the EA.
Enrolment Credential
Hardware-bound long-lived certificate that the device uses to prove it is entitled to request operational credentials. Lives in the secure element. Never used to sign V2X messages directly — only used to authenticate PC requests to the AA.
Pseudonymous Certificate
Short-lived operational certificate. Used to sign one batch of V2X messages over a few minutes, then rotated. Carries no device identifier. Issued in batches by the AA via Butterfly Key Expansion so that the AA itself cannot link PCs back to a single requesting EC.
References: ETSI TS 102 941 (trust + privacy management framework), IEEE 1609.2 (certificate format), ETSI TS 103 097 (secured message headers). The full V2X PKI mechanics are on the V2X PKI technology page.
Field tampering, firmware extraction, key cloning, fleet compromise.
The threat model for an in-laboratory device is not the threat model for a field-deployed device. The first assumes a controlled adversary on a controlled network; the second assumes physical access and indefinite time. Four failure modes recur across every deployment that tried software-only identity and ended up replacing it.
Flash extraction. A microcontroller's external SPI flash — or its internal flash via a debug interface left enabled or recoverable — can be read out by an attacker with bench-top equipment. A private key stored as bytes in flash is bytes in an attacker's possession. Encryption-at-rest of the flash with a key derived from a hardware-fused root is the minimum bar; what a secure element gives is one level above: the key never reaches flash at all.
Firmware extraction with key reuse. Extracting one device's firmware reveals the cryptographic patterns the entire fleet uses. If the per-device key is derived from a shared master in firmware, the firmware extract yields the master. Once the master is out, the entire fleet's identity is reproducible by anyone. A hardware-rooted per-device identity has no master to leak.
Key cloning. A device whose identity is software-stored can be cloned: the bytes are copied to a second device, and now two devices present the same identity to the fleet PKI. A pseudonymous V2X deployment with cloned keys allows a single attacker to amplify a hazard signal across geographies it does not occupy. A hardware-bound identity cannot be cloned without copying the silicon — an attack that costs more than the deployment.
Fleet compromise from a single device. The compounding failure mode. A successful extract on one device, given software-only identity, yields the cryptographic technique used across the fleet. The marginal cost of compromising the second device is near zero. Hardware identity inverts this property: every device requires its own attack, against its own silicon, with no scaling discount. Whether the fleet is one device or one million, the per-device attack cost is the same.
What plugs in where.
The architecture above is industry-shape. The mapping below is what AmbiSecure ships against it — silicon, applets, services, infrastructure. The boundary between what we provide and what we integrate alongside is explicit in section 9.
IoT Security Co-Processor
The hardware root of trust for embedded fleets. CC EAL5+ certified secure-element silicon; ECDSA-P256/P-384 hardware acceleration; key isolation; signed boot; automotive operating range. The piece that sits at the bottom of every section on this page.
JavaCard Applets
FIDO, PIV, OpenPGP, eID applets — and custom applets for V2X certificate management. Multi-applet co-residence under GlobalPlatform 2.3.1; applet upgradability for credential-policy changes that do not require silicon replacement.
Personalisation lines
HSM-backed manufacturing-time provisioning. SCP03-equivalent wrapping; key-ceremony procedures with split custody; per-device serialisation; audit-grade logging. The factory side of section three.
JavaCard development
Custom-applet engineering for credential lifecycle scenarios the off-the-shelf applet does not cover — V2X EC/PC management, fleet-specific attestation flows, applet-side revocation enforcement.
FIDO & WebAuthn
The hardware-attested identity pattern at the human-authenticator scale. Same architectural shape as fleet-device attestation, smaller credentials, FIDO MDS as the equivalent of a fleet authority — included here because the attestation pattern is the reference.
eSIM Initiative
The telecom-scale credential lifecycle in production. SGP.22 and SGP.32 deployment patterns informing the broader fleet-PKI work. External site, sister-initiative within the Ambimat Group.
The boundary, in writing.
Procurement-grade positioning needs an explicit boundary. The list below exists to keep this page useful to integrators and auditors who need to know where AmbiSecure stops and an OEM, a CA operator, or a system integrator picks up. None of these are aspirational omissions; they are the architectural shape of what AmbiSecure ships.
- Not a Root CA operator. AmbiSecure does not operate the Root Certificate Authority for any V2X, FIDO, or government-identity deployment. Root operation belongs to the regulator-designated entity (in India, CCA for V2X under the proposed framework). AmbiSecure integrates against an operator-run Root.
- Not a turnkey OBU or RSU vendor. The integrated radio + compute + secure element + application stack that constitutes a V2X OBU is an OEM product. AmbiSecure supplies the secure-element silicon and the applet platform that the OEM integrates.
- No claim of ISO 26262 (functional safety) or ASPICE (automotive software process) certification of the integrated AmbiSEC Module product. Automotive-grade certification of the integrated product is a target, not a present claim. The underlying secure-element silicon's CC EAL5+ certification is at the chip level and is the only certification claim made for AmbiSEC Module today.
- No claim of TRAI or government endorsement. The TRAI Consultation Paper of 30 April 2026 is referenced on this and adjacent pages as a public document defining the proposed framework for V2X security in India. References are descriptive, not endorsements.
- No named customer or deployment claims. Where this page or any V2X page refers to "city-scale" or "fleet-scale" deployments, the framing is architectural. Specific deployments, where they exist, are covered under NDA and not disclosed on the public site.
- No fabricated chip-vendor or silicon-partner claims. Component-level partnerships, where they exist, are disclosed only with vendor authorisation.
The Trust Center documents the certification posture and the disclosure practice in full. The Certifications page lists the standards AmbiSecure designs against and the one chip-level certification (CC EAL5+) that is formally held.
Questions integrators ask first.
Can a software TPM substitute for a discrete secure element?
For some deployments, yes — specifically those where the threat model is bounded to network adversaries and the device chassis is in a controlled environment. For field-deployed devices subject to physical access (OBUs, RSUs, smart-meter endpoints, kiosks), a discrete tamper-resistant secure element is the architecture that survives. Software TPMs share the host MCU's attack surface; a discrete SE does not.
How do you handle the case where a fleet authority changes?
The factory-injected manufacturer identity is invariant; the fleet credential is not. A device that moves between fleet authorities re-enrols under the new authority by attesting with the manufacturer identity. The previous fleet credential is revoked through the previous authority's revocation channel; the new one is issued by the new authority. The silicon stays put.
What is the practical minimum for a credential rotation cadence?
Depends on the credential's purpose. V2X Pseudonymous Certificates are designed for refresh on the order of minutes to limit linkability windows. eSIM operational profiles may persist for years. FIDO credentials are typically lifetime-of-authenticator. The cadence is a property of the threat model, not the technology — the technology supports any cadence the policy specifies.
Can the secure element's identity be migrated to a new device?
Architecturally, no. That is the property that makes it a hardware-bound identity. If a device is decommissioned, the silicon is decommissioned with it; the new device receives its own factory-injected identity on its own provisioning run. This is by design — a migrable identity is a clonable identity.
What does integration look like from an OEM's perspective?
Host MCU communicates with the secure element over I²C or SPI. The integration touchpoints are: the secure-element APDU command set, the JavaCard applet AID for the credential type in use, and the personalisation-line procedure for factory injection. The application firmware does not handle keys; it requests signatures, attestations, and certificate refreshes from the secure element. AmbiSecure provides the applet, the SDK, and the personalisation line; the OEM provides the host firmware integration.
Designing an at-scale credential lifecycle?
Tell us about the fleet, the connectivity profile, and the credential authority you are integrating against. We respond within two business days.