Cloud PKI automates the certificate lifecycle most organizations used to neglect, and it does that job well. But the edges of the automation, the renewal window that closes for good, the leaver whose certificate outlives their account, the devices the console cannot see, are exactly where your certificate incidents will come from, and some of those edges are documented more quietly than they behave.
With the hierarchy designed, the work shifts from architecture to machinery: how certificates actually reach devices, renew, and die. This is the article where I am going to be careful about a distinction that matters more here than anywhere else in this family. Some of what follows is documented behavior I can point at. Some is behavior practitioners have observed that the documentation does not cover, or covers differently. I will tell you which is which, because designing around a documented guarantee and designing around an observed tendency are different disciplines, and certificate infrastructure punishes people who confuse them.
The delivery machinery
Delivery is a trio of profiles per platform, and the trio has internal wiring. A trusted certificate profile carries the root, a second one carries the issuing CA, and the SCEP profile requests the actual certificate from the issuing CA’s enrollment endpoint. The SCEP profile explicitly references the trusted profile that holds the root its issuing CA chains to, and that reference is load bearing: point it at the wrong trusted profile and enrollment fails in ways that look like anything but a wrong dropdown selection. The same goes for assignment. These profiles depend on each other at deployment time, so they belong on the same groups, deliberately, as a set. Splitting them across assignments that almost overlap is one of the classic ways this feature fails quietly.
Two constraints from the hierarchy article follow the profiles around. The usages and key sizes a SCEP profile requests must fit inside what the issuing CA was created with; ask for an EKU the CA does not carry and the profile errors and no certificate is issued. And the subject you build must be constructible: every variable you reference has to exist on the target user or device object in Entra. A profile that stamps the email address into the subject will simply not issue for the one service account that has no email address, and the failure surfaces as an error row in the profile report, not as an alert anyone reads. The on-premises variables, the SAM account name and the distinguished name, exist only for objects synced from Active Directory, which is the first hint of a theme this article returns to.
Issuance, and the key that never leaves
The issuance flow itself is the part of the system I trust most, and it is worth one paragraph of appreciation. The device generates its key pair locally and the private key never leaves the hardware. What travels is a signing request plus an encrypted challenge, and a validation service in the cloud checks both against what the profile authorized before the issuing CA signs anything: that the request came from an enrolled, managed device, that the challenge is untampered, that the certificate being requested matches what the administrator actually configured. This is the registration authority role that NDES and the connector used to play, hosted and hardened by someone whose job it is. A new issuing CA can be handing out certificates within minutes of creation. The only operational caveat is visibility lag: the reporting surfaces trail reality by up to a day, so never treat the console as a live view of issuance.
The hybrid tax: strong mapping
If your certificates will ever be judged by Active Directory, by a domain controller during certificate sign-in, or by an NPS server during network authentication, there is a compliance item that is no longer optional. Since the enforcement changes that finished rolling out in 2025, certificates must carry a strong mapping to the AD object they authenticate as, and the mechanism Intune provides is embedding the on-premises security identifier into the certificate’s subject alternative name. The variable exists for exactly this, it rides in the URI attribute, and for device certificates it works only for hybrid-joined devices whose objects are synced. There is no grace mode left; a certificate without the SID fails authentication against a patched domain controller even though Cloud PKI issued it flawlessly. And notice what that implies for the object that has no on-premises SID at all: a cloud-only user or an Entra-joined-only device has nothing to embed and nothing to map to. That dead end is not a configuration problem, it is a topology fact, and it is the reason the next article in this family exists.
Renewal, and the window that closes
Renewal is automatic and threshold driven: you set a percentage of remaining lifetime, and once a certificate crosses into that window the device requests a replacement at check-in, receiving a new certificate with a new key pair. Retries continue until renewal succeeds. So far, so self-operating. The edge is what happens when the window closes. For Apple platforms the documentation is admirably blunt: renewal can only happen inside the threshold window, the device has to be unlocked while it syncs, and if the certificate expires without renewing, it stays expired. Intune stops trying, offers no way to redeploy an expired certificate, and the remediation is to exclude the device from the profile and re-include it so a fresh certificate issues. That is a dead end with a manual escape hatch, on the platform where devices most often sleep in drawers.
For Windows and Android, Microsoft documents no equivalent behavior, and I want to be precise about what that means: it does not mean those platforms self-heal, it means nobody has written down what they do. The scoping of the warning to Apple platforms implies a difference without stating one. The defensible design response is to make the question irrelevant. Give certificates enough validity, and renewal windows enough width, that a device would have to be absent for months before the window could close on it, and fold long-absent devices into the device cleanup discipline you already run. A certificate lifecycle that depends on undocumented recovery behavior is a design error even when the recovery happens to work.
Revocation: what happens, and what does not
Revocation is where the documented story and the observed story diverge enough that I will lay them side by side. What Microsoft documents for Intune SCEP certificates generally is a tidy trigger list: certificates are revoked and removed when a device is wiped, retired, or unenrolled, when it leaves the assigned group, or when the profile is unassigned, and revoked when the profile is modified. What Microsoft documents for Cloud PKI specifically is manual revocation, a permission for it, and a revocation list that updates whenever a certificate is revoked. The Cloud PKI documentation set contains no trigger list of its own, and the generic list predates the service and never mentions it.
The field fills in the rest, and not reassuringly. Practitioners working with the service through late 2025 have reported that removing a device from a profile’s assignment removed the certificate from the device without revoking it, and that after a profile modification the superseded certificate remained listed as active in the console alongside its replacement. I have not put every trigger through a lab myself, so I hold those as observations rather than verdicts. But the design conclusion does not require a verdict: treat automatic revocation as a courtesy and manual revocation as the control. When a certificate must die, revoke it yourself and confirm it in the console. Two more documented behaviors sharpen that posture. Revoking a certificate while the SCEP assignment still stands just means the device requests a fresh one at next check-in, so revocation without de-assignment is a rotation, not a removal. And the identity-side triggers people assume exist do not: removing a user’s license, or deleting the user from the directory entirely, revokes nothing. The device keeps its certificate until expiry. For a leaver, the order of operations is retire or wipe the device first, then remove the account, exactly the inversion of how most offboarding runbooks are written.
Treat automatic revocation as a courtesy. Manual revocation is the control.
One platform hole deserves its own sentence. For Android devices enrolled through the device owner paths, fully managed, dedicated, and the corporate work profile variant, certificate reporting is not available and Intune cannot revoke their SCEP certificates at all; the fallback is revoking manually against the CA itself. If your estate leans on those enrollment models, your certificate console is blind exactly where your kiosks and frontline devices live, and the CRL becomes your only lever.
Watching it run
The monitoring surface is honest but thin. Each issuing CA has a dashboard of active, expired, and revoked counts, refreshed daily, and a certificate list that currently displays only the first thousand entries, with the fuller inventory living in the tenant-wide certificates report under device monitoring. Read those numbers for what they are: a record of what was issued, not of what is deployed and working. A certificate revoked yesterday or superseded last month still appears in issuance history, and nothing in the product distinguishes a certificate that is securing a Wi-Fi session from one rotting in the store of a device that was reimaged. Most importantly, there is no expiry alerting for issued certificates anywhere in the service. The CA itself will warn you about its own expiration well in advance. For the fleet’s certificates, nobody will. Fold a certificate review into the quarterly health check cadence, watch the expired count for a number that should be near zero and is not, and treat its growth as the early signal of renewal windows quietly closing across your estate.
Alerting yourself, since the product will not
The missing leaf-certificate expiry alerting is the one monitoring gap worth closing with your own code, because a certificate that lapses on a laptop asleep in a drawer is invisible until the user comes back and cannot reach the network. Microsoft Graph exposes the issued certificates per certification authority, so a short query, run on whatever schedule your team actually reads alerts from, turns the silent expired count into a list of devices to get ahead of. This reports the active certificates whose validity ends inside a threshold window.
# Cloud PKI leaf certificates approaching expiry. Needs BOTH scopes below.
# Microsoft Graph beta surface as of July 2026; re-verify names if it returns nothing.
$days = 30
Connect-MgGraph -Scopes 'DeviceManagementCloudCA.Read.All','DeviceManagementConfiguration.Read.All'
$cutoff = (Get-Date).AddDays($days).ToUniversalTime()
$base = 'https://graph.microsoft.com/beta/deviceManagement/cloudCertificationAuthority'
foreach ($ca in (Invoke-MgGraphRequest -Method GET -Uri $base).value) {
$uri = "$base/$($ca.id)/getAllCloudCertificationAuthorityLeafCertificates"
$leaves = (Invoke-MgGraphRequest -Method POST -Uri $uri).value
$leaves |
Where-Object { $_.certificateStatus -eq 'active' -and
([datetimeoffset]$_.validityEndDateTime).UtcDateTime -le $cutoff } |
Select-Object @{n='CA';e={$ca.displayName}}, subjectName, deviceName,
userPrincipalName, serialNumber, validityEndDateTime
}Two things about that query are load bearing. It rides the Microsoft Graph beta surface, which is where the Cloud PKI certificate resources live and which can change without notice, so if it starts returning nothing, re-verify the endpoint and property names before blaming your tenant. And it needs two different permissions granted together, DeviceManagementCloudCA.Read.All to list the authorities and DeviceManagementConfiguration.Read.All to read their certificates, a split that produces a baffling empty result when only one is present. Run it app-only from Azure Automation or a scheduled task, pipe the output into mail, Teams, or a ticket, and you have the alerting the service itself does not provide.
That is the lifecycle: delivery that is precise about its wiring, issuance that is cryptographically sound, renewal that works until a window closes, revocation that is guaranteed only when you perform it, and monitoring that records the past rather than watching the present. None of it is disqualifying, and all of it is manageable once named. What remains is the question this whole capability ultimately serves: the certificate is on the device, and something on your network has to decide whether to believe it. That something is a RADIUS server, Microsoft does not sell one, and the next article is about what to do instead.
Intune Deployment Guide · Phase 12: The Intune Suite
‹ Previous: [12.3.1] Designing the Hierarchy: Cloud Root, BYOCA, and the Three-Slot Budget
Next: [12.3.3] The RADIUS Question: EAP-TLS in a Cloud-Native Estate ›
