Intune does not fail loudly. It fails as a certificate that lapsed, a connector that stopped syncing, a baseline three versions behind, a break-glass account nobody has tested since it was created. None of these announce themselves, which is why a managed estate needs a standing review on the calendar rather than a response to the next outage. This is the quarterly checklist I run, organized so the highest-consequence items come first, because a lapse there stops enrollment or management outright. It is the operational discipline underneath [10.2] Scaling Without Losing Your Mind.
The expirations that stop everything
This is the domain where a missed date is an outage, so it goes first and it gets verified every quarter even though most of these renew on their own annual schedule. The failure mode is always the same: silent until the day it breaks a whole platform’s worth of devices.
| Item | Lifetime | What a lapse breaks |
|---|---|---|
| Apple MDM push certificate | 365 days, annual. Renew with the same Apple ID that created it. | All iOS, iPadOS, and macOS check-in and management stops. Renewing under a different Apple ID replaces it and breaks every existing Apple enrollment. |
| Apple ADE (enrollment) token | 365 days, annual. | New and wiped corporate Apple devices can no longer enroll through Automated Device Enrollment. |
| Apple VPP / Apps and Books token | 365 days, annual. Also goes invalid on Managed Apple ID changes. | Assignment and updating of volume-purchased apps stops. |
| Managed Google Play connection | No expiry. This is an ownership check, not a renewal. | Confirm it is bound to a Microsoft Entra account with a live mailbox, not a personal Gmail. Losing the account disconnects all Android Enterprise management. |
| Microsoft Cloud PKI CA lifecycles | Root 5 to 25 years, issuing 2 to 10 years. Renewal-eligible at 50 percent of life; portal banners escalate at 50 percent, six months, 90 days, 30 days, and expiry. | An expired issuing CA stops certificate issuance for Wi-Fi, VPN, and 802.1x. Renew on the six-month banner, not the 30-day one. |
| Certificate Connector for Intune | Each version is supported six months from release and may keep working up to roughly 18 months. | An unsupported or offline connector silently stops issuing and renewing certificates. Confirm it shows active and is on a current version. |
If you build only one alert in the whole tenant, build it here, because the native status page turns amber just seven days before an Apple certificate expires. The Cloud PKI lifecycle in particular rewards planning ahead; the design is in [12.3] Microsoft Cloud PKI.
Posture and hygiene
With the expirations covered, the quarterly work is mostly reconciliation: making the estate’s actual state match its intended one. Compliance is the headline, but read it for trend and for the buckets that hide problems. A persistent error state, which can legitimately take up to seven days to resolve during evaluation, is worth investigating past that window, and the devices reporting no compliance policy at all are usually the real find. Confirm the tenant is still set to mark a device with no policy as noncompliant, because that default is what makes the gap visible in the first place.
Then hunt conflicts and clutter. Configuration conflicts happen when two profiles set the same value differently, and the device resolves them by applying neither, so a conflict is a setting you think is enforced and is not. Stale and duplicate policies, profiles assigned to empty groups, overlapping definitions of the same control across a baseline and a settings-catalog profile, are the root cause of most of those conflicts, and consolidating them is the single highest-leverage cleanup you can do. Device hygiene closes it out: confirm device cleanup rules exist with a sane inactivity threshold, which can run from a minimum of 30 days to a maximum of 270, remembering that when rules overlap the one with fewer days wins and that cleanup only removes the Intune record rather than wiping the device. Reconcile that against Entra’s own stale-device cleanup so a machine is not counted active in one directory and dead in the other.
Baselines, updates, and drift
Security baselines drift by design, because when Microsoft ships a new version the older one becomes read-only, so part of the review is confirming you are on a current version and planning the in-place update, watching for the baseline-versus-profile conflicts that appear when the same setting is set in two places. Where you run a community or third-party baseline, the drift check is against your own documented reference rather than a Microsoft version tag. On the update side, the one report that earns its place is the Autopatch management status view, and the bucket that matters is the one labeled other: those are the Windows devices covered by no update policy at all, quietly falling behind. The strategy behind that is in [5.5] Updates: Autopatch as Default. This is also where you keep the estate’s deprecation awareness current: WSUS was deprecated in September 2024, still operational but frozen, and anything still leaning on it needs a documented exit rather than a surprise.
Identity, access, and governance
The access plane is reviewed on the same cadence because it drifts as quietly as everything else. Walk the Conditional Access policies for scope and exclusions, and use report-only and the insights workbook to see impact before you touch anything, the same discipline as [CA 2.1] Testing Conditional Access. The item people skip and regret is the break-glass accounts: you should have at least two cloud-only emergency accounts, excluded from the policies that could lock them out, on phishing-resistant credentials, and Microsoft’s own guidance is to test them at least every 90 days. Run the PIM access reviews so privileged roles are eligible rather than standing, check that your Intune scope tags and custom roles still match the delegation you intended, and confirm Multi-Admin Approval still covers the sensitive resource types, with the standing caution that a role-scoped approval policy can deadlock RBAC if you enable it before everything else is in place.
Apps, licensing, and what changed
The lighter domains still belong on the list. Review app install failures by app and by ring for the persistent ones, confirm Enterprise App Management catalog apps are tracking current versions where you rely on their auto-update, and reconcile license utilization so you are paying for seats that are used and only enabling add-on features where they are licensed. Finally, budget time to read what Microsoft changed: the Message Center and the what-is-new and deprecation notices carry act-by dates, and the quarterly review is where you translate those into work before they translate themselves into an incident. Change management for the actions that come out of all this is [10.5] Change Management.
The checklist
- Expirations: Apple push certificate, ADE token, VPP token, Cloud PKI CA lifecycles and the leaf-certificate expired count that nothing alerts on ([12.3.2]), certificate connector version and health, NDES/SCEP service certs. Managed Google Play ownership.
- Compliance: pass and fail trend, persistent error states past seven days, devices with no assigned policy, the no-policy-equals-noncompliant tenant setting.
- Configuration: conflicts, assignment errors, stale and duplicate policies, overlapping definitions of the same setting.
- Baselines and updates: baseline version drift and read-only migrations, the Autopatch other bucket, feature-update readiness, any remaining WSUS dependency.
- Device hygiene: cleanup rules and thresholds, inactive and duplicate records, retire and wipe follow-through, enrollment and Autopilot error trends.
- Identity and access: Conditional Access review, break-glass validation every 90 days, PIM access reviews, RBAC and scope-tag drift, Multi-Admin Approval coverage.
- Apps and licensing: install-failure trends, Enterprise App Management catalog currency, license utilization.
- Change awareness: Message Center, what-is-new, and deprecation notices translated into dated actions.
Run this every quarter and Intune stays boring, which is the entire goal. The status surfaces that this review reconciles by hand, and the alarms worth building so you are not relying on the review to catch a lapse, are in [10.1.1] Setting Up Monitoring.
Intune Deployment Guide · Phase 10: Day-Two Operations
‹ Previous: [10.2] Scaling Without Losing Your Mind
Next: [10.3] Where to Go Next ›
