SCEP vs PKCS Intune: which certificate profile to use, and where each breaks

Intune can deliver a certificate from a Microsoft certification authority two ways, and the choice is structural rather than a preference. SCEP vs PKCS Intune comes down to one difference that decides everything else: where the private key is created. Most comparison guides lead with the infrastructure, which is the consequence and not the cause. This page leads with the key, gives the decision as a table, then covers what each path needs, where each one breaks, and what Cloud PKI does to the answer.

If you are here because a connector is already failing rather than because you are choosing, the diagnosis order for a broken Microsoft CA path is in why Intune NDES connector requests fail. If you hold the licence for it, the question may be moot: Intune Cloud PKI cost covers the option that removes the on-premises server from both sides of this comparison.

One disclosure before the detail. My tenant is a lab with no enrolled devices. I have not run either profile type against a production certification authority, so every factual claim below is taken from Microsoft’s current documentation and verified on 24 September 2026, with the source named. The judgement section at the end is labelled as judgement rather than measurement.

SCEP vs PKCS Intune: the decision in one table

Read the first row first. Everything below it follows from it.

Where the private key is created, and why it decides the rest

Microsoft states the difference plainly on the PKCS certificate profile documentation: “Unlike SCEP, with PKCS the certificate private key is generated on the server where the certificate connector is installed and not on the device.” The same page adds the consequence that most deployment guides skip: “The certificate template must allow the private key to be exported so that the connector can export the PFX certificate and send it to the device.”

That is the whole decision, and it is a security decision before it is an operational one. A PKCS deployment requires a certificate template marked exportable, a PFX containing the private key travelling from your connector server to Intune and down to the device, and an issuing CA that is capable of producing a key it does not control. Plenty of security teams will not sign that off, and they are not being awkward. Microsoft does mark the key as non-exportable once it lands: “After the certificates install on the device, the private key is marked as not exportable.” That protects the key at rest on the endpoint. It does nothing about the window in which the key existed somewhere else.

SCEP inverts it. The device generates the key, keeps it, and sends only a certificate signing request. Nothing that could impersonate the device ever crosses the wire. The price is the infrastructure: for a Microsoft CA you need the Network Device Enrollment Service, its policy module, and a challenge validation path that has several places to go wrong.

If you have no constraint pushing you towards PKCS, pick SCEP. If your certificate has to carry attributes that only a directory knows, or your recovery model depends on the CA archiving the key, pick PKCS and accept the exportable template.

What each one needs before it will issue anything

The PKCS prerequisites, as documented: an Active Directory domain with domain-joined servers, an Enterprise certification authority rather than a Standalone one, an exported copy of the root certificate, and the Certificate Connector for Microsoft Intune at version 6.2406.0.1001 or later. The connector server’s computer account needs Read and Enroll on the certificate template, and Issue and Manage Certificates plus Request Certificates on the CA itself. A user type PKCS certificate additionally requires user affinity on the device, which in practice means the device has a primary user, and what the Intune primary user field controls is worth reading before you assume it is populated.

That connector version is not arbitrary. It is the build that adds the security identifier extension to issued certificates, which is what satisfies the strong certificate mapping the Key Distribution Center has required since KB5014754. Microsoft’s wording: “The Key Distribution Center (KDC) requires a strong mapping format in PKCS certificates deployed by Microsoft Intune and used for certificate-based authentication.” Installing the right build is not enough on its own. You also have to turn it on:

1# Enables the SID extension in certificates issued through PKCS profiles.
2# Without this value, certificate-based authentication against a patched
3# domain controller fails strong mapping and the logon is refused.
4HKLMSoftwareMicrosoftMicrosoftIntunePFXCertificateConnector
5    EnableSidSecurityExtension  (DWORD) = 1

Restart the connector service afterwards. This is the single most common way a PKCS deployment passes every test in the Intune console and then fails at the point of use, because the certificate is present, valid and correctly assigned, and the domain controller still refuses it.

The SCEP side needs NDES, the same certificate connector, and a trusted root certificate profile deployed to the same group as the SCEP profile. Miss the trusted root profile and the SCEP profile fails for a reason that looks nothing like a missing root.

Both share two documented boundaries worth knowing before you design a subject name. Certificate validity must sit between five days and 24 months, and Microsoft warns that periods shorter than five days risk the certificate landing in a near-expiry or expired state on arrival. Android 12 and later, on personally-owned work profile devices, no longer supply serial number, IMEI or MEID, so any subject or subject alternative name built on a hardware identifier will be empty on exactly the devices you were trying to identify.

The Windows key storage difference that catches people

A SCEP profile on Windows lets you choose the key storage provider: the Trusted Platform Module KSP if the device has one, the Software KSP, or Windows Hello for Business. That choice is in the profile. The SCEP certificate profile documentation also records the limits on it: 4096 bit keys are not supported on a hardware TPM, and Windows Hello for Business does not support 4096 bit keys at all, with no workaround offered.

