Key Points
- SCEP authenticates enrollment using a shared secret, rather than verifying the device, so if the challenge password is leaked, an attacker can obtain a valid certificate.
- SCEP is hardware blind: it cannot tell whether the private key lives in a TPM, a Secure Enclave, or a plain file on disk.
- Device attestation (TPM, MDM, or ACME DA) binds enrollment to a specific, verified device.
- CERT/CC VU#971035 documents that SCEP does not strongly authenticate certificate requests.
- Layering attestation on SCEP, or moving to ACME Device Attestation, closes the gap.
What Is SCEP and What Does It Verify?
The Simple Certificate Enrollment Protocol (SCEP) is an IETF protocol (RFC 8894) for delivering X.509 certificates to managed devices. SCEP is the default certificate enrollment mechanism in Microsoft Intune, Jamf, Kandji, Workspace ONE, and most other MDMs.
A SCEP enrollment looks like this:
- The MDM pushes a SCEP profile (server URL and challenge password) to a managed device.
- The device generates a key pair locally and builds a Certificate Signing Request (CSR).
- The device wraps the CSR in a PKCS#7 envelope, includes the challenge password, and posts it to the SCEP server.
- The SCEP server validates the challenge password and forwards the CSR to the Certificate Authority (CA).
- The CA signs the certificate and the SCEP server returns it to the device.
The SCEP server only confirms that whoever sent the CSR knew a valid challenge password. It does not confirm that the requester is the device the MDM targeted. It does not confirm that the private key was generated in a Trusted Platform Module (TPM) or a Secure Enclave. It does not confirm the device is compliant or even still enrolled.
SCEP authenticates a secret, not a device. That distinction is the entire scep attestation security gap.
The Core SCEP Attestation Security Gap
CERT/CC’s VU#971035 states the problem plainly: SCEP “does not provide a method for the SCEP server to strongly authenticate the entity requesting a certificate.” Three weaknesses grow out of that design choice.
Shared Secret Is the Only Proof of Identity
The challenge password is static, often shared, often reused. In most Intune deployments, the same SCEP URL and challenge serve every device in scope. If an attacker extracts that secret from an MDM profile, a support ticket, a memory dump, or a misconfigured proxy log, they can submit their own CSR and receive a valid corporate certificate. Once the secret is out, the protocol cannot tell whether the next CSR came from a managed iPhone or an attacker’s laptop running OpenSSL.
Hardware Blindness
SCEP does not care where the private key was generated. A TPM-bound key on a corporate laptop and a software key on an unmanaged device produce identical CSRs from the server’s point of view. The protocol has no key-attestation field and no mechanism for the CA to refuse a software-generated key. If the key is exportable, a stolen certificate is a stolen identity.
No Device Posture or Compliance Check
Once a SCEP-issued certificate is in hand, it is valid until expiration regardless of whether the device is later jailbroken, removed from MDM, or infected with malware. SCEP issues certificates statelessly, so a device that was healthy at enrollment can be compromised today and still present a trusted certificate to your RADIUS server.
What Device Attestation Adds
Device attestation forces the requester to prove three things before a certificate is issued: that the device is who it claims to be; that the key was generated in tamper-resistant hardware; and that the device meets compliance posture. Three sources of attestation are in production today.
TPM Key Attestation
A Trusted Platform Module (TPM) is a hardware security chip in most enterprise laptops. TPM key attestation lets the device prove cryptographically that a private key was generated inside the TPM and cannot be exported.
Microsoft Active Directory Certificate Services (AD CS) supports TPM key attestation as a CA policy: the CA refuses to sign a CSR without a valid TPM Endorsement Key certificate and attestation statement. TPM attestation does not natively integrate with SCEP.
MDM-Issued Device Attestation
Apple Managed Device Attestation (iOS 16, macOS 13) cryptographically proves that a request originates from a specific Apple device using the Secure Enclave and Apple’s manufacturer certificate chain. Google Endpoint Verification provides a parallel mechanism for managed Chrome OS and Android. Both anchor attestation in hardware the manufacturer shipped, not a secret you provisioned.
ACME Device Attestation (ACME DA)
ACME Device Attestation (identified in the IETF working draft as draft-acme-device-attest) adds a device attestation challenge to the Automated Certificate Management Environment (ACME) protocol.
The device proves to the CA, using TPM, Secure Enclave, or Android KeyStore attestation, that the requester is a specific physical device and the key is hardware-bound. ACME Device Attestation, or ACME DA, is the modern SCEP replacement across Apple, Google, and Microsoft ecosystems, with attestation built into the enrollment and renewal flow.
How SCEP and SCEP-with-Attestation Compare
| Capability | SCEP only | SCEP + TPM/MDM attestation | ACME Device Attestation |
| Authentication factor | Shared challenge password | Challenge password plus hardware attestation | Hardware attestation, no shared secret |
| Verifies key origin | No | Yes (TPM, Secure Enclave) | Yes (TPM, Secure Enclave, KeyStore) |
| Verifies device identity | No | Yes (manufacturer attestation chain) | Yes (manufacturer attestation chain) |
| Native MDM support | Yes (Intune, Jamf, others) | Partial (AD CS, custom CA policy) | Yes (Apple, Google, modern MDMs) |
| Renewal carries attestation | No | Sometimes | Yes |
| Resistant to leaked enrollment URL | No | Yes | Yes |
SCEP plus attestation closes most of the practical gap if the CA enforces it as policy. ACME Device Attestation removes the shared secret entirely and is the better long-term destination.
Practical Steps to Close the SCEP Authentication Gap
You do not have to abandon SCEP overnight. Close the gap in stages.
- Inventory every SCEP enrollment endpoint. List every MDM SCEP profile, every Network Device Enrollment Service (NDES) instance, and every cloud SCEP gateway, with the challenge mechanism for each.
- Move from static to dynamic challenge passwords. A dynamic challenge generates a one-time-use password tied to a specific enrollment request. This shrinks the blast radius of a leaked secret.
- Enforce TPM or Secure Enclave key generation in MDM policy. Intune, Jamf, and other MDMs let you require hardware-generated keys. Turn this on for every device that supports it.
- Require attestation at the CA. Configure the CA to refuse CSRs that do not include a valid TPM, MDM, or ACME attestation statement. This is the policy boundary that closes the gap.
- Pilot ACME Device Attestation for new device fleets. Apple Managed Device Attestation works on iOS 16+, macOS 13+, and tvOS 16+; Google supports it on managed Chrome and Android.
- Plan SCEP retirement for legacy hardware. Set a date by which all new enrollments use ACME DA and SCEP profiles are scoped only to devices that cannot do better.
How SecureW2 Closes the SCEP Attestation Security Gap
SecureW2 customers do not have to choose between keeping SCEP for legacy devices and getting hardware-backed attestation for everything else. The SecureW2 cloud PKI layers attestation on top of SCEP for managed devices that support TPM or Secure Enclave key generation, and issues certificates over ACME Device Attestation for Apple, Google, and modern Microsoft fleets.
JoinNow Dynamic PKI acts as a managed CA that enforces attestation as a hard policy: CSRs without a valid attestation statement are refused, and certificates are short-lived, hardware-bound, and tied to a specific enrolled device. JoinNow Cloud RADIUS consumes those certificates for 802.1X authentication, so the RADIUS server rejects the softness SCEP alone could not catch. See the SecureW2 overview of ACME Device Attestation and the underlying Dynamic PKI and Cloud RADIUS services for details.
If your team runs SCEP through Intune, Jamf, or Workspace ONE today, schedule a demo and we will walk you through a phased path from challenge-password SCEP to attested issuance.
Frequently Asked Questions
What is SCEP attestation?
SCEP attestation layers hardware-backed device attestation onto a SCEP enrollment so the CA can verify that the requester is a specific, managed, hardware-trusted endpoint. SCEP itself does not include attestation, so it must be added through CA policy or replaced with ACME Device Attestation.
Is SCEP secure?
SCEP transports a CSR safely but does not strongly authenticate the requester. SCEP relies on a shared challenge password and provides no native way to verify hardware identity, making plain SCEP insufficient for high-assurance environments unless attestation is layered on top.
What is the difference between SCEP and ACME Device Attestation?
SCEP authenticates with a shared challenge password and does not verify the device or key origin. ACME Device Attestation uses a hardware-backed attestation statement from a TPM, Secure Enclave, or Android KeyStore, with no shared secret involved.
Can SCEP verify a device’s identity?
No. SCEP only verifies that the requester knows the challenge password. There is no SCEP field for device identity, key origin, or compliance posture.
What replaces SCEP for device certificate enrollment?
ACME Device Attestation is the most direct replacement and is where Apple, Google, and Microsoft are moving. Where ACME DA is not yet available, layering TPM or MDM attestation on top of SCEP closes most of the practical gap until full migration is feasible.
