Conditional Access blocks approved phones because device record is stale

Issue Summary

This article covers a Mobile Device Management issue within Mobile Devices where Conditional Access blocks approved phones because device record is stale. Use the path below to confirm scope, isolate whether the break is device-side, carrier/network-side, identity-related, or MDM-driven, and move from basic user checks into deeper administrative remediation.

Symptoms and Scope

• The reported problem matches the article title: Conditional Access blocks approved phones because device record is stale.
• At least one affected device, user, OS version, and network context can be compared with a known-good example.
• The current failure can be tied to a recent iOS/Android update, app change, enrollment action, policy assignment, certificate change, or carrier/network condition.

Tier I: Basic Checks

1. Confirm the scope: single device, single user, device model family, carrier path, Wi-Fi path, or broader tenant-wide/mobile-fleet impact.
2. Capture exact errors, screenshots, iOS or Android version, app version, and the last known working state before changing settings.
3. Test the simplest path first: alternate network, device restart, app relaunch, fresh sign-in, and comparison against a known-good mobile device.
4. Check whether the issue started after an OS update, policy push, app update, SIM/eSIM change, password reset, or certificate rotation.

Tier II: Admin Investigation

1. Review MDM compliance state, configuration profiles, app protection policies, conditional access results, certificate health, and account sign-in logs tied to Mobile Device Management.
2. Compare the failing device against a healthy device with the same app, platform version, and policy target so you isolate what is actually different.
3. Apply the least disruptive administrative fix first, such as re-pushing a profile, refreshing enrollment, excluding one test device, or correcting a narrow policy conflict.
4. Document whether the root cause was app configuration, identity, compliance, network path, notification permissions, certificate trust, or mobile OS behavior.

Tier III: Advanced Remediation

1. Move to advanced remediation only after lower-tier checks are documented and reversible.
2. If management or identity is involved, validate the full chain across MDM, app protection, conditional access, push notification service, certificates, and downstream SaaS dependencies.
3. Re-enroll, rebuild app containers, rotate certificates, reset network settings, or wipe/re-provision only when the evidence points there and business impact justifies it.
4. Validate the final state from the device user experience and the admin console so the fix is real, durable, and not just temporarily masked.

Escalation Guidance

• Escalate when the issue affects multiple users, breaks executive/line-of-business mobile access, or points to platform/vendor defects that cannot be corrected with safe local changes.
• Include screenshots, device model, OS version, app version, carrier/Wi-Fi context, enrollment state, timestamps, and the Tier I / II / III work already completed.
• State clearly whether the blocker is network, carrier, MDM, conditional access, certificate trust, push notification delivery, application behavior, or a likely vendor bug.

Prevention and Documentation

• Document the root cause, stable fix, and any device or policy exception added so future support stays consistent and narrow in scope.
• Update enrollment runbooks, mobile standards, app deployment notes, or compliance baselines if the failure followed a repeatable pattern.
• Where possible, stage OS updates, validate policy changes on pilot devices, and monitor certificate or push-service dependencies before broad rollout.