How We Built Cloud-Based Certificate Enrolment for Intune-Managed Devices

The problem

Most of our customers are cloud-native SMEs whose Windows fleet lives in Intune. They want certificate-based authentication for 802.1X, it is the most phishing-resistant method and it survives a user changing their password, but they do not want to operate a PKI to get it.

Microsoft's own answer is to stand up AD CS, NDES and the Intune Certificate Connector on an on-prem Windows server, then expose NDES through a reverse proxy or Azure App Proxy. That works. It also adds a server to patch, a CA to back up, an HSM question to dodge and a security zone the customer hoped never to open. For a fifty-laptop SME with one IT contractor, it is a non-starter.

What this means for customers

Arbiter takes the RADIUS pain away. A cloud SCEP service is the natural extension: take the certificate deployment pain away too. The change is in how many moving parts the customer has to own.

That is the whole dependency list. The customer's only job is three Intune profiles and one Azure AD app permission. The CA, the SCEP endpoint, the connector, rotation, revocation and the soak-window root rollover all move into Arbiter and are managed for them. Microsoft Intune certificates with no customer-operated PKI infrastructure, no domain and no certificate team.

What we built, in one paragraph

An Intune-managed device asks Intune for permission to enrol. Intune hands it a signed, short-lived challenge. The device sends that challenge and a certificate request to Arbiter's SCEP service. Arbiter checks the challenge with Microsoft and, if it is valid, signs a certificate from the tenant's cloud CA. The device installs it and uses it for EAP-TLS across Wi-Fi and wired. Intune stays the authority on which devices qualify; Arbiter is the certificate authority that issues to them. Everything below is how that one sentence holds up on the wire.

Architecture

Three parties, one clear division of authority. Intune decides which devices qualify and issues the challenge. Microsoft Graph validates that challenge on every request, so compliance, device assignment and challenge expiry stay enforced by Microsoft. Arbiter is the certificate authority: it never decides who deserves a certificate, it issues one when Graph confirms Intune already said yes. That boundary is what makes a connector-less design legitimate rather than a security shortcut.

Two infrastructure choices follow from that:

• scep.arbiter.ie is its own subdomain, not a path under the app. SCEP clients have no Entra session and no app cookie, so carving an auth exception into the main proxy is the kind of config that drifts into a hole. Separate subdomain, separate access log, clean blast radius.
• /scep/{shortname} is the tenant identifier. The shortname is the same one customers already see in their portal URL, so the Intune profile stays human-readable and there is nothing new to look up.

One request, end to end: the device generates a key pair locally, builds a CSR, wraps the CSR and its challenge in a PKCS#7 CMS envelope and POSTs to scep.arbiter.ie. Arbiter unwraps the envelope, decrypts the CSR, validates the challenge against Graph, signs the CSR under the tenant intermediate, wraps the signed certificate back into a CMS response and posts a success notification so Intune marks the certificate issued. The round trip is about 600 ms, roughly 350 ms of which is the two Graph calls. Windows runs SCEP out of band, so the device never feels that latency.

Lab validation

Test laptop: Windows 11 IoT Enterprise LTSC, Entra-joined, Intune-managed, on the Arbiter Lab tenant. SCEP profile with a 2048-bit RSA spec, a SAN plus UPN subject template and a software KSP.

The certificate authenticating wired EAP-TLS on a Catalyst 9200

ARBITER-SW1#show access-session int g1/0/2 de
        Interface:  GigabitEthernet1/0/2
      MAC Address:  aa11.bb22.cc33
        User-Name:  host/3be8eb6b-34d4-465c-aa16-1ffe268979b8
           Status:  Authorized
           Domain:  DATA

Server Policies:
       Vlan Group:  Vlan: 21

Method status list:
   Method           State
    dot1x           Authc Success

The same certificate authenticated the Wi-Fi profile on the same laptop against the vWLC, into the same VLAN, on the same policy match. One enrolment, two NAS classes, identical outcome. The protocol work all passed in unit tests; the failures that actually blocked us only surfaced once a real laptop met a real switch. Enrolling the key to the TPM KSP broke EAP-TLS until we switched to the software KSP. Windows also ships its wired-autoconfig service disabled, so wired 802.1X did nothing until a Platform Script started it. Both fixes are in the customer setup guide.

Why this matters

The same plumbing extends to macOS, iOS and iPadOS via Intune, to Jamf as a second MDM and to operator-minted challenges for non-MDM devices like IoT and network gear.

The selling point of cloud NAC for the SME is that we run the boring infrastructure so you do not. For a fifty-laptop firm, standing up AD CS, NDES and a Connector to get certificate-based 802.1X is exactly the project that never quite happens, so the fleet stays on a pre-shared key instead.

The goal is not to eliminate PKI. It is to remove the parts of PKI that belong in every customer's ticket queue.

References

• RFC 8894: Simple Certificate Enrolment Protocol (SCEP)
• RFC 5652: Cryptographic Message Syntax (CMS)
• RFC 3279: Algorithms and Identifiers for the X.509 Public Key Infrastructure
• Microsoft Learn: Configure infrastructure for SCEP certificates in Intune (NDES path, for contrast)