EST vs SCEP vs CMP: Choosing a Certificate Enrollment Protocol for IoT Devices (2026)

Every connected device that authenticates with a certificate needs a way to get that certificate, renew it and lose it again when it is retired or compromised. Three standard protocols cover devices: SCEP, the long-standing default of network equipment and MDM; EST, its HTTPS-based successor; and CMP, the most complete of the three and the one industrial and telecom profiles have converged on. ACME, the protocol behind Let's Encrypt, completes the picture for servers and gateways.

This guide compares them on what matters for a device fleet: how the first certificate is authorised on the production line, how renewal proves it is the same device, how revocation works, and what each protocol demands from constrained firmware.

---

Table of Contents

1. The Short Answer
2. SCEP (RFC 8894)
3. EST (RFC 7030)
4. CMP (RFC 4210, RFC 9480, RFC 9483)
5. Where ACME Fits
6. Comparison Table
7. Factory Provisioning: a Reference Flow
8. How DuoKey PKI Supports the Three Protocols
9. FAQ

---

The Short Answer

• New device programmes: use CMP with the Lightweight CMP Profile (RFC 9483) if your firmware stack has a CMP client, or EST if you want the simplest HTTPS-based client.
• Network equipment, Wi-Fi and MDM-managed endpoints: SCEP remains the protocol most of them speak; keep it for that installed base.
• Servers, gateways and Kubernetes workloads: ACME, ideally with short-lived certificates.
• Whatever you choose, issue device certificates from a dedicated device CA, separate from server and user CAs, so it can be rotated or revoked on its own.

---

SCEP (RFC 8894)

The Simple Certificate Enrollment Protocol dates from the late 1990s and was only published as an informational RFC in 2020 (RFC 8894). It wraps a PKCS#10 request in a PKCS#7 envelope encrypted to the CA and sends it over HTTP.

Strengths

• Supported by almost every router, switch, firewall, VPN concentrator and MDM platform, including Microsoft Intune.
• Simple to operate when the client already has it.

Limits

• Authorisation usually rests on a challenge password, often static and shared by many devices.
• Renewal semantics are weak and implementations vary.
• The CA has to decrypt each request, so it needs an RSA key it can use for decryption, which rules out many HSM and vault configurations.
• No modern algorithm agility in many deployed clients.

SCEP is a protocol to keep for the installed base, not one to choose for a new product.

---

EST (RFC 7030)

Enrollment over Secure Transport (RFC 7030, 2013) carries PKCS#10 requests over HTTPS. The TLS session protects the exchange; the client authenticates with HTTP credentials, a client certificate or both.

Operations

Strengths

• Plain HTTPS: easy to implement, proxy and monitor.
• Clean separation of first enrolment and re-enrolment.
• A CoAP binding (RFC 9148) exists for very constrained devices.

Limits

• Re-enrolment is only bound to the current certificate if the server (or an ingress in front of it) terminates mutual TLS and checks the client certificate. Without that, renewal is authorised by the same credential as the first enrolment.
• No revocation request in the protocol: revocation happens out of band.

---

CMP (RFC 4210, RFC 9480, RFC 9483)

The Certificate Management Protocol (RFC 4210, updated as CMPv3 by RFC 9480 in 2023) is the most complete of the three. It covers initial requests, certification requests, key update, revocation requests, and certificate confirmation. Messages are protected either with a shared MAC secret (for the first enrolment) or with a signature by an existing key.

The Lightweight CMP Profile (RFC 9483) narrows CMP to what industrial and IoT devices need. 3GPP has long used CMP for base station certificates.

Strengths

• Key update (kur) is signed by the device's current key and carries its current certificate, so renewal proves the device is the one that was enrolled. A stolen bootstrap secret alone cannot renew someone else's identity.
• Revocation request (rr) is part of the protocol.
• The CA chain can be returned in the answer (caPubs).
• Transport-independent (HTTP, CoAP, or offline files).

