Conditional Access: How It Works and How Attackers Bypass It

Conditional access (CA) is the policy layer in an identity provider that decides, at sign-in, whether a request gets through. In Microsoft Entra ID it is a policy engine that combines signals about the user, device, location, and risk, then grants access, requires another step such as MFA, or blocks. Okta makes the same decision through its authentication policies.

A tenant can pass every console check (MFA for all users, legacy authentication blocked, compliant devices for admins, a break-glass account excluded) and still approve an attacker's sign-in or miss an access path entirely. Those settings describe what a policy requires. They don't establish whether a sign-in belongs to the legitimate user, or whether every path into the tenant meets a policy at all.

This guide covers how the two policy engines evaluate a sign-in, common baseline designs, the paths attackers use to get around them, and the log signals that separate a bypassed policy from a satisfied one.

TL;DR:

• Conditional access evaluates sign-ins and token requests, so a stolen access token keeps working until it expires unless a resource that supports Continuous Access Evaluation (CAE) revokes it, and device binding is the main defense against a stolen refresh token.
• Most bypasses exploit coverage gaps: legacy protocols and Resource Owner Password Credentials (ROPC) can't satisfy MFA, so a password alone works wherever no policy blocks them, and unscoped resources and report-only policies leave other paths unenforced.
• Device-based requirements hold only as well as enrollment, device credentials, and endpoint integrity, as primary refresh token (PRT) replay, rogue device joins, and attestation proxying show.
• Monitoring complements hardening: look for successful sign-ins that conflict with intended policy, token reuse across devices, and factor resets followed by unfamiliar sign-ins.

How Conditional Access Evaluates a Sign-In

Entra ID and Okta both decide at authentication time, and their mechanics differ in ways that change how you design and audit policies.

Entra ID Conditional Access

An Entra policy is an if-then statement of assignments and access controls. Every applicable policy must be satisfied, and the assignments inside a policy combine with AND.

Evaluation runs in two phases. The first collects session details such as network location and device identity, for both enabled and report-only policies. The second enforces, and a Block control stops evaluation outright. Otherwise, unmet grant controls are prompted in a fixed order (MFA, compliant device, hybrid-joined device, approved client app, app protection policy, password change, terms of use, custom controls), and session controls apply once grants are met.

Three Entra behaviors cause production surprises:

• New policies apply to all client app types unless you configure the client apps condition.
• Policies scoped to roles or groups are evaluated only when a token is issued. A user added to a group stays unaffected until their next token.
• Device platform targeting relies on user-agent strings, which Microsoft describes as unverified and changeable.

Microsoft recommends running each policy in report-only mode for at least one week before enforcing it, and risk-based policies require Entra ID P2 licenses.

Okta's Equivalents

Okta Identity Engine evaluates the global session policy first, then the app sign-in policy, and the assurance requirements of both must be met. Rules evaluate in priority order until one matches. Put restrictive rules at the top; default policies always sit last and can't be deleted. Device posture comes from device assurance policies, which check OS version, patch level, screen lock, and disk encryption, and apply only through an app sign-in policy rule.

Without Identity Threat Protection (ITP), Okta evaluates policies for identity threats only at sign-in. With ITP, IP or device changes trigger re-evaluation of the global session and app sign-in policies, and a deny logs policy.auth_reevaluate.fail.

The pairing below is an approximate map of features that don't line up one to one.

‍

Common Policy Designs and Where They Thin Out

Most baselines draw on Microsoft's managed policies and CISA's Binding Operational Directive BOD 25-01, which requires phishing-resistant MFA, a legacy-authentication block, and blocking high-risk users and sign-ins for federal civilian agencies. The rest come from CISA's broader Secure Cloud Business Applications (SCuBA) recommendations and Microsoft's templates:

• Phishing-resistant MFA for all users.
• Block legacy authentication.
• Block device code flow, which CISA's SCuBA baseline recommends and Microsoft ships as a managed policy.
• Block high-risk users and sign-ins, which needs Entra ID P2.
• Require compliant or hybrid-joined devices, and block unknown or unsupported platforms alongside it, because platform targeting relies on spoofable user-agent strings.
• Shorten sessions on unmanaged devices. Microsoft's template turns off persistent browser sessions and sets sign-in frequency to one hour.
• Exclude break-glass accounts from blocking policies.

