Azure AD / Microsoft Entra Conditional Access “Bypass” via Phantom Device Registration & PRT Abuse — A Deep Technical Breakdown

Spread the love

Time to read: 10–12 minutes (technical deep dive)

Conditional Access (CA) in Microsoft Entra ID (formerly Azure AD) is often treated as the enforcement point for MFA, compliant-device requirements, location rules, and risk-based policies.
Recent red-team research shows how an attacker can still reach protected resources without touching a corporate endpoint by abusing the device trust chain—specifically Device Registration Service (DRS), Primary Refresh Tokens (PRTs), and Intune compliance evaluation. [cyderes.com], [learn.microsoft.com]

This is the core idea: CA doesn’t “secure devices” by itself; it evaluates claims. If an attacker can mint tokens that contain device/compliance claims that CA trusts, they can satisfy “Require compliant device” controls in unexpected ways. [cyderes.com], [techcommun…rosoft.com]

“Who is this post for?”

This post is for anyone who relies on Microsoft Entra Conditional Access—from beginners to seasoned engineers—because it explains the attack chain in plain language first, then goes deep technically. [learn.microsoft.com], [techcommun…rosoft.com]

SOC Analysts & Threat Hunters who need log-driven detection ideas and investigation pivots. [learn.microsoft.com], [techcommun…rosoft.com]
Identity / IAM Engineers who design Conditional Access, device trust, and enrollment restrictions. [cyderes.com], [learn.microsoft.com]
Intune / Endpoint Admins who assume “compliant device” is a hard gate and want to understand where it can fail. [cyderes.com]
Cloud Security Architects building Zero Trust defenses across tokens, device identity, and policy enforcement. [techcommun…rosoft.com], [learn.microsoft.com]
IT Leaders & Security Managers who need a clear explanation of why “Report-only” policies are not controls and what to prioritize. [cyderes.com]

What you’ll walk away with
A mental model for the device trust chain (DRS → device identity → PRT → token claims → CA evaluation) and a practical list of controls and detection points to break that chain. [cyderes.com], [learn.microsoft.com]

1) What happened (high-level): from blocked creds to “device-trusted” tokens

In the referenced engagement (a production Entra tenant with ~16k users and ~82k devices), researchers started with valid credentials that were blocked by Conditional Access (AADSTS errors) and still built a chain to broad tenant access by:

Authenticating through a path CA didn’t effectively stop,
Registering a “phantom” device through DRS,
Minting a PRT that carried device claims, and
Achieving Intune “compliance” on a non-corporate machine because compliance signals were treated permissively. [cyderes.com]

Critically, the report calls out that key CA policies existed but were left in Report-only, which logged what would have happened but did not block the chain. [cyderes.com]

2) Conditional Access fundamentals: CA enforces at token issuance, not “everywhere”

Conditional Access decisions are evaluated when Entra issues tokens (or refreshes them), based on signal inputs (user, location, risk, client type) and—importantly here—device identity and compliance claims.
This matters because a session can become “acceptable” to CA if the resulting token contains the right authentication method reference (AMR) values and device identifiers, even if the actual endpoint is not what you think it is. [techcommun…rosoft.com], [cyderes.com] [cyderes.com], [techcommun…rosoft.com]

Microsoft’s own guidance also emphasizes that some flows (like device code flow) are higher risk, and Entra added explicit CA controls to restrict them. [learn.microsoft.com], [securitybo…levard.com]

3) The weak link: device identity as a “trust amplifier”

3.1 Device Registration Service (DRS) is a separate trust boundary

DRS is the service responsible for onboarding/joining devices into Entra.
In the report, a key finding is that DRS did not validate the caller as a “real Windows device”; it validated the token, allowing a “phantom” device to be registered and receive a signed certificate and private key material used as device identity. [cyderes.com], [learn.microsoft.com] [cyderes.com]

Microsoft documentation notes that authentication flow policies can explicitly target risky flows, and that enforcement for authentication flows policies against Device Registration Service began in September 2024 for certain policy scopes.
But “can be enforced” is not the same as “is enforced in your tenant,” especially if policies are mis-scoped, excluded, or left report-only. [learn.microsoft.com] [cyderes.com], [learn.microsoft.com]

