Quickstart - Microsoft Intune SCEP

This walks through the Intune configuration profiles a Windows device needs to enroll: the trusted-root profile, a device certificate, and a user certificate. It assumes the Entra directory is already connected — see Microsoft Intune — and an endpoint has Microsoft Intune enabled under Enrollment authentication.

Deploy the root before the SCEP profile reaches a device, and assign both to the same device group.

1. Trusted certificate profile

Download the CA bundle from the endpoint page, then create a Trusted certificate profile (Windows 10 and later) in Intune:

• Certificate file — the downloaded bundle.
• Destination store — Computer certificate store — Root.

Without this step the device enrolls but never trusts the issuing hierarchy, so anything presenting the certificate afterward — Wi-Fi, VPN, 802.1X — fails even though enrollment reported success.

2. Device certificate profile

Create a SCEP certificate profile with Certificate type set to Device.

Intune's warning about the Any Purpose and Any App Policy EKUs applies to authorities created in Microsoft's own Cloud PKI product, not to a SimpleSCEP root — and SimpleSCEP refuses anyExtendedKeyUsage outright regardless of which CA it comes from, so it does not apply here either way.

3. User certificate profile

Same profile type, Certificate type set to User:

Root certificate, extended key usage, renewal threshold, and SCEP Server URLs work the same as the device profile.

How far the customization goes

SimpleSCEP does not maintain a list of Intune variables it understands, and it does not rewrite a request to fit one. The subject and every subject alternative name are checked against the endpoint's own subject and SAN patterns — plain regular expressions an administrator writes — and, if they match, issued exactly as the profile sent them. {{DeviceName}}, {{UserPrincipalName}}, {{AAD_Device_ID}}, a custom OU=, an unusual SAN shape — none of it needs SimpleSCEP's support to work, only a pattern on the endpoint that allows it through.

The one asymmetry worth knowing before deploying either profile above: a blank subject pattern accepts anything, but a blank SAN pattern accepts nothing — an endpoint with no SAN pattern set refuses both the device profile's URI SAN and the user profile's email SAN. Set a pattern on the endpoint's Issuance policy before assigning either profile, for example:

Device endpoint SAN pattern:  ^IntuneDeviceId://[0-9a-fA-F-]{36}$
User endpoint SAN pattern:    ^[^@\s]+@yourcompany\.com$

Anchor both with ^…$; an unanchored pattern matches a substring of the name, not the whole thing. If device and user certificates share one endpoint, the pattern needs to accept both shapes — putting each on its own endpoint keeps the pattern, validity, and permitted usages specific to what that population actually needs. See Issuance profiles and key usages for how the subject and SAN patterns are evaluated.

SCEPman's Windows 10 Intune guide walks through the same three profiles and is a reasonable reference for the Intune side of this. Where it differs is what happens after Intune sends the request: SCEPman's own configuration settings decide what a profile may ask for, where SimpleSCEP's issuance policy — subject pattern, SAN pattern, and permitted extended key usages, all set per endpoint — decides it instead, so changing what a profile can request is an endpoint setting, not a redeployment.

Verify enrollment

Sync the device, then confirm the certificate on the Certificates page — subject, SANs, and usages should match what the profile asked for. If enrollment fails, check the endpoint's Recent enrollments log for the refusal reason before assuming the profile is wrong; see Troubleshooting.