Entra ID & Intune Device Compliance Architecture, Safeguards, and Diagnostics

Integrating Conditional Access with Intune compliance lets Entra ID verify both identity and endpoint posture before issuing tokens - MFA alone is not enough. This guide covers the decoupled architecture, lockout safeguards, Report-only rollout, token lifecycle limits, and diagnosing AADSTS53000.

1. Core Architecture and Signal Mechanics

Device compliance enforcement relies on three distinct, decoupled components:

1. Microsoft Intune (compliance evaluator) - deploys compliance profiles, collects posture reports, evaluates rules, and writes isCompliant = True/False to the Entra device object. Intune does not issue access tokens or process sign-in requests.
2. Microsoft Entra ID (identity store and policy engine) - stores deviceId records, hosts Conditional Access, and reads the directory isCompliant attribute during authentication and token renewal.
3. Endpoint token broker - on Windows, CloudAP and WAM manage the Primary Refresh Token (PRT). On iOS and Android, Microsoft Authenticator or Company Portal passes device identity context.

+-------------------+       1. State Report       +----------------------+
|  Managed Endpoint | --------------------------> |   Microsoft Intune   |
+-------------------+                             +----------------------+
          |                                                  |
          | 3. Token Request (PRT)                           | 2. Write isCompliant
          v                                                  v
+------------------------------------------------------------------------+
|                           Microsoft Entra ID                           |
|       [Reads isCompliant attribute -> Evaluates Conditional Access]    |
+------------------------------------------------------------------------+

Propagation latency and AADSTS53000

Evaluation relies on asynchronous directory writes. Propagation latency typically spans 5 to 30 minutes between remediating a non-compliant setting and Entra updating its record.

If a user fixes BitLocker, Defender signatures, or similar and signs in immediately, Entra may still read isCompliant = False and return AADSTS53000 (Device is not in required device state: compliant). A manual sync from Company Portal accelerates the client check-in cycle.

2. Baseline Compliance and Lockout Safeguards

Essential compliance categories:

• Device health: Secure Boot, BitLocker/FileVault, code integrity.
• System security: Firewall, Defender real-time protection, current antimalware signatures.
• OS posture: Supported build numbers and minimum platform requirements.

Critical tenant default

By default, Mark devices with no compliance policy assigned as is set to Compliant. Unmanaged or unassigned endpoints then pass compliance checks automatically.

1. Navigate to Devices → Compliance → Compliance policy settings.
2. Change the setting to Not compliant.
3. Confirm every active device group has an applicable policy before saving.

Fast-changing signals (AV and EDR)

Antivirus and EDR definitions update multiple times daily. Transient lag can flip a device non-compliant. With zero-day enforcement, users can be blocked mid-session.

• Set Mark device noncompliant to 1 to 3 days, not 0. The device enters InGracePeriod - Intune surfaces it to admins, but Conditional Access does not block access.
• Add Send email to end user on Day 0 or Day 1 with clear remediation steps before the grace window ends.

3. Conditional Access Report-Only Mode

Report-only evaluates sign-ins against policy conditions and writes the projected outcome to audit logs without blocking access or prompting users.

Sign-In Event ---> [ CA Policy Evaluation ] ---> Write Result to Audit Logs
                                           ---> Grant Access Unconditional

Why Report-only is non-negotiable

Turning compliance enforcement straight to On risks business disruption. Report-only surfaces:

1. Unenrolled / unmanaged endpoints that will fail once enforced.
2. Missing platform policies (for example macOS or iOS) that cause implicit failures.
3. Service and service-principal dependencies that lack device context.
4. Third-party and browser limits where device identity tokens are not passed.

Report-only configuration blueprint

1. Open the Microsoft Entra admin center (entra.microsoft.com).
2. Go to Protection → Conditional Access → Policies → New policy.
3. Users: include a pilot group or All users; exclude break-glass and designated service accounts.
4. Target resources: start with key workloads (Exchange Online, SharePoint Online) before All cloud apps.
5. Grant: Require device to be marked as compliant.
6. Enable policy: set the toggle to Report-only.