3.2 Why “Report-only” is dangerous for identity controls

The engagement explicitly highlights that two policies that would have broken the chain were present but not enforced (left in Report-only).
That’s not a theoretical nuance—attackers routinely live in the gap between “we tested it” and “we enabled it.” [cyderes.com]

4) Device Code Flow: why defenders keep being asked to block it

Device code flow was designed for input-constrained devices (CLI tools, smart displays) and involves a user completing auth in a browser using a device code.
Microsoft classifies device code flow as high risk because it can be used in phishing and to access resources from unmanaged devices, and it recommends blocking it wherever possible. [learn.microsoft.com], [securitybo…levard.com]

This risk isn’t hypothetical: there have been real campaigns abusing device code flow (e.g., Storm-2372 device code phishing), and multiple defender writeups focus on how that flow can be used to acquire tokens by tricking users into authorizing a code.
The red-team chain in the report aligns with the broader theme: alternate auth flows can become entry points into downstream device trust operations if they aren’t explicitly controlled. [jeffreyappel.nl], [securitybo…levard.com] [cyderes.com], [learn.microsoft.com]

5) Phantom device registration → PRT minting: why PRTs matter

5.1 What is a PRT?

A Primary Refresh Token (PRT) is a long-lived authentication artifact used by Windows sign-in and brokers to silently obtain access tokens for cloud resources.
Microsoft’s token-theft guidance frames long-lived/session tokens as the “season pass” of identity—if stolen or mis-issued, they enable repeated access without repeated MFA prompts. [cyderes.com], [techcommun…rosoft.com] [techcommun…rosoft.com]

5.2 Device claims are the “key” that opens device-based CA controls

The engagement describes minting a PRT that contains device-bound claims (e.g., a device ID and certificate-based authentication indicators) that cause CA to evaluate the session as device-authenticated (e.g., AMR including rsa).
This is the turning point: the same user credentials that were blocked in a normal sign-in path could now produce tokens that appear to satisfy “joined/compliant device” requirements due to the presence of device claims. [cyderes.com] [cyderes.com], [techcommun…rosoft.com]

5.3 Why token binding / token protection is relevant

Microsoft’s recommended direction for defeating token replay is token protection (sender-constrained/bound tokens) so stolen tokens can’t be replayed from another device.
However, this chain is subtler than classic replay: it’s about minting tokens with trusted device claims, which is why hardening device registration and attestation becomes equally important. [techcommun…rosoft.com] [cyderes.com], [techcommun…rosoft.com]

6) Intune compliance: the “self-asserted” gap

Conditional Access often uses “Require device to be marked as compliant” as a strong control.
But the report demonstrates a practical pitfall: a phantom endpoint was marked compliant because missing health attestation responses were treated as “not applicable” rather than non-compliant, and compliance can rely on device self-reporting unless attestation is enforced. [techcommun…rosoft.com], [cyderes.com] [cyderes.com]

The report explicitly calls out Microsoft Health Attestation Service (HAS) as a mechanism for external validation, but notes it was not required in the tested environment. [cyderes.com]

Defender takeaway: If compliance policy logic interprets absent signals permissively, “compliance” becomes a weak predicate for access control. [cyderes.com], [techcommun…rosoft.com]

7) Hybrid identity multiplies blast radius: synced privileged accounts

Separate from the phantom-device chain, the engagement surfaced a structural risk in hybrid environments: on-prem AD-synced accounts holding privileged Entra directory roles.
The report highlights that compromising on-prem AD can provide a direct path to cloud tenant takeover when privileged roles (e.g., Global Administrator, Privileged Role Administrator) are assigned to synced identities. [cyderes.com]

This aligns with Microsoft’s broader framing that identity attacks increasingly focus on token/session artifacts and privilege paths rather than “just passwords,” emphasizing layered defenses and continuous evaluation. [techcommun…rosoft.com]

8) Related: Microsoft is also closing other CA “enforcement gaps” in 2026

In parallel to these device-trust abuse paths, Microsoft announced improvements to CA enforcement where some sign-ins could bypass CA when policies targeted “All resources” with exclusions and requests were for limited OIDC/directory scopes.
The rollout begins March 27, 2026 (phased through June 2026), and aims to ensure CA policies apply more consistently to these authentication requests. [4sysops.com], [petri.com]

