Skip to main content
← All controls
AC-2 / AC-3 / IA-2 / IA-8 NIST SP 800-53 Rev 5

Conditional Access baseline policies

Demonstrate that Conditional Access baseline policies are defined, enforced, and configured to block or challenge high-risk authentication attempts based on user, device, location, and application risk signals.

Description

What this control does

Conditional Access baseline policies are pre-configured rulesets in identity platforms (primarily Microsoft Entra ID/Azure AD) that enforce authentication and authorization requirements based on user attributes, device state, location, risk level, and application sensitivity. These policies act as guardrails by automatically blocking or requiring additional verification (e.g., multi-factor authentication, compliant device) before granting access to cloud resources. They are foundational to Zero Trust architectures, enabling organizations to dynamically adapt access controls to real-time risk signals rather than relying solely on perimeter defenses.

Control objective

What auditing this proves

Demonstrate that Conditional Access baseline policies are defined, enforced, and configured to block or challenge high-risk authentication attempts based on user, device, location, and application risk signals.

Associated risks

Risks this control addresses

  • Unauthorized access from compromised credentials originating from anomalous geographic locations or suspicious IP addresses
  • Lateral movement by attackers using stolen credentials from unmanaged or non-compliant devices
  • Credential stuffing or brute-force attacks bypassing authentication due to lack of adaptive MFA enforcement
  • Privileged account compromise when administrators authenticate from untrusted networks without additional verification
  • Data exfiltration via legacy authentication protocols that bypass modern authentication and conditional policies
  • Session hijacking or token replay attacks when session controls and sign-in frequency policies are absent
  • Insider threats leveraging personal or unmanaged devices to access sensitive applications without device compliance checks

Testing procedure

How an auditor verifies this control

  1. Obtain and inventory all active Conditional Access policies from the identity platform (e.g., Microsoft Entra ID portal, API export, or PowerShell dump).
  2. Review each baseline policy configuration to confirm scope, including targeted users, groups, roles, applications, and exclusions.
  3. Verify that policies enforce MFA or block access for high-risk sign-ins, legacy authentication protocols, and access from unmanaged devices.
  4. Examine sign-in logs for the past 90 days to identify authentication attempts evaluated by Conditional Access policies, noting allow, block, and challenge outcomes.
  5. Select a sample of 10-15 recent sign-in events flagged as high-risk or anomalous and trace whether Conditional Access policies correctly blocked or challenged the session.
  6. Test a subset of policies by simulating sign-in scenarios from different device types, locations, and user risk levels using the policy simulation tool or controlled test accounts.
  7. Review change logs and approval records for Conditional Access policy modifications to confirm adherence to change management procedures.
  8. Interview identity and access management administrators to validate understanding of policy intent, monitoring responsibilities, and incident response workflows for policy violations.
Evidence required Collect screenshots or JSON exports of all active Conditional Access policies showing conditions, controls, and enforcement actions. Obtain sign-in logs (filtered by Conditional Access policy results) for the audit period, including event timestamps, user identities, source IPs, device compliance status, and policy decisions (block, allow, challenge). Retrieve change management tickets or approval records for policy creation, modification, or deletion within the past 12 months.
Pass criteria All baseline Conditional Access policies are actively enforced, correctly scoped to appropriate user populations and applications, successfully block or challenge high-risk authentication attempts as evidenced by sign-in logs, and policy changes follow documented approval workflows.

Where this control is tested

Audit programs including this control