How to configure conditional access in Microsoft 365

Conditional access is the security feature that ties everything else in Microsoft 365 together. MFA verifies identity. Intune verifies devices. Defender verifies email and endpoints. Conditional access creates the rules that decide what happens when a user tries to sign in – whether they are allowed in, challenged with MFA, restricted to specific apps, or blocked entirely, based on who they are, where they are, what device they are using, and what they are trying to access.

Without conditional access, your security controls are disconnected. You can require MFA, but you cannot require it only when someone signs in from an unfamiliar location. You can manage devices with Intune, but you cannot block unmanaged devices from accessing company data. Conditional access is what makes these tools work together as a coherent security policy rather than a collection of independent settings.

This guide covers the policies every small business should configure, how to set them up without locking anyone out, and the common mistakes that cause problems.

What conditional access requires

Conditional access is included in Microsoft 365 Business Premium and any plan with Azure AD Premium P1 (or Entra ID P1, as Microsoft now calls it). It is not available in Business Basic or Business Standard. If you are on a lower plan, see Microsoft 365 licensing explained for small business for a breakdown of what each plan includes and when the upgrade to Premium is justified.

You also need at least one break-glass account – an emergency admin account that is excluded from all conditional access policies. If a misconfigured policy locks every admin out, this account is your recovery path. More on this later.

How conditional access works

Every time a user signs into a Microsoft 365 service, the sign-in is evaluated against your conditional access policies. Each policy has three components:

Assignments define who and what the policy applies to:

• Users and groups (all users, specific groups, specific users)
• Cloud apps (all apps, Office 365, specific apps like Exchange Online or SharePoint)
• Conditions (device platform, location, client app type, sign-in risk level)

Access controls define what happens when the conditions match:

• Grant access (with or without additional requirements)
• Block access entirely

Session controls define restrictions on the session itself:

• Sign-in frequency (how often re-authentication is required)
• Persistent browser session (whether the session survives a browser close)
• App-enforced restrictions (limited access from unmanaged devices)

Policies are evaluated in order and all applicable policies must be satisfied. If one policy requires MFA and another requires a compliant device, the user must satisfy both. The most restrictive combination wins.

The essential policies

Policy 1: Require MFA for all users

This is the single most impactful security policy you can enable. It requires every user to complete multi-factor authentication on every sign-in (or based on conditions you define).

Configuration:

1. Go to Entra admin center > Protection > Conditional Access > Policies
2. Click “New policy”
3. Name: Require MFA – All Users
4. Users: All users. Exclude your break-glass account.
5. Cloud apps: All cloud apps
6. Conditions: None (applies to all sign-ins)
7. Grant: Require multifactor authentication
8. Enable policy: Report-only (initially)

If you already have security defaults enabled, disable them before creating conditional access policies. Security defaults and conditional access cannot coexist – conditional access replaces and supersedes security defaults with more granular control.

For context on why MFA alone is not sufficient and what other controls should accompany it, see MFA is not enough: what else small businesses need to do.

Policy 2: Block legacy authentication

Legacy authentication protocols (POP, IMAP, SMTP with basic auth, older versions of Exchange ActiveSync) do not support MFA. An attacker who obtains a user’s password can authenticate through a legacy protocol and bypass MFA entirely. This is one of the most common attack paths against Microsoft 365 tenants.

Configuration:

1. Name: Block Legacy Authentication
2. Users: All users. Exclude your break-glass account.
3. Cloud apps: All cloud apps
4. Conditions: Client apps > check “Exchange ActiveSync clients” and “Other clients”
5. Grant: Block access
6. Enable policy: Report-only (initially)

Run this in report-only mode for at least two weeks. Check the sign-in logs for any legitimate services using legacy authentication – older printers that scan to email, legacy accounting software, or POP/IMAP email clients. Migrate these to modern authentication or create targeted exceptions before enforcing the policy.

This is covered at a high level in our Microsoft 365 security hardening guide – this article goes deeper into the actual configuration steps.

Policy 3: Block sign-ins from untrusted locations

If your business operates only in the United States, there is no legitimate reason for someone to sign in from Russia, China, or Nigeria. Blocking sign-ins from countries where you have no employees or partners eliminates the majority of credential stuffing and brute force attacks.

