SCEP vs EST vs CMP: Certificate Enrollment Protocols Compared

ACME dominates public certificate enrollment. But for enterprise and device enrollment — MDM-managed phones, network equipment, IoT sensors, industrial systems — three older protocols remain essential: SCEP, EST, and CMP.

Each was designed for a different era and a different problem. SCEP (1990s, Cisco) is simple but insecure. EST (2013, IETF) is SCEP’s modern replacement. CMP (2005, IETF) is the most powerful but most complex. Here’s when each makes sense.

---

Quick Comparison

Feature	SCEP	EST	CMP
RFC	8894 (informational)	7030 (standards track)	4210/9483 (standards track)
Transport	HTTP (plain)	HTTPS (TLS required)	HTTP/HTTPS/TCP
Initial auth	Challenge password (shared secret)	HTTP Basic or client cert	Shared secret or client cert
Re-enrollment	New challenge password needed	Existing client cert (mTLS)	Existing client cert
CA cert distribution	GetCACert operation	/cacerts endpoint	PKI message
Server-side keygen	❌	✅	✅
CA-initiated operations	❌	❌	✅ (key update announcements)
Revocation request	❌	❌	✅
Message security	PKCS#7 envelope (app-layer)	TLS (transport-layer)	Per-message signatures
Complexity	Low	Medium	High
Primary use case	MDM, network devices	IoT, modern enterprise	Telecom (3GPP), industrial
Status	Legacy (being replaced)	Recommended for new deployments	Niche but powerful

---

SCEP: The Legacy Standard

What It Is

SCEP (Simple Certificate Enrollment Protocol) was designed by Cisco in the late 1990s for network devices (routers, switches, access points) that needed certificates but couldn’t handle complex enrollment. It uses HTTP with PKCS#7 message wrapping.

How It Works

1. Client → GET /cgi-bin/pkiclient.exe?operation=GetCACert
   ← CA returns its certificate (client needs this to encrypt the request)

2. Client generates key pair + CSR
   Client wraps CSR in PKCS#7 (encrypted with CA's public key, signed with client's new key)
   Client includes challenge password for authorization

3. Client → POST /cgi-bin/pkiclient.exe?operation=PKIOperation
   ← CA validates challenge password, signs certificate, returns in PKCS#7

4. If pending: Client polls GetCertInitial until CA responds

When to Use SCEP

• Microsoft Intune/JAMF MDM — still the primary protocol for pushing certificates to managed devices
• Cisco/Juniper network equipment — built-in SCEP clients, often the only option
• Legacy systems that only support SCEP (no EST/CMP capability)

When NOT to Use SCEP

• New deployments where EST is supported
• Environments requiring strong initial authentication (SCEP’s challenge password is weak)
• Systems that need re-enrollment without new shared secrets

The Security Problem

SCEP’s challenge password is typically a static shared secret. Anyone who obtains it can enroll any identity. There’s no per-device authorization — the password is the only gate. This is SCEP’s fundamental weakness and the primary reason EST was created.

# SCEP challenge password in Intune profile (one-time, per-request)
# Intune generates unique challenge per enrollment — better than static
# But many SCEP deployments still use a single static password for all devices

---

EST: The Modern Replacement

What It Is

EST (Enrollment over Secure Transport, RFC 7030) is SCEP’s successor. It runs over HTTPS (TLS provides transport security) and supports re-enrollment using the existing client certificate — no shared secrets needed for renewal.

How It Works

1. Client → GET https://est-server/.well-known/est/cacerts
   ← CA chain returned (trust bootstrap)

