SCEP vs PKCS: choosing the right certificate delivery method for Intune and AD CS
A practical comparison of the two certificate enrollment options available in the Intune Certificate Connector — and why the choice matters more than most guides suggest.
When you deploy certificates to Intune-managed devices using Active Directory Certificate Services as your CA, you have two delivery mechanisms available through the Intune Certificate Connector: SCEP (Simple Certificate Enrollment Protocol) and PKCS (delivered as PKCS#12 PFX bundles). Most guides treat this as a minor configuration detail. It isn't.
The choice between SCEP and PKCS determines where private keys are generated, whether they can ever be extracted, how your infrastructure is exposed, and ultimately how strong your certificate-based authentication actually is. In regulated environments — PCI DSS, Zero Trust architectures, or anywhere you care about key security — making the right choice here is fundamental.
This post covers both options in depth: how they work mechanically, their security implications, how each behaves across Windows, macOS, and iOS, and the decision criteria that should drive your choice.
1 What SCEP and PKCS actually do
The fundamental difference between SCEP and PKCS comes down to two questions: where is the private key generated? and Do you accept the additional overhead for running a NDES service?
Private key never leaves the device.
Private key transits the connector at delivery.
This distinction has cascading implications for security, infrastructure design, and operational complexity — all of which we'll work through below.
2 SCEP in depth
SCEP is the older and more widely supported protocol. It was designed specifically to solve the problem of enrolling large numbers of devices for certificates in a scalable way, and it does so by having each device manage its own key material.
Infrastructure requirements
SCEP via Intune requires three components working in concert:
- The Intune Certificate Connector — installed on a Windows Server, handles the trust relationship between Intune and your on-premises CA
- NDES (Network Device Enrollment Service) — a Windows Server role service that implements the SCEP protocol and acts as the gateway between devices and AD CS. Must be on a dedicated member server, not on the CA itself
- AD CS Issuing CA — signs the certificate requests forwarded by NDES
The residual consideration with NDES is therefore operational rather than exposure-based: it is still an additional server role to deploy, patch, and keep healthy alongside the connector and CA, and its default request rate limiting may need tuning for bulk enrollment. But the "dangerous internet-facing box" framing applies only to the legacy publishing model — not to the connector-based Intune deployment.
Pros and cons
- Private key generated on device - never exists anywhere else in the infrastructure
- TPM key binding on Windows: key generated inside TPM, hardware-bound, non-exportable
- Secure Enclave binding on iOS with ECC P-256 keys - automatic on supported hardware
- No PKCS#12 bundle ever in transit - only CSR (public) and certificate flow between systems
- Gold standard PKI design - aligns with RFC 5280 intent that keys are generated by the end entity
- Strong fit for Zero Trust and high-security regulated environments
- NDES server required - additional infrastructure to deploy, patch, and monitor
- NDES is one more server role to deploy, patch, and keep healthy (though not internet-facing in the connector model)
- Three components must all be healthy simultaneously (Connector + NDES + CA)
- NDES default rate limiting can throttle bulk enrollment events without tuning
- Device must reach the Intune service to renew - long-offline devices can hit a bootstrapping problem at expiry
- More complex to troubleshoot than PKCS when enrollment fails
3 PKCS in depth
The PKCS option (sometimes called PFX delivery in Intune documentation) takes a fundamentally different approach: instead of the device generating its own key, the Intune Certificate Connector requests a certificate from AD CS on behalf of the device, packages the certificate and private key as a PKCS#12 bundle, encrypts it using a device-specific key, and delivers it through the Intune MDM channel.
Infrastructure requirements
PKCS delivery is simpler: just the Intune Certificate Connector and AD CS. No NDES. The connector communicates outbound to Intune and inbound to AD CS using its service account credentials. Devices receive their certificates through the standard Intune MDM channel — the same channel used for all other policy delivery.
What about the PFX password? Doesn't someone have to type it?
A reasonable concern: if the private key is delivered inside a password-protected PFX, does a user or admin have to enter a password, and does that password have to be distributed or stored somewhere? The answer is no — and understanding why matters.
In the on-demand PKCS profile flow (per-device certificates for Wi-Fi and VPN), the PFX password is purely a transport wrapper. It is generated and handled automatically, encrypted for the specific target device, and consumed exactly once when the device installs the certificate. The moment the key is imported into the device's key store — the TPM/KSP on Windows, or Keychain/Secure Enclave on Apple platforms — the transport password is discarded. It is never re-entered, never typed by a user, and never needs to be distributed. From that point the key is protected by the hardware key store, not by any password.
The TPM question — correcting a common misconception
A common assumption is that PKCS delivery means the private key cannot be hardware-bound. On Windows, this is not entirely true. When you configure the Intune PKCS certificate profile to use the TPM KSP (Microsoft Platform Crypto Provider), Windows imports the delivered private key directly into the TPM during installation. Once inside the TPM, the key is hardware-bound and non-exportable — equivalent in protection to a SCEP-enrolled TPM key after the point of delivery.
The difference that remains: with SCEP + TPM, the key is generated inside the TPM and never exists outside it. With PKCS + TPM, the key exists transiently on the connector server during packaging before being imported into the TPM. For most organisations this distinction is an acceptable residual risk; for the most sensitive environments it is meaningful.
This TPM import capability is Windows-only. macOS and iOS have no equivalent mechanism for importing an externally-delivered key into the Secure Enclave.
Pros and cons
- No NDES required — simpler infrastructure with fewer components
- One fewer server role — no NDES to deploy, patch, or maintain
- Delivery via Intune MDM channel — no device-to-NDES connectivity needed
- More predictable throughput for large bulk enrollments
- TPM key binding achievable on Windows via TPM KSP configuration
- Easier to troubleshoot — fewer components in the enrollment chain
- Works well for user certificates pre-provisioned before user login
- Private key transits the connector server transiently during packaging
- No hardware key binding on macOS or iOS — software key storage only
- Certificate template must allow key export at issuance (CT_FLAG_EXPORTABLE_KEY)
- Connector server handles key material — must be treated as a sensitive, hardened host
- No true hardware key attestation even when TPM KSP is used on Windows
- Weaker key security model than SCEP for non-Windows platforms
4 Platform behaviour: Windows, macOS, and iOS
The security characteristics of SCEP vary significantly by platform — and understanding these differences is essential for designing a cross-platform certificate deployment.
Windows
Windows has the richest options for hardware key binding. With SCEP, configuring the certificate profile to use the TPM KSP causes the key pair to be generated inside the TPM — the key never exists in software. With PKCS, the same TPM KSP setting causes Windows to import the delivered key into the TPM. Both options give you hardware-bound keys post-installation; only SCEP gives you a key that was never outside hardware at any point.
Both RSA and ECC keys can be stored in the Windows TPM, giving you flexibility on key algorithm choice.
macOS
On macOS, the private key is always generated on the device (SCEP) or installed to the System Keychain (PKCS). Hardware binding to the Secure Enclave is possible with SCEP on Apple Silicon Macs (M1/M2/M3 and later) and Intel Macs with T2 chips, but only with ECC P-256 keys — RSA keys cannot be stored in the Secure Enclave on macOS.
Critically, Intune cannot guarantee or force Secure Enclave storage on macOS through the SCEP profile — it is determined by the OS based on hardware capability and key algorithm. This is a meaningful difference from Windows where you can explicitly mandate TPM KSP.
iOS and iPadOS
iOS has the most straightforward hardware binding story, and it works automatically. All modern iPhones and iPads (A7 chip and later — effectively everything from iPhone 5s onward) have a Secure Enclave. When a SCEP enrollment uses ECC P-256 as the key type, iOS stores the private key in the Secure Enclave automatically — no additional configuration is needed. The key is hardware-bound and cannot be extracted.
RSA keys on iOS are stored in the software Keychain, which is protected by hardware-encrypted storage and the device passcode, but is not Secure Enclave-bound. For this reason, always use ECC P-256 for iOS SCEP deployments.
Platform comparison
| Capability | Windows | macOS | iOS / iPadOS |
|---|---|---|---|
| SCEP key generation location | Device (software or TPM) | Device (software or Secure Enclave) | Device (software or Secure Enclave) |
| PKCS key origin | Connector → imported to TPM | Connector → software Keychain only | Connector → software Keychain only |
| Hardware binding (SCEP) | Yes — TPM | ECC only, not guaranteed | Yes — ECC auto-SE |
| Hardware binding (PKCS) | Yes — TPM KSP | No | No |
| Force hardware storage via Intune | Yes | No | Automatic with ECC |
| Best key algorithm for HW binding | RSA or ECC | ECC P-256 | ECC P-256 |
| Auto-renewal via Intune | Yes | Yes | Yes |
| Cert removed on Intune unenrollment | Yes | Yes | Yes |
5 TPM and hardware key storage — the full story
Hardware key storage is the single most important security dimension in this comparison. Here's the complete picture across both options and all platforms.
SCEP + TPM (Windows) — strongest option
Configure the Intune SCEP profile to use Enroll to Trusted Platform Module (TPM) KSP, otherwise fail. The key pair is generated inside the TPM during enrollment. The private key never exists in software at any point — it is created in hardware, lives in hardware, and operations that use it (signing, decryption) happen inside the hardware. It cannot be exported by anyone, including administrators.
PKCS + TPM KSP (Windows) — strong, with a caveat
Configure the Intune PKCS profile to use the TPM KSP and set Enroll to Trusted Platform Module (TPM) KSP, otherwise fail. Windows imports the delivered private key into the TPM during PFX installation. Post-installation, the key is hardware-bound and has the same protection properties as a SCEP TPM key. The caveat: the private key existed on the connector server transiently during PFX packaging. For most organisations this is an acceptable residual risk — the window is brief and the connector should be a hardened, access-controlled server. For the highest-sensitivity environments, SCEP + TPM removes this risk entirely.
SCEP + ECC P-256 (iOS) — strong and automatic
No special configuration needed. Any iOS device on A7 silicon or later (iPhone 5s / iPad Air 1st gen and later — effectively all devices in active use) will automatically store an ECC P-256 private key in the Secure Enclave. The key cannot be extracted. Just set the Intune SCEP profile to use ECC P-256 and iOS handles the rest.
SCEP + ECC P-256 (macOS) — best effort
On Apple Silicon and T2-equipped Intel Macs, macOS may store an ECC P-256 SCEP key in the Secure Enclave, but this is not guaranteed or configurable from Intune. It is hardware-dependent and OS-determined. On older Intel Macs without a T2 chip, keys will be in the software Keychain regardless of algorithm. This is the weakest hardware binding story of any platform.
6 Key archival and recovery — the deciding factor
There is one architectural difference between SCEP and PKCS that trumps almost everything else, and it comes down to a single question: does this certificate's private key ever need to be recovered?
SCEP cannot archive keys — by design
In SCEP, the private key is generated on the device and never leaves it. The CA only ever sees a certificate signing request containing the public key. This means there is nothing for the CA to archive — the private key simply does not exist anywhere the CA can capture it. Active Directory Certificate Services key archival, using a Key Recovery Agent (KRA), requires the private key to be escrowed at the CA at the moment of issuance. That is fundamentally incompatible with the SCEP model. If you need recoverable keys, SCEP is architecturally ruled out.
For authentication certificates, this is a feature — not a limitation
Here's the key insight: for authentication certificates — Wi-Fi, VPN, 802.1X — you never want to recover the private key. If a device is lost, wiped, or the key is otherwise gone, the correct response is simply to issue a new certificate. There is no data locked behind an authentication key, so there is nothing to recover. A non-recoverable, TPM-bound, non-exportable key is exactly what you want. SCEP delivers precisely this.
For encryption certificates, recovery is mandatory
Encryption certificates are the opposite case. If a user loses the private key for an S/MIME email certificate or an EFS file-encryption certificate, every message and every file ever encrypted to that key becomes permanently unreadable. For these use cases, the key must be archived at the CA so it can be recovered — which means it must be generated in a way the CA can escrow. SCEP cannot do this; you need a PKCS flow with key archival enabled on the CA and a configured Key Recovery Agent.
| Use case | Key recoverable? | Right approach |
|---|---|---|
| Wi-Fi / VPN / 802.1X client auth | No — reissue if lost | SCEP (or PKCS), TPM-bound, non-exportable, no archival |
| S/MIME email encryption | Yes — losing it loses all encrypted mail | PKCS with CA key archival + Key Recovery Agent |
| EFS / data-at-rest encryption | Yes — losing it loses all encrypted files | PKCS with CA key archival + Key Recovery Agent |
7 Side-by-side comparison
| Factor | SCEP | PKCS (PFX delivery) |
|---|---|---|
| Private key generation | On the device — always | On the AD CS server / connector |
| Private key in transit | Never — only CSR and signed cert flow | Transits connector transiently during packaging |
| NDES required | Yes | No |
| Infrastructure complexity | Higher — Connector + NDES + CA | Lower — Connector + CA |
| Windows TPM binding | Yes — key generated in TPM (strongest) | Yes — key imported to TPM (strong) |
| iOS Secure Enclave binding | Yes — automatic with ECC P-256 | No |
| macOS Secure Enclave binding | Best effort with ECC P-256 on Apple Silicon | No |
| Key attestation | Possible on Windows with TPM | Not possible |
| Certificate template exportable key flag | Not required | Required at issuance |
| Key archival / recovery possible | No — key never leaves device, cannot be escrowed | Yes — supports CA key archival for recovery |
| Suits authentication certificates | Yes — ideal (non-recoverable is a feature) | Yes |
| Suits encryption certificates (S/MIME, EFS) | No — cannot recover lost keys | Yes — with archival enabled |
| Bulk enrollment throughput | Limited by NDES rate limiting (tunable) | More predictable — connector-controlled |
| Offline device renewal risk | Similar — device reaches Intune to renew (not NDES directly) | Lower — MDM channel used for delivery |
| PCI / regulated environments | Preferred — stronger key model | Acceptable with TPM KSP (Windows only) |
| Operational overhead | Higher — more components to manage | Lower — simpler architecture |
8 Which one should you choose?
The right answer depends on your security requirements, device mix, and operational capacity. Here's the decision breakdown:
- You need the strongest possible key security model — key never leaves the device
- You have iOS or macOS devices and want Secure Enclave key binding
- Hardware key attestation is a requirement
- The certificates are for authentication only — no key recovery needed (reissue on loss)
- You have operational capacity to deploy and maintain NDES securely
- Your device estate includes significant non-Windows platforms
- You want simpler infrastructure with no NDES to manage
- Your estate is primarily Windows and TPM KSP covers your key binding needs
- You need predictable throughput for large bulk enrollment events
- You're pre-provisioning user certificates before first login
- You need key archival and recovery — S/MIME, EFS, or any encryption certificate
- Operational simplicity is a priority and key transit risk is acceptable
- You want fewer components to troubleshoot and maintain
9 The SCEPman angle
If the main drawback of SCEP is the operational overhead of running and maintaining NDES, it's worth knowing that this problem is solvable without switching to PKCS.
SCEPman: SCEP security without NDES complexity
SCEPman (from Glueck Kanja GAB) is a cloud-native SCEP and OCSP service that runs in your Azure tenant as an App Service. It implements the SCEP protocol natively in the cloud, replacing NDES entirely. Devices enroll via SCEP and generate their own key pairs locally — the full SCEP security model, including Secure Enclave binding on iOS with ECC P-256 and TPM binding on Windows.
The CA private key is protected by Azure Key Vault with HSM backing (FIPS 140-2 Level 2+), and revocation can be linked to Intune device compliance state in real time — automatically revoking certificates when devices fall out of compliance or are unenrolled.
If you want the strongest key security model (SCEP, device-generated keys, hardware binding across all platforms) without the operational burden of running and hardening an on-premises NDES server, SCEPman is architecturally the cleanest answer.
Key takeaways
- SCEP generates keys on the device — the private key never exists anywhere in your infrastructure. PKCS generates keys on the connector and delivers them to the device. This is the fundamental security difference.
- PKCS + TPM KSP on Windows imports the delivered key into the TPM, giving hardware-bound protection post-delivery — but the key still transited the connector. SCEP + TPM generates the key in the TPM and it never leaves hardware.
- On iOS, SCEP with ECC P-256 automatically stores private keys in the Secure Enclave — no configuration required. PKCS on iOS is always software-stored.
- SCEP requires NDES — but in the Intune Certificate Connector model it is not internet-facing. The connector polls Intune outbound; devices never talk to NDES. Both servers can be fully isolated. The real cost of NDES is operational (one more role to run), not exposure. PKCS requires only the connector and your CA.
- For mixed Windows/macOS/iOS environments, SCEP provides a more consistent security posture — hardware binding works across all platforms. PKCS hardware binding is Windows-only.
- SCEP cannot archive keys for recovery — the CA never sees the private key. This makes it perfect for authentication certificates (reissue on loss) but rules it out for encryption certificates like S/MIME or EFS, which need an archival-capable PKCS flow. Split your architecture along these lines.
- The PFX password in the on-demand flow is a transport wrapper only — generated automatically, consumed once at install, then discarded as the key enters the TPM. No user types it, no one distributes it. Don't confuse it with the admin-supplied password in the separate imported-PFX/S-MIME feature.
- SCEPman/Cloud PKI eliminates the NDES problem while retaining full SCEP key security — worth evaluating if NDES complexity is your main objection to SCEP.
No comments:
Post a Comment