Skip to Content

Why Device Trust Is Often Assumed, Not Verified

23 January 2026 by
Jaspreet Singh
black flat screen computer monitor

Why Device Trust Is Often Assumed, Not Verified

A Technical Deep Dive into Identity, Tokens, and Trust Decay

Device trust in Microsoft identity ecosystems is not continuously validated.

Device trust is a cached claim based on point-in-time signals and is often relied upon well beyond the period it accurately reflects the device's security posture. (Protecting Tokens in Microsoft Entra ID, 2025)

This article details where trust is inferred, how it is embedded in tokens, and why identity systems may continue to trust compromised devices.

1. Device Trust Is a Claim, Not a State

In Entra ID, “device trust” is represented by claims issued at authentication time, not by a live verification channel. (Authentication and Conditional Access for B2B users - Microsoft Entra External ID, 2024)

Common Device-Related Claims

  • deviceid
  • isCompliant
  • isManaged
  • trustType (AzureAD / Hybrid)
  • xms_device_capability

These claims are:

  • Evaluated once
  • Embedded into access & refresh tokens
  • Trusted until token expiry or revocation

Identity does not re-verify the device after the initial check.

It continues to trust the previously issued claim. (Zero Trust identity and device access policies, n.d.)

2. Intune Compliance: How the Signal Is Actually Generated

Compliance Evaluation Flow (Simplified)

  1. Device checks in with Intune
  2. Compliance policies are evaluated.
  3. The compliance state is written to Entra ID.
  4. isCompliant=true becomes available to CA

Critical Limitations

  • Compliance evaluation is not event-driven.
  • Changes in device state after check-in are not detected.
  • There is no real-time enforcement of device integrity.
  • Sessions are not invalidated natively when compliance changes. (Singh, 2025)

If Defender is disabled after the compliance evaluation:

  • Entra ID does not detect this change.
  • Existing tokens remain valid despite the change.
  • Conditional Access policies are not re-evaluated.

This represents a significant gap in device trust.

3. Conditional Access: Pre-Issuance Only

Conditional Access is enforced during token issuance, not during token usage. (Continuous access evaluation in Microsoft Entra, 2024)

CA Evaluation Occurs When:

  • Interactive sign-in happens
  • Token refresh requires re-evaluation.
  • Explicit reauthentication is forced.

CA Does NOT Run When:

  • Device posture changes
  • Defender detects malware
  • Local admin is added.
  • The browser session is hijacked.

Once a token is issued:

  • Conditional Access is no longer enforced after token issuance.
  • Authorization relies on claims, not verification (Secure applications and APIs by validating claims, 2025)

4. Token Lifetime Is Longer Than Device Integrity

Typical Defaults

  • Access token: ~1 hour
  • Refresh token: up to 90 days (Refresh tokens in the Microsoft identity platform, 2025)
  • Conditional Access re-evaluation is inconsistent and depends on specific conditions.

A stolen refresh token from a “trusted device” can:

  • Mint new access tokens
  • Preserve device claims
  • Bypass MFA
  • Survive device compromise

Device trust can be transferred through tokens. (Token Protection by using Microsoft Entra ID, 2024)

5. Continuous Access Evaluation (CAE): Why It’s Not Enough

Continuous Access Evaluation is often mistaken for real-time verification. (Wong, 2025)

What CAE Actually Does

  • Responds to specific identity events

  • Examples:

    • User disabled
    • Password reset
    • Admin revocation

What CAE Does NOT React To

  • Device non-compliance
  • Defender alerts
  • Tamper protection disabled.
  • Continuous Access Evaluation is based on identity events, not device state. (Continuous access evaluation in Microsoft Entra, 2025) ven.

6. Defender for Endpoint Integration: Where Trust Still Breaks

Even with MDE + Entra ID integration enabled:

  • MDE alerts do not automatically revoke sessions
  • Risk signals are often delayed and lack granularity.
  • Identity systems do not continuously process endpoint-detection-and-response telemetry. (Disconnected environments, proxies, and Microsoft Defender for Endpoint, 2023)

Unless you explicitly:

  • Automate session revocation
  • Trigger sign-in frequency reset
  • Disable user or device

Identity will continue to trust the device unless action is taken.

7. Hybrid Join and the Myth of Corporate Trust

Hybrid-joined devices are often treated as:

  • “Known”
  • “Safe”
  • “Internal”

But Hybrid Join only proves:

  • AD object existence
  • Device registration

It does NOT prove:

  • Secure boot
  • OS integrity
  • Patch level
  • Runtime health

A hybrid join confirms the presence of an identity but does not reflect the device's security posture. (Join your cloud-native endpoints to Microsoft Entra - Microsoft Intune, 2024)

8. Attack Path: Trusted Device → Token → Persistence

Realistic Attack Sequence

  1. User signs in from a compliant device
  2. CA issues a token with isCompliant=true.
  3. Attacker gains local execution.
  4. The token or browser session is stolen.
  5. Defender detects activity (optional)
  6. Identity continues to honor the token.
  7. Attacker operates as a trusted user.

