Microsoft 365 Conditional Access for Small Businesses, 6 Rules That Stop Most Account Takeovers

A stolen password shouldn’t be enough to get into your email, files, or Teams. Yet most account takeovers I see in Microsoft 365 Conditional Access start the same way: one weak sign-in path that never got closed.

When I’m handling Small Business IT projects like Office 365 Migration work, Cloud Management, and Endpoint Security hardening, I treat identity as the front door. Conditional access rules are the deadbolt, the alarm, and the “nope” sign for risky logins. The best part is you don’t need enterprise complexity to get real protection, you need six clean policies and the discipline to roll them out safely.

Quick setup notes (so you don’t lock yourself out)

Microsoft Entra ID Conditional Access lives in the Entra admin center and typically requires Entra ID Premium P1. Risk-based controls usually need P2. Microsoft also publishes baseline options like Microsoft-managed Conditional Access policies, which can help small teams start with safer defaults.

Before any policy goes live, I always do three things:

• Create two break-glass accounts (emergency access) with long passwords stored offline, no day-to-day use, and strong monitoring. Optiv’s emergency access account guidance matches how I approach it.
• Build a small pilot group (5 to 10 users) and use Report-only first.
• Confirm what “managed” means for you (Intune compliant, hybrid joined, or both). This ties directly to Device Hardening and Secure Cloud Architecture.

The 6 conditional access rules I deploy to stop most takeovers

Each rule below includes the goal, scope, and an example configuration you can copy into your own IT Strategy for SMBs.

1) Require MFA for all users (everywhere, all the time)

Goal: Make stolen passwords useless.

Include/Exclude: Include All users (or a staged rollout group first), exclude break-glass accounts.

Suggested conditions:
Apps: All cloud apps. Locations: Any. Platforms: Any.

Grant controls: Require MFA (or an authentication strength you approve).

Session controls: Consider disabling persistent browser sessions for high-risk roles.

Example policy settings

• Users: All users
• Exclude: Break-glass accounts, service accounts that can’t do MFA (fix these quickly)
• Cloud apps: All cloud apps
• Grant: Require multi-factor authentication
• Session: Sign-in frequency set (start with 7 days, then tighten for admins)

This one policy carries a lot of weight for Cybersecurity Services without adding much daily pain.

2) Block legacy authentication (POP, IMAP, SMTP AUTH where possible)

Goal: Shut down older sign-in methods that bypass modern controls.

Include/Exclude: Include All users, exclude break-glass accounts (and remove mailboxes from break-glass so legacy paths don’t matter).

Suggested conditions:
Client apps: Legacy authentication clients. Apps: Exchange Online (or All cloud apps to be safe).

Grant controls: Block access.

Session controls: Not applicable.

Example policy settings

• Users: All users
• Exclude: Break-glass accounts
• Cloud apps: Office 365 Exchange Online (or All cloud apps)
• Client apps: Other clients, legacy auth
• Grant: Block access

Common pitfall: scoping this only to Exchange and forgetting other entry points. Attackers love the “one old protocol” you missed.

3) Require compliant (managed) devices for admin roles

Goal: Protect your keys to the kingdom, even if an admin password gets phished.

Include/Exclude: Include Directory roles (Global Admin, Exchange Admin, SharePoint Admin), exclude break-glass accounts.

Suggested conditions:
Apps: Admin portals and management apps (start with All cloud apps if you want full coverage). Locations: Any. Platforms: Windows, macOS, iOS, Android.

Grant controls: Require MFA and require compliant device.

Session controls: Set a shorter sign-in frequency for admins.

Example policy settings

• Users: Directory roles, chosen admin roles
• Exclude: Break-glass accounts
• Conditions: Device platforms (your real fleet)
• Grant: Require MFA, require device to be marked compliant
• Session: Sign-in frequency 12 hours (or shorter if risk is high)

This is where Cloud Infrastructure meets Endpoint Security. If the device isn’t managed, I don’t treat it as trustworthy.

4) Require MFA for medium/high risky sign-ins (risk-based)

Goal: Add friction when Entra thinks a sign-in looks suspicious.

Include/Exclude: Include All users, exclude break-glass accounts.

Suggested conditions:
Sign-in risk: Medium and High (P2). Apps: All cloud apps. Locations: Any.

Grant controls: Require MFA (or block High if your team can handle it).

Session controls: Tighten sign-in frequency for risky events.

Example policy settings

• Users: All users
• Exclude: Break-glass accounts
• Conditions: Sign-in risk = Medium, High
• Grant: Require MFA (option: Block access for High)
• Session: Sign-in frequency 1 hour for this policy

If you run restaurants, this matters more than you think. A takeover that hits email can quickly snowball into Restaurant POS Support chaos, vendor fraud, and missed orders.

5) Browser session controls for unmanaged devices (reduce token risk)

Goal: Limit damage when staff use personal devices or shared PCs.

Include/Exclude: Include All users (or frontline groups), exclude break-glass accounts.

Suggested conditions:
Apps: SharePoint, OneDrive, Exchange Online, Teams. Device state: Not compliant (unmanaged). Platforms: Any.

Grant controls: Require MFA.

Session controls: Sign-in frequency and persistent browser session controls; use app-enforced restrictions where available.

Example policy settings

• Users: All users (or “Frontline and Contractors” group)
• Exclude: Break-glass accounts
• Conditions: Device = Not marked compliant
• Grant: Require MFA
• Session: Disable persistent browser session, set sign-in frequency 4 hours

This protects file access during busy shifts and supports Business Continuity & Security, even on shared devices near the kitchen.

6) Break-glass accounts excluded (and tightly constrained)

Goal: Keep emergency access available without creating a permanent backdoor.

Include/Exclude: This is the one policy that targets break-glass accounts directly.

Suggested conditions:
Locations: Allow only trusted locations if you can. Apps: Limit to admin portals. Platforms: Any.

Grant controls: Usually don’t require MFA (it’s for MFA outages). Block from everywhere else.

Session controls: Keep sessions short.

Example policy settings

• Users: Break-glass accounts only
• Conditions: Locations include All, exclude Trusted locations
• Cloud apps: Microsoft Admin Portals (or a tight set)
• Grant: Block access (outside trusted locations)
• Session: Sign-in frequency 1 hour

I also keep break-glass accounts unlicensed (no mailbox), and I alert on any sign-in. That turns “emergency access” into a controlled tool, not a lingering risk. For broader context on identity controls, Microsoft’s overview of Microsoft Entra for business security is a solid reference.

Common mistakes I see (and how to avoid them)

• Locking out admins: Always exclude break-glass and test with Report-only before enforcing.
• Over-broad exclusions: Don’t exclude “All trusted locations” if you don’t control the IP ranges.
• Not scoping to All cloud apps: Attackers don’t care which app you forgot.
• Leaving legacy auth open “for one scanner”: Use modern auth options, or isolate that workflow.
• No device plan: If you require compliant devices, you need a real path for enrollment and Device Hardening.

Implementation order (safe-by-default)

1. Create break-glass accounts and document the process.
2. Block legacy authentication.
3. Require MFA for all users.
4. Require compliant devices for admin roles.
5. Turn on risk-based MFA (if you have P2).
6. Add browser session controls for unmanaged access.

Validation checklist (don’t skip this)

• Start every new policy in Report-only for at least a few days.
• Use Sign-in logs and per-policy reporting to confirm matches and failures.
• Run the What If tool for key users (owner, admins, frontline, service accounts).
• Test from: a managed device, an unmanaged device, an offsite network, and a mobile network.
• Confirm your Business Technology Partner process for emergencies (who can use break-glass, when, and how it’s audited).

Closing thoughts

Most takeovers aren’t magic, they’re just unguarded paths. With these six conditional access rules, I can turn Microsoft 365 into a much harder target without slowing down day-to-day work. This is the kind of Infrastructure Optimization that supports Digital Transformation, whether I’m working on Data Center Technology upgrades, Kitchen Technology Solutions, or Tailored Technology Services for a growing office.

If you want help implementing these policies with least privilege and a phased plan, I’m happy to act as your Managed IT for Small Business partner and get your tenant to a safer baseline fast.