Microsoft Cloud PKI provides cloud-managed certificate authorities and a SCEP service integrated with Intune. It can remove NDES infrastructure for supported Intune certificate use cases, but it is not automatically a full replacement for an enterprise PKI that issues server, network, code-signing or non-Intune certificates.
Choose the deployment model
| Model | Design | Use when |
|---|---|---|
| Cloud root and issuing CA | Root and issuing authorities are created and managed in Cloud PKI | You want a cloud-native hierarchy dedicated to Intune-managed endpoints |
| Bring your own CA | A Cloud PKI issuing CA is anchored to an existing private CA | You need the issuing hierarchy to chain to established enterprise trust |
For a regulated organisation, the decision should include key ownership, cryptographic standards, certificate policy, audit, revocation, offline-root requirements, RADIUS compatibility and disaster recovery.
Design before creating a CA
- Define certificate use cases: Wi-Fi, VPN, S/MIME, application or certificate-based authentication.
- Choose user versus device certificates.
- Define subject and SAN values expected by relying systems such as Cisco ISE or NPS.
- Set certificate validity, renewal threshold and revocation process.
- Confirm root and issuing certificate trust distribution.
- Document coexistence with AD CS, NDES and existing SCEP profiles.
- Assign Cloud PKI permissions through a custom Intune role and PIM where appropriate.
Create the CA hierarchy
- Go to Tenant administration > Cloud PKI and select Create.
- Create the root CA or start the BYOCA process according to the approved design.
- Create an issuing CA. Certificate issuance to Intune devices requires an issuing CA.
- Record the CA common name, validity, algorithm, key size and published URLs in the design record.
- Export the public CA certificates needed for trust distribution and relying-party configuration.
- For BYOCA, protect the CSR signing workflow and verify the returned certificate chain before activation.
Create trust and SCEP profiles
Deploy the trusted root certificate profile before the SCEP profile. Then create a SCEP certificate profile for the supported platform and use case. Align subject and SAN values with the relying service rather than choosing a convenient default.
Example validation commands on Windows
certutil -store -user My
certutil -store My
certutil -verify -urlfetch exported-device-certificate.cerValidate network authentication end to end
For 802.1X, validate more than certificate issuance. Confirm the certificate chain is trusted by RADIUS, the expected identity is extracted from the subject or SAN, the certificate-authentication profile matches, revocation endpoints are reachable and the authorisation rule can resolve the device or user.
Plan renewal and CA lifecycle
Cloud PKI supports staged CA renewal. Begin planning at the CA half-life, validate the staged CA through its temporary SCEP URI, and activate only after trust and relying-party tests succeed. Record who owns leaf-certificate revocation, CA pause, renewal and emergency response.
Define rollback
- Keep the previous certificate profile and authentication policy available during transition.
- Retain existing trust until all dependent devices and services are confirmed.
- Do not delete a CA while active leaf certificates are still in use.
- Have a device recovery path for expired or invalid certificates.
- Monitor issuance, renewal and revocation before expanding assignment.
Microsoft references
- Microsoft Cloud PKI overview
- Cloud PKI fundamentals
- Cloud PKI deployment models
- Configure root and issuing CA
- Bring your own CA
- Renew a certificate authority
- Certificates for authentication in Intune
Review note: Microsoft cloud licensing, rollout dates and portal labels can change. Validate your tenant, Message Centre notices and current documentation before production implementation.