No policy is violated.

No CA rule is re-evaluated.

No trust is revoked.

9. Why “Require Compliant Device” Is a Weak Control Alone

This control:

  • Verifies compliance once
  • Does not bind access to continued integrity
  • Does not enforce re-verification

It works best as:

  • A gate, not a guarantee

Without:

  • Short token lifetimes
  • Aggressive reauthentication
  • Automated revocation

This approach can create a false sense of security. (Zero Trust identity and device access policies, n.d.)

10. What Verified Device Trust Would Actually Require

Architectural Requirements (Not UI Toggles)

  1. Event-Driven Trust Revocation

    • EDR alerts must trigger a session kill
    • Device compromise must invalidate tokens.

  2. Trust Expiration

    • Device trust must decay.
    • Claims should age out rapidly.

  3. Runtime Enforcement

    • Access tied to live health
    • Not historical compliance

  4. Identity–Security Feedback Loop

    • Security signals → identity enforcement.
    • Avoid relying on dashboards or manual intervention, as they introduce delays.

11. The Core Truth

Device trust today is:

  • Static
  • Cached
  • Assumed (Göckel, 2024)

Attackers often do not break trust directly.

Instead, they wait for identity systems to stop verifying device trust. (Zero Trust Is Broken Without Device Identity, But Not Irreparable, 2025)Until device trust becomes:

  • Continuous
  • Revocable
  • Event-driven

“Zero Trust” remains a marketing term, not a control model.

Final Takeaway

Identity does not verify devices — it remembers them.

Relying solely on memory is an inadequate security control.



Written by Jaspreet Singh — Microsoft identity & security practitioner. Author at ITBlogs.ca. Lab notes and testing at f11.ca.


References

(2025). Protecting Tokens in Microsoft Entra ID. Microsoft Entra ID. https://learn.microsoft.com/en-us/entra/identity/devices/protecting-tokens-microsoft-entra-id

(2024). Authentication and Conditional Access for B2B users - Microsoft Entra External ID. Microsoft Learn. https://learn.microsoft.com/en-us/entra/external-id/authentication-conditional-access

(n.d.). Zero Trust identity and device access policies. https://download.microsoft.com/download/e/d/0/ed03381c-16ce-453e-9c89-c13967819cea/zero-trust-identity-and-device-access-policies.pdf

Singh, H. (May 17, 2025). Analysis of Conditional Access Enforcement for Windows Device Compliance in Entra ID. Microsoft Q&A. https://learn.microsoft.com/en-us/answers/questions/2276666/analysis-of-conditional-access-enforcement-for-win

(2024). Continuous access evaluation in Microsoft Entra. Microsoft Entra ID. https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-continuous-access-evaluation

(2025). Secure applications and APIs by validating claims. Microsoft Learn. https://learn.microsoft.com/en-us/entra/identity-platform/claims-validation

(2025). Refresh tokens in the Microsoft identity platform. Microsoft Learn. https://learn.microsoft.com/en-us/entra/identity-platform/refresh-tokens

(2024). Token Protection by using Microsoft Entra ID. Microsoft Community Hub. https://techcommunity.microsoft.com/blog/coreinfrastructureandsecurityblog/token-protection-by-using-microsoft-entra-id-/4302207

Wong, A. (August 12, 2025). Real-Time Security with Continuous Access Evaluation (CAE) comes to Azure DevOps. Azure DevOps Blog. https://devblogs.microsoft.com/devops/real-time-security-with-continuous-access-evaluation-cae-comes-to-azure-devops/

(2025). Continuous access evaluation in Microsoft Entra. Microsoft Entra ID | Microsoft Learn. https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-continuous-access-evaluation

(2023). Disconnected environments, proxies and Microsoft Defender for Endpoint. Microsoft Tech Community. https://techcommunity.microsoft.com/t5/microsoft-defender-for-endpoint/disconnected-environments-proxies-and-microsoft-defender-for/ba-p/3710502

(n.d.). Zero Trust identity and device access policies. https://download.microsoft.com/download/e/d/0/ed03381c-16ce-453e-9c89-c13967819cea/zero-trust-identity-and-device-access-policies.pdf

Göckel, S. (2024). Better Together – Microsoft Azure AD and deviceTRUST. deviceTRUST. https://devicetrust.com/blog/microsoft-azure-ad-and-devicetrust/

(2025). Zero Trust Is Broken Without Device Identity, But Not Irreparable. Device Authority. https://deviceauthority.com/zero-trust-is-broken-without-device-identity-but-not-irreparable/

(2024). Join your cloud-native endpoints to Microsoft Entra - Microsoft Intune. Microsoft Learn. https://www.microsoft.com/en-us/microsoft-entra/solutions/cloud-native-endpoints/azure-ad-joined-hybrid-azure-ad-joined

Guest Users: The Overlooked Lateral Movement Path in Entra ID