SGP.32 and V2X PKI: The Common Architectural Pattern

Overview

Two engineering communities have spent the last few years quietly converging on the same architectural idea. The GSMA's SGP.32 IoT eSIM remote provisioning specification, finalised in 2023, gave headless IoT endpoints a credible operator-controlled lifecycle. ETSI's TS 102 941 and IEEE's 1609.2, the European and North American V2X public-key infrastructures, gave vehicles a way to prove authorisation to transmit safety messages without being tracked across drives. Different domains, different threat models, different timelines — but a structural pattern that maps surprisingly cleanly when you put the two architectures side by side.

This article walks through the parallel. Where SGP.32 places SM-DP+ and SM-DS, V2X places the Enrolment Authority and Authorisation Authority. Where SGP.32 talks about IPA and eUICC, V2X talks about Onboard Units and a tamper-resistant Secure Element. The lifecycle vocabulary differs; the underlying separation-of-concerns is the same. For engineering teams thinking about multi-domain credentials on a single secure element — and for the manufacturing lines that produce them — the convergence is more than a curiosity.

The V2X side of this comparison is the work of our sister property within the Ambimat Group, AmbiSecure; the SGP.32 / eSIM side is the work of this SIM-Auth Platform site. The architectures share a structural pattern. They are not a joint product.

The Shape of the Problem Both Architectures Solve

Strip away the acronyms and both standards answer the same core question: how do you give a device a long-lived hardware-rooted identity, then issue short-lived operational credentials against that identity, without either the device or the back-end becoming a single point of failure?

Both communities arrived at the same shape:

• A tamper-resistant secure element on the device. Holds the long-term key material; never exposes it to the operating system. The device proves possession via cryptographic challenge-response.
• An identity-issuance authority off-device. Issues the long-term credential after an enrolment ceremony that establishes the device's right to exist in the system.
• A separate operational authority off-device. Issues short-lived working credentials against the long-term identity, repeatedly, without re-running enrolment.
• A discovery surface. Lets the device or its agent find which authority to contact.
• A revocation surface. Lets the system retire a device or credential when something changes — compromise, decommissioning, transfer of ownership.

Once you see the shape, the names map quickly.

SGP.32 in Brief: eUICC, IPA, SM-DP+, SM-DS, eIM

SGP.32 extends the GSMA's remote SIM provisioning architecture from consumer phones (SGP.22) into IoT, where the device often has no screen, no user, and no Local Profile Assistant. The roles:

• eUICC — the hardware secure element on the device. Holds eSIM profiles inside isolated security domains. Designed against widely accepted secure-element conventions and, on capable silicon, sits on chips at CC EAL5+ assurance.
• IPA — the IoT Profile Assistant. Replaces the consumer-side LPA. Runs either on the device (IPAd) or on a back-end on the device's behalf (IPAe). Drives the local profile lifecycle.
• SM-DP+ — the Subscription Manager Data Preparation Plus. The MNO-owned issuance authority. Prepares the operator profile, binds it to the eUICC's EID, makes it ready for download.
• SM-DS — the Subscription Manager Discovery Service. Tells the device (or its agent) which SM-DP+ has a profile waiting.
• eIM — the eSIM IoT Manager. The new SGP.32 actor. Orchestrates the lifecycle for a fleet of IoT devices on behalf of the device owner — typically an enterprise or service provider — without requiring user interaction at each device.

For the structural read of the same architecture from the V2X side, AmbiSecure publishes a structured SGP.32 reference that includes an EA/AA-vs-SM-DP+ comparison table — useful when reading the two standards together.

V2X PKI in Brief: EA, AA, EC, PC

V2X PKI is the cryptographic identity layer for vehicle-to-everything safety communications. ETSI TS 102 941 governs the European stack; IEEE 1609.2 governs the North American one; both share the same conceptual structure. The roles, from AmbiSecure's V2X PKI primer:

