This build sheet takes the certificate that the previous sheet put on the device and makes the network believe it: the RADIUS-side trust checklist, the Wi-Fi profile that presents the right certificate to the right server, the per-platform traps, and an end-to-end authentication test that includes proving a revoked certificate gets refused.
The authenticator itself is whichever of the three shapes you chose in the RADIUS article, and this sheet stays vendor neutral: the checklist below is what any EAP-TLS terminator needs from you, with the NPS-specific notes called out where the incumbent differs. Certificates must already be issuing and validated per the CA build sheet before anything here will work.
Prerequisites
- The profile trio from the CA build sheet is deployed and certificates are confirmed on pilot devices for every platform in scope.
- The authenticator is chosen and standing: an NPS box, a cloud RADIUS tenant, or equipment-local termination.
- You know the authenticator’s own server certificate: who issued it, its subject names, and which root signs it, because clients will be told to expect exactly that.
- The SSID plan is decided. For a migration, a parallel SSID makes rollback trivial; flipping the certificate reference on an existing SSID’s profile is cleaner long term but commits the population that receives it, per the migration sequencing.
- The Cloud PKI CRL distribution point URLs recorded during the CA build are in hand for firewall work.
Step 1: Prepare the authenticator
| Item | Requirement | Why |
|---|---|---|
| Trust the client chain | Upload BOTH the Cloud PKI root and issuing CA certificates | Validation needs the full chain, and Android clients will not fetch intermediates for anyone; assume nothing else will either. |
| Revocation reachability | The authenticator can fetch the Cloud PKI CRL URLs over the internet from its own egress path | The CDP is Microsoft-hosted and public; a datacenter RADIUS segment with no egress fails every connection in default NPS posture. These URLs are not in Microsoft’s endpoint allowlist doc, so hand your firewall team the ones you recorded. |
| Migration overlap | Old and new chains trusted simultaneously for the entire cutover | Pulling the old root while any population still presents old certificates looks exactly like a RADIUS outage. |
| Server certificate | Valid server-authentication certificate with the DNS names clients will be told to expect | Cloud PKI cannot issue it. Source it from a public CA, a surviving private CA, or the cloud RADIUS vendor, and record which root signs it for Step 2. |
| NPS only: object mapping | Devices hybrid joined, objects synced, certificates carrying the SID alternative name | NPS authorizes against AD, strong mapping is permanently enforced, and a certificate without the SID is refused. The failure signature is a denial with reason code 16. |
One NPS note worth stating before it is discovered at 2 a.m.: the registry switches that relax revocation checking exist for diagnosis, not for production. If certificate connections only work with revocation checking loosened, the finding is that your RADIUS server cannot reach the CRL, and the fix belongs in the firewall, not the registry.
Step 2: The Windows Wi-Fi profile
| Setting | Value | Why |
|---|---|---|
| Wi-Fi type | Enterprise | Enterprise unlocks the EAP configuration; Basic is pre-shared-key territory. |
| Connect automatically / when hidden | Enabled as your SSID design requires | Machine-auth Wi-Fi that does not connect automatically defeats its own purpose at the logon screen. |
| EAP type | EAP-TLS | Certificate authentication on both sides; no passwords anywhere in the exchange. |
| Certificate server names | The exact subject names from the authenticator’s server certificate | Pins which servers the client will speak to and suppresses the trust prompt users would otherwise learn to click through. |
| Root certificates for server validation | The trusted profile carrying the root that signed the SERVER certificate | This is the server’s root, which is not necessarily your Cloud PKI root: a public-CA server certificate means no root profile is needed at all, because the device already trusts it. |
| Authentication method | SCEP certificate, referencing the profile from the CA build sheet | This reference IS the cutover switch: the certificate presented changes when and only when this changes. |
| Authentication mode | Machine | Device certificates authenticate before anyone signs in; choose User only when network policy must follow the person, matching the certificate-type decision made in the CA sheet. |
Step 3: Per-platform notes
iOS, iPadOS, and macOS follow the same shape with Apple’s payload names: the enterprise Wi-Fi profile references the SCEP certificate as the identity and the trusted certificate profile for server validation, and macOS adds the user-versus-device channel decision that should match the certificate type. Android carries the sharp edges. Deploy the full chain, root and issuing profiles both, because Android performs no chain discovery. Populate the RADIUS server name: on current Android versions a profile without it may simply refuse to connect, and Microsoft documents a length cap on that field in newer releases, so the documented guidance is to enter the domain suffix rather than an exhaustive server list. And on AOSP devices, SCEP certificates support Wi-Fi configuration only, which happens to be exactly this scenario, but nothing beyond it.
Step 4: Assign, ringed
Assign the Wi-Fi profile to the same pilot group that already holds the certificate trio, and expand ring by ring only after the pilot passes the end-to-end test below. In a migration, this is the step where the sequencing doctrine becomes real: populations move one at a time, the previous profile remains one reference-change away, and nothing retires until the last ring settles.
Validation
- On a pilot Windows device, confirm the interface state and the profile in use:
netsh wlan show interfaces
netsh wlan show profiles
Get-WinEvent -LogName "Microsoft-Windows-WLAN-AutoConfig/Operational" -MaxEvents 20 | Format-List TimeCreated, Id, Message- On the authenticator, confirm the success from its side: NPS logs an access-granted event (6272) naming the device and the EAP-TLS method, and a denial (6273) carries the reason code that separates a mapping failure from a revocation failure from an expired certificate. Cloud RADIUS services surface the same verdicts in their portal logs, usually with the presented certificate’s subject and serial.
- Confirm the device connected with the certificate you intended, not a cached credential or a neighboring SSID: the serial number in the authenticator’s log should match the certificate on the device.
End-to-end test
The positive path first: restart the pilot device and watch it join the network from the logon screen, before any user signs in, which proves machine authentication end to end. Then the test most deployments skip, which is the one that matters: prove that revocation actually refuses access. Remove the pilot device from the SCEP profile assignment, revoke its certificate, and attempt to connect. Expect nuance here rather than instant rejection: the authenticator honors its cached revocation list, which can be days old by design, so the refusal becomes reliable only after the cache refreshes, and forcing a revocation-list refresh on the authenticator is the honest way to see the final state promptly. When the connection is refused and the log names the revocation as the reason, you have witnessed the entire chain of custody work: issuance, delivery, presentation, validation, and revocation, each performed and each verified. Restore the device afterward, re-add it to the assignment, and let a fresh certificate issue.
That completes this family. The anchor frames what Cloud PKI is and refuses to be, the doctrine articles argue the hierarchy, the lifecycle, the authenticator, and the migration, and the two build sheets stand the whole thing up and prove it works. Operate it from here with the quarterly review discipline the lifecycle article prescribes, and with the standing rule that has carried every piece of this family: the parts Microsoft automates are excellent, and the parts it leaves quiet are yours to own on purpose.
Intune Deployment Guide · Phase 12: The Intune Suite
‹ Previous: [12.3.5] Build Sheet: Cloud PKI CAs and the Profile Trio
Next: [12.4] The Operational Layer: Remote Help, Advanced Analytics, and Tunnel for MAM ›
