top of page

Your Conditional Access Policy Has a Backdoor (And It Doesn't Need Your Endpoints to Use It)

  • Writer: Scott Pagel
    Scott Pagel
  • 2 days ago
  • 5 min read
Laptop displaying Microsoft Entra ID, orange alert "Your Conditional Access Policy Has a Backdoor." Icons show cloud, security, and resilience.

A single stolen username and password were enough to compromise a 16,000-user Microsoft tenant.


No malware. No ransomware. No compromised corporate laptop.


Just a trust model that believed what it was told.


In a May 2026 red team engagement published by Howler Cell and Cyderes, researchers demonstrated a path around Microsoft Entra ID Conditional Access policies using phantom device registration, fake compliance claims, and Primary Refresh Token (PRT) abuse. The result was tenant-wide access without ever touching a legitimate endpoint.


That should concern every SMB running Microsoft 365.


Conditional Access is supposed to be the gatekeeper. It enforces MFA, requires compliant devices, and blocks risky authentication attempts. But what happens when an attacker bypasses the front door entirely and walks through a service endpoint your policies never covered?


That is exactly what this attack path exposed.



What Actually Happened


The attack chain sounds complicated, but the underlying issue is straightforward: Microsoft trusted a device registration process that never fully verified whether the device was legitimate.


The attackers began with valid credentials purchased online. When they attempted a normal login, Conditional Access blocked them because the tenant required a compliant or hybrid-joined device.


So they targeted Microsoft’s Device Registration Service (DRS) instead.


Using device code authentication flow, they registered a Linux system as a fake Windows device. Microsoft accepted it without validating hardware attestation or confirming it was a real corporate endpoint.


That fake device was then issued a Primary Refresh Token containing false compliance claims. Entra ID interpreted the device as trusted and granted access accordingly.


Intune made the problem worse by accepting self-declared hybrid join status without validating it against on-prem Active Directory. Missing security controls like BitLocker, Secure Boot, and antivirus attestation were treated as “not applicable” instead of non-compliant.


The result was a phantom device that appeared legitimate enough to satisfy Conditional Access policies.


Why This Matters for Your Organization (Not Just Enterprise)


The moment SMBs hear “16,000-user tenant,” many assume this does not apply to them.


It does.


The attack path works because of default Microsoft behaviors, not because the organization was unusually large. Smaller businesses are often more exposed because they lack dedicated identity security teams reviewing Conditional Access policies and monitoring Entra ID activity regularly.


At SafeStorz, we see this gap frequently during Microsoft 365 onboarding and tenant consolidation projects. Businesses often have Conditional Access enabled, but enforcement is inconsistent across device registration, MFA, compliance policies, and privileged account management. On the surface, everything looks secure. Underneath, there are usually trust assumptions nobody realized existed.


If your organization has deployed:


  • Intune

  • Entra Connect

  • Hybrid Azure AD Join

  • Conditional Access policies

  • Device compliance enforcement


…without specifically reviewing device code flows and DRS protections, this deserves attention.


A lot of organizations assume “compliant device required” automatically means secure. This research showed that device trust itself can be spoofed if attestation controls are too permissive.


The Compliance Theater Problem


This is the sharpest part of the story.


Intune said the device was compliant.


It was not.


That is not just a configuration mistake. It is a design assumption that compliance can partially be self-reported without strong validation.


Zero-trust architecture is supposed to eliminate implicit trust. But if missing attestation data is accepted as “not applicable” instead of failing compliance checks, the trust model still has holes in it.


The word “compliant” on a dashboard means nothing if the system never verified the security posture in the first place.


This is why SafeStorz standardizes Microsoft 365 and Intune baselines instead of allowing every environment to evolve into custom configurations with inconsistent enforcement. The company built repeatable Intune deployment baselines with Conditional Access, Defender policies, app packaging, and Autopatch specifically to reduce policy drift and sparse security configurations across tenants.


Consistency reduces gaps.


What Microsoft Says to Do (And What That Leaves Unaddressed)


The researchers came out of the engagement with clear recommendations: block device code authentication flows, require MFA for device registration, enforce TPM 2.0 attestation before issuing PRTs, use Microsoft Health Attestation Service instead of self-reported compliance data, restrict Graph API access, and move privileged roles to cloud-only accounts managed through PIM.


These are the right calls.


But Microsoft does not enforce most of them by default. They are available. They are documented. They are not on. And most SMBs do not have an internal team whose job is to go find them.


That is the real problem.


A lot of businesses configure Conditional Access once, watch it work for a few weeks, and file it under solved. Meanwhile, default behaviors stay permissive, policies drift, and trust assumptions nobody reviewed are still sitting there quietly.


Identity security is not a configuration event. It is an ongoing practice. Policies need to be reviewed against how trust is actually being enforced in the environment, not just how it was configured the day someone set it up.


That gap between documentation and enforcement is where this attack lived.

Where Cynet Closes the Gap


Even well-configured environments need behavioral detection as a backstop.


Policies fail. Configurations drift. Attackers adapt.


That is why SafeStorz uses Cynet XDR with 24/7 MDR as part of its security stack.


Conditional Access policies are preventative controls. Cynet helps detect what happens when preventative controls are bypassed or abused.


That includes:


  • Unexpected device registrations

  • Suspicious token exchange activity

  • Bulk directory enumeration

  • Unusual Graph API behavior

  • Lateral movement following identity compromise

  • Microsoft 365 posture and vulnerability exposure


This layered approach mirrors how SafeStorz handles real-world incidents. In one customer environment, Cynet detected suspicious lateral movement activity early enough for the team to investigate, isolate potential exposure, review firewall access, and strengthen MFA and device compliance controls before the situation escalated into a larger incident.


The MDR component matters just as much as the tooling itself.


Alerts are useless if nobody is watching them.


And critically, SafeStorz environments are designed with isolation and reduced blast radius from the start. Even if an attacker compromises a Microsoft 365 identity, your critical infrastructure is not sitting in one large flat trust zone.


Resilience is not about preventing every failure.


It is about ensuring failure does not dictate outcomes.


Three Things to Check Right Now


If you are running Microsoft 365 and Entra ID today, answer these three questions:


  1. Are device code authentication flows still enabled?


Many organizations never explicitly disable them, leaving an alternate authentication path open.


  1. Does Intune treat missing attestation data as non-compliant?


If missing BitLocker, Secure Boot, or TPM validation is simply marked “not applicable,” your compliance policies may not be enforcing what you think they are.


  1. Are privileged accounts synced from on-prem Active Directory?


Hybrid identity environments create additional escalation paths. Cloud-only privileged accounts managed through PIM reduce exposure significantly.


If you do not know the answers, it is worth having the conversation now instead of after an incident.


Final Thoughts


This attack path did not rely on malware or compromised endpoints. It exploited trust assumptions hiding inside identity infrastructure that many organizations believed were already secure.


That is why identity hardening, behavioral monitoring, and architectural isolation matter so much now.


Modern attackers do not always smash through the front door.


Sometimes they register a phantom device, inherit trust they never earned, and walk in quietly instead.


SafeStorz performs identity security reviews and Microsoft 365 hardening assessments as part of managed services onboarding. If you want an honest look at your Conditional Access policies, device trust exposure, and privileged identity risks, let’s talk.

 
 
bottom of page