• EA — Enrolment Authority. Issues a long-term Enrolment Certificate (EC) to a vehicle after an enrolment ceremony. The EC binds a hardware identity on the vehicle's secure element to a permission to exist in the V2X ecosystem.
• AA — Authorisation Authority. Issues short-lived Pseudonym Certificates (PCs) against the EC. The vehicle uses one PC for a few minutes, then rotates to another. Across a drive, an outside observer cannot link consecutive transmissions to a single vehicle.
• EC — Enrolment Certificate. Long-lived. Proves the vehicle is enrolled. Stays inside the secure element. Used only to request PCs, never to broadcast.
• PC — Pseudonym Certificate. Short-lived. Signs Cooperative Awareness Messages and Decentralised Environmental Notification Messages. Designed to be unlinkable across rotations.

Underneath both EC and PC sits a hardware Secure Element — the same primitive an eUICC is, with different applets resident. See the AmbiSecure write-up on secure elements in connected vehicles for the vehicle-side packaging.

The Structural Parallel

With both architectures on the table, the mapping is direct.

The mapping is not a coincidence. Both standards bodies inherited the same hard-won lesson from the 2010s: a flat trust model where the device's identity, its operational credentials, and the network's view of it are all the same artefact does not scale. Separating issuance from authorisation, anchoring everything in a tamper-resistant boundary on the device, and making the lifecycle explicit and observable from the back-end is the architecture that survives contact with production.

What's Different — Pseudonymity, Rotation, Trust-List Topology

The structural parallel is genuine. The operational fit is not. Three differences shape how each architecture deploys in practice.

Pseudonymity. V2X PCs rotate frequently — typically every few minutes during a drive — so a vehicle is unlinkable across the rotation boundary by an outside observer with passive radio access. SGP.32 has no equivalent requirement. An IoT device is intentionally identifiable as itself to its operator; the eUICC's EID is a stable identifier by design. Pseudonymity is a V2X-specific privacy property; importing it into an IoT eSIM context would actively break the operator's ability to manage the fleet.

Rotation cadence. An eSIM profile can live for years on the same eUICC; profile rotation is an exception, usually triggered by operator switch or revocation. A V2X PC is born to be retired. The credential systems built around each have different storage, transport, and CRL economics as a result. For the IoT-side rotation pattern, see eSIM/eUICC Provisioning Architecture; for the V2X-side rotation pattern, see AmbiSecure's pseudonymous-certificates write-up.

Trust-list topology. V2X PKI is multi-issuer by design — Europe, North America, and (increasingly) several Asian jurisdictions each operate their own root authorities, with cross-recognition managed through trust lists. SGP.32 is per-profile MNO-bound — the device's relationship is with its operator's SM-DP+, mediated by the GSMA Certificate Issuer. The cross-jurisdictional logic is built into V2X from day one; in SGP.32 it lives at the operator-relationship layer above the protocol.

The Implication: a Unified Personalisation Line

The interesting consequence of the structural parallel is on the manufacturing floor.

A connected-vehicle telematics unit — or a connected industrial sensor on a private LTE network, or a smart-metering endpoint in a regulated utility — wants both identities on board: the cellular profile so it can connect, and the application-domain credential (V2X PC, fleet PKI cert, utility-control cert) so it can be trusted by the relying party. Two separate personalisation steps, with two separate trust roots, is how it has been done historically. The convergence makes a single personalisation step plausible.

The pattern, in outline:

• One Secure Element per device. Multi-applet capable. Isolated security domains under widely accepted secure-element conventions.
• One personalisation event at manufacturing. The eUICC applet receives its bootstrap and EID. The V2X applet (or fleet-PKI applet, or whichever domain credential is in play) receives its long-term identity in a parallel security domain. Both are written under HSM-controlled key custody, in one motion, in one factory station.
• Two lifecycles from there. The cellular profile follows SGP.32 — IPA-driven, eIM-orchestrated, MNO-bound. The application credential follows its own domain lifecycle — EA/AA for V2X, enterprise PKI for industrial. The hardware boundary is shared; the back-end authorities stay separate.
• One trust-chain audit story. "A specific Secure Element, with attestable provenance from this manufacturing line, signed this transaction" — true whether the transaction is a cellular authentication challenge or a V2X PC request.

For the AmbiSecure-side architectural read on this convergence, see device identity at scale (which makes the same argument from the hardware-identity side) and the manufacturing-scale credential personalisation write-up. For the SIM-Auth-side read of the same primitive, see SIM-based authentication and the trust-chain architecture page.

