Conditional Access in Entra ID: Policies for SMEs

What Is Conditional Access?

Without Conditional Access, Microsoft Entra ID makes a simple binary decision at every sign-in: are the username and password correct? If yes, the user gains access. If no, access is denied. This binary logic ignores the entire context of the sign-in: from which device does the access originate? From which country? At what time? To which application? Are there signs of a compromised account?

Conditional Access adds a context-aware layer to this binary decision. Instead of "access yes or no," the question becomes: "access under which conditions?" The answer might be: "access permitted, but only with MFA," or "access permitted, but only from a compliant device," or "access denied because the sign-in comes from an unusual country."

Technically, Conditional Access functions as a policy engine sitting between authentication (Who are you?) and authorization (What are you allowed to do?). The concept fits perfectly into a zero trust architecture where every access is individually verified. Each policy consists of three components:

Assignments (Who and What):

• Users and groups (or all users)
• Cloud apps or actions (e.g., all apps, Office 365 only, Azure Management only)
• Conditions (location, device platform, sign-in risk, client app)

Access Controls (What Happens):

• Grant: allow access with requirements (MFA, compliant device, domain-joined)
• Block: deny access entirely
• Session: restricted access (e.g., no downloads, time-limited)

Activation Status:

• Report-Only: policy is evaluated but not enforced (logging only)
• On: policy is enforced
• Off: policy is disabled

Prerequisites and Licenses

Conditional Access requires at least an Entra ID P1 license, which is included in Microsoft 365 Business Premium, E3 and E5. For risk-based policies (sign-in risk, user risk), you need Entra ID P2, which is included in E5 or available as an add-on to E3.

Before you create the first policy, clarify the following prerequisites:

• Check licensing: Every user affected by Conditional Access needs a P1 license. This also applies to guest users (the licensing of the inviting tenant applies here).
• Create break glass accounts: At least two emergency access accounts with Global Admin rights, a long password, no MFA, excluded from all Conditional Access policies. These accounts are your lifeline if a faulty policy locks out all regular admins.
• Configure named locations: Set up trusted locations (office IP addresses) and blocked countries as named locations in Entra ID.
• Prepare MFA registration: Users must have registered their MFA method before an MFA policy takes effect. Plan a registration campaign with adequate lead time.

The Six Core Policies

The following six policies form a solid foundation that addresses the most important attack vectors without unnecessarily impeding daily work. The order corresponds to the recommended introduction sequence.

Policy 1: MFA for All Users

This policy is the baseline: every user must authenticate with a second factor at every sign-in to a cloud app. This sounds radical but is less disruptive in practice than feared, because Entra ID remembers compliant devices and trusted locations and does not prompt for MFA at every login (token lifetime, primary refresh token).

Configuration:

• Assignments: all users, all cloud apps
• Exceptions: break glass accounts, service accounts (if necessary, but minimize)
• Grant: require multi-factor authentication
• Status: report-only initially, switch to on after 2 weeks of evaluation

Why not Security Defaults? Security Defaults offer a simplified MFA variant that is available free of charge. However, they allow no exceptions, no combination with other policies and no granular control. As soon as you activate a single Conditional Access policy, Security Defaults are automatically disabled. Therefore, start directly with Conditional Access instead of taking the detour via Security Defaults.

Policy 2: Block Legacy Authentication

Legacy authentication protocols (POP3, IMAP, SMTP AUTH, ActiveSync with basic auth) do not support MFA. As long as they are active, an attacker with stolen credentials can completely bypass the MFA requirement from policy 1 by using a legacy protocol.

Configuration:

• Assignments: all users, all cloud apps
• Conditions: Client Apps = "Other clients" and "Exchange ActiveSync"
• Exceptions: break glass accounts (and possibly a dedicated service account for multifunction printers if they require SMTP AUTH)
• Grant: block access
• Status: report-only, then analyze logs (which users/apps still use legacy auth?), migrate remaining applications, then on