2. Initial enrollment:
   Client → POST https://est-server/.well-known/est/simpleenroll
   Auth: HTTP Basic (username/password) or bootstrap client cert
   Body: PKCS#10 CSR
   ← Signed certificate returned (PKCS#7)

3. Re-enrollment (renewal):
   Client → POST https://est-server/.well-known/est/simplereenroll
   Auth: Existing client certificate (mTLS) — no password needed!
   Body: New CSR
   ← New signed certificate returned

When to Use EST

• New IoT deployments — devices that need initial enrollment + ongoing renewal
• Enterprise environments replacing SCEP — better security, same simplicity
• Any system that supports EST — it’s strictly better than SCEP
• Devices with HTTPS capability (most modern devices)

The Killer Feature: Re-enrollment

EST’s /simplereenroll endpoint is what makes it superior to SCEP. The device authenticates with its current certificate to get a new one. No shared secrets. No challenge passwords. No credential distribution for renewal. The device’s existing identity IS the authentication.

# Re-enrollment: device uses current cert to authenticate
curl --cert current-device.pem --key current-device.key \
  --cacert ca-chain.pem \
  --data-binary @new.csr \
  -H "Content-Type: application/pkcs10" \
  https://est.internal/.well-known/est/simplereenroll

---

CMP: The Full-Lifecycle Protocol

What It Is

CMP (Certificate Management Protocol, RFC 4210) is the most comprehensive certificate management protocol. It handles: initial enrollment, re-keying, renewal, revocation, CA key updates, cross-certification, and error handling. It’s the only protocol where the CA can initiate operations (push updates to devices).

How It Works

1. Initialization Request (IR):
   Client → CA: "I want my first certificate"
   Auth: shared secret (MAC-based) or existing cert
   ← CA returns signed certificate + CA certs

2. Key Update Request (KUR):
   Client → CA: "I have a new key pair, sign it"
   Auth: existing certificate
   ← CA returns new certificate

3. Revocation Request (RR):
   Client → CA: "Revoke my certificate"
   Auth: existing certificate
   ← CA confirms revocation

4. CA Key Update Announcement (CKUANN):
   CA → Client: "My key has changed, here's the new CA cert"
   (CA-initiated — unique to CMP)

When to Use CMP

• Telecom/5G — 3GPP mandates CMP for network element certificate management
• Industrial systems — devices that need CA-initiated key updates
• High-security environments — per-message authentication (not just transport)
• Complex PKI operations — cross-certification, CA migration, bulk re-keying

The Lightweight CMP Profile (RFC 9483)

Full CMP is complex (dozens of message types). RFC 9483 defines a simplified subset for common use cases — making CMP practical without implementing the entire specification.

---

Decision Framework

What are you enrolling?

Mobile devices (MDM-managed):
├── Intune/JAMF → SCEP (only option for most MDM platforms)
└── Modern MDM with EST support → EST (preferred if available)

Network equipment (Cisco, Juniper, Palo Alto):
├── Supports EST → EST
└── SCEP only → SCEP (most current network gear)

IoT devices:
├── Has HTTPS stack → EST (best for IoT lifecycle)
├── Very constrained (no TLS) → CMP over HTTP (message-level security)
└── Legacy → SCEP

Telecom/5G infrastructure:
└── CMP (3GPP mandate, no alternative)

Enterprise servers/services:
├── Can use ACME → ACME (preferred for automation)
├── No ACME, has HTTPS → EST
└── Legacy Windows → SCEP via NDES

General rule:
├── New deployment → EST (or ACME if public certs)
├── Existing SCEP infrastructure → keep SCEP, plan EST migration
└── Telecom/industrial → CMP

---

Migration: SCEP to EST

If you’re running SCEP and want to migrate to EST:

Phase 1: Deploy EST Server Alongside SCEP

Most modern CAs (EJBCA, Smallstep, Microsoft NDES with EST plugin) support both protocols simultaneously. Deploy EST without removing SCEP.

Phase 2: New Enrollments via EST

All new device enrollments use EST. Existing devices continue using SCEP until their next renewal.

Phase 3: Re-enrollment via EST

When existing devices renew, they can switch to EST (if the device supports it). The device authenticates with its current SCEP-issued certificate to EST’s /simplereenroll endpoint.

Phase 4: Decommission SCEP

Once all devices have migrated to EST, disable the SCEP endpoint.

Timeline: 1-2 certificate lifecycles (1-2 years for annual certs).

---

Protocol Support by CA

CA/Platform	SCEP	EST	CMP	ACME
Microsoft AD CS (NDES)	✅	⚠️ (plugin)	❌	❌
EJBCA	✅	✅	✅	✅
Smallstep	❌	❌	❌	✅
HashiCorp Vault	❌	❌	❌	❌ (API only)
AWS Private CA	❌	❌	❌	❌ (API only)
Entrust PKI	✅	✅	✅	✅
DigiCert ONE	✅	✅	❌	✅
Sectigo SCM	✅	✅	❌	✅
OpenXPKI	✅	✅	✅	❌

---

FAQ

Q: Why not just use ACME for everything? A: ACME is designed for domain-validated certificates (prove you control a domain). It doesn’t work for: device identity (devices don’t have domains), user certificates, or environments where domain validation isn’t applicable. SCEP/EST/CMP handle identity-based enrollment where ACME can’t.

Q: Is SCEP being deprecated? A: Not formally, but it’s being replaced by EST in new deployments. SCEP will persist for years because of the massive installed base (every MDM platform, every Cisco device). But new protocol development is focused on EST and CMP.

Q: Can EST work without initial credentials? A: EST requires some form of initial authentication (HTTP Basic, bootstrap certificate, or TLS-PSK). The “bootstrap problem” (how does the device get its first credential?) is the same for all protocols. Common solutions: manufacturer-installed bootstrap certificate (IDevID), one-time password provisioned during manufacturing, or physical proximity verification.

Q: Which is fastest for high-volume enrollment? A: EST (simple HTTPS POST/response, minimal overhead). CMP has more message exchanges. SCEP’s PKCS#7 wrapping adds processing overhead. For bulk enrollment (factory provisioning), EST’s simplicity wins.

Q: Do I need all three protocols? A: Most organizations need 1-2. Typical: ACME (public certs) + EST (device enrollment). Or: ACME (public) + SCEP (MDM, legacy network gear). Only telecom/industrial organizations typically need CMP.