PKI Enrollment Protocols for Enterprise and IoT: ACME vs EST vs SCEP vs CMPv2

The enrollment protocol decides who can join your PKI. ACME fits enterprise reachability, EST fits constrained devices, SCEP persists in legacy gear, CMPv2 dominates telco. The real comparison, the failure modes, and the hybrid patterns that work.

The enrollment protocol is a policy decision disguised as a technical one. It determines who can request a certificate, under what conditions, with what bootstrap assumptions — and it propagates into every corner of the operational model. Get the protocol choice wrong at the start of a unified PKI programme and the reconciliation work multiplies.

Four protocols matter: ACME, EST, SCEP, and CMPv2. A fifth — the Matter commissioning flow — deserves a brief mention because it is protocol-like in its constraints. Each was designed for a different operational reality. None is the universal answer. A unified PKI for enterprise and IoT will expose at least two of them concurrently.

This is the practitioner view: what each protocol assumes, where it fails, and how to choose when you have real mixed-estate constraints.

ACME: the enterprise default

ACME (RFC 8555) was built for the web. The original use case was automating Let's Encrypt certificate issuance for public web servers. The protocol design is explicit about its assumptions: the client holds an account key, the client can solve a challenge proving control of an identifier (typically a DNS name), the CA verifies the challenge, the certificate is issued.

ACME's dominance in enterprise PKI is not accidental. Most internal services are web services, most internal services have DNS names, most internal services can serve HTTP challenges or update DNS records. ACME also gained RFC 9773 ARI (ACME Renewal Information), which lets the CA signal renewal windows to clients — critical for operators pushing toward 47-day certificate lifetimes under CA/B Forum SC-081v3.

Where ACME works: any endpoint with reliable network reachability, modern TLS stack, and capacity to hold protocol state. Enterprise web, internal APIs, Kubernetes ingress, load balancers, service mesh sidecars.

Where ACME breaks:

• Factory provisioning. The device is on a factory floor network with no path to a public CA, no DNS control, and no way to solve a challenge. ACME is not the protocol for initial device identity.
• Constrained devices. An ACME client with full RFC 8555 support is non-trivial to implement on a microcontroller with 512KB of RAM. The libraries exist (step-certificates ACME client, various minimal clients), but the protocol state machine is heavier than EST's.
• Intermittent connectivity. ACME assumes the client can complete a full flow — nonce, account, order, authorisation, challenge, finalise, certificate — in one session. A cellular-connected sensor that wakes every six hours and transmits for 30 seconds cannot reliably complete an ACME flow.
• Non-DNS identifiers. ACME's identifier model is built around DNS names. RFC 8738 adds IP identifiers; draft specifications for device identifiers exist but are not universally implemented. Issuing an ACME certificate to a device identified by a serial number or MAC address is possible but not clean.

For enterprise, ACME is the default. For IoT, it is a useful tool at specific boundaries (gateway-to-cloud, edge-to-CA) but not a universal device enrollment protocol.

EST: the device workhorse

EST (RFC 7030) is the protocol most enterprise PKI practitioners have heard of but never implemented. It was designed specifically for devices. The design premise: the device already holds a bootstrap credential — typically an IDevID installed at manufacture per IEEE 802.1AR — and uses that credential to authenticate the enrollment request over TLS client authentication.

EST does not solve domain challenges. It does not negotiate account keys. It sends a CSR over a TLS-client-authenticated HTTP POST and receives a certificate back. The protocol is small, the client implementations are small, the state machine fits in constrained device firmware.

Where EST works:

• Operational certificate issuance for devices that hold a factory-installed IDevID.
• LDevID issuance in environments where 802.1AR-compliant bootstrap is in place.
• Re-enrollment scenarios where the current certificate authenticates the renewal.

Where EST breaks:

• No bootstrap credential. EST assumes the device already has something to authenticate with. If the device ships without an IDevID — still common in consumer IoT — EST cannot be the initial enrollment protocol. This is what Bootstrapping Remote Secure Key Infrastructure (BRSKI, RFC 8995) addresses: a protocol layered above EST for zero-touch bootstrap.
• Implementation scarcity. Far fewer production-quality EST implementations exist than ACME. Cisco's EST client libraries, OpenXPKI's EST interface, and vendor-specific offerings cover much of the field. The tooling ecosystem is thinner.
• Enterprise resistance. Enterprise PKI teams know ACME. EST is foreign. A unified PKI proposing EST for devices runs into cultural friction independent of the technical merits.

EST is the right protocol for most device operational enrollment. It is not the protocol for enterprise web, and it is not the protocol for devices that ship without a bootstrap credential.

SCEP: the legacy that won't die

SCEP (RFC 8894) is older than EST and older than most of the assumptions of modern PKI. It predates TLS as the transport; the original SCEP used HTTP with PKCS#7 payloads and a shared secret or challenge password as the authentication mechanism. The IETF formalised the existing deployed SCEP in 2020 with RFC 8894, not because SCEP deserved formalisation, but because it was ubiquitous enough that standardising the reality was better than letting implementations drift.

SCEP persists in three places:

• Cisco networking gear. Router and switch certificate enrollment flows are SCEP-native.
• MDM enrollment. Apple MDM, Microsoft Intune, and other MDM platforms use SCEP profiles extensively for device certificate provisioning.
• Industrial control systems. Brownfield OT environments run SCEP because the devices were specified fifteen years ago and cannot be replaced.