Check before activation: Analyze the sign-in logs from the last 30 days for legacy auth usage. Filter: Client App = "Other clients." Common candidates are older scanners/printers with scan-to-email, old Outlook versions, third-party CRM systems and mobile email apps. Migrate these applications to Modern Authentication before enforcing the policy.

Policy 3: Elevated Requirements for Administrators

Administrator accounts are high-value targets. A separate policy for admin roles ensures that strict requirements apply even if the general MFA policy allows an exception for some reason.

Configuration:

• Assignments: directory roles (Global Admin, Security Admin, Exchange Admin, SharePoint Admin, User Admin, Privileged Role Admin, Cloud Application Admin, Authentication Admin, Helpdesk Admin, Billing Admin)
• Cloud apps: all cloud apps
• Exceptions: break glass accounts
• Grant: require multi-factor authentication AND require compliant device (when using Intune)
• Status: report-only for 1 week, then on

Additional recommendation: If you have Entra ID P2, enable Privileged Identity Management (PIM) for all admin roles. Instead of permanent role assignment, admins activate their role only when needed (just-in-time), provide a justification and receive the permission only for a defined period (e.g., 4 hours). This significantly reduces the attack surface because admin rights are not active around the clock.

Policy 4: Require Device Compliance

This policy ensures that only devices meeting the defined security requirements can access corporate data. This requires that you have set up Microsoft Intune and defined compliance policies per device platform.

Configuration:

• Assignments: all users
• Cloud apps: Office 365 (or specific apps)
• Exceptions: break glass accounts, possibly guest users (who cannot enroll their own devices in Intune)
• Grant: require device to be marked as compliant
• Status: report-only for at least 2 weeks (check compliance status of all devices!)

BYOD fallback: Not every company can roll out Intune to all devices, particularly in BYOD scenarios. For these cases, an alternative policy that requires an App Protection Policy (MAM) instead of device compliance is a good option. This protects corporate data within managed apps (encrypted, not copyable, remotely wipeable) without fully managing the personal device.

Policy 5: Geo-Blocking

If your company has no employees or business partners in certain countries, there is no reason to allow sign-ins from those countries. Geo-blocking is not perfect protection (attackers use VPNs and proxies), but it eliminates the majority of automated attacks and significantly reduces noise in the sign-in logs.

Configuration:

• Create named location: "Blocked Countries" with the countries from which no access is expected
• Assignments: all users, all cloud apps
• Conditions: Locations = Include "Blocked Countries"
• Exceptions: break glass accounts
• Grant: block access
• Status: report-only for 2 weeks (check whether there are legitimate sign-ins from blocked countries, e.g., employees on business travel)

Practical approach: Instead of maintaining a long blocklist, it is often simpler to use an allow-list. Create a named location with the countries where sign-ins are permitted (e.g., Germany, Austria, Switzerland and countries where business travel regularly occurs) and block everything else.

Consider business travel: Inform employees that they must notify you before traveling to a country that is not enabled, so you can temporarily enable the country or prepare an exception account.

Policy 6: Risk-Based Sign-In

This policy uses the risk assessment from Entra ID Identity Protection (requires P2 license) and dynamically responds to suspicious sign-in attempts. Entra ID analyzes every sign-in for anomalies: unusual location, impossible travel, anonymous IP address, password spray patterns, known attacker infrastructure and more. Each sign-in receives a risk level: None, Low, Medium or High.

Configuration:

• Assignments: all users, all cloud apps
• Conditions: Sign-in Risk = Medium and High
• Exceptions: break glass accounts
• Grant: require multi-factor authentication (at medium risk), block access (at high risk, optional)
• Status: report-only for 2-4 weeks, then gradually activate

Supplementary: User Risk Policy:

• Conditions: User Risk = High
• Grant: require password change (user must change password)
• This policy responds not to individual sign-ins but to the cumulative risk assessment of a user (e.g., credentials found in a leak)

Practical Example: Conditional Access for a Company with 100 Employees