A PKCS profile gives you no such control, and the same 4096 bit ceiling applies in a less forgiving way: on Windows, 4096 bit key storage is supported only in the Software KSP. If somebody in your organisation has written 4096 bit into a certificate standard and somebody else has written hardware-backed key storage into the same document, those two requirements cannot both be met. That conflict is usually discovered after the CA has been built.

The failure modes

PKCS failures concentrate in one log, on the connector server, at %program_files%Microsoft intunendesconnectorsvclogslogs, in files named NDESConnector_date_time.svclog. The name is a leftover and it is misleading: the PKCS path logs there too. These are the strings worth searching for, quoted from Microsoft’s PKCS certificate profile troubleshooting article, last updated 30 March 2026.

1# The connector cannot reach the CA over RPC. Firewall or CA service, not Intune.
2IssuePfx - COMException: ... (0x800706BA): CCertRequest::Submit: The RPC server
3is unavailable. 0x800706ba (WIN32: 1722 RPC_S_SERVER_UNAVAILABLE)
4
5# The template name in the profile does not match a template published on the CA.
6IssuePfx - COMException: ... (0x80094800): The requested certificate template
7is not supported by this CA.
8
9# The CA is issuing, but manual approval is on. Check Pending Requests on the CA.
10IssuePfx - The submission is pending: Taken Under Submission
11
12# The CA policy module rejected it. Usually template permissions or subject rules.
13IssuePfx - The submission failed: Denied by Policy Module

Two of those look like Intune problems and are not. “The RPC server is unavailable” is a network path or a stopped certificate services instance between your connector and your CA. “Taken Under Submission” means the CA is working exactly as configured and somebody left certificate manager approval enabled on the template, so every request sits in the Pending Requests folder until a human clicks it. Neither will resolve by re-syncing the device.

“Denied by Policy Module” is the one that wastes the most time, because it is a category rather than a cause. The frequent specific case is CERTSRV_E_SUBJECT_EMAIL_REQUIRED, where the template demands an email name in the subject or subject alternative name and the user object does not have one populated. The error surfaces on the CA, not in Intune, and the device shows only a generic profile failure.

When a request is stuck rather than failing, the connector leaves evidence on disk. Three folders under %programfiles%Microsoft IntunePfxRequest, named Failed, Processing and Succeed, tell you within seconds whether the request ever reached the connector at all. If Processing is filling and Succeed is not, the problem is between the connector and the CA. If all three are empty, the problem is upstream and the device never generated a request worth forwarding, which usually means assignment or the missing trusted root profile.

The device-side logs are worth knowing but are rarely where the answer is. On Windows, Event Viewer under Applications and Services Logs, Microsoft, Windows, DeviceManagement-Enterprise-Diagnostics-Provider. On Android, OMADM.log through the Company Portal app. Both will tell you the profile failed. Neither will tell you why, because the device genuinely does not know. The same asymmetry applies when a policy simply never lands, which is covered in the Intune device not syncing diagnosis order, and when two profiles disagree, covered in which Intune policy actually wins.

What Cloud PKI does to this decision

Microsoft Cloud PKI changes the shape of the question rather than answering it, and it does so in one direction only. Its documentation, last updated 11 June 2026, states that its components “replace the need for an on-premises certificate authority, NDES, and Intune certificate connector”, and that support “is for the SCEP (PKCS#7) protocol and certification format, and Intune-MDM enrolled devices supporting the SCEP profile”.

Read that second quote carefully, because the words PKCS and SCEP both appear in it and they are not doing the same job. PKCS#7 there is a certificate format. The profile type you deploy is a SCEP profile. Cloud PKI does not issue through a PKCS certificate profile.

The practical consequence: if Cloud PKI is anywhere on your roadmap, a PKCS deployment today is work you will redo. Moving a fleet from a PKCS profile to a SCEP profile is not a settings change. It is a new profile, a new issuing chain, a reissue to every device, and a revocation plan for the old certificates. If the only reason you were reaching for PKCS was that NDES looked like too much server to build, Cloud PKI removes that reason entirely and leaves you on the SCEP side of the table.

What I would do differently

Start from the security constraint, not the infrastructure. The SCEP vs PKCS Intune question is never really which profile is easier to deploy. It is whether your organisation will accept a certificate template that permits private key export. Ask that first, in writing, before any server is built. It takes ten minutes and it eliminates one of the two options in most regulated environments.

Treat the SID extension registry value as part of the PKCS build, not as troubleshooting. It belongs in the build document next to the connector version, because the failure it prevents does not look like a certificate problem. It looks like a broken logon, days later, reported by a user who cannot tell you what changed.

Do not let a certificate standard specify both 4096 bit keys and hardware-backed storage on Windows. One of those has to give, and finding out which after the CA is in production is an expensive way to learn it.

If you are building new in 2026 and the licence is available to you, evaluate Cloud PKI before either option here. Not because the on-premises path is broken, but because you would be choosing to own two servers, a policy module and a renewal cycle in order to arrive at the same SCEP profile you would have deployed anyway.

Last verified: 24 September 2026.