Azure Conditional Access: The Minimum Policies Every Organization Needs
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
A newly created Microsoft 365 or Entra ID tenant with Security Defaults disabled and no Conditional Access policies configured allows any credential, from any device, from any country, at any time, to access any application. This configuration is the baseline state of many organizations that have moved to Microsoft 365 without a security-specific configuration review.
The seven policies below represent the minimum baseline. Each one corresponds to a specific attack technique with confirmed active exploitation. The policies are listed in order of risk reduction per implementation effort: do the first three before anything else.
Policy 1: Require MFA for All Administrators (Highest Priority)
What it blocks: Password spray and credential stuffing attacks targeting admin accounts. An attacker with a valid Global Admin password gets blocked without the second factor.
Configuration:
- Navigate to Entra ID > Security > Conditional Access > New Policy
- Name:
CA001 - Require MFA for Administrators - Assignments > Users: Select directory roles → Global Administrator, Security Administrator, Exchange Administrator, SharePoint Administrator, Conditional Access Administrator, Authentication Administrator, Privileged Role Administrator (at minimum)
- Assignments > Cloud apps: All cloud apps
- Access controls > Grant: Require multi-factor authentication
- Enable policy: On
Critical misconfiguration to avoid: Do not exclude your break-glass emergency access accounts from this policy: include them with a separate, hardware-token MFA method. Emergency access accounts excluded from MFA are the most common admin account backdoor left by attackers after initial compromise.
Licensing requirement: Entra ID P1 (included in Microsoft 365 Business Premium, E3, E5)
Policy 2: Block Legacy Authentication (Highest Priority)
What it blocks: Password spray attacks using legacy protocols. SMTP AUTH, POP3, IMAP4, Exchange ActiveSync, and Basic authentication all bypass modern MFA because they cannot complete an MFA challenge. 97% of password spray attacks in 2025 used legacy authentication.
Configuration:
- Name:
CA002 - Block Legacy Authentication - Assignments > Users: All users
- Assignments > Conditions > Client apps: Select: Exchange ActiveSync clients, Other clients (this covers SMTP AUTH, POP3, IMAP4, Basic auth)
- Access controls > Grant: Block access
- Enable policy: On
Before enabling: Run Entra ID sign-in logs filtered by 'Client App = Exchange ActiveSync' and 'Client App = Other' for 14 days. Any legitimate app using legacy auth appears here: these must be migrated to modern authentication before you enable the block. Common offenders: older MFP/copier email scanning, legacy CRM systems, and older Outlook versions configured with Basic auth.
Licensing requirement: Entra ID P1
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Policy 3: Require MFA for All Users (High Priority)
What it blocks: Credential stuffing attacks on standard user accounts. This is the single highest-coverage policy for protecting against account compromise from credential leak databases.
Configuration:
- Name:
CA003 - Require MFA for All Users - Assignments > Users: All users (with explicit exclusion list for break-glass accounts and service accounts that cannot support MFA)
- Assignments > Cloud apps: All cloud apps
- Access controls > Grant: Require multi-factor authentication
- Enable policy: Report-only mode first for 14 days, then On
Report-only mode is critical: Enable this policy in Report-only mode for 14 days before enabling it. Review sign-in logs for blocked authentications that would have occurred. Any legitimate service principal, shared account, or automation that would be blocked must be excluded explicitly before you turn this on.
Licensing requirement: Entra ID P1
Policies 4-7: Additional Baseline Controls
Policy 4: Block High-Risk Sign-Ins (requires Entra ID P2)
Entra ID P2 includes Identity Protection, which scores each sign-in for risk based on leaked credential databases, atypical behavior, and known-malicious IP addresses. This policy blocks sign-ins that exceed a high-risk threshold.
- Name:
CA004 - Block High Risk Sign-Ins - Assignments > Users: All users
- Conditions > Sign-in risk: High
- Access controls > Grant: Block access
Alternatively, if P2 is not licensed, set Conditions > Sign-in risk to High and Grant: Require MFA (users with leaked credentials must re-authenticate, giving them a chance to recover their account while blocking the attacker who does not have their phone).
Policy 5: Require Compliant or Hybrid-Joined Devices for High-Sensitivity Applications
For applications containing sensitive data (SharePoint sites with HR data, financial systems, admin portals), require that the device is either Intune-compliant or Hybrid Azure AD joined. This prevents access from personal, unmanaged devices.
- Name:
CA005 - Require Compliant Device for Sensitive Apps - Assignments > Cloud apps: Select specific sensitive applications
- Access controls > Grant: Require device to be marked as compliant OR Require Hybrid Azure AD joined device (choose one or combine with OR)
Policy 6: Restrict Admin Portal Access to Trusted Locations or Compliant Devices
This policy limits access to the Microsoft 365 admin centers, Entra ID portal, and Azure portal to known-good network locations or managed devices, preventing an attacker with stolen credentials from accessing administrative interfaces from their own infrastructure.
- Name:
CA006 - Restrict Admin Portals - Assignments > Cloud apps: Microsoft Admin Portals (Microsoft Entra admin center, Microsoft 365 admin center, Azure portal)
- Access controls > Grant: Require multi-factor authentication AND Require compliant device (use AND, not OR)
Policy 7: Require MFA for Azure Management
Azure subscription management via the Azure portal, Azure CLI, and Azure PowerShell requires MFA regardless of what other policies cover. A credential compromise targeting Azure management APIs can exfiltrate infrastructure, export virtual machine disks, and access Key Vault secrets.
- Name:
CA007 - Require MFA for Azure Management - Assignments > Cloud apps: Microsoft Azure Management
- Assignments > Users: All users
- Access controls > Grant: Require multi-factor authentication
What to Do Before Entra ID P1 Is Licensed
Entra ID P1 is required for Conditional Access. If your organization is on a license tier that does not include P1 (Microsoft 365 Business Basic or E1 without add-ons), use Security Defaults as an interim measure.
Security Defaults are free, built into every Entra ID tenant, and provide:
- MFA requirement for all administrators on every sign-in
- MFA registration required for all users within 14 days
- Legacy authentication blocked for all users
- MFA required for Azure management operations
Enable Security Defaults: Entra ID > Overview > Properties > Manage security defaults > Enable.
Security Defaults vs Conditional Access: Security Defaults are all-or-nothing and cannot be customized. They cover the most critical policies (admin MFA, legacy auth block) but cannot be scoped to specific apps, exclude specific users, or incorporate risk-based signals. They are the right starting point for organizations without P1; replace them with Conditional Access when licensing allows.
The bottom line
A minimum Conditional Access baseline requires seven policies in priority order: MFA for administrators, legacy authentication blocking, MFA for all users, high-risk sign-in blocking, compliant device requirement for sensitive applications, admin portal access restriction, and MFA for Azure management. Implement the first three before anything else: they stop the attacks responsible for the majority of Entra ID account compromises. Use Security Defaults as a free interim baseline if Entra ID P1 is not yet licensed. Enable all new policies in Report-only mode for 14 days before turning them on.
Frequently asked questions
What Conditional Access policies should every organization have?
At minimum: require MFA for all administrators, block legacy authentication (SMTP AUTH, IMAP4, POP3, Basic auth), and require MFA for all users. These three policies stop the attack patterns responsible for the majority of Microsoft 365 and Entra ID compromises. Enable them in Report-only mode for 14 days before turning them on to identify legitimate traffic that would be affected.
What is the free alternative to Azure Conditional Access?
Security Defaults are free and built into every Entra ID tenant. They enforce MFA for administrators, require MFA registration for all users, and block legacy authentication: covering the most critical policies without requiring Entra ID P1 licensing. They cannot be customized or scoped. Use them as an interim baseline until Conditional Access is licensed.
How do I block legacy authentication in Azure Conditional Access?
Create a Conditional Access policy with: Users = All Users, Cloud Apps = All Cloud Apps, Conditions = Client Apps = Exchange ActiveSync clients and Other clients (the legacy authentication protocols), Access Controls = Block. This blocks legacy authentication protocols like IMAP, POP3, SMTP AUTH, and older Office clients that cannot perform modern MFA. Before enabling in production, run the policy in Report-Only mode for 14 days and review the sign-in logs for any legitimate legacy auth dependencies. Common exceptions needed: some multifunction printers and line-of-business applications that cannot be upgraded.
What Entra ID license do I need for Conditional Access?
Conditional Access requires Entra ID P1, which is included in Microsoft 365 Business Premium, E3, and E5 plans. Entra ID P1 standalone is approximately $6 per user per month. Risk-based Conditional Access policies (those that use sign-in risk or user risk as conditions) require Entra ID P2, included in E5 or available standalone at approximately $9 per user per month. Organizations on M365 E3 get Conditional Access through their existing license; those on M365 Business Standard or Business Basic need to upgrade or add P1 licensing.
How do I handle Conditional Access policy conflicts when policies contradict each other?
Conditional Access policies apply with an implicit OR across policies: if any policy grants access, access is granted; if any policy blocks access, the block takes precedence. When a user matches both a grant policy and a block policy, the block wins. To avoid conflicts: name policies consistently with a prefix indicating scope (CA001-Block Legacy Auth, CA002-Require MFA All Users), document the intended interaction for overlapping policies, use the Conditional Access What If tool (in Entra ID portal) to test how policies apply to specific users and conditions before enforcement.
How do I handle Conditional Access MFA requirements for shared accounts and service accounts that cannot complete MFA?
Shared accounts and service accounts that cannot complete interactive MFA challenges are among the most common reasons organizations create exceptions to their MFA Conditional Access policies. The correct approach is not to create blanket exclusions for these accounts: it is to eliminate the accounts that require exclusions or to use authentication mechanisms that do not require interactive MFA. For service accounts used by automated processes and applications, replace interactive authentication with managed identities (for Azure resources), workload identity federation, or service principals authenticated with certificates rather than passwords. These authentication methods do not go through Conditional Access interactive sign-in flows and do not need MFA exceptions. For shared human accounts (shared mailboxes, shared login accounts for specific applications), the security goal is to eliminate shared accounts rather than to accommodate them: shared accounts cannot be attributed to individual users, which makes forensic investigation and access review impossible. Where shared accounts cannot be eliminated immediately, restrict them to specific named locations (your office IP range) via a Conditional Access location-based policy rather than excluding them from MFA entirely. For break-glass emergency access accounts, register hardware FIDO2 tokens as the MFA method rather than authenticator apps: these provide the MFA assurance level without requiring an active smartphone. Document every Conditional Access exclusion in a register with the justification, the account owner, and a review date so exclusions are assessed regularly rather than accumulating indefinitely.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.