Reviewing evaluation results

After 7 to 14 days in Report-only:

1. Open Entra ID → Sign-in logs.
2. Select interactive or non-interactive user sign-ins.
3. Filter Conditional Access → Report-only.
4. Inspect outcomes:
   • Report-only Success - safe for enforcement.
   • Report-only Failure - investigate unenrolled devices or missing sync.
   • Report-only Not Applied - out of policy scope.
5. Switch the policy to On only after target cohorts show clean compliance signals.

4. Token Lifecycles, CAE, and Token Protection

Access token lifetimes

After a successful compliance check, access tokens remain valid for their full lifetime - typically 60 to 90 minutes. If the device falls out of compliance mid-session, existing tokens continue until expiry. Re-evaluation happens when the broker presents the PRT for a new access token; Conditional Access then sees isCompliant = False and returns AADSTS53000.

Continuous Access Evaluation (CAE)

CAE lets supported apps (Teams, Outlook, SharePoint, and others) extend token lifetimes up to about 28 hours while listening for real-time revocation events.

• Default CAE triggers: account disablement, password changes, explicit session revocation, and high-risk location changes.
• Compliance is not a default CAE trigger. Losing Intune compliance during a CAE session does not revoke access until the next token refresh or session check.
• Mitigation: use Conditional Access Sign-in frequency session controls to force periodic re-evaluation.

Token Protection

Conditional Access Token Protection cryptographically binds refresh tokens to the TPM of the compliant endpoint. Stolen tokens replayed from an unmanaged or non-compliant device fail the binding check - the compliance signal cannot be spoofed or reused off-device.

5. Diagnostic Workflow for AADSTS53000

                      [ User Encountering AADSTS53000 ]
                                      |
                                      v
                          Check Entra Sign-In Logs
                                      |
         +----------------------------+----------------------------+
         |                                                         |
         v                                                         v
[ Grant: Compliant Failed ]                               [ Other CA Failure ]
         |                                                         |
         v                                                         v
Check Entra Device Record                                   Review CA Policy
(`isCompliant` Attribute)                                  Conditions & Exclusions
         |
         +-------------------------------+
         |                               |
         v                               v
[ Entra: isCompliant = False ]   [ Entra: isCompliant = True ]
         |                               |
         v                               v
Check Intune Device Blade          Check Client Endpoint Health
(Identify failing rule)            (dsregcmd /status for PRT state)

Step 1: Sign-in log analysis

1. Open Entra ID → Sign-in logs and locate the failed correlation ID.
2. Open the Conditional Access tab.
3. Expand the compliance policy and confirm the grant failure is specifically "Require device to be marked as compliant".

Step 2: Directory object verification

1. Go to Entra ID → Devices → All devices.
2. Find the device using deviceId from the sign-in log.
3. Check Is Compliant:
   • No - problem is Intune evaluation or directory sync.
   • Yes - problem is the endpoint broker or PRT state.

Step 3: Intune evaluation and sync

1. Open Intune Admin Center → Devices → Compliance.
2. Review per-setting status (OS version, BitLocker, antivirus, and so on).
3. If Intune shows Compliant but Entra shows Not Compliant, trigger a Company Portal sync and allow about 15 minutes for directory propagation.

Step 4: Endpoint health (dsregcmd /status)

On Windows, run an elevated Command Prompt:

dsregcmd /status

• Device State: AzureAdJoined = YES
• SSO State: AzureAdPrt = YES
• PRT freshness: recent AzureAdPrtUpdateTime

If AzureAdPrt is NO or stale, the broker cannot pass device identity to Entra - compliance grants fail regardless of Intune status.

Step 5: Mobile browser SSO

On iOS and Android, Safari or Chrome often fail with AADSTS53000 because browsers do not pass device certificate context by default.

• iOS: deploy the Microsoft Enterprise SSO plug-in via Intune MDM for Safari.
• Android: provision client certificates via Authenticator and configure Chrome integration.

Summary Checklist