Entra ID: Conditional Access Basic Policies

Entra ID (formerly Azure Active Directory) Conditional Access is the backbone of identity-driven security in the cloud. It allows you to apply granular access controls based on specific conditions, such as user location, device state, the application being accessed, and the detected risk level. This isn’t an add-on feature, but a fundamental element for protecting resources and ensuring compliance. Read also: GDPR System Admin: Role, Obligations & Compliance

These policies are crucial for mitigating attacks like credential stuffing, phishing, and replay attacks, which exploit weak or stolen credentials. Implementing a set of basic policies is the first step for any organization using Entra ID, regardless of size or industry. It helps you strengthen security without compromising usability for legitimate users, applying controls only when and where necessary.

Entra ID: Conditional Access in 60 seconds

To quickly configure and manage Conditional Access policies in Entra ID, here are the essential PowerShell commands using the Microsoft.Graph module:

# Install the Microsoft.Graph module (if not already present)
Install-Module -Name Microsoft.Graph -Scope CurrentUser

# Connect to Microsoft Graph with necessary permissions to read policies
Connect-MgGraph -Scopes Policy.Read.All

# List existing Conditional Access policies and their state
Get-MgIdentityConditionalAccessPolicy | Select DisplayName, State

# View sign-in logs with Conditional Access failures (last 20)
Get-MgAuditLogSignIn -Filter "conditionalAccessStatus eq 'failure'" -Top 20

# Disconnect from the Graph session
Disconnect-MgGraph

Reference versions: Microsoft Entra ID (current stable version, consulted November 2026) · documentation consulted November 2026

What is Conditional Access and what license is needed

Conditional Access is the Entra ID policy engine that enables you to implement “if-then” rules. For example: if a user attempts to sign in from an unknown location, then require multi-factor authentication (MFA). This shifts the focus from simple password verification to real-time risk assessment for every sign-in attempt. Policies are applied before the user accesses the resource, adding a proactive layer of protection. Read also: Network Microsegmentation: VLANs & Firewalls in Production

To use Conditional Access, an Entra ID P1 or P2 license is required. P1 offers basic functionalities, while P2 adds advanced features like integration with Identity Protection for real-time risk detection (e.g., compromised credentials, sign-ins from anomalous IPs) and automated responses. Without one of these licenses, the functionality will not be available or will be limited to a subset of predefined policies.

Prerequisites

Before implementing any Conditional Access policy, ensure you have:

• Entra ID P1 or P2 license: Verify that all users to whom policies will apply have the appropriate license.
• MFA enabled and configured: Users must have registered at least one MFA method (e.g., Microsoft Authenticator, SMS, calls) to satisfy MFA policy requirements.
• Emergency accounts: Identify and create at least two emergency accounts (break-glass accounts) with high privileges, excluded from any Conditional Access policy. These accounts are crucial for regaining access to the tenant in case of incorrect policy configuration.
• Security groups: Use Entra ID security groups to assign policies. This simplifies management and reduces the risk of errors compared to assigning to individual users. Create groups for administrators, standard users, users with special needs, etc.
• Planning and communication: Inform users about new policies and how they might affect their access. Clear communication reduces resistance and support tickets.

1. First rule: exclude emergency accounts

This is the most critical and often overlooked step. Emergency accounts, or ‘break-glass accounts’, are highly privileged accounts (like Global Administrator) used only in emergency situations, for example, if all Conditional Access policies inadvertently block access for all administrators. These accounts must be excluded from all Conditional Access policies. Failing to do so could lead to a situation where no one can access the tenant to correct a configuration error, resulting in a total lockout.

Protection for these accounts relies on procedural and physical controls (e.g., credentials stored in a safe, intensive access monitoring), rather than Conditional Access policies that might block them. Microsoft recommends configuring at least two such accounts. Their activity must be constantly monitored via audit logs and specific alerts to detect any misuse.

2. Mandatory MFA for administrators

This is the most important policy for the security of your tenant. Accounts with administrative roles (Global Administrator, Application Administrator, Exchange Administrator, SharePoint Administrator, etc.) are primary targets for attackers. Compromising one of these accounts can lead to total control of your environment. Requiring MFA for administrators drastically reduces the risk of unauthorized access, even if the password is stolen.

How to configure it:

1. Navigate to Entra ID > Protection > Conditional Access > New policy.
2. Assign a meaningful name, for example, “MFA – Administrators”.
3. Under Users or workload identities > Include, select Directory roles and choose all relevant administrative roles (e.g., Global Administrator, Security Administrator, Cloud Application Administrator, etc.).
4. Under Access controls > Grant, select Require multi-factor authentication.
5. Set the policy to On (after testing it in report-only mode, as we’ll see later).

This policy is a standard requirement for compliance with regulations like NIS2 (Art. 21) and ISO 27001:2022, which emphasize the protection of privileged accounts. Read also: NIS2 Compliance: Obligations for EU Businesses

3. Block legacy authentication

Legacy authentication refers to protocols like POP3, IMAP, SMTP, MAPI, and other APIs that do not support modern authentication and, consequently, MFA. These protocols are a common attack vector, as they allow attackers to attempt sign-ins with stolen credentials without facing the MFA challenge. Disabling legacy authentication is a key security recommendation from Microsoft and CISA.

How to configure it:

1. Create a new Conditional Access policy, for example, “Block Legacy Authentication”.
2. Under Users or workload identities > Include, select All users (or a specific group if you want to apply it gradually).
3. Under Cloud apps or actions > Include, select All cloud apps.
4. Under Conditions > Client apps, select Yes and then check Exchange ActiveSync clients and Other clients.
5. Under Access controls > Block access.
6. Set the policy to On.

A typical output when listing policy status after creation:

DisplayName                           State
----------                           -----
MFA - Administrators                 Enabled
Block Legacy Authentication          Enabled

Caution: Before enabling this policy for all users, verify the use of legacy clients in your environment. Tools like Outlook 2010 or some third-party applications might stop working. Monitor sign-in logs to identify users and apps that use them.

4. MFA for all users, with the right exceptions

After protecting administrators and blocking legacy protocols, the next step is to extend MFA to all users. This significantly elevates the overall security posture of the tenant. However, applying MFA indiscriminately can create friction for users. This is where Conditional Access conditions become useful for creating exceptions based on specific scenarios.

How to configure it:

1. Create a new policy, for example, “MFA – All Users”.
2. Under Users or workload identities > Include, select All users. Under Exclude, add emergency accounts and, if necessary, specific groups of users who should not use MFA (e.g., service accounts, but with great caution).
3. Under Cloud apps or actions > Include, select All cloud apps.
4. Under Access controls > Grant, select Require multi-factor authentication.
5. Under Conditions, you can add exceptions:

• Locations: Exclude network locations defined as trusted (e.g., the corporate network with known public IPs). This allows users to bypass MFA when in the office. Read also: Zabbix Agent 2: Installation, Configuration, and Plugins
• Devices: Require the device to be “Compliant” or “Hybrid Azure AD joined” to bypass MFA, encouraging the use of managed and secure devices.

1. Set the policy to Report-only initially, then enable it.

5. Use report-only mode before enabling

Every new Conditional Access policy, or significant modification to an existing one, should first be implemented in Report-only mode. This mode allows you to simulate the policy’s application without it actually affecting user access. The results are recorded in Entra ID sign-in logs, allowing you to see which users or applications would have been blocked or would have required MFA.

Why it’s crucial: It prevents unexpected disruptions. A configuration error can block access for entire categories of users or critical applications. Report-only mode gives you the opportunity to identify and correct these issues before they have a real impact on production. It is an essential operational practice for any sysadmin or security engineer.

How to enable it: When creating or modifying a policy, in the Enable policy pane, select Report-only instead of On.

6. Read sign-in logs to understand what was blocked

Once policies are in Report-only mode (or even after activation), it is crucial to monitor sign-in logs to understand their impact. Entra ID sign-in logs provide valuable details on every sign-in attempt, including the results of applied Conditional Access policies.

To access the logs:

1. Navigate to Entra ID > Monitoring & health > Sign-in logs.
2. Use filters to narrow down the search. The most useful filters include:

• Conditional Access status: “Failure” or “Report-only (success/failure)”.
• User: To investigate specific user issues.
• Cloud app: To see the impact on a specific application.

Look for events where the “Conditional Access status” indicates a failure or block. This will tell you exactly which policy caused the block and why. Analyzing these logs helps you refine policies and resolve access issues for users.

Using PowerShell to filter specific failure events is also an efficient approach:

# Connect to Microsoft Graph (if not already connected)
Connect-MgGraph -Scopes AuditLog.Read.All

