Conditional Access policies in Microsoft 365 automatically enforce security rules based on conditions like who is signing in, where they are signing in from, and what device they are using. Instead of treating every login the same, Conditional Access lets you require extra verification for risky situations while keeping low-risk access smooth for your team. It is one of the most important security features available to small businesses, and most are not using it.
What You Need
- Microsoft 365 Business Premium, E3, or E5. Conditional Access requires Entra ID P1 licensing, which is included with Business Premium but not with Business Basic or Business Standard.
- Entra ID admin access (Global Administrator or Conditional Access Administrator role)
- An understanding of how your team accesses company resources: from the office, remotely, on mobile devices, or a mix
Athencia deploys Microsoft 365 Business Premium for all managed clients specifically because it includes Conditional Access, Microsoft Intune, and Defender for Office 365 at no extra cost. Organizations on Business Basic or Business Standard cannot use Conditional Access and are limited to Security Defaults, which offer far less control.
How Conditional Access Works
Every time someone signs in to Microsoft 365, the sign-in request is evaluated against your Conditional Access policies before access is granted. The policy checks several conditions:
- Who is the user? An admin, a regular employee, a guest?
- What device are they on? A company-managed device, a personal phone, an unknown computer?
- Where are they? Your office network, their home, a coffee shop, another country?
- What app are they accessing? Outlook, SharePoint, a third-party app connected through single sign-on?
- What is the risk level? Is this a normal sign-in pattern, or does it look suspicious?
Based on those conditions, the policy does one of three things: grants access normally, requires additional verification (like MFA or a compliant device), or blocks access entirely.
Think of it as a smart security checkpoint. An employee signing in from a company laptop at the office gets through quickly. That same employee signing in from an unknown device in another country gets asked for extra proof, or gets blocked outright.
Why Business Basic and Standard Are Not Enough
Security Defaults, which are available on all Microsoft 365 plans, enforce MFA for all users and block legacy authentication. That is a solid baseline. But Security Defaults are all-or-nothing. You cannot customize them.
With Conditional Access, you can:
- Require MFA only when signing in from outside the office
- Block access entirely from countries where you have no employees
- Require a company-managed device for accessing sensitive applications
- Allow mobile access only through protected apps like Outlook and Teams
- Apply different rules to admins, regular users, and guests
- Enforce device compliance standards through Microsoft Intune
None of these are possible with Security Defaults alone. If your business has any remote workers, uses personal devices, or needs to comply with industry regulations, Conditional Access is not optional.
Common Policies for Small Businesses
You do not need dozens of policies. Most small businesses are well served by five or six policies that cover the most important scenarios.
1. Require MFA for All Users
This is the most basic and most important policy. Every sign-in requires a second factor of verification.
- Users: All users (exclude one break-glass admin account)
- Target resources: All cloud apps
- Grant: Require multifactor authentication
2. Block Sign-Ins from Untrusted Countries
If your team only operates in the United States, there is no reason to allow sign-ins from other countries. Blocking foreign sign-ins eliminates a large percentage of automated attacks.
- Users: All users
- Conditions: Locations > Include all locations, Exclude your trusted countries
- Grant: Block access
To set up named locations, go to entra.microsoft.com > Protection > Conditional Access > Named locations > + Countries location. Select the countries where your employees and clients are located and save.
3. Require Compliant Devices
This policy ensures that only devices meeting your organization's security standards can access company data. A compliant device is one enrolled in Microsoft Intune that passes your compliance checks: encryption enabled, operating system up to date, screen lock active, and endpoint protection running.
- Users: All users
- Target resources: All cloud apps (or specific sensitive apps)
- Grant: Require device to be marked as compliant
This policy works hand-in-hand with Intune. When you deploy Microsoft 365 Business Premium, Intune is included for device management. Athencia configures Intune compliance policies as part of every Athencia One onboarding, setting the baseline requirements that devices must meet before they are granted access.
For endpoint protection, Athencia layers Huntress Managed EDR on top of Microsoft Defender for Business. Defender provides the baseline antivirus and endpoint detection included with Business Premium. Huntress adds a 24/7 Security Operations Center staffed by human threat hunters who investigate and respond to threats that automated tools miss. Together, they ensure that compliant devices are not just configured correctly but actively monitored for threats.
4. Block Legacy Authentication
Legacy authentication protocols like POP3, IMAP, and SMTP basic auth do not support MFA. Attackers exploit these protocols to bypass MFA entirely. Blocking them closes one of the most common attack vectors.
- Users: All users
- Conditions: Client apps > Select Exchange ActiveSync clients and Other clients
- Grant: Block access
Before enabling this, verify that no employees are using legacy email clients or apps that rely on basic authentication. Most modern apps (Outlook desktop, Outlook mobile, Thunderbird with OAuth) use modern authentication and will not be affected.
5. Require App Protection on Mobile Devices
For employees who access company email and files on personal phones, this policy restricts access to managed apps like Outlook and Teams. Company data stays within those protected apps and cannot be copied to personal apps or saved to unmanaged storage.
- Users: All users
- Conditions: Device platforms > iOS, Android
- Target resources: Office 365
- Grant: Require approved client app or require app protection policy
This uses Intune App Protection Policies, which protect company data on the device without requiring full device enrollment. The employee's personal photos, messages, and apps are untouched. Only company data within managed apps is controlled.
6. Require MFA for Guest Users
External guests who access your Teams channels, SharePoint sites, or shared files should be held to the same MFA standard as your internal team. A compromised client email account should not be able to walk into your environment unchallenged.
- Users: Guest or external users
- Target resources: All cloud apps
- Grant: Require multifactor authentication
Setting Up Your First Conditional Access Policy
Here is the step-by-step process for creating a policy in the Entra admin center.
- Sign in to entra.microsoft.com
- In the left sidebar, navigate to Protection > Conditional Access > Policies
- Click + New policy
- Enter a clear, descriptive name (e.g., "Require MFA - All Users" or "Block Legacy Auth")
- Under Assignments > Users, select the users or groups the policy applies to. Start with a test group of a few users, not your entire organization.
- Under Assignments > Target resources, select All cloud apps or specific apps
- Under Conditions, set any conditions (locations, device platforms, client apps)
- Under Access controls > Grant, choose the action: Require MFA, Require compliant device, Block access, etc.
- Set Enable policy to Report-only
- Click Create
Report-only mode is critical. It lets you see exactly which sign-ins would be affected by the policy without actually blocking anyone. Leave it in report-only mode for at least one week before switching to On.
Why Report-Only Mode Matters
Turning on a Conditional Access policy without testing it first can lock out your entire team. Report-only mode prevents this by simulating the policy without enforcing it.
While a policy is in report-only mode:
- Every sign-in is evaluated against the policy
- The sign-in logs show whether the policy would have been applied (and what the result would have been)
- No users are actually blocked or prompted for additional verification
To review report-only results:
- Go to entra.microsoft.com > Identity > Monitoring & health > Sign-in logs
- Click on any sign-in event
- Under the Conditional Access tab, you will see each policy and whether it would have applied
Look for unexpected impacts: service accounts that would be blocked, shared devices that cannot satisfy compliance requirements, conference room accounts, or third-party integrations that use basic authentication. Fix these before switching the policy to On.
The Break-Glass Account
Every organization using Conditional Access must have at least one emergency access account (commonly called a break-glass account). This is a Global Administrator account that is excluded from all Conditional Access policies.
Why? If a policy misconfiguration locks out every admin, you need a way to sign in and fix it. Without a break-glass account, you would need to contact Microsoft support, which can take hours or days.
Break-glass account best practices:
- Use a strong, random password stored securely (1Password is a good option for this; Athencia includes 1Password in its Athencia One Complete package)
- Do not assign it to a real person
- Exclude it from all Conditional Access policies
- Enable alerts for when this account signs in (any sign-in on this account should be investigated)
- Do not enable MFA on this account (that defeats its purpose as a fallback)
Common Mistakes
Locking yourself out. Always exclude a break-glass account from every Conditional Access policy. Test in report-only mode first.
Not testing in report-only mode. Enforcing an untested policy can block your entire team, including all admins. Always run in report-only for at least a week.
Being too restrictive too fast. Start with MFA for all users. Once that is stable, add device compliance. Then add location restrictions. Layering policies incrementally gives you time to identify and fix problems.
Forgetting service accounts. Automated processes, scheduling tools, and service accounts may fail if they cannot satisfy MFA or device compliance requirements. Identify these accounts and either exclude them from specific policies or configure them to use managed identities.
Not blocking legacy authentication. This is one of the most exploited gaps in Microsoft 365 security. Even with MFA enforced, attackers can authenticate through POP3 or IMAP, which do not support MFA. Block legacy auth early.
Ignoring identity threats after deployment. Conditional Access sets the rules, but it does not actively hunt for identity-based attacks. Huntress Managed ITDR layers on top of Entra ID to monitor for credential theft, token replay attacks, and other identity threats around the clock. Conditional Access controls the front door; Huntress watches for intruders who find a way around it.
Need Help?
Conditional Access is powerful, but getting the policies right requires understanding your team's access patterns, device landscape, and compliance needs. If you want help designing and deploying Conditional Access policies for your business, contact Athencia. We configure Conditional Access as part of every managed client onboarding.
