Compliance Drift After a Root CA Renewal in Workspace ONE UEM
Workspace ONE UEM manages 3,800 Windows 10 and 11 endpoints. A device compliance policy requires BitLocker, a minimum OS build, and a valid 802.1X client certificate issued by internal Microsoft PKI through SCEP with 12-month validity. Conditional access blocks corporate email when a device is non-compliant. After the root CA was renewed with an overlapping validity window, 240 devices began showing Compliance Unknown for 8 to 14 hours before returning to compliant. Thirty-five devices remained non-compliant for over 48 hours and lost email. Separately, 60 devices in a lab OU have never received the new root CA profile. Those devices are co-managed with Configuration Manager, and the lab OU has an enrollment restriction that disables user enrollment. No changes were made to compliance policies or assignment groups. The service desk reports that affected users are spread across three regions.
1. Explain why 240 devices oscillate between Compliance Unknown and compliant, while 35 remain non-compliant for days. What would you check first?
Read the worked answer
Oscillation. Compliance is evaluated at check-in and when a relevant profile or policy state changes, not continuously. The root CA renewal forced the certificate profile to re-evaluate on every device. Devices that had not yet checked in, or whose certificate profile was still installing, reported stale or incomplete data to the compliance engine. The engine then reported Compliance Unknown rather than Non-compliant because it could not evaluate the certificate condition. Conditional access uses the last known compliance state, so email was blocked during that window. The 8-to-14-hour spread matches normal check-in jitter across three regions, not a policy defect.
Stuck devices. The 35 devices for 48 hours or more are a different failure. Check, in order: last check-in time, profile installation status, SCEP/NDES logs, certificate template permissions, and whether the device has the new root in its trusted store. Common causes are a failed SCEP challenge, a pending reboot required to finish profile installation, an expired MDM push certificate, or a device that has not contacted the service since the change. Do not start by editing the compliance policy; that would mask the data problem.
First checks. Pull the device list with last check-in, compliance reason, and profile status. Compare a stuck device with a recovered device in the same region. If the stuck device shows a failed certificate profile, the problem is SCEP or trust, not compliance evaluation.
2. Why have the 60 lab OU devices never received the new root CA profile, and how would you confirm the cause without changing assignments?
Read the worked answer
Several independent mechanisms can produce this symptom, so confirm rather than assume:
- Assignment scope: the root CA profile may be assigned to a smart group whose criteria exclude the lab OU, or the lab devices may sit in an organization group where profile inheritance is disabled. Expand the smart group preview and check the device list membership.
- Co-management workload: these devices are co-managed with Configuration Manager. If the workload for device configuration or compliance is set to ConfigMgr, UEM may not deliver the profile even though the assignment looks correct. Check the co-management slider and the device's management authority.
- Enrollment type: the lab OU blocks user enrollment. If the profile is assigned to a user group rather than a device group, device-enrolled lab machines will never receive it. Check whether the profile targets users, devices, or both.
- Profile prerequisites: the root CA profile may depend on a prerequisite profile or on a device that has not checked in. Check installation status, not just assignment.
Confirm by comparing the smart group preview with the actual device list, then checking one lab device's profile status and co-management settings. Only after the cause is identified should you change assignment scope or the co-management workload; changing both at once would make the result impossible to attribute.
3. Prioritize the remediation and describe the controls you would add to prevent the same outage at the next certificate renewal.
Read the worked answer
Remediation order. First restore service to the 35 blocked users: repair SCEP enrollment or push the root CA to the trusted store, confirm the certificate is valid, then force a compliance check. Second, handle the 240 oscillating devices by verifying that their certificates renewed and their new root is trusted; avoid broad policy changes until the data settles. Third, fix the lab OU after identifying whether the cause is assignment scope, co-management workload, or enrollment type. Communicate a single status message to the service desk so they stop issuing local workarounds.
Prevention controls.
- Add a 24-to-48-hour compliance grace period for certificate renewal so a transient unknown state does not trigger email block.
- Renew the root CA and issuing CA with enough overlap that the new root is distributed at least one full check-in cycle before the old one expires.
- Pilot certificate changes on a ring of 50 to 100 devices across all regions before broad rollout.
- Monitor certificate expiry, SCEP failure rate, and compliance-unknown counts as leading indicators, not just final compliance percentage.
- Document the dependency between conditional access, compliance evaluation, and PKI so a PKI change is reviewed as an identity and access change, not a routine certificate task.