What is SCEP (Simple Certificate Enrollment Protocol)

SCEP (Simple Certificate Enrollment Protocol) is a certificate enrollment protocol originally designed by Cisco in the late 1990s for network devices (routers, switches, access points) that needed certificates but couldn’t handle complex enrollment workflows. It uses simple HTTP GET and POST operations with PKCS#7/PKCS#10 message wrapping. Despite never becoming a full IETF standard (it’s an informational RFC — RFC 8894), SCEP is deeply embedded in enterprise infrastructure, MDM platforms, and network equipment worldwide.

Why it matters

• Legacy ubiquity — virtually every enterprise MDM platform (Microsoft Intune, JAMF, VMware Workspace ONE) supports SCEP for device certificate enrollment. It’s the lowest common denominator.
• Device simplicity — SCEP requires only HTTP and basic PKCS operations. No TLS client authentication needed for initial enrollment (unlike EST). Suitable for constrained devices with minimal crypto libraries.
• Network equipment support — Cisco IOS, Juniper Junos, Palo Alto, and most enterprise network gear have built-in SCEP clients. It’s often the only enrollment protocol these devices support.
• MDM integration — mobile device management platforms push SCEP profiles to phones, laptops, and tablets for Wi-Fi (EAP-TLS), VPN, and email certificate enrollment.
• Being superseded — EST (RFC 7030) is the modern replacement with better security properties. But SCEP’s installed base means it won’t disappear for a decade or more.

How it works

1. Client obtains CA certificate — HTTP GET to the SCEP server’s GetCACert endpoint. Returns the CA’s certificate (needed to encrypt the enrollment request).
2. Client generates key pair — creates RSA key pair and PKCS#10 CSR with desired subject/SANs.
3. Client wraps request — CSR is signed with the client’s new private key, then encrypted with the CA’s public key (PKCS#7 envelope). A challenge password is included for authorization.
4. Client submits request — HTTP POST (or GET with base64-encoded payload) to the SCEP server’s PKIOperation endpoint.
5. CA processes request — validates the challenge password, checks the CSR against policy, and either auto-approves or queues for manual approval.
6. Client polls for response — if pending, client polls GetCertInitial until the CA responds with the signed certificate (also PKCS#7 wrapped).
7. Certificate delivered — CA returns the signed certificate encrypted with the client’s public key. Client decrypts and installs.

In real systems

Microsoft Intune + NDES (Network Device Enrollment Service):

Flow: Mobile Device → Intune MDM Profile → NDES (SCEP server) → AD CS (CA)

1. Intune pushes SCEP profile to device with:
   - SCEP server URL (NDES endpoint)
   - Challenge password (one-time, generated by Intune)
   - Key size, subject format, SAN template
2. Device generates key pair and CSR
3. Device submits to NDES via SCEP
4. NDES validates challenge, forwards to AD CS
5. AD CS issues certificate
6. Device receives cert — used for Wi-Fi (EAP-TLS) or VPN auth

Cisco IOS router enrollment:

crypto ca trustpoint MY-CA
  enrollment url http://scep-server.internal:80/certsrv/mscep/mscep.dll
  subject-name CN=router01.example.com
  revocation-check crl
!
crypto ca enroll MY-CA
% Start certificate enrollment..
% The subject name in the certificate will include: CN=router01.example.com
% Include the router serial number? [yes/no]: no
% Request certificate from CA? [yes/no]: yes

JAMF Pro (macOS/iOS MDM):

<!-- SCEP payload in MDM profile -->
<dict>
  <key>PayloadType</key>
  <string>com.apple.security.scep</string>
  <key>URL</key>
  <string>https://scep.example.com/scep</string>
  <key>Challenge</key>
  <string>one-time-challenge-password</string>
  <key>KeySize</key>
  <integer>2048</integer>
  <key>Subject</key>
  <array><array>
    <array><string>CN</string><string>%ComputerName%</string></array>
  </array></array>
</dict>

Where it breaks

Static challenge password — many SCEP deployments use a single shared challenge password for all enrollments. Anyone who obtains this password (from a device profile, network capture, or configuration backup) can enroll certificates for any identity. There’s no per-device authorization. Fix: use one-time challenge passwords generated per enrollment request (Intune does this), or migrate to EST which uses TLS client authentication.

No encryption in transit (HTTP) — SCEP was designed for HTTP, not HTTPS. The PKCS#7 envelope encrypts the CSR content, but the outer HTTP request is plaintext. An attacker on the network can see that enrollment is happening, identify the SCEP server, and potentially replay requests. Modern deployments should always front SCEP with HTTPS, but many legacy configurations still use plain HTTP.

NDES as single point of failure — Microsoft NDES is a single IIS application that bridges SCEP to AD CS. If NDES goes down, all device enrollments fail. MDM-managed devices that need certificate renewal can’t reach the SCEP endpoint. There’s no built-in HA for NDES — you must deploy multiple instances behind a load balancer, which introduces its own complexity with challenge password state.

Operational insight

SCEP’s biggest operational risk isn’t the protocol itself — it’s the challenge password management. In many enterprises, the SCEP challenge password is a static value configured once and never rotated. It’s embedded in MDM profiles pushed to thousands of devices, stored in configuration management databases, and known by multiple administrators. This single secret is the only authorization gate for certificate enrollment. If leaked, an attacker can enroll certificates for any identity in your PKI — impersonating any user or device. Treat the SCEP challenge password with the same security as a CA private key: rotate it regularly, use one-time passwords where possible, and audit all enrollments against expected device inventory.

Related topics

• What is EST
• What is ACME Protocol
• Certificate Enrollment
• What is a Certificate Authority
• PKI for IoT Devices