Intune offers two main ways to put a CA-issued certificate on a managed device: SCEP profiles and PKCS profiles. They end in the same place — a certificate in the device's store — but they get there by fundamentally different routes, and picking the wrong one causes problems that only surface later, at renewal time or when a user gets a second device. This guide covers the mechanics, the differences that actually matter, and a simple rule for choosing.
The core difference: where the private key is born
SCEP (Simple Certificate Enrollment Protocol) is a request protocol. The device generates its own key pair locally, builds a certificate signing request (CSR), and submits it to a SCEP endpoint together with a challenge that proves the request was authorised by Intune. The CA signs the request and returns a certificate. The private key is created on the device and never travels anywhere — on capable hardware it can be generated inside a TPM, Secure Enclave or StrongBox, making it non-exportable by design.
PKCS delivery inverts this. The key pair is generated server-side — with on-prem ADCS, by the Intune Certificate Connector, which requests the certificate from your CA and packages certificate plus private key into an encrypted PFX blob that Intune delivers to the device. The key exists, at least momentarily, outside the device that will use it.
Intune also supports imported PKCS certificates (often called PFX import), where you bring certificates issued elsewhere — typically existing S/MIME certificates — and Intune distributes them to a user's devices. Same delivery mechanism, but issuance happens entirely outside Intune.
Everything else — security posture, infrastructure requirements, multi-device behaviour, renewal — follows from where the key is born.
Security implications
For authentication use cases, device-generated keys are simply stronger. A SCEP-issued certificate whose key lives in a TPM cannot be copied to another machine; stealing the certificate file gets an attacker nothing without the hardware. That's the property that makes EAP-TLS worth deploying in the first place.
A PKCS-delivered key is exportability-by-design: the whole point is that the key can exist in more than one place. The delivery pipeline protects it in transit (the package is encrypted for the target device), but the key's lifecycle includes a server-side generation step and, depending on your CA configuration, possible key archival. That's a liability for authentication — and exactly the feature you need for encryption.
The multi-device problem, and why S/MIME forces PKCS
Consider S/MIME encryption. Mail encrypted to a user is encrypted with their public key; reading it requires the corresponding private key. If the user reads mail on a laptop, a phone and a tablet, the same private key must be present on all three. A device-generated SCEP key can't do this — each device would have a different key, and mail encrypted to one would be unreadable on the others.
PKCS profiles handle this natively: a user-targeted PKCS certificate is delivered to each of the user's enrolled devices with the same key material. This is the canonical PKCS use case, and there's no SCEP workaround for it.
Signing is more forgiving — a signature only needs a valid key, not a shared one — but in practice S/MIME deployments deliver both signing and encryption certificates via PKCS for consistency, and key recovery (so a replacement device can still read old mail) is only possible when keys are escrowed, which again means server-side generation.
Infrastructure differences
With on-prem ADCS, both routes need the Intune Certificate Connector, but they use it differently:
- SCEP needs a SCEP endpoint reachable from wherever devices roam — with ADCS that means NDES published to the internet, with all the operational weight that carries. The connector validates challenges; the device talks to the SCEP URL directly.
- PKCS needs no internet-facing endpoint at all. The connector makes an outbound connection to Intune, picks up pending requests, gets certificates from the CA, and hands the encrypted packages back to Intune for delivery. For organisations allergic to publishing endpoints, this is PKCS's quiet advantage.
Cloud-issued alternatives shift this picture: Microsoft Cloud PKI and third-party cloud SCEP services remove the NDES burden from the SCEP path entirely, while PKCS remains tied to a connector and an on-prem (or self-managed) CA. If you're cloud-only with no ADCS, SCEP via a cloud CA is usually the only practical route — which is fine, because cloud-only estates rarely have the S/MIME requirements that demand PKCS.
Renewal behaviour
Both profile types renew before expiry, driven by the profile's renewal threshold — the percentage of certificate lifetime remaining at which the device becomes eligible to renew. But the mechanics differ in ways that matter operationally:
- SCEP renewal is re-enrolment. The device generates a new key pair and submits a fresh CSR; the result is a new certificate with a new key. Anything that pinned or mapped the old certificate needs to cope with the change — which standard EAP-TLS and VPN configurations do, since they validate the chain and identity rather than the specific certificate.
- Renewal requires the device to check in. A device that's powered off or offline through its entire renewal window will sail past expiry, and if the expired certificate was its Wi-Fi credential, it may not be able to get online to fix itself. Size validity periods and thresholds against your real offline windows — the renewal pitfalls guide covers this trap in detail.
- Certificates are revoked and removed on unenrolment or profile removal (behaviour varies somewhat by platform), so removal of a profile assignment is not a harmless act on a device whose network access depends on that certificate.
Performance and scale
SCEP distributes the cryptographic work: every device generates its own keys, and the CA just signs CSRs. PKCS concentrates work on the connector, which generates keys and processes requests serially per connector instance. For large deployments or bulk re-issuance events (a CA migration, a template change), SCEP scales more gracefully; PKCS deployments should plan connector capacity and expect large waves to take time.
When each one fits
Use SCEP when:
- The certificate authenticates the device or user — Wi-Fi (EAP-TLS), VPN, wired 802.1X, client TLS to internal apps.
- You want keys generated and held in hardware, non-exportable.
- Each device should have its own distinct identity.
- You want the option of cloud-hosted issuance without on-prem infrastructure.
Use PKCS when:
- The same key must exist on multiple devices — S/MIME encryption above all.
- You need key escrow or recovery.
- You want certificate delivery without publishing any endpoint to the internet, and you already run ADCS with the connector.
Use imported PKCS (PFX import) when:
- Certificates are issued by an existing external process and Intune's job is purely distribution.
For most organisations the split lands at: SCEP for everything authentication-related (the bulk of certificates by volume), PKCS only for S/MIME, and no PKCS at all if S/MIME isn't in scope. If you find yourself reaching for PKCS for a Wi-Fi certificate, stop and check the reasoning — it almost always signals a misunderstanding somewhere, and it gives up the hardware-bound key protection that justified certificate authentication in the first place.
One last practical note: whichever protocol you choose, the certificate's content — subject, SANs, key usage, EKU — is defined in the Intune profile and must match what the consuming system expects. A perfectly delivered certificate with the wrong SAN type still fails at the RADIUS server. Get the profile right first; the delivery protocol is the easy part.