Designing, deploying, and operating Microsoft Intune. Home of the Intune Deployment Guide.
Conditional Access is authored by whoever owns identity, but the signal it reads is manufactured by the endpoint estate. This is what the Intune side of that seam actually owns, and what a compliant device claim does and does not promise.
The unbox-and-install checklist has been optional for years. Here is what Windows deployment looks like when Autopilot, Intune, and Entra do the repetitive work, and what has to be true in your tenant before it feels effortless.
Wiring the Cloud PKI certificate into EAP-TLS Wi-Fi: the vendor-neutral RADIUS checklist, the Wi-Fi profile settings, the per-platform traps, and an end-to-end test that proves a revoked certificate gets refused.
Standing up the Cloud PKI hierarchy and the profiles that deliver from it: root CA, issuing CA, trusted certificate profiles, and the SCEP profile, ending with a validated end-to-end issuance and revocation test.
Microsoft gives you coexistence primitives but no migration doctrine. The sequencing that cannot strand a device, and the honest ledger at the end: NDES retires, the connector retires conditionally, AD CS almost never does.
Cloud PKI issues the client certificates, but Microsoft sells nothing that terminates EAP-TLS. The authenticator decision, NPS, cloud RADIUS, or the box itself, quietly decides how much Active Directory you keep.
Cloud PKI automates issuance, renewal, and revocation, but its edges are where certificate incidents come from. What is documented, what the field has observed, and how I design around both.
Cloud PKI gives you three certificate authority slots and no way to edit a CA after you create it. That makes hierarchy design a one-shot decision, and this is how I make it.
