Conditional Access: Zero Trust enforcement in Azure AD

Conditional Access is a policy engine built into Microsoft Entra ID (formerly Azure AD) that enforces Zero Trust principles by evaluating a set of signals before granting or blocking access to resources. Every access request triggers the engine, which assesses conditions including user identity, device compliance state, network location, application sensitivity, and real-time risk scores produced by Microsoft Entra ID Protection. Based on these signals, policies either grant access, require step-up authentication such as MFA, restrict the session to limited permissions, or block the request entirely. This model replaces legacy perimeter-based security. It operates on the principle that no user or device is implicitly trusted, regardless of network location. In a hybrid or fully cloud environment, Conditional Access acts as the primary enforcement plane for identity-driven access control. It integrates with Intune for device compliance signals, with Defender for Endpoint for device risk, and with Microsoft Purview for session-level data protection through App Control policies. Understanding its policy evaluation logic, including grant controls versus session controls, is essential for any practitioner securing Microsoft 365 or Azure workloads.

Detecting misconfigurations or abuse of Conditional Access policies requires monitoring the Microsoft Entra ID sign-in logs and audit logs. Sign-in logs record the applied Conditional Access policies for every authentication event, along with the result: success, failure, or interrupted. The 'ConditionalAccessStatus' field in these logs indicates whether policies were satisfied, not applied, or blocked the request. Security teams should alert on authentication events where Conditional Access policies show a result of 'notApplied' for sensitive applications, which may indicate policy gaps or bypasses via legacy authentication protocols. Legacy authentication attempts bypass modern policy evaluation entirely and should be tracked using the 'clientAppUsed' field. In Microsoft Sentinel, the SigninLogs table exposes the 'ConditionalAccessPolicies' array, allowing granular KQL queries per policy ID and outcome. Audit logs under the 'Policy' category record every creation, modification, or deletion of Conditional Access policies. Sudden modifications to named locations, trusted IP ranges, or exclusion groups are high-priority signals. Monitoring changes to the 'Exclude' clause of policies is critical, as attackers with privileged access may add compromised accounts to exclusion groups to silently bypass enforcement.

Red Team operators targeting Entra ID environments focus on identifying and abusing gaps in Conditional Access policy coverage. A common attack path is legacy authentication exploitation: protocols such as IMAP, POP3, SMTP AUTH, and Basic Auth against Exchange Online bypass modern Conditional Access evaluation entirely. Tools like MailSniper or custom Python scripts can spray credentials over these legacy endpoints. Another vector is device compliance bypass: if a policy grants access only to compliant devices, obtaining a Primary Refresh Token (PRT) from a legitimate compliant device allows token replay from an attacker-controlled machine using tools like ROADtoken or AADInternals. Named location exclusions are another target; if trusted IP ranges are overly broad or misconfigured, attackers on compromised infrastructure within those ranges receive elevated trust. From a hardening perspective, defenders should block legacy authentication via dedicated Conditional Access policies, enforce continuous access evaluation (CAE) to revoke tokens in near-real-time, apply sign-in frequency controls to limit long-lived sessions, and audit exclusion group membership regularly. The 'What If' tool in Entra ID allows policy simulation to identify coverage blind spots before attackers do.