Conditional Access baseline for SMBs in Entra ID

What Conditional Access does

Conditional Access in Microsoft Entra ID evaluates every sign-in on signals: who is signing in, to which app, from which device and location, and with what risk. Based on that, you allow the sign-in, require additional controls (such as MFA or a managed device) or block it.

Licensing: P1, P2 or Security Defaults

Conditional Access requires at least Microsoft Entra ID P1 for the users the policy applies to. P1 is included in, among others, Microsoft 365 Business Premium and Microsoft 365 E3. Risk-based policies (sign-in risk and user risk) require Entra ID P2, which is included in Microsoft 365 E5, for example, or available as a standalone licence or add-on. Licence bundles change regularly, so check what your subscription currently includes in the Microsoft 365 admin centre.

No P1? Then use Security Defaults. This is a free, fixed set of settings that enforces MFA registration, blocks legacy authentication and gives administrators extra protection. Security Defaults and your own Conditional Access policies do not go together: as soon as you enable your own policies, you switch Security Defaults off.

The baseline policy set

With SMB clients I always start with this set.

1. Block legacy authentication

Old protocols such as POP, IMAP and SMTP AUTH with basic authentication do not support MFA and are a favourite target for password spraying. Create a policy for all users and all resources, with the client apps “Exchange ActiveSync clients” and “Other clients” as the condition, and block as the action. First check the sign-in logs to see which devices or applications still use legacy authentication. Multifunction printers that scan to email are the classic culprit. Microsoft is continuing to phase out basic authentication for SMTP AUTH in Exchange Online; the current timeline is in the Message Center.

2. MFA for all users

Require MFA for all users on all resources. Preferably use an authentication strength rather than the generic MFA requirement, so you decide which methods count. SMS and voice calls are the weakest options; the Microsoft Authenticator app with number matching, or passkeys, are stronger. Don’t forget guest users: include them deliberately or create a separate policy for them.

3. Phishing-resistant MFA for administrators

Accounts with admin roles deserve more than ordinary MFA. Target a policy at the directory roles (at least Global Administrator, Security Administrator, Exchange Administrator, SharePoint Administrator, User Administrator, Privileged Role Administrator and Intune Administrator) and require the built-in phishing-resistant MFA authentication strength: FIDO2 security keys, passkeys, Windows Hello for Business or certificate-based authentication. Ideally, administrators have separate, unlicensed admin accounts, distinct from their everyday account with a mailbox.

4. Managed device for admin portals or sensitive apps (optional)

If you manage devices in Intune, you can require the device to be compliant or Microsoft Entra hybrid joined for the “Microsoft Admin Portals” resource. You can do the same for sensitive apps, such as your accounting package or HR system if they sign in through Entra ID. Only switch this on once your compliance policies are in order; otherwise you block people based on a half-finished policy.

5. Risk policies (P2 only)

With Entra ID P2 you create two policies: require MFA for medium or high sign-in risk, and require a secure password change or risk remediation for high user risk. Configure these in Conditional Access. Microsoft has phased out the old risk policies within ID Protection itself; if you still have them, migrate them.

6. Location and country policies (with caveats)

Named locations and countries can be useful, for example to block sign-ins from countries where you have no business activity. Be realistic, though. IP geolocation is not always accurate, attackers simply use VPNs and hosting providers in your own country, and staff who travel or use a mobile network can be blocked unexpectedly. Use location as an extra layer, never as a replacement for MFA.

Additionally: restrict device code flow

Under the authentication flows condition you can block device code flow. It is increasingly abused for phishing.

Break-glass accounts

Create at least two emergency access accounts: cloud-only accounts on the .onmicrosoft.com domain, holding the Global Administrator role and not tied to a person. Exclude them from your Conditional Access policies, so a faulty policy cannot lock you out completely. Because Microsoft makes MFA mandatory for its admin portals, these accounts also need a strong method. A FIDO2 security key kept in a physically secure place is a common choice.

Excluded does not mean unmonitored. Set up an alert that fires on every sign-in by these accounts, for example via an alert rule on the sign-in logs in Log Analytics or Microsoft Sentinel. Test the accounts periodically and document who may use them and how.

Naming

A fixed naming convention makes your policies readable in logs and during handovers. For example: CA001-All-BlockLegacyAuth, CA002-All-MFA and CA010-Admins-PhishingResistantMFA. Use groups for exclusions, such as a group “CA-Exclusion-EmergencyAccess”, so you can see at a glance who is excluded from what.

To quickly see which policies exist and in which state, Microsoft Graph PowerShell helps (scope Policy.Read.All):

Get-MgIdentityConditionalAccessPolicy -All | Select-Object DisplayName, State | Sort-Object DisplayName

Common mistakes

• Locking yourself out. A policy for all users without excluding the emergency access accounts is the best-known mistake. Always test in Report-only mode first.
• Forgetting service accounts. Accounts for scan-to-email, synchronisation or old integrations cannot do MFA. Map them, replace them with app registrations or managed identities where possible, and exclude what remains in a targeted way, with a location condition.
• Excluding too much. Every exclusion is a gap. An “Exclusions” group that holds thirty people after a year undermines the whole policy. Give exclusions an owner and an end date.
• No plan for MFA registration. Users who have not registered yet are prompted to do so at their first sign-in. Consider protecting security info registration, for example with a Temporary Access Pass.

Rollout plan

1. Inventory licences, admin roles, service accounts and devices that use legacy authentication.
2. Create the emergency access accounts, test them and set up monitoring.
3. Make sure all users have registered for MFA.
4. Create all policies in Report-only mode and let them run for at least one to two weeks.
5. Analyse the results in the sign-in logs and with the What If tool; resolve service accounts and exceptions.
6. Tell users what is changing and when.
7. Enable the policies in phases: first the legacy block and admin policies, then MFA for a pilot group, then for everyone.
8. Disable Security Defaults at the moment your own policies go live, not earlier.