The baseline is worth deploying, and teams get into trouble when they treat it as finished. Template policies exclude only the admin who creates them, and user-scoped policies don't block service principals. On Okta, a common misconfiguration requires a device to be both Registered and Not managed, a combination no registered, managed device can meet.

Where Attackers Get Around Conditional Access

The paths below mix resources and accounts no policy covers, requirements an attacker can meet, and tokens or sessions reused after they were issued.

1. Legacy Authentication and ROPC

Basic authentication can't satisfy an MFA challenge, so a correct password is enough wherever a service still accepts it and no policy blocks the request or requires MFA. Legacy mail protocols such as IMAP and POP can't process client access policies or MFA in Okta, and Microsoft attributes more than 99% of password spray attacks to legacy authentication protocols.

Exchange Online turned off Basic authentication for most protocols in 2022 and 2023, but SMTP AUTH kept it. Under Microsoft's revised SMTP AUTH timeline, Basic authentication for SMTP AUTH becomes disabled by default for existing tenants at the end of December 2026, though admins can still turn it back on. Microsoft plans to announce a final removal date in the second half of 2027.

ROPC, a flow that sends the user's password straight to the token endpoint, is the quieter problem. Microsoft recommends against ROPC because it's incompatible with MFA. Users who must complete MFA are blocked, leaving the exposure with accounts and apps that no MFA policy covers, and Wiz found that several Microsoft first-party apps present in every tenant still accept ROPC. In the LSHIY password spray campaign, attackers replayed validated credentials over ROPC against tenants whose Conditional Access MFA didn't cover the flow.

Okta's legacy /api/v1/authn endpoint shows the same coverage lesson. A June 2026 lab simulation by Panther got a session token from the endpoint without an MFA challenge, even though the test account had factors enrolled. Okta's Authentication API evaluates sign-on and MFA policy during primary authentication. An enrolled factor protects nothing unless a policy requires it.

The Midnight Blizzard intrusion Microsoft disclosed in January 2024 started with a password spray against a legacy, non-production test tenant account that didn't have MFA enabled.

2. Token Theft After a Legitimate MFA

Adversary-in-the-middle (AiTM) kits proxy the real login page: the user completes genuine MFA, and the attacker captures the resulting session token. Microsoft linked the Tycoon2FA phishing kit to nearly 100,000 compromised organizations since 2023 and noted that captured sessions kept working even after password resets.

Device code phishing skips the proxy. The attacker gets the victim to authorize a device code, receives tokens, and never touches the password. Customers rarely use device code flow and attackers use it frequently, according to Microsoft. The Storm-2372 campaign, which Microsoft now assesses as part of Midnight Blizzard, used the Authentication Broker client ID to obtain a refresh token, register a device, and get a PRT.

Microsoft's 2026 Digital Defense Report found that AiTM phishing and token theft more than doubled their share of detected attacks in the first half of 2026, though that share remains small.

Device binding and revocation are the mitigations. Entra Token Protection is generally available for native apps that access Exchange Online, SharePoint, and Teams, while browser support is in Preview and covers only web apps that call Azure Resource Manager. Okta FastPass and FIDO2 resist phishing only when policy enforces them, and phishable fallback methods left in place undo both.

3. Device Compliance and Trust Spoofing

Device-based requirements assume the device claim is trustworthy, and attackers have broken that assumption in documented ways:

• PRT replay: Dirk-jan Mollema's roadtx tool, released in 2022, can replay a stolen PRT carrying the source device's deviceid claim, and the resulting token passes a compliant-device check. Extracting the PRT together with its session key using Mimikatz works only on devices without a Trusted Platform Module (TPM).
• Rogue joins: SpecterOps showed that joining a rogue device or overwriting an existing one can satisfy hybrid-joined or registered-device requirements, though it needs valid credentials and doesn't by itself make the device compliant.
• Sync account abuse: SpecterOps also found that the Entra Connect sync account can add credentials to any device in the tenant and use them to get past device-restricted policies such as privileged access workstation rules.

