Conditional Access starter policies for a small business

Conditional Access is the policy engine in Microsoft Entra ID that decides, on every sign-in, whether to allow it, block it, or ask for more proof (like multi-factor authentication). It's the heart of modern Microsoft 365 security, and it's also the easiest place to accidentally lock your whole company out of email. This guide gives a small business a safe starter set of policies, built in the right order and with the right safety nets. It's for the admin who has Microsoft Entra ID P1 (included in Business Premium) and wants a sensible baseline. By the end you'll have a break-glass account, named locations, and a handful of policies running in report-only that you can confidently switch on.

Before you start

• Global Administrator access, and your own admin account protected by MFA.
• Microsoft Entra ID P1 or higher (Business Premium includes it). Conditional Access needs at least P1.
• Security defaults turned off. Conditional Access and security defaults can't both be on.
• A list of your sensitive apps (for example, finance or HR systems) and your office public IP addresses if you have static ones.

Step 1: Create and exclude a break-glass account

This is the single most important safety step. Do it before any policy.

1. In the Microsoft Entra admin center (entra.microsoft.com), go to Identity, then Users, then create a new user, for example named "Emergency Access."
2. Give it a long, random passphrase and store that somewhere safe and offline (a sealed envelope in a safe, or a vault only senior people can open).
3. Assign it the Global Administrator role.
4. Plan to exclude this account from every Conditional Access policy you create.

Step 2: Set up named locations

Named locations let policies treat "from the office" or "from the United States" differently from "from anywhere."

1. Go to Protection, then Conditional Access, then Named locations.
2. Add an IP ranges location for your office, entering your static public IP addresses, and mark it as trusted if appropriate.
3. Optionally add a Countries location for the places your staff actually work, which you can later use to block sign-ins from elsewhere.

Step 3: Policy 1, require MFA for all users

This is the baseline everyone should have.

1. Go to Protection, then Conditional Access, then Policies, then New policy. Name it "CA01 Require MFA for all users."
2. Users: include All users, exclude your break-glass account.
3. Target resources: All cloud apps.
4. Grant: Require multifactor authentication.
5. Enable policy: Report-only. Save.

Step 4: Policy 2, block legacy authentication

Legacy authentication is the set of old protocols (like older mail clients) that can't do MFA, so attackers love them. Block them.

1. New policy named "CA02 Block legacy authentication."
2. Users: All users, exclude break-glass.
3. Target resources: All cloud apps.
4. Conditions: Client apps, then select Exchange ActiveSync clients and Other clients (the legacy ones).
5. Grant: Block access.
6. Enable policy: Report-only. Save.

Step 5: Policy 3, require a compliant or hybrid-joined device for sensitive apps

This says that to reach your most sensitive apps, the device itself must be managed and healthy, not just the user verified.

1. New policy named "CA03 Require compliant device for sensitive apps."
2. Users: the people who use those apps, exclude break-glass.
3. Target resources: select your sensitive apps (for example, your finance system or all apps if you're ready for that).
4. Grant: Require device to be marked as compliant, OR require hybrid Microsoft Entra joined device. Select "Require one of the selected controls."
5. Enable policy: Report-only. Save.

Step 6: Read the report-only results before going live

This is where report-only earns its keep.

1. Let the policies sit in report-only for a few business days so real sign-ins flow through them.
2. Go to Protection, then Conditional Access, then Insights and reporting (or open Sign-in logs and check the Report-only tab for each sign-in).
3. For each policy, look at who would have been blocked or challenged. Are there surprises? A service account that can't do MFA? A line-of-business app using legacy authentication? A user whose laptop isn't enrolled yet?
4. Fix the surprises (exclude a genuine service account, modernize an app, enroll a laptop) before you flip anything to On.

Step 7: Turn the policies on, one at a time

Once the report-only results look clean:

1. Switch CA01 (Require MFA) from Report-only to On. Watch sign-ins for an hour.
2. Switch CA02 (Block legacy auth) to On. Watch for broken mail clients or app integrations.
3. Switch CA03 (Compliant device) to On only after device enrollment is confirmed.

Going one at a time means if something breaks, you know exactly which policy did it.

Verify enforcement

1. Sign in as a normal test user and confirm MFA is required (CA01).
2. Try connecting an old mail client that uses legacy authentication and confirm it's blocked (CA02).
3. From an unenrolled device, try to reach a sensitive app and confirm you're blocked or challenged as designed (CA03).
4. Confirm the break-glass account is excluded from all three policies, and confirm your sign-in alert for that account works by signing in with it once (then review the alert).

What to do next

You now have a safe Conditional Access baseline: MFA everywhere, legacy authentication blocked, sensitive apps gated to healthy devices, and a break-glass account standing by. From here, sensible additions are blocking sign-ins from countries you don't operate in, requiring stronger authentication for admins, and adding sign-in risk policies if you move up to Microsoft Entra ID P2. If you'd like us to design and stage these policies, run the report-only review, and flip them on without drama, that's a routine engagement for us, so reach out and we'll set it up with you.