What is a SCEP server?

What SCEP is

SCEP — the Simple Certificate Enrollment Protocol — is a small, old, extremely well-supported protocol for one job: getting a certificate onto a device without a human being present. It is defined in RFC 8894, and it predates that RFC by roughly two decades of shipping implementations.

Its reach is the reason it survives. Apple's configuration profiles, Microsoft Intune, Jamf Pro, Mosyle, Kandji, Workspace ONE, and most network appliances all speak it natively. If you want certificates on a mixed fleet without writing an agent for each platform, SCEP is the protocol every one of them already has.

What the server does

A SCEP server sits in front of a certificate authority and answers three kinds of request:

• GetCACert — hand back the CA certificate, and the chain, so the device knows who it is talking to and can encrypt to it.
• GetCACaps — say which options this server supports, such as SHA-256 signing and POSTing a request rather than stuffing it in a URL.
• PKIOperation — take an encrypted, signed certificate signing request, decide whether to honour it, and return an issued certificate.

Almost all of the interesting behaviour is in that third one, and specifically in decide whether to honour it. SCEP has no user session and no directory lookup. The device's whole claim to be allowed a certificate is a shared secret it includes in the request — the challenge password.

The enrollment exchange

Concretely, from the moment your MDM pushes a profile:

1. The MDM sends the device a profile carrying the SCEP URL, the challenge, the subject name to request, and the key size.
2. The device fetches the CA certificate from the server and checks its fingerprint against the one pinned in the profile. This step is what stops the device from enrolling against an impostor — the fingerprint belongs in the profile, and a profile without one is worth fixing.
3. The device generates its own private key, locally. That key never travels, and the SCEP server never sees it. This is the property that makes certificates worth the trouble in the first place.
4. It builds a PKCS#10 signing request, includes the challenge, signs the whole thing, and encrypts it to the CA certificate it just fetched.
5. The server decrypts, checks the challenge, applies whatever policy it has about names and extensions, signs a certificate, and returns it encrypted back to the device's key.
6. The device installs the certificate alongside its key, and the profile ties it to a Wi-Fi or VPN payload so it gets used.

Renewal is the same exchange again. Crucially it is the device that initiates it, on a schedule its management platform decides — a SCEP server has no channel to a device and never initiates anything. A device that nothing re-enrols will let its certificate expire and stop authenticating.

Challenge passwords

There are two flavours, and the difference matters more than the documentation of most products admits.

Static challenges are one secret shared across the fleet. Anything holding it can obtain a certificate, so the profile carrying it should be scoped to the devices that need it, and the secret should be rotatable in one action when it leaks. This is how SCEP is deployed nearly everywhere.

Dynamic challenges mint a single-use secret per device, which is strictly better, and which requires the enrollment platform and the CA to agree on a mechanism for passing it. In practice that agreement is vendor-specific — it is what NDES's password page and Intune's certificate connector exist to broker — and it is the main reason those components are as awkward as they are.

The realistic security model for a static challenge is: possession of the challenge gets you a certificate with a name the CA is willing to sign. So constrain what the CA will sign, watch what it issues, and be able to rotate. A certificate that a RADIUS server will not map to a real computer or user object is not much of a prize.

Running your own

The usual routes are Microsoft's NDES in front of AD CS, or an open-source CA such as step-ca, EJBCA or Dogtag. All of them work. The cost is not the software; it is that you have now taken on:

• An internet-reachable enrollment endpoint, because devices enrol from coffee shops and hotel Wi-Fi, not only from your office. That usually means a reverse proxy or an application gateway in front of it, and a firewall conversation.
• A CA private key that now needs storing, backing up and — the part people postpone — a plan for replacing if it is ever exposed.
• CRL publication that never lapses. An expired revocation list does not fail open. Validators reject the chain outright, and every device drops off the network at once. This is the single most common self-inflicted outage in private PKI.
• Availability during enrollment windows, plus patching the OS and web server the endpoint runs on.

None of that is hard. It is just permanent, and it is owned by whoever is on call.

Using a hosted one

A hosted SCEP server moves the endpoint, the key custody and the CRL schedule to someone else, and leaves you with the parts that are genuinely yours: which devices get a profile, what names go in the certificates, and which certificates you revoke.

The thing to check before you hand any of that over is whose root you end up trusting. If a provider issues every customer from one shared CA, then installing that root means your network will accept a certificate issued to any other customer of theirs. That is a real, structural problem and no amount of policy language fixes it.

ScepNet generates a separate root and intermediate per organization, so there is nothing shared to accept. You can also sign our intermediate with your own offline root, which keeps the trust anchor — the part that is hard to change later — entirely yours.

Which to pick

Run your own if you already operate a CA competently, need dynamic challenges, or have a regulatory reason the key cannot leave your premises. Those are good reasons and they do not go away.

Use a hosted server if the CA is not the point — if what you actually wanted was for every laptop to hold a certificate by Friday, and running certificate infrastructure was the tax you were prepared to pay to get there.

Next: how those certificates get used for 802.1X, which is where deployments actually go wrong.