On Okta, GitLab's red team got past Okta Verify device attestation by proxying attestation requests through SOCKS-capable malware on the victim's machine, after ordinary cookie theft failed. The work dates to May 2023 and was disclosed in September 2024. Okta has since shipped mitigations, and its FastPass hardening guidance names abuse of FastPass from a malware-compromised device as the remaining attack category.

4. Scope Gaps, Exclusions, and Report-Only Policies

Microsoft says Conditional Access "applies to resources not clients," with one exception for confidential clients requesting ID tokens. Policies scoped to directory roles also aren't enforced for administrative-unit-scoped or custom roles.

Fabian Bader and Mollema showed in 2025 that the Device Registration Service resource isn't protected by network or compliance requirements, and Microsoft's security response team classed this as expected behavior.

Exclusions built from user lists or legacy on-premises security groups let users join the group to escape the policy, so review them on the same schedule as the rest of your identity security posture. Report-only policies sit in the console looking like coverage while enforcing nothing.

5. Recovery Flows the Policy Never Sees

Conditional access doesn't check the identity-proofing decision a help-desk agent makes on a phone call, although the admin session that performs a reset can have its own protections. CISA's Scattered Spider advisory, updated in July 2025, describes attackers using help-desk social engineering to get passwords reset and MFA transferred to devices they control.

Voice phishing is growing: Mandiant's M-Trends 2026 found it in 11% of the intrusions Mandiant investigated in 2025, while email phishing fell to 6%. Okta has documented callers asking service desks to reset all MFA factors enrolled by highly privileged users.

What to Monitor

The most useful detections ask whether a sign-in succeeded on a path that policy should have blocked, or came from a device other than the one that earned the token.

Entra ID Sign-In and Audit Signals

The sign-in log, ID Protection, and the audit logs cover most of the bypass paths above:

• Sign-in log fields conditionalAccessStatus, appliedConditionalAccessPolicies, and clientAppUsed. The same Bader and Mollema research hunts for successful sign-ins whose CA results look inconsistent with intended enforcement. A policy can also log an interrupt or failure before a later authentication step completes, so check the full sequence before calling it a bypass.
• ID Protection risk detections anomalousToken, attackerinTheMiddle, and attemptedPrtAccess. Anomalous token detections produce false positives at low and medium risk.
• Device code sign-ins by the Authentication Broker (app ID 29d9ed98-a469-4536-ade2-f981bc1d605e), which Elastic's prebuilt rule flags.
• Add device audit events. Elastic flags phishing-kit registrations that use OS build 10.0.19045.2006 and a DESKTOP- name prefix.
• The Unified Audit Log (UAL) and mailbox audit records, which show what a session actually touched.

A successful sign-in doesn't prove mailbox access, so correlate sign-ins with workload audit records before concluding what an attacker reached.

Okta System Log Signals

The equivalent Okta events cover factor resets, session roaming, and policy changes:

• user.mfa.factor.reset_all followed by a sign-in from a new device, and security.session.detect_client_roaming, both from Okta's detection guidance.
• policy.auth_reevaluate.fail from ITP session protection.
• Multiple device token hashes for a single Okta session, an Elastic rule mapped to MITRE ATT&CK techniques T1539 and T1550.004.
• Policy modification or deletion, covered by a Sigma rule, plus a query on eventType sw "system.mfa.factor", because Okta says no System Log event records a factor downgrade.

Retention decides whether any of this is usable: Microsoft keeps sign-in and audit logs for seven days on Entra ID Free and 30 days on P1 and P2, so longer investigations depend on routing them to Log Analytics, a storage account, or a cloud SIEM. The same events feed identity threat detection programs, and they are what to test any ITDR tool against.

How to Harden Conditional Access

Where to start depends on which gaps your tenant has today:

