Conditional Access in Microsoft 365: practical baseline for small tenants in 2026

Conditional Access is one of the areas where a small Microsoft 365 tenant can make the biggest leap in quality. You don't need a SOC, a full E5, or dozens of policies: you need a reasoned, tested baseline applied with discipline. In 2026, identity is still the real perimeter: email, SharePoint, Teams, modern VPNs, SaaS applications, and admin portals almost always go through Entra ID. If an account is compromised, the problem is no longer just the mailbox: it's the entire operational infrastructure.

The goal of this guide is not to copy a universal configuration. It is to build a practical foundation for SysAdmins, MSPs, and advanced homelabs managing small or medium Microsoft 365 tenants, with few administrators and often hybrid users. Policies should always be tested in report-only mode and documented, but starting with a simple schema avoids both an overly permissive tenant and an unmanageable one.

Minimum prerequisites

Before writing policies, I would sort out four elements. First: at least two cloud-only break-glass accounts, excluded from Conditional Access policies, with long passwords stored offline, no mailboxes, and sign-in monitoring. Second: MFA already registered for everyone, preferably with modern methods. Third: dedicated Entra groups, for example CA-Admins, CA-All-Users-Pilot, CA-Exclusions-BreakGlass, and CA-Service-Accounts. Fourth: logs and audits that can be consulted, because an unobserved policy is just a trap waiting to spring.

If you use Intune, also add realistic compliance policies: active encryption, firewall, antivirus, supported operating system, and no jailbreak/root for mobile. Don't immediately create an impossible compliance policy: if 40% of PCs turn out non-compliant for a minor detail, users will look for shortcuts and you will spend your day making exceptions.

Policy 1: MFA for everyone, with priority on strong methods

The first policy should require MFA for all users for the main cloud applications. Exclude only break-glass and service accounts that cannot interact, but the latter should be minimized and protected with alternatives like workload identity, certificates, or secret rotation.

Where possible, push towards phishing-resistant methods: passkeys/FIDO2, Windows Hello for Business, or certificate-based authentication. SMS and voice calls are better than nothing, but shouldn't be the final destination. For administrators, I would avoid compromises: no privileged access without strong MFA. It's a boring rule until the day it saves the tenant.

Recommended rollout: first pilot group, then internal users, then guests and collaborators. Leave the policy in report-only for a few days and check the sign-in logs: old applications, obsolete clients, and poorly made automations emerge immediately.

Policy 2: blocking legacy authentication

POP, IMAP, uncontrolled SMTP AUTH, and old Office clients are still a frequent side door. A dedicated policy must block legacy authentication for all users. If a printer or management software exists that sends mail via SMTP AUTH, don't use this exception as an excuse to leave the whole tenant open. Isolate the case: dedicated account, robust password, minimum permissions, authenticated connector or relay where possible, monitoring, and review date.

This is one of the controls with the best effort/benefit ratio. Before enabling it, search the logs for legacy sign-ins over the last 7-30 days. If you find none, enable it. If you find some, fix the application instead of normalizing the risk.

Policy 3: administrators always protected

Accounts with privileged roles deserve separate policies. Require strong MFA, block access from unexpected countries, apply shorter sessions, and consider requiring a compliant device or dedicated administrative workstation. For Global Administrator, Privileged Role Administrator, Exchange Administrator, SharePoint Administrator, and security roles, convenience cannot be the main criterion.

A good practice is to use separate accounts: one standard for email and daily work, one privileged only for administration. If available, use Privileged Identity Management to make roles just-in-time. In small tenants it often seems overkill, but it reduces permanent exposure and forces you to think about elevations.

Policy 4: access from compliant devices for sensitive data

Not everything needs to immediately require a compliant device, but Exchange Online, SharePoint, and OneDrive almost always contain sensitive data. A balanced baseline is: MFA for everyone from anywhere, and compliant device for download or full access to company data. For personal devices, you can allow restricted web access, preventing download and sync if the license and available features permit it.

Here Intune becomes the operational piece. Compliance must not be an aesthetic badge: active BitLocker, functioning Defender, updated system, screen lock, and minimum OS version are concrete controls. For a homelab or small office, even just distinguishing between a managed notebook and an unknown PC greatly changes the attack surface.

Policy 5: risk, geography, and sessions

If you have Entra ID Protection, use user risk and sign-in risk to require MFA, password change, or block. Alternatively, work with simpler criteria: block or challenge for never-used countries, pay attention to sign-ins from anonymous networks, shorter session lifetime for administrative portals.

Don't abuse geographic blocking: those who travel, use corporate VPNs, or work with international suppliers can generate false positives. Better to start with report-only and a reasoned list of allowed countries. For administrators, however, a more aggressive restriction makes sense.

Implementation checklist

1. Create two cloud-only break-glass accounts and explicitly exclude them.
2. Prepare pilot groups and named exclusion groups, not opaque dynamics.
3. Enable policies in report-only and check sign-in logs.
4. Block legacy authentication after inventorying clients and applications.
5. Require strong MFA for administrators before standard users.
6. Integrate Intune only with measurable and sustainable compliance policies.
7. Document every exception with owner, reason, and expiration.
8. Monthly check logs, exclusions, and accounts without MFA.

Mistakes to avoid

The first mistake is excluding half the company to avoid tickets. The second is not having break-glass accounts and discovering the problem during a lockout. The third is creating ten overlapping policies without clear naming: after six months no one understands anymore why an access is denied. Use readable names, for example CA001-Block-Legacy-Auth-AllUsers or CA010-Require-PhishingResistant-MFA-Admins.

The fourth mistake is confusing security with annoyance. If a policy produces too many MFA prompts, users will approve everything automatically. Better fewer, more targeted prompts, with strong methods and risk signals.

Conclusion

An effective Conditional Access baseline doesn't have to be huge. For a small tenant I would start with five pillars: modern MFA for everyone, hardened administrators, legacy block, compliant devices for sensitive data, and periodic log review. It is a realistic, maintainable configuration, robust enough to stop many common attacks against Microsoft 365.

The important part is treating it as a process, not as a screen to configure once. Every new management software, printer, consultant, or personal device can introduce an exception. And every exception must have an expiration date. That is where the difference between a "configured" tenant and a truly administered tenant shows.