Boundary

One thing worth saying directly so the framing of this article is unambiguous. This site — the AmbiSecure SIM-Auth Platform — operates the SGP.22 / SGP.32 lifecycle direction and the eSIM/eUICC architecture work. It does not operate V2X PKI authorities. AmbiSecure's primary site operates the V2X PKI work and the hardware-rooted device-identity layer. It does not operate SM-DP+ / SM-DS infrastructure. The two are sibling properties within the Ambimat Group, citing each other where the technical overlap is real. This article describes the architectural pattern they share — not a joint product, not a joint deployment, not a regulator-endorsed convergence.

Frequently Asked Questions

What is SGP.32 and what problem does it solve?

SGP.32 is the GSMA's remote SIM provisioning architecture for IoT, finalised in 2023. It introduces the IoT Profile Assistant (IPA) and the eSIM IoT Manager (eIM) so that headless IoT devices — which cannot run a user-facing Local Profile Assistant — can have their eSIM profiles managed remotely by an authorised back-end. SM-DP+ and SM-DS retain their roles from SGP.22; what changes is who initiates and orchestrates the provisioning, and how it scales to constrained and unmanned endpoints.

What is V2X PKI and how is it structured?

V2X PKI is the public-key infrastructure for vehicle-to-everything communications, designed against ETSI TS 102 941 (Europe) and IEEE 1609.2 (North America). It separates long-term identity (issued by the Enrolment Authority against an Enrolment Certificate) from short-lived pseudonymous credentials (issued by the Authorisation Authority as Pseudonym Certificates) so that a vehicle can prove authority to transmit without being trackable across sessions.

What is the structural parallel between SGP.32 and V2X PKI?

Both architectures separate two concerns: an identity-issuance authority (SM-DP+ in SGP.32, EA in V2X) that performs heavyweight enrolment, and a discovery or authorisation surface (SM-DS in SGP.32, AA in V2X) that performs lighter, repeatable lifecycle operations. Both anchor the credential inside a tamper-resistant secure element. Both treat the device as the trust root and the back-end as the relying party — not the other way around.

What is different between the two architectures?

V2X uses pseudonymous certificates that rotate frequently (typically every few minutes during operation) so a vehicle is unlinkable across drives. SGP.32 has no pseudonymity requirement — an IoT device is intentionally identifiable as itself to its operator. V2X is designed for a multi-issuer trust-list landscape (per region/jurisdiction); SGP.32 is designed for a per-profile MNO-bound model. The rotation cadence, privacy posture, and CRL strategy differ accordingly.

Can a single device hold both eUICC and V2X applets on one secure element?

Yes, where the secure element supports multi-applet residency under controlled security domains. A connected-vehicle telematics unit, for example, can carry an eUICC applet handling the cellular profile under SGP.32 and a V2X applet handling EC/PC credentials under IEEE 1609.2 — provisioned in a single personalisation step at manufacturing. This article describes the architectural pattern that makes such a unified personalisation line plausible; it is not a claim that AmbiSecure or the SIM-Auth Platform currently operates one in production.

Sources and References

1. GSMA — eSIM for IoT (SGP.32)
2. AmbiSecure — structured SGP.32 reference with EA/AA vs SM-DP+ comparison
3. ETSI — TS 102 941 (V2X trust and privacy management)
4. IEEE — 1609.2 (Wireless Access in Vehicular Environments)
5. AmbiSecure — how V2X PKI works
6. AmbiSecure — device identity at manufacturing scale
7. AmbiSecure — device identity at scale (V2X / eSIM / IoT convergence)
8. AmbiSecure SIM-Auth — eSIM/eUICC provisioning architecture (RSP, SM-DP+, LPA)
9. AmbiSecure SIM-Auth — trust chain & embedded identity architecture

Related Articles

• eSIM/eUICC Provisioning Architecture: RSP, SM-DP+, and LPA Integration
• eSIM vs eUICC vs iSIM: The Engineering Difference
• eUICC Applet Development for Secure Identity
• Hardware-Backed Identity for IoT Devices
• Why Secure Elements Matter in Connected Infrastructure

Related capability: eSIM / eUICC · Secure Elements · Trust Chain Architecture · Telecom Integration