Known SCEP weaknesses:

• Shared-secret authentication is weak.
• The original protocol used RSA-based message encryption with no algorithm agility.
• Challenge passwords are often static and widely shared.
• Request replay is possible in older implementations.

What you do about SCEP:

• Accept it exists in the estate.
• Isolate it: SCEP-issuing CAs should be separate from modern CAs, with short-lifetime profiles and aggressive scoping.
• Wrap it: modern CA platforms that expose SCEP alongside EST/ACME let you migrate devices one at a time rather than forklifting.
• Audit it: every SCEP-issued certificate should appear in the same inventory as ACME and EST certificates. Separate audit trails for SCEP is how shadow PKI grows.

SCEP is not a forward-looking choice. It is a real-world constraint that unified PKI must accommodate.

CMPv2: the telco standard

CMPv2 (RFC 4210), with updates in the RFC 9480/9481/9482/9483 series and consolidated in RFC 9810, is the enrollment protocol mandated by 3GPP specifications for telecom equipment. If you operate 5G infrastructure, Radio Access Network equipment, or IMS core, you operate CMPv2.

CMPv2 supports richer transaction types than EST — key update, cross-certification, revocation requests — and has formal support for proof-of-possession beyond simple CSR signing. Implementation complexity is correspondingly higher.

Where CMPv2 matters:

• Telecom operator PKI for RAN and core equipment.
• Any device subject to 3GPP certificate enrollment requirements.
• Cross-operator trust relationships where CMP's cross-certification flows are useful.

Where CMPv2 does not belong: enterprise web PKI, consumer IoT, anything outside the telco-specified domain. Using CMPv2 for general enterprise enrollment imposes protocol complexity for no benefit.

A unified PKI serving telco requirements alongside enterprise needs CMPv2 support as a specific module, not as the default. For non-telco enterprise and device needs, ACME and EST cover the space.

Matter commissioning: protocol-adjacent

Matter devices are provisioned through a commissioning flow specified by the Connectivity Standards Alliance, not through ACME, EST, or SCEP. The Matter flow layers on top of the device's Device Attestation Certificate (DAC) — issued during manufacture by a CSA-approved PAA/PAI chain — and the Node Operational Certificate (NOC) issued by the Matter fabric administrator at commissioning time.

This matters for unified PKI because Matter is not optional for any device carrying the Matter badge, and the Matter PKI chain is separate from both enterprise and traditional IoT PKI. An organisation operating in the smart home ecosystem will have Matter CAs alongside its enterprise CAs, and the enrollment protocol is Matter-specific. See Matter PKI and Matter Device Attestation Certificates for the details.

The hybrid pattern: policy at the CA, not at the protocol

Unified PKI across enterprise and IoT exposes multiple enrollment protocols. The architectural choice that matters most is where policy lives.

Protocol-layer policy (wrong): each protocol endpoint has its own authentication, its own allowed algorithms, its own profile rules. ACME issues 47-day RSA-2048 TLS certs, EST issues 10-year ECDSA P-256 IDevIDs, SCEP issues whatever the legacy profile said in 2011. Three policy surfaces, three audit trails, three places where policy drift happens.

CA-layer policy (right): the CA holds profile definitions (enterprise-tls-47d, device-idevid-20y, device-ldevid-1y). Each enrollment protocol is a transport. The protocol layer authenticates the requester, but the policy — algorithm, validity, extensions, OCSP pointer, CRL DP — is bound to the profile, not to the protocol. A CSR arriving via ACME, EST, or SCEP maps to the same profile if the requester is authorised for it.

This is the architecture that makes unified PKI operationally coherent. It is also the architecture that most commercial PKI platforms claim to support. Axelspire's assessment experience is that support quality varies dramatically: some platforms apply protocol-layer policy badly disguised as CA-layer policy, producing the same drift the CA-layer model was meant to prevent.

The evaluation question is direct: can I define a single profile, and can I expose it through ACME, EST, SCEP, and CMPv2 with identical policy enforcement? If the answer is "yes, but each protocol module has its own profile definition," the platform is not truly CA-layer.

Protocol decision matrix

Where the table says two protocols, both are valid. The choice is about existing tooling and the operational team.

What this means for unified PKI platform selection

When evaluating whether a PKI platform supports the unified enterprise-plus-IoT operating model, the protocol-level questions are:

1. Does it expose ACME, EST, SCEP, and — if telco is in scope — CMPv2 concurrently?
2. Does it define policy at the CA profile layer, applied consistently across all protocols?
3. Does it support ACME with RFC 9773 ARI for renewal signalling?
4. Does it support EST reenrollment using the current certificate, not just initial enrollment?
5. Does SCEP support run through the same inventory and audit system as the modern protocols?
6. Is the protocol set extensible — can the platform add protocols without core changes — or is the protocol set fixed?

A platform that answers "yes" to all six is uncommon. A platform that claims all six and delivers three is the common case. The evaluation work is separating claim from delivery.

For architectural options that handle protocol diversity without forcing single-vendor consolidation, see platform consolidation vs best-of-breed. For the broader reconciliation framework, see the unified PKI pillar.

Further reading

• Unified PKI for enterprise and IoT
• Certificate lifetime policy across enterprise and IoT
• Factory provisioning vs runtime enrollment
• Matter PKI
• SPIFFE and workload identity for device fleets