The theory sounds good, but what does introduction look like in practice? Let us take a fictional example: Muller & Partners GmbH, an engineering firm with 100 employees, 5 IT admins, Microsoft 365 Business Premium and the requirement to build an ISMS per ISO 27001.

Weeks 1-2: Preparation

The IT department creates two break glass accounts, stores the passwords in sealed envelopes in the safe, and configures alert policies that send a notification for every sign-in with these accounts. Named locations are configured for the office IP addresses and the permitted countries (DACH + frequent travel destinations).

In parallel, the MFA registration campaign starts. All employees receive instructions for installing the Microsoft Authenticator app and a registration appointment. IT provides support for problems. Goal: 100 percent MFA registration within two weeks.

Weeks 3-4: Report-Only Phase

All six policies are created in report-only mode. The IT department analyzes the logs daily and answers the following questions:

• How many sign-ins would be affected by the legacy auth block? (Result: 12 sign-ins per day from three old scanners)
• Are there sign-ins from blocked countries? (Result: 2 employees were at a trade show in the US — the country is added to the allow-list)
• Which devices are not Intune-compliant? (Result: 15 personal smartphones, for which MAM instead of MDM is configured)

Week 5: Gradual Activation

• Monday: Policy 2 (legacy auth block) is enforced after the scanners were migrated to Modern Authentication
• Wednesday: Policy 1 (MFA for all) and Policy 3 (admin MFA) are activated
• Friday: Policy 5 (geo-blocking) is activated

Week 6: Remaining Policies

• Policy 4 (device compliance) is activated with a 7-day grace period for not-yet-compliant devices
• Policy 6 (risk-based) remains in report-only for one more week and is then activated

Result After 6 Weeks

Muller & Partners GmbH has a structured Conditional Access framework that addresses the most important attack vectors. In the ISMS, the six policies are documented as TOMs and mapped to controls A.5.15, A.8.2 and A.8.5. The Secure Score has improved by 25 points through these measures.

Report-Only Mode in Detail

Report-only mode is the most important tool for the safe introduction of Conditional Access. A policy in report-only mode is evaluated at every sign-in, but the result is only logged, not enforced. You see in the sign-in logs exactly which sign-ins would be affected without anyone actually being blocked or prompted for MFA.

How to use report-only effectively:

1. Create the policy in report-only mode
2. Wait at least 2 weeks (preferably 4 weeks to also capture rare sign-in scenarios)
3. Analyze the sign-in logs: filter for "Report-only: Failure" (would have been blocked) and "Report-only: Not applied" (exceptions)
4. Identify and resolve issues (e.g., legacy auth usage, missing MFA registration, non-compliant devices)
5. Switch the policy to "On" when no unexpected blocks remain

Tip: Use the Conditional Access Insights and Reporting Workbook in Azure Monitor to get a graphical overview of the impact of your report-only policies. The workbook shows at a glance how many users would be affected and which policy would cause the most blocks.

Emergency Access: Break Glass Accounts

Break glass accounts are emergency access accounts that you use when all other access to the tenant is blocked. This can happen if a faulty Conditional Access policy locks out all admins, if the MFA service fails, or if an attacker has compromised the admin accounts.

Best practices for break glass accounts:

• Create at least two accounts (redundancy)
• Cloud-only accounts (no synchronization with on-premises AD)
• Global Admin role permanently assigned
• Extremely long password (at least 24 characters, randomly generated)
• No MFA (so the account works even during MFA outages)
• Excluded from all Conditional Access policies
• Passwords stored in sealed envelopes in a physical safe
• Alert policy: notification on every sign-in with a break glass account
• Quarterly testing: sign in with the break glass account, reset password, create new envelope
• Document in the ISMS: who has access to the safe? Who is notified? What is the process?

The idea of having an account without MFA in an otherwise MFA-protected tenant feels wrong. That is understandable. But the alternative — having no access to the tenant during an outage — is significantly more dangerous. The break glass account is adequately secured through its password length, alerting monitoring and physical protection. Microsoft explicitly recommends this approach in the official documentation.