Configuration:

1. First, create a named location: Entra admin center > Protection > Conditional Access > Named locations
2. Click “Countries location” and select every country where your employees, remote workers, and travel destinations are located. Name it “Allowed Countries.”
3. Create the policy:

– Name: Block Sign-Ins From Untrusted Countries

– Users: All users. Exclude your break-glass account.

– Cloud apps: All cloud apps

– Conditions: Locations > Include “Any location,” Exclude “Allowed Countries”

– Grant: Block access

– Enable policy: Report-only (initially)

Review the report-only results carefully. If employees travel internationally, you need to either add those countries to the allowed list or create an exception process (a temporary policy change or a separate group for traveling users).

You can also create named locations based on IP addresses. If your office has a static IP, mark it as a trusted location. This lets you create policies that are more lenient for office connections and stricter for connections from unknown networks.

Policy 4: Require compliant devices

If you manage devices with Microsoft Intune, you can require that only devices meeting your compliance policies can access Microsoft 365. A stolen password is useless if the attacker’s device does not pass your compliance checks.

Configuration:

1. Name: Require Compliant Device – Windows and Mac
2. Users: All users. Exclude your break-glass account.
3. Cloud apps: Office 365
4. Conditions: Device platforms > Include Windows, macOS
5. Grant: Require device to be marked as compliant
6. Enable policy: Report-only (initially)

This policy only works if devices are enrolled in Intune and compliance policies are configured. Do not enforce this policy until your devices are enrolled – you will lock everyone out. The correct sequence is: set up Intune, enroll devices, verify compliance status, then enable this policy.

Policy 5: Require app protection for mobile devices

For personal phones and tablets (BYOD), you cannot require full device compliance because you do not manage the device. Instead, require that mobile access goes through approved apps with app protection policies applied.

Configuration:

1. Name: Require App Protection – Mobile
2. Users: All users. Exclude your break-glass account.
3. Cloud apps: Office 365
4. Conditions: Device platforms > Include iOS, Android
5. Grant: Require approved client app AND require app protection policy
6. Enable policy: Report-only (initially)

This ensures that employees can only access company data through Outlook, Teams, and OneDrive with your app protection policies (PIN required, copy/paste restricted, company data encrypted) rather than through a browser or unmanaged app.

Policy 6: Require MFA for admin roles

Even if you have a general MFA policy for all users, create a separate, stricter policy for administrative roles. This ensures admin access is always protected, even if someone accidentally excludes admins from the general policy.

Configuration:

1. Name: Require MFA – Admin Roles
2. Users: Directory roles > select Global Administrator, Exchange Administrator, SharePoint Administrator, User Administrator, Security Administrator, and any other admin roles in use
3. Cloud apps: All cloud apps
4. Conditions: None
5. Grant: Require multifactor authentication
6. Enable policy: On (this one can be enforced immediately since admins should already have MFA)

Policy 7: Restrict admin portal access

The Microsoft 365 admin center, Entra admin center, and Azure portal should only be accessible to people who need them.

Configuration:

1. Name: Block Admin Portal Access – Non-Admins
2. Users: All users. Exclude admin role group.
3. Cloud apps: Microsoft Admin Portals
4. Grant: Block access
5. Enable policy: On

This prevents non-admin users from even loading the admin center. Without this policy, any user can navigate to admin.microsoft.com and see a limited view of the admin center, which is an unnecessary information exposure.

The break-glass account

Before enforcing any conditional access policy, create a break-glass (emergency access) account:

1. Create a cloud-only account (not synced from on-premises AD) with a name like [email protected]
2. Assign the Global Administrator role
3. Set a very long, complex password (40+ characters) and store it in a physical safe or sealed envelope accessible to authorized personnel
4. Do not register MFA on this account (the point is that it works when MFA is broken or unavailable)
5. Exclude this account from every conditional access policy
6. Monitor sign-ins on this account – any sign-in should trigger an alert because this account should never be used in normal operations

This account is your recovery path if a conditional access misconfiguration locks out all administrators. Without it, you may need to contact Microsoft support and go through an identity verification process that can take days.

Report-only mode: the critical first step