1. If you haven't confirmed legacy authentication is gone, filter sign-in logs by clientAppUsed and by an AuthenticationProtocol of ropc, a value the SigninLogs table records, before enforcing the block. Check the UAL for legacy sign-ins too.
2. If your admins aren't yet on phishing-resistant MFA, start there and remove phishable fallback methods for those accounts before expanding to everyone.
3. If device compliance is your main boundary, set Intune's "Mark devices with no compliance policy assigned as" setting to Not compliant, which Microsoft advises for Conditional Access deployments, lock down enrollment, and alert on devices that reach compliance soon after registration.
4. If device code flow is in your threat model, block it wherever it isn't required and keep detection on Authentication Broker device code grants, because authentication controls, including phishing-resistant MFA, don't prevent this attack.
5. If your workforce is largely on unmanaged personal devices, accept the position in the NCSC's BYOD guidance, reviewed in 2025, that a BYOD deployment protects corporate data less effectively than managed devices, and lean on browser-only access, shorter sessions, and download restrictions.
6. If you can't yet define identity detection use cases, tighten just-in-time access and boundaries first, so detections have a smaller, clearer surface to watch.

Investigating What Policy Already Approved

These attacks tend to end in an authenticated session that looks legitimate in isolation, whether it came from a coverage gap, a stolen token, or a manipulated recovery process. Policy engines aren't built to tell whether that session is what it appears to be. An anomalousToken detection, a factor reset, or a new device registration is ambiguous on its own.

Resolving it means correlating the identity event with endpoint telemetry and the user's device history. It also means checking whether a help-desk ticket exists, whether an exclusion was ever approved, and what the session did next, which is where identity-based lateral movement shows up. Alerts that wait on manual correlation often sit in queues or get closed as benign without a recorded reason.

Daylight is a MASS company, meaning it offers managed agentic security services for Security Operations. Its managed detection and response (MDR) service investigates identity alerts from tools such as Okta and Microsoft Entra ID Protection against identity, device, and organizational context, with security experts taking over complex cases.

Frequently Asked Questions About Conditional Access

Does Continuous Access Evaluation Stop a Stolen Token From Working?

Only partially. Without CAE, Microsoft re-evaluates policy when a client refreshes its access token, by default every hour. CAE sessions get tokens valid for up to 28 hours, and resources that support CAE reject them after critical events such as account disablement, password reset, or admin token revocation, with up to 15 minutes of propagation latency. Policy and group membership changes can take up to a day. Research from Insinuator published in September 2026 adds that resources don't require CAE tokens, so an attacker holding a refresh token that isn't device-bound can request a plain, non-CAE access token. CAE also doesn't support guest accounts for instant revocation.

Do Role-Scoped Policies Protect PIM-Eligible Admins?

Not until the role is activated in Privileged Identity Management (PIM). Before activation, an eligible user isn't covered by a role-scoped policy, so their everyday sessions fall under whatever policies apply to ordinary users. Since May 2026, Entra lets you require reauthentication at role activation through Conditional Access to force a fresh policy check when the role becomes active.

Can I Trust Microsoft-Managed Policies to Stay in Place?

Audit them like your own. Microsoft normally creates managed policies in report-only mode and enables them no sooner than 30 days after introduction, though it can move faster in some cases. In an April 2026 community thread on Microsoft Q&A, a moderator reported that a backend change had removed the managed policy requiring phishing-resistant MFA for admins without a Message Center notice. Check that each managed policy still exists and still covers what your tenant needs. Entra Backup and Recovery, on by default since July 2026, keeps seven days of daily backups of CA policies and named locations on P1 and P2.

How Should Conditional Access Handle AI Agent Identities?

Narrowly, for now. In Entra, agent identities support only the Block access control, and agent users, in Preview, support blocking or requiring a compliant device. Microsoft's managed policy that blocks high-risk agents is also in Preview. On Okta, Agent SSO, generally available since August 24, 2026, issues short-lived tokens to agents and moves their authorization to the identity provider, but it applies only to agents that support Cross App Access. Confirm what each deployment supports, and rely on monitoring where policy doesn't reach.

Are Trusted Network Locations Safe to Exempt From MFA?

They're a common audit finding. IPs are dynamic and geolocation isn't guaranteed, so location alone shouldn't decide access. Microsoft's Octo Tempest guidance tells defenders to scrutinize trusted locations and exclusions. Every exemption is a path the policy no longer challenges.