This is relevant because it underscores a key operational reality: CA behavior depends on policy scoping, flow types, and platform enforcement details that change over time—so continuous validation is essential. [4sysops.com], [learn.microsoft.com]

9) Attack chain model (defender view)

Below is a simplified defender-oriented chain showing where controls should break it (not an exploitation recipe). [cyderes.com], [learn.microsoft.com]

flowchart LR
A[Valid credentials obtained] --> B[Auth path allowed (unexpectedly)]
B --> C[DRS device registration]
C --> D[Device certificate identity]
D --> E[PRT minted / session bootstrap]
E --> F[Access token w/ device claims]
F --> G[Conditional Access satisfied (device/compliance)]
G --> H[Intune compliance accepted]
H --> I[Graph/app access + enumeration]

%% Defender breakpoints
B -. Block / restrict .-> B1[Block risky auth flows (e.g., Device Code Flow)]
C -. Enforce .-> C1[MFA + restrictions on device registration]
H -. Require .-> H1[Require attestation-backed compliance (HAS/TPM signals)]

Breakpoints:

Block/limit device code flow where not required. [learn.microsoft.com], [securitybo…levard.com]
Require MFA for device registration and restrict who can register devices. [cyderes.com], [learn.microsoft.com]
Require attestation (TPM/HAS) rather than self-report for device trust/compliance. [cyderes.com], [techcommun…rosoft.com]
Move CA policies from Report-only to Enabled with deadlines and ownership. [cyderes.com]

10) Detection engineering: what to hunt for in logs

10.1 Device code flow usage

Microsoft recommends using sign-in logs and the authentication protocol filter to understand device code flow usage, and Entra includes an “original transfer method” property for protocol tracking. [learn.microsoft.com], [jeffreyappel.nl]

KQL idea (Microsoft Sentinel) — device code sign-ins:

SigninLogs
| where TimeGenerated > ago(30d)
| where AuthenticationProtocol == "deviceCode"
| project TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress, ConditionalAccessStatus, OriginalTransferMethod
| order by TimeGenerated desc

This aligns with defender guidance to filter by AuthenticationProtocol == "deviceCode" and review protocol tracking fields. [learn.microsoft.com], [jeffreyappel.nl]

10.2 Device Registration Service targeting

Microsoft documentation explicitly identifies Device Registration Service as a targetable resource in CA policies (including via its client ID) and notes how auth flows enforcement can apply to DRS depending on scope. [learn.microsoft.com]

KQL idea — sign-ins involving DRS (resource/client ID filtering depends on your schema):

SigninLogs
| where TimeGenerated > ago(30d)
| where ResourceId == "01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9"
| project TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress, AuthenticationProtocol, ConditionalAccessStatus
| order by TimeGenerated desc

Use this to spot unexpected DRS interactions, especially from unusual IPs/locations or user populations. [learn.microsoft.com], [cyderes.com]

10.3 “Report-only” drift as a security signal

The engagement demonstrates that report-only policies can be the difference between a logged event and a blocked event.
Operationally, treat Report-only duration as a measurable risk: if a policy is still report-only after X days, it should trigger governance escalation. [cyderes.com] [cyderes.com], [4sysops.com]

11) Hardening: practical mitigations that actually break this chain

11.1 Block or tightly restrict device code flow

Microsoft recommends blocking device code flow wherever possible and provides explicit CA controls for it.
If you must allow it (e.g., for specific room devices), scope it narrowly (named locations, device platforms, specific users) and monitor it continuously. [learn.microsoft.com], [securitybo…levard.com] [learn.microsoft.com], [jeffreyappel.nl]

11.2 Enforce MFA + constraints for device registration (DRS)

The report calls out that device registration policy enforcement would have broken the chain early.
Combine “MFA for device registration” with limiting who can register/join devices in the first place and avoiding permissive defaults. [cyderes.com] [cyderes.com], [learn.microsoft.com]

11.3 Require hardware/attestation-backed device trust (TPM / Health Attestation)

