Microsoft Cloud PKI

👋 Introduction

Public Key Infrastructure (PKI) is a framework that uses digital certificates to authenticate identities and secure communications between devices and services. PKI can be used for protecting access for example to VPN, Wi-Fi, email, web access or devices, but a traditional PKI can be complex and resource-intensive, often requiringing a whole on-premise environment.

Microsoft Cloud PKI, part of the Intune Suite, delivers a fully cloud-based solution that automates certificate issuance, renewal, and revocation. By eliminating the need for on-premises infrastructure, Cloud PKI simplifies certificate lifecycle management across all supported platforms, making it easier for organizations to secure their environments at scale. This article provides an overview of Microsoft Cloud PKI, its core functionality, and its architecture.

Cloud PKI Features

Feature	Overview
Multiple CAs per tenant	Create a two-tier PKI hierarchy (root and issuing CA) fully in the cloud.
Bring Your Own CA (BYOCA)	Chain an Intune Issuing CA to your existing private CA (Microsoft or non-Microsoft), supporting external multi-tier hierarchies.
Signing & encryption algorithms	Supports RSA (2048, 3072, 4096-bit keys).
Hash algorithms	Supports SHA-256, SHA-384, SHA-512.
HSM-backed keys	CAs use Azure Managed HSM for key protection (no Azure subscription needed with Intune Suite/Cloud PKI license).
Certificate registration authority	Built-in SCEP registration authority for each Cloud PKI Issuing CA.
CRL distribution	Intune hosts CRL endpoints - CRLs valid for 7 days, refreshed every 3.5 days, updated on revocation.
AIA endpoints	Intune hosts AIA endpoints for parent certificate retrieval.
End-entity certificate issuance	Issues SCEP (PKCS#7) certificates to Intune-enrolled devices.
Certificate lifecycle management	Issue, renew, and revoke certificates.
Reporting dashboard	Monitor certificate status and revoke certificates in the Intune admin center (updated daily).
Auditing	Track admin actions (create, revoke, search) in Intune.
RBAC permissions	Custom roles for Cloud PKI management (read, create, revoke, disable/enable CAs).
Scope tags	Assign, edit, or remove scope tags for CAs.

WARNING

Be aware the trial CAs use software-based RSA keys and you can not change that even after purchasing a license. You need to create a new CA after that.

✅ Prerequisites

• Supported platforms: Android, iOS/iPadOS, macOS, Windows (devices must be Intune-enrolled and support SCEP certificate profiles)
• Licensing: Microsoft Intune Suite license or Microsoft Cloud PKI standalone Intune add-on license
• Permissions: Assigned Intune role permissions
  • Read certificate authorities (CAs)
  • Create root or issuing CAs
  • Revoke issued leaf certificates (requires read CA permission)

INFO

For more information about configuring custom roles and scope tags in Intune, refer to Role-based access control with Microsoft Intune.

🌊 Architecture & Flow

Microsoft Cloud PKI issues certificates using SCEP with it's cloud-based CA and registration authority.

INFO

The certificate registration authority consists of B2 and B3 in the architecture.

Preperations in Intune (B1, B2 & B3):

• Create Cloud PKI root and issuing CAs.
• Assign trusted certificate profiles for both CAs.
• Assign platform-specific SCEP certificate profiles.

Arcitecture flow:

A1. Device checks in and receives certificate/SCEP profiles.
A2. Device generates a private key and CSR, sends to SCEP service.
A3. SCEP service validates the request.
A4. Registration authority requests issuing CA to sign the CSR.
A5. Device receives the signed certificate.

NOTE

The SCEP challenge is encrypted and signed by Intune to ensure secure certificate requests.

📃 Certificate fundamentals

Certification authority types

A certification authority (CA) performs the following tasks:

• Verifies the identity of a certificate requestor
• Issues certificates to requestors
• Manages certificate revocation

Microsoft Cloud PKI supports these types of certificate authorities:

• Root CA
• Issuing CA

Root certification authority

A root certification authority (CA) sits at the very top of your PKI setup, think of it as the main source of trust for everything below it. Its certificate is self-signed, meaning it basically vouches for itself (the issuer and subject are the same). You trust a root CA by adding its certificate to your trusted root store. From there, the root CA can hand out certificates to other CAs or even directly to users, devices, or services, signing each one with its private key to prove they're legit.

IMPORTANT

Microsoft Cloud PKI issues certificates exclusively to devices that are enrolled through mobile device management (MDM).

Issuing certification authority

NOTE

The terms intermediate, issuing, and subordinate all refer to the same CA role. Microsoft Cloud PKI uses "issuing CA" for this type.

An issuing CA is a subordinate certification authority that operates below a root CA in the hierarchy. It can:

• Issue certificates to other subordinate CAs within the hierarchy.
• Issue end-entity (leaf) certificates to servers, services, clients, or devices.

Issuing CAs can be positioned at any tier in the CA hierarchy except the root level.

---

Chaining

Chaining determines the optimal trust path for verifying a certificate. Each OS or service uses a certificate chain engine to compute and validate this path.

The chain building process involves:

• Certificate discovery: The process of finding and retrieving the issuing CA certificate for a leaf certificate, ensuring the chain leads up to a trusted root CA.
• Certificate validation: Building possible chains and checking each certificate for validity (name, time, signature, revocation, and other constraints).
• Selecting the best chain: Returning the highest quality trust path.

When verifying a certificate, the chain engine searches the certificate store for intermediate and root candidates. Multiple intermediates may be needed to complete the chain. The engine matches certificates using the subject key identifier (SKI) and authority key identifier (AKI), repeating the process until it finds a self-signed root certificate.

Chain validation process

NOTE

Certificate chain validation methods differ by OS. This section covers Windows 10/11.

Windows validates certificate chains using three methods:

• Exact match: Uses issuer’s subject, serial number, and KeyID from the AKI extension.
• Key match: Uses only the KeyID from AKI to find a parent with a matching SKI.
• Name match: If AKI is missing, matches the issuer’s subject name to the parent’s subject.

If SKI and AKI are missing, Windows uses name matching and if duplicates exist, selects the newest certificate. If the parent certificate isn't found locally, Windows tries to retrieve it using URLs from the authority information access field.

Each certificate in the chain is checked for formatting, validity, revocation and that the chain ends in a trusted root.
The chain is valid only if all checks pass.

Name matching chain validation example:

Chain of trust

For certificate-based authentication to work, both your devices and services (like Wi-Fi, VPN, or web apps) need to trust the full CA chain. Just make sure the root CA certificate is installed everywhere. If a device is missing the issuing CA cert, it can usually grab it automatically using the AIA (Authority Information Access) info in the certificate.

Certificate-based authentication

The certificate-based authentication process and handshake work as follows:

1. Your device starts talking to the service it wants to connect to.
2. The service replies that it wants to establish a secure connection using TLS/SSL and the SSL handshake begins.
3. The service asks your device to show a client authentication certificate.
4. Your device hands over its certificate so it can prove who it is.

🧑‍🔧 Configurating Cloud PKI

Microsoft Cloud PKI supports two deployment options:

• Cloud root CA: Set up a private, cloud-based two-tier PKI in your Intune tenant, with a root CA and one or more issuing CAs that deliver certificates to managed devices via SCEP. All CAs remain tenant-private.

• Bring your own CA (BYOCA): Use your existing private CA (e.g., ADCS) as the trust anchor by creating a cloud-based issuing CA in Intune. Intune sends a CSR (Certificate Signing Request) for your private CA to sign, establishing the trust chain.

Microsoft Cloud PKI objects are created and managed in the Microsoft Intune admin center. From there, you can:

• Set up and manage Cloud PKI
• Create and assign certificate profiles to devices
• Monitor issued certificates

Trust Anchor Location and Chain of Trust

In order to use certificate-based authentication, you must first decide where to store the trust anchor (usually the root CA). This anchor enables devices and services to verify certificates. Ensure that all systems have the complete certificate chain, from the root to the issuing CA. If an intermediate certificate is missing, it can often be retrieved automatically via the AIA link in the certificate.

---

Configure Cloud CA

1. Sign in to the Microsoft Intune admin center and navigate to Tenant administration → Cloud PKI and select Create.

2. On the first page provide a Name and a Description.
3. On the Configuration settings page you configure the CA settings.

CA type: Root CA	CA type: Issuing CA
Validity period: 5, 10, 15, 20 or 25 years	Root CA source: Intune or BYOCA Validity period: 2, 4, 6, 8 or 10 years (The validity must not exceed the root CA's)
Extended Key Usages purposes: Sever auth Client auth Code signing Email protection IPSEC end system IPSEC tunnel IPSEC user Time stamping OCSP signing Smartcard logon MAC adress Custom Type Name Object Identifier	Extended Key Usages purposes: Select the intended purpose of the CA from those selected in the Root CA settings.
Subject attributes: Common name (CN) Optional: Organization (O) Country (C) (must be a two-character code) State/province (ST) Locality (L)	Subject attributes: Common name (CN) Optional: Organization (O) Country (C) (must be a two-character code) State/province (ST) Locality (L)
Encryption, select the key size and algorithm: RSA-2048 and SHA-256 RSA-3072 and SHA-384 RSA-4096 and SHA-512	The Encryption is set by the root CA.

INFO

You can use custom validity periods with the Microsoft Graph API.

4. Select Next and on the next to pages you can add Scope tags and create the CA.

WARNING

Setting cannot be changed after creation.

Configure Bring your own Root CA (BYOCA)

1. Use the issuing CA’s subject attributes to make a CSR (certificate signing request).
2. After the CA is created you can Download the CSR in the CA's properties to obtain the certificate signing request file in .req format.
3. Next you need to sign this request with your privat root CA and upload the signed certificate to the Cloud PKI again.

You can learn more about using your own root CA here.

---

Create Certificate Profiles

Microsoft Cloud PKI includes a built-in SCEP service that handles certificate requests for devices automatically.

To start issuing certificates, you’ll need to create trusted cert profiles for both your root and issuing CAs. These profiles build trust with the Cloud PKI registration authority that uses SCEP. Then you need for every platform (Windows, Android, iOS/iPadOS, macOS) that’ll get SCEP certs a separate profiles.

 

Create a trusted Certificate Profile for the root and issuing CA

First you need to download the public keys from your Cloud PKI.

1. Open the Microsoft Intune admin center and navigate to Tenant administration → Cloud PKI.

2. Now select your root CA and issuing CA's and download the certificates.

NOTE

Here you can also find the following information:

• Certificate Revocation List (CRL) distribution point URI
• Authority Information Access (AIA) URI
• SCEP URI (for issuing CAs)

Clients must have network access to these endpoints.

Now we need to install the downloaded root and issuing CA certificates on the clients.

1. Open the Microsoft Intune admin center and navigate to Devices → Configuration.
2. Next you need to click Create and select New Policy.
3. After that you choose your Platform and select Profile type: Templates

4. Here we choose Trusted certificate and click Create.
5. In the next screen you can set the Name and Description.
6. After that you upload first the root certificate and in a second trusted certificate profile the issuing certificate.
7. You need to select the appropriate Destination store for the certificate.

8. Next choose an assignment, applicability rules and create the profiles.

Create SCEP certificate profile

Just like you set up trusted cert profiles, you’ll need to create a SCEP cert profile for each OS you want to support. This lets devices grab client auth certificates from the issuing CA, which they’ll use for things like connecting to Wi-Fi or VPN.

NOTE

SCEP certificates for Intune-managed devices can only be issued by Cloud PKI issuing CAs, including BYOCA.

First you need to copy the SCEP URI from your Cloud PKI.

1. Open the Microsoft Intune admin center and navigate to Tenant administration → Cloud PKI.
2. Now select your issuing CA and copy the SCEP URI in the Properties.

Next you create the SCEP certificate Profile.

1. Open the Microsoft Intune admin center and navigate to Devices → Configuration.
2. Next you need to click Create and select New Policy.
3. After that you choose your Platform and select Profile type: Templates

4. Here we choose SCEP certificate and click Create.
5. In the next screen you can set the Name and Description.
6. Now under Configuration settings you can paste the copied SCEP URI into the SCEP Server URLs field. Keep the {{CloudPKIFQDN}} placeholder as is, Intune will fill in the right FQDN when it sends the profile to devices. It’ll be something under *.manage.microsoft.com. You can find more infos about Network Endpoints for Microsoft Intune here.
7. After that you can configure the remaining settings:
   • Certificate type: User or Device
   • Subject name format: Ensure all variables used are present on the user or device object in Microsoft Entra ID.
   • Certificate validity period: The amount of time remaining before the certificate expires in days, month or years.
   • Key storage provider (KSP): Select where you want to store the certificate key (TPM KSP, Windows Hello for Business or Software KSP).
   • Key usage: Specify the cryptographic action that is required to exchange the certificate's public key (Digital Signature, Key encipherment).
   • Key size (bits): Select the key length (1024, 2048 or 4096).
   • Hash algorithm: Use a hash algorithm type with the certificate (SHA-1 or SHA-2).
   • Root Certificate: Select the root CA that this chain of trust should use.
   • Extended key usage: Select the EKU you specified in the issuing certificate. If you choose an EKU that isn't on the issuing CA, the SCEP profile will fail and no certificate will be issued.
   • Renewal threshold: The device can ask for a renewal as soon as this percentage of the time is left.

4. Lastly you assign the profile to your targets and then Create it.

🔍 Monitoring

View issued certificates

To view issued certificates, go to Devices → Monitor, and then select Certificates.

Monitor Cloud PKI issuing CA

Monitor certificate deployments from issuing CA's to your Intune devices. When opening the CA you find a dashboard displaying the following:

• Active certificates
• Expired certificates
• Revoked certificates
• Total issued certificates

Select View all certificates to see all issued certificates. The Reports are normally updated in 24 hours.

You can also manually revoke an issued leaf certificate from this dashboard.

1. Select View all certificates.
2. Choose the certificate and click Revoke.

WARNING

If you manually revoke a certificate and the device is still assigned, it will grab a new one the next time it checks in.

View SCEP certificate profile report

Go to Devices → Configuration and select the SCEP profile, and then select Certificates.

Audit logs

In the admin center, go to Tenant Administration → Audit Logs.

You can current list of the available logs here.

View Certificates on the Client

Open the local certificate store (certmgr.msc) on your device and navigate to Trusted Root Certificate Authorities → Certificates to view the installed Root Certificates.

Open the local certificate store (certmgr.msc) on your device and navigate to Intermediate Certificate Authorities → Certificates to view the installed Intermediate Certificates.

💡 Conclusion

In short, Intune Cloud PKI makes it a lot easier to manage certificates without the hassle of on-prem infrastructure. It’s a modern, cloud-based solution that integrates seamlessly with Intune, helping you securely authenticate devices and users while keeping things scalable and simple. Whether you're rolling out certificates for Wi-Fi, VPN or app access, Cloud PKI takes care of the heavy lifting, so you can focus more on managing endpoints and less on managing cert servers.

So in my opinion, if you use certificates and have your devices intune managed, Cloud PKI is the killer feature of the Intune Suite. It replaces so much manual work and local infrastructure, that it is well worth the price in my opinion.

You can find kown issues and limitations here.