This build sheet stands up a Cloud PKI hierarchy and the profile trio that delivers certificates from it: root CA, issuing CA, two trusted certificate profiles, and the SCEP profile, ending with a validated end-to-end issuance test. The design decisions behind every value here are argued in the doctrine articles; this is the execution.
Two things before the first step. Every CA property below is permanent once created, so treat this sheet as a checklist you complete on paper first and transcribe second, exactly as the hierarchy article argues. And do not build production on a trial: trial CAs use software-backed keys that never convert to HSM keys, so a hierarchy created during evaluation is a throwaway by design.
Prerequisites
Confirm each of these before creating anything:
- Licensing is active and visible in the tenant: Microsoft 365 E5 (provisioned in the summer 2026 wave), the Intune Suite, or the standalone Cloud PKI add-on. If the Cloud PKI node is missing under Tenant administration, the license has not landed yet.
- The hierarchy decisions are written down: trust anchor (cloud root or BYOCA), EKU set, key sizes, validity periods. One attempt, per the doctrine.
- You hold an Intune role that includes the Cloud PKI permissions (Intune Administrator covers it; a scoped role needs the Cloud PKI create/read permissions and, later, revoke).
- The platform list you will serve is known, because every platform needs its own trusted certificate profiles and SCEP profile.
- For BYOCA only: the signing CA’s HTTP AIA and CDP endpoints are settled before the signing ceremony, because those URLs bake into the issuing CA certificate permanently and cannot be amended afterwards. Reachability is a matter for the relying parties on your network that validate these certificates, not for the managed devices, which are given the chain in Step 4.
Step 1: Create the root CA
Tenant administration, Cloud PKI, create a root CA first; the issuing CA anchors to it and cannot exist without it.
| Setting | Value | Why |
|---|---|---|
| Name | Per your naming convention, e.g. VCIO Root CA G1 | The generation suffix matters: roots cannot be renewed in place, so a successor root will one day need a distinct name. |
| Validity | 25 years | Roots cannot be renewed in place; a shorter root schedules a full trust redistribution for yourself. Take the maximum unless policy forbids it. |
| Key size and algorithm | RSA-4096 with SHA-512 | The CA’s choice is the ceiling for everything beneath it, and a 25-year anchor should not carry the smallest allowed key. Leaf certificates still issue at 2048. |
| Extended key usages | Client Authentication, plus only usages you can name a scenario for | Issuing CAs can only offer what the root carries, the set is immutable, and Any Purpose is refused by the product. Narrow and deliberate. |
Step 2: Create the issuing CA
| Setting | Value | Why |
|---|---|---|
| Name | e.g. VCIO Issuing CA 01 | Numbered, because the second issuing CA is the most likely future use of your third and final CA slot. |
| Root CA source | The root from Step 1 | Two-tier is the only cloud-hosted shape; the issuing CA inherits its EKU ceiling from this anchor. |
| Validity | 10 years | Issuing CAs renew in place since mid-2026, staged and tested before activation, with the production SCEP URI unchanged. Long validity costs nothing operationally. |
| Key size and algorithm | RSA-4096 with SHA-512 | Same ceiling logic as the root. This bounds what SCEP profiles may request, not what they must. |
| Extended key usages | Client Authentication (subset of the root’s set) | A mismatch between SCEP profile EKUs and this list is the number one issuance failure, and fixing an EKU means a new CA. |
BYOCA variant. If the issuing CA anchors to your existing private CA instead: create the CA as bring-your-own, download the generated CSR, sign it at your CA using the Subordinate Certification Authority template (any tier of a multi-tier hierarchy can sign), then upload both the signed certificate and the full chain file; Intune requires both. The hash algorithm and validity are inherited from the signing CA, not chosen here, and every certificate in the private chain will need its own trusted certificate profile in Step 4. Do not begin this until the HTTP AIA and CDP configuration from the checklist is settled, because retrofit means re-issuing the CA certificate.
Step 3: Download the CA certificates
From each CA’s properties, download the public certificate: one file for the root, one for the issuing CA. While you are on the issuing CA’s properties, also copy the SCEP URI for Step 5 and record the CRL distribution point URLs, because your network team will need them for anything on-premises that validates these certificates; they are not published in Microsoft’s endpoint documentation.
Step 4: Trusted certificate profiles
Per platform you serve, create two trusted certificate profiles under device configuration: one carrying the root certificate, one carrying the issuing CA certificate. The root profile is mandatory, and the SCEP profile will reference it by name; the issuing profile spares clients from chain-building surprises, and Android in particular does not chase authority information access paths, so the full chain must be delivered. Name them so the pairing is obvious, for example Cloud PKI Root G1 - Windows and Cloud PKI Issuing 01 - Windows. On Windows, the destination store stays Computer certificate store - Root for the root certificate and Intermediate for the issuing certificate. BYOCA estates create one profile per certificate in the private chain, per platform.
Step 5: The SCEP profile
One SCEP profile per platform. The table shows the Windows device-certificate build, which is the workhorse for certificate-based Wi-Fi; the decision between user and device certificates is a row in the table because it is a decision, not a default.
| Setting | Value | Why |
|---|---|---|
| Certificate type | Device | Device certificates authenticate before sign-in and survive shared use; pick User instead when network policy must follow the person rather than the machine. |
| Subject name format | CN={{AAD_Device_ID}} | Guaranteed present on every enrolled device. Avoid {{DeviceId}} on Windows, and avoid attributes (like email) that some targets lack, because a missing attribute means no certificate. |
| Subject alternative name | URI = {{OnpremisesSecurityIdentifier}} for hybrid-joined estates; otherwise omit | Mandatory where AD or NPS will judge the certificate, per the strong-mapping enforcement; meaningless for cloud-only objects, which have no SID. |
| Certificate validity period | 24 months | There is no expiry alerting for leaf certificates; long validity plus a wide renewal window keeps absent devices out of the expired-certificate dead end. |
| Key storage provider | Enroll to TPM KSP, otherwise fail | Hardware-bound keys, and an explicit failure beats a silent software fallback. |
| Key usage | Digital signature, key encipherment | The standard client-authentication pair. |
| Key size | 2048 | 4096 is unsupported in the TPM provider; 2048 with SHA-256 is the compatibility floor and fits under the CA’s ceiling. |
| Hash algorithm | SHA-256 | Universal relying-party support; the CA’s SHA-512 ceiling permits it. |
| Extended key usage | Client Authentication | Must exist on the issuing CA or the profile errors and nothing issues. |
| Renewal threshold | 30% | Roughly a seven-month renewal window on a 24-month certificate; a device has to vanish for most of a year before renewal can be missed. |
| Root Certificate | The trusted profile from Step 4 carrying the ROOT | The linkage rule: this must be the root the issuing CA anchors to, not the issuing certificate itself. |
| SCEP Server URLs | The issuing CA’s SCEP URI, pasted intact | Leave {{CloudPKIFQDN}} exactly as written; Intune resolves it at delivery. Never mix NDES URLs into this list. |
Step 6: Assign as a set
Assign the root profile, the issuing profile, and the SCEP profile to the same group, starting with a pilot ring of a few devices per platform. The SCEP profile depends on the trusted profiles at deployment time, and near-miss assignments where the groups almost overlap are the classic silent failure of this feature. One group, three profiles, expanded together ring by ring.
Validation
- Console: the issuing CA’s dashboard shows issued certificates climbing; remember reporting can trail issuance by up to 24 hours.
- Per profile: the SCEP profile’s device status shows success rows, and any error rows name the device and the reason (missing subject attribute and EKU mismatch are the two to expect).
- On a Windows pilot device, confirm chain and leaf from an elevated prompt:
Get-ChildItem Cert:\LocalMachine\Root | Where-Object Subject -like "*VCIO Root*"
Get-ChildItem Cert:\LocalMachine\CA | Where-Object Subject -like "*VCIO Issuing*"
Get-ChildItem Cert:\LocalMachine\My | Where-Object Issuer -like "*VCIO Issuing*" | Format-List Subject, NotAfter, EnhancedKeyUsageListThe leaf should show your subject format, a two-year expiry, and Client Authentication in the usage list. On iOS and macOS the equivalent check is the management profile’s certificate payloads plus the device’s entry in the SCEP profile report; on Android, remember that device-owner enrollment modes do not report certificates at all, so console silence there is a known blind spot rather than a failure.
End-to-end test
Prove the full lifecycle on one pilot device before scaling: confirm the certificate on the device and in the console as above, then remove that device from the SCEP profile’s assignment group, and only then revoke its certificate from the issuing CA’s certificate list. The order is the lesson: revoking while the assignment stands simply issues a replacement at next check-in. Confirm the certificate shows revoked in the console and, if you want the complete proof, fetch the CRL from the distribution point URL you recorded in Step 3 and confirm the serial number appears in it. Then re-add the device to the group and watch a fresh certificate issue. You have now exercised issuance, revocation, the re-issuance trap, and recovery, which is every behavior the lifecycle article warned you about, performed deliberately on hardware you control. The certificate is on the device and provably manageable; the final build sheet makes the network believe it.
Intune Deployment Guide · Phase 12: The Intune Suite
‹ Previous: [12.3.4] Migrating Off NDES: What Retires and What Pretends To
Next: [12.3.6] Build Sheet: Certificate-Based Wi-Fi End to End ›