# View sign-in logs with Conditional Access failures (last 20)
Get-MgAuditLogSignIn -Filter "conditionalAccessStatus eq 'failure'" -Top 20 | Format-Table CreatedDateTime, UserDisplayName, AppDisplayName, ConditionalAccessStatus

This command will give you a quick overview of blocked sign-ins, essential for troubleshooting.

7. List policies from PowerShell

Managing Conditional Access policies through the Azure portal GUI is intuitive, but for audits, automation, or simply a quick overview, PowerShell offers a powerful alternative. Using the Microsoft.Graph module, you can list all policies and view their status, which is useful for documentation or quickly verifying configurations.

To list policies, ensure you have Policy.Read.All permissions and are connected to Microsoft Graph:

# Connect to Microsoft Graph with necessary permissions
Connect-MgGraph -Scopes Policy.Read.All

# List all Conditional Access policies
Get-MgIdentityConditionalAccessPolicy | Select DisplayName, State, GrantControls, Conditions

The output of Get-MgIdentityConditionalAccessPolicy will show the policy name, its state (Enabled, Disabled, ReportOnly), and details about access controls (GrantControls) and conditions (Conditions). This is particularly useful for quickly identifying active or report-only policies and for getting an overview of their main rules. Read also: Docker Disk Space: Prune, Logs, and Unused Images

Common Errors and Troubleshooting

Error or exact message	Cause	Solution
“Access blocked by Conditional Access policy”	User or condition not met by an active policy.	Check sign-in logs to identify the policy and conditions. Modify the policy or exclude the user/group.
“MFA required but not configured”	User has not registered MFA methods.	Ask the user to register MFA via aka.ms/mfasetup.
User cannot access Outlook desktop	Legacy authentication block active.	Check if the user is using an outdated client. Enable modern authentication on the client or temporarily exclude the user from the policy (with caution).
Administrator locked out after a new policy	Emergency accounts not excluded or policy too restrictive.	Use an emergency account to sign in and disable/modify the policy.
Unexpected policy applied (or not applied)	Policy order, overlapping conditions, or incorrect groups.	Review processing order (it’s not sequential like firewalls, but all matching policies are evaluated). Check user/group inclusions/exclusions.

Frequently Asked Questions

Is the order of Conditional Access policies important?

No, unlike traditional firewalls, the processing order of Conditional Access policies in Entra ID is not sequential. All policies applicable to a given user, app, and condition are evaluated simultaneously. If even one policy requires a control (e.g., MFA) and one policy blocks access, the latter prevails. It is important to design policies so they do not overlap contradictorily.

Can I exclude a specific user from a policy?

Yes, every Conditional Access policy has an “Exclude” section where you can specify users or groups. This is fundamental for emergency accounts or for testing policies on a subset of users before extending them. Always use groups for exclusions to facilitate management and reduce manual errors.

What is the difference between Entra ID P1 and P2 for Conditional Access?

Entra ID P1 offers basic Conditional Access functionalities, allowing you to create policies based on users, groups, apps, locations, and device state. Entra ID P2 includes all P1 features and adds integration with Identity Protection, which allows incorporating user risk and sign-in risk as conditions in policies. This enables dynamic responses based on the probability of identity compromise.

How can I test a new policy without blocking users?

“Report-only” mode is the solution. When creating or modifying a policy, set its state to “Report-only” instead of “On”. This will cause the policy to be evaluated and its results recorded in the sign-in logs, but without actually applying the controls. You can then analyze the logs to see the potential impact and refine the policy before enabling it for everyone.

Is it possible to apply Conditional Access policies to guest or external users?

Yes, Conditional Access policies can also be applied to guest users (B2B) who access your tenant. This is crucial for protecting resources shared with external partners or consultants. You can include guest users in groups to which policies apply or create specific policies for them, ensuring that even external access complies with your security standards.

Conclusions with Operational Takeaways

Implementing Conditional Access in Entra ID is not an option, but a security imperative. By starting with basic policies—excluding emergency accounts, mandatory MFA for administrators, blocking legacy authentication, and MFA for all users with smart exceptions—you can build a solid foundation for protecting your tenant. Always remember to use “Report-only” mode to test the impact of your policies and constantly monitor sign-in logs. These steps will allow you to strengthen your security posture, reduce the attack surface, and ensure compliance with current regulations, proactively and scalably protecting your identities in the cloud.

Sources

• What is Conditional Access in Microsoft Entra ID?
• Plan for emergency access accounts in Microsoft Entra ID

Updated: November 2026