Every conditional access policy should start in report-only mode. This evaluates the policy against every sign-in and logs what would have happened (allowed, blocked, MFA required) without actually enforcing anything.

In the Entra admin center > Sign-in logs, you can filter by “Conditional Access” to see which policies applied to each sign-in and what the result would have been. Look for:

• Legitimate sign-ins that would be blocked. An employee working from home whose ISP routes through a different country. A legacy scanner that authenticates with basic auth. A user with a non-compliant device.
• Service accounts that would be affected. Automated processes that sign in to Microsoft 365 APIs may not support MFA or conditional access. These need to be identified and either excluded or migrated to managed identities.
• Volume of affected sign-ins. If 30% of sign-ins would be blocked, you have a lot of preparation before enforcement.

Run each policy in report-only mode for at least one to two weeks. Address every legitimate sign-in that would be blocked before switching to enforcement.

Enforcing policies safely

When you are ready to enforce a policy:

1. Switch it from “Report-only” to “On”
2. Monitor the sign-in logs closely for the first 24-48 hours
3. Be available to respond to “I can’t sign in” reports immediately
4. Have the break-glass account credentials accessible in case something goes wrong

Enforce policies one at a time, not all at once. Start with the MFA policy (lowest risk of lockout since most users should already have MFA configured), then legacy auth block, then location restrictions, then device compliance.

Common mistakes

No break-glass account

The most dangerous mistake. If a conditional access policy is misconfigured and blocks all admin accounts, you have no way to fix it. Create the break-glass account before creating any policies.

Enforcing without report-only testing

Switching a policy from “Off” to “On” without testing it in report-only mode first blocks legitimate users. Always test. Report-only mode exists for this exact reason.

Blocking legacy auth without checking first

Blocking legacy authentication is essential, but doing it without identifying what uses it breaks things. Older copiers and scanners that email documents, legacy CRM systems, and POP email clients on personal devices all use legacy auth. Find them first, migrate or exclude them, then block.

Forgetting about service accounts

Automated processes, shared room mailboxes that sign in to Teams panels, and API integrations may not support MFA or comply with device policies. Identify these accounts and create appropriate exclusions or move them to managed identities that do not require interactive sign-in.

Too many exclusions

Every exclusion weakens the policy. If you exclude half your users from the MFA policy because they complained, you have half your users unprotected. Exclusions should be minimal and documented with a reason. Regular audits of exclusion lists catch entries that were added temporarily and never removed.

Not monitoring after enforcement

Conditional access policies are not set-and-forget. New employees, new devices, travel, and changes in business operations all affect which policies apply. Monitor sign-in logs weekly for the first month and monthly after that. The Microsoft 365 security audit checklist includes conditional access policy review as a quarterly item.

Conditional access and guest users

Conditional access policies apply to guest users by default unless you exclude them. This is usually desirable – you want guests to authenticate with MFA before accessing your data. But location-based policies may block guests who are in countries outside your allowed list.

Create a separate policy for guest users if needed:

• Require MFA for all guest sign-ins (always)
• Use a broader location allowlist for guests than for internal users
• Require app protection policies on guest mobile devices

When to get help

Conditional access configuration for a 5-person business with a single office location and standard devices is manageable with this guide. For businesses with remote workers across multiple states or countries, BYOD devices across multiple platforms, compliance requirements, and service accounts that interact with Microsoft 365 APIs, the configuration requires more planning and more careful testing.

Sequentur handles conditional access deployment as part of our Intune and security hardening projects. We design the policy set, test in report-only mode, resolve every blocked legitimate sign-in, and enforce incrementally. Once the policies are in place, ongoing monitoring and adjustment falls under our managed Microsoft 365 services.

Summary

Conditional access policies control who can access your Microsoft 365 environment and under what conditions. The essential policies are: require MFA for all users, block legacy authentication, block sign-ins from untrusted countries, require compliant devices (if using Intune), require app protection for mobile devices, and add stricter requirements for admin roles.

Every policy must start in report-only mode. Test for at least one to two weeks, identify every legitimate sign-in that would be blocked, resolve those before enforcing, and enforce one policy at a time. Always maintain a break-glass account excluded from all policies. Conditional access is the most powerful security tool in Microsoft 365 – and the most likely to lock you out if misconfigured. Take the time to do it right.