The engagement highlights that the phantom device lacked TPM/Secure Boot/BitLocker, yet could be considered compliant because attestation wasn’t required.
Requiring Health Attestation Service (HAS) and/or strong attestation predicates makes “compliance” harder to counterfeit. [cyderes.com] [cyderes.com], [techcommun…rosoft.com]

11.4 Token theft defenses still matter (token protection + CAE)

Microsoft recommends token protection (bound tokens) and Continuous Access Evaluation (CAE) to reduce replay and invalidate sessions when risk changes.
While this chain isn’t classic token replay, CAE and token protection strengthen the overall identity posture and reduce attacker dwell time when anomalies are detected. [techcommun…rosoft.com] [techcommun…rosoft.com], [learn.microsoft.com]

11.5 Fix hybrid privilege design

The report explicitly warns that synced privileged accounts create an on-prem-to-cloud escalation path.
Best practice is to keep your most privileged Entra roles cloud-only, use just-in-time activation (e.g., PIM), and minimize privileged role assignment to synced identities. [cyderes.com] [cyderes.com], [techcommun…rosoft.com]

12) A concise “secure configuration” checklist

Use this as an actionable baseline you can audit quarterly:

Device code flow: blocked tenant-wide unless a documented exception exists. [learn.microsoft.com], [securitybo…levard.com]
Authentication flows CA: explicitly configured, enabled (not report-only), and tested against real sign-ins. [learn.microsoft.com], [cyderes.com]
DRS / device registration: MFA enforced; device join/registration permissions minimized. [cyderes.com], [learn.microsoft.com]
Intune compliance: require attestation signals (HAS/TPM/secure boot/bitlocker) and ensure missing signals are treated as non-compliant. [cyderes.com]
Report-only governance: any report-only policy must have an owner + deadline; report-only ≠ control. [cyderes.com]
Token security: adopt token protection where supported; enable CAE and risk-based policies. [techcommun…rosoft.com]
Hybrid privileged roles: eliminate synced Global Admins; move privileged identities to cloud-only where feasible. [cyderes.com]
Prepare for CA enforcement changes (2026): test apps that request limited OIDC scopes under your CA policies. [4sysops.com], [petri.com]

Conclusion: the “bypass” is really a trust-chain failure

This incident class is best understood as abuse of implicit trust boundaries:

If DRS will register “a device” based on tokens,
If PRT issuance accepts that device identity, and
If Intune compliance allows permissive evaluation (including “not applicable” for missing attestation),
then Conditional Access becomes a policy engine evaluating claims that can be manufactured. [cyderes.com], [techcommun…rosoft.com]

The fix is not a single toggle. It’s closing the loops: restrict risky auth flows, harden device registration, require attestation-backed compliance, and treat “report-only” as an unacceptable steady state for high-impact controls. [cyderes.com], [learn.microsoft.com]

References / further reading

Cyderes Howler Cell report: “One Password, No Device, Full Tenant…” [cyderes.com]
Microsoft Learn: Conditional Access — Authentication flows & protocol tracking [learn.microsoft.com]
Microsoft Entra blog: “How to break the token theft cyber-attack chain” [techcommun…rosoft.com]
Device code flow hardening discussion & Microsoft-managed policy mention [securitybo…levard.com]
CA enforcement change (March 27, 2026 rollout) analyses [4sysops.com], [petri.com]
Device code flow abuse writeup / Storm-2372 context [jeffreyappel.nl]

If you’re using Conditional Access as your “last line of defense,” take a moment to ask: Do your policies validate device trust—or do they trust device claims?
A great next step is to pick one thing from this post and implement it this week—like blocking device code flow, enforcing MFA for device registration, or tightening compliance attestation requirements—then measure the impact in your sign-in logs. [cyderes.com], [techcommun…rosoft.com] [learn.microsoft.com], [securitybo…levard.com], [cyderes.com]

Your turn:

Which control is hardest in your environment right now: device registration, Intune compliance, or token/session protection?
Reply with your constraints (e.g., “we need device code for X” or “we can’t enforce full compliance yet”), and I’ll suggest a low-disruption rollout plan tailored to that scenario. [cyderes.com], [techcommun…rosoft.com] [learn.microsoft.com], [jeffreyappel.nl]