Limits

• A richer ASN.1 message format: client libraries are heavier than EST.
• Fewer off-the-shelf clients in consumer devices.

---

Where ACME Fits

ACME (RFC 8555) automates certificates for anything that can answer an HTTP or DNS challenge: web servers, gateways, Kubernetes ingress through cert-manager. ACME renewal information (RFC 9773) tells clients when to renew, which matters as public TLS certificate lifetimes shrink towards 47 days. It is not designed for factory provisioning of devices that have no public name. See our ACME and private CA guide.

---

Comparison Table

---

Factory Provisioning: a Reference Flow

1. Create a device issuing CA, separate from server and user CAs. Keep its signing key in an HSM, a cloud KMS or an MPC vault if your protocol choice allows it.
2. Configure the endpoint: for EST, auto-approve with a strong endpoint secret and a maximum validity; for CMP, an HMAC secret with key update allowed and a maximum validity.
3. On the line, each device generates its key pair, on its secure element when it has one, builds a CSR (EST) or CRMF request (CMP) with its serial number as subject and enrols with the bootstrap credential. Give each device its own identity in the request so rate limits and audit apply per device.
4. Store the issued certificate and the CA chain on the device.
5. Rotate the bootstrap secret per batch or per production line. It only authorises enrolment; changing it does not affect certificates already issued.
6. In the field, renew with CMP key update (or EST re-enrolment behind mutual TLS) and revoke compromised or retired devices so relying parties see them in OCSP and the next CRL.

---

How DuoKey PKI Supports the Three Protocols

DuoKey PKI supports EST (cacerts, simpleenroll, simplereenroll, serverkeygen, csrattrs), CMP (RFC 4210 / 9483) with key update and revocation requests, SCEP (RFC 8894) with optional Microsoft Intune request validation, ACME (RFC 8555, with RFC 9773 renewal information) and Kubernetes cert-manager, all bound to the CA you choose.

• CA keys: a CA created with a vault signs every certificate, CRL and OCSP response in that vault (HSM, cloud KMS or MPC cluster) without exporting the key. SCEP is the exception: it decrypts requests with the CA key, which vault back-ends do not offer, so a SCEP profile needs an RSA CA whose key is held by the platform.
• Revocation: per-CA OCSP responders and CRLs, and revocation from the console, the management API or CMP.
• Governance: M-of-N quorum on CA revocation, CA and template changes and high-value issuance, plus access policies by user, IP, country and time on every enrolment protocol.
• Algorithms: RSA, ECC, ML-DSA, SLH-DSA and a hybrid ML-DSA-65 + ECDSA-P256 composite.

DuoKey PKI runs device identity in production at Volkswagen. The factory provisioning use case walks through the setup.

---

FAQ

Is SCEP still secure?

SCEP itself can be run safely, but deployments often rely on a static challenge password shared across devices, and the protocol has no reliable renewal binding. Using per-request validation (for example Microsoft Intune) and short validity periods helps. For new products, EST or CMP are better choices.

What is the difference between EST and CMP?

Both enrol devices with standard certificate requests. EST is simpler and runs over HTTPS. CMP has protocol-level key update signed by the device's current key and revocation requests, which makes it stronger for long-lived devices.

Can a device enrol without generating its own key?

EST serverkeygen and CMP central key generation let the server create the key pair, but the private key then exists outside the device for a moment. Generate keys on the device, on its secure element if it has one, whenever possible.

Which protocol does the EU Cyber Resilience Act require?

None. The CRA requires appropriate authentication and protection of data and updates, not a specific protocol. See our Cyber Resilience Act page.

Do these protocols support post-quantum certificates?

The protocols carry standard certificate requests, so they can carry ML-DSA or composite keys if the client, the CA and the relying parties support them. DuoKey PKI can issue ML-DSA, SLH-DSA and hybrid composite certificates.