Conditional Access and BYOD

Bring Your Own Device is widespread in mid-market companies but poses a particular challenge for Conditional Access. Personal devices cannot be enrolled in Intune (or employees do not want this), they do not meet compliance policies, and you have no control over the security state of the device.

The solution is a tiered model:

Corporate devices (Intune-managed):

• Full access to all cloud apps
• Device compliance as access condition
• Offline file access permitted

Personal devices with MAM (App Protection):

• Access to Office apps (Outlook, Teams, OneDrive) with App Protection Policy
• Corporate data within apps encrypted and separated from the personal area
• Copy/paste between managed and unmanaged apps can be restricted
• Remote wipe of corporate data possible without touching personal data

Unknown devices (e.g., hotel PC):

• Access only via browser (no app access)
• Session-based restrictions: no download, no printing, automatic sign-out after inactivity
• Conditional Access App Control (requires Defender for Cloud Apps)

Common Mistakes with Conditional Access

Creating too many policies: Every policy increases complexity and the likelihood of conflicts. Keep the number of policies as low as possible. Six to ten policies are sufficient for most mid-market companies.

Not understanding overlapping policies: Conditional Access evaluates all applicable policies. If one policy requires MFA and another blocks access, the most restrictive wins. This can lead to unexpected blocks if you have not thought through the interaction between policies.

Not documenting exceptions: Every exception in a Conditional Access policy should be documented and justified. "Because the CEO wanted it" is not an acceptable justification. In the ISMS, every exception requires a risk assessment and a planned measure to eliminate the exception.

Skipping the report-only phase: The temptation is great to activate a seemingly harmless policy immediately. In practice, there are almost always surprises: forgotten service accounts, unknown legacy apps, employees abroad. The report-only phase costs two weeks but saves hours at the helpdesk.

Not maintaining named locations: When the office IP address changes or a new location opens, the named locations must be updated. Without current named locations, location-based policies do not work correctly.

Documenting Conditional Access in the ISMS

Conditional Access policies are technical and organizational measures (TOMs) that should be documented in the ISMS. In ISMS Lite, the policies can be captured as TOMs and mapped to the appropriate ISO 27001 controls, including review date and responsible person. The documentation includes:

Per policy:

• Name and description of the policy
• Mapping to ISO 27001 controls
• Affected users and exceptions (with justification)
• Configuration (conditions and access controls)
• Activation date and responsible person
• Last review and next planned review

Cross-cutting:

• Break glass account process (storage, testing, alerting)
• Process for new policies (report-only, evaluation, activation)
• Process for exceptions (request, approval, time-limit, review)
• Named locations and their maintenance process

The mapping to ISO 27001 controls is clear:

• A.5.15 (Access Control): Conditional Access as a whole
• A.8.2 (Privileged Access Rights): Admin-specific policies, PIM
• A.8.5 (Secure Authentication): MFA policies
• A.8.1 (User Endpoint Devices): Device compliance policies
• A.5.18 (Access Rights): Exception management

Monitoring and Continuous Improvement

Conditional Access is not set-and-forget. The policies must be regularly reviewed and adjusted:

Monthly:

• Review sign-in logs for blocked sign-ins (are they attacks or false positives?)
• Review risk detections in Identity Protection (with P2 license)
• Check new users and groups for correct assignment

Quarterly:

• Review all policies for currency (new apps, new locations, changed requirements?)
• Review exceptions (are they still needed? Can they be removed?)
• Review named locations for currency
• Test break glass accounts

Annually:

• Compare entire Conditional Access framework against current Microsoft recommendations and best practices
• Feed results into the management review
• Add new policies as needed based on changed threats or business requirements

Further Reading

• Securing Microsoft 365: The 15 Most Important Security Settings
• Intune for Beginners: Device Management Without Enterprise Complexity
• Zero Trust for SMEs: Principles and Pragmatic Implementation
• Introducing MFA: Overcoming Resistance and Building Acceptance
• Microsoft Secure Score: What It Measures and How to Improve It