Skip to main content

Glossary

SCEP

SCEP (Simple Certificate Enrollment Protocol) is a protocol that lets a device request and receive an X.509 certificate from a certificate authority without a human copying files around. MDMs use it to give each managed device its own certificate, which then authenticates it to Wi-Fi, VPN and email servers.

How it works

The flow is short. The MDM pushes a SCEP payload to the device: the URL of the SCEP server, a challenge password and the subject fields the certificate should carry (device serial, user name, department). The device generates a key pair locally, builds a certificate signing request, and sends it to the SCEP server with the challenge. The server checks the challenge, forwards the request to the CA, and returns the signed certificate. The private key never leaves the device.

SCEP dates from the late 1990s at Cisco and was only formalized as RFC 8894 in September 2020. It's simple by design: HTTP transport, PKCS#7 envelopes, a shared-secret challenge. That simplicity is why every MDM and most enterprise CAs (Microsoft NDES, EJBCA, DigiCert, Smallstep) support it.

Its main weakness is the challenge password. If it's static and leaks, anyone can request a certificate. So MDMs generate a one-time challenge per device, or use a dynamic challenge issued by the CA.

Why it matters for a fleet

Passwords don't scale on mobile. A user typing the Wi-Fi password on 3 devices, changing it every 90 days and sharing it with the new intern is how corporate networks end up open. A per-device certificate replaces that: the device authenticates with 802.1X EAP-TLS, the RADIUS server checks the certificate, and no one types anything.

The same certificate can authenticate the VPN client, sign S/MIME email and identify the device to internal web apps. Revoke it and the device loses everything at once, which is exactly what you want when a phone is lost.

Certificates also expire, typically after 1 or 2 years. Without an automated enrollment protocol, renewal means a help desk ticket per device. With SCEP, the MDM re-enrolls before expiry and the user notices nothing.

How Appaloosa handles it

Appaloosa deploys SCEP profiles to iOS, iPadOS, macOS and Android devices as part of a configuration profile, alongside the Wi-Fi or VPN payload that uses the resulting certificate. You point it at your SCEP server, define the subject template and the key size (2048-bit RSA minimum, ECC where the CA supports it), and each enrolling device gets its own certificate automatically.

The console reports which devices hold a valid certificate and when it expires, so renewal becomes a scheduled task inside your mobile device management rather than a surprise on a Monday morning when 200 devices drop off the Wi-Fi.

Book a demo

See Appaloosa run on your fleet

A 20-minute call on your real setup. Enrollment, private apps, security.

Book a demo

See the full platform Explore Appaloosa

Frequently asked questions

Do I need my own certificate authority to use SCEP?
Yes, or a hosted one. SCEP is the delivery mechanism, not the issuer. Microsoft AD CS with the NDES role is the common on-premises choice. Cloud options include DigiCert, Sectigo, SecureW2 and Smallstep. The MDM only needs the SCEP endpoint URL and a way to obtain challenge passwords.
What's the difference between SCEP and ACME or EST?
ACME (used by Let's Encrypt) targets web servers and validates domain ownership, not devices. EST (RFC 7030) is SCEP's designed successor with TLS-based authentication and better key handling, but MDM and CA support is still thinner. SCEP remains the protocol every MDM speaks today, with EST worth watching.
Can the private key be extracted from the device?
Not in normal operation. The key pair is generated on the device and, on iOS and modern Android, stored in hardware-backed keystores (Secure Enclave, StrongBox). A jailbroken or rooted device weakens that guarantee, which is one more reason to tie certificate issuance to a compliance check.