Microsoft 365 Conditional Access: the plain-language guide

Conditional Access is the heart of modern Microsoft 365 security. At every sign-in attempt, it decides whether access is granted, denied, or subject to an extra requirement such as multi-factor authentication. Many administrators find it intimidating, with its dozens of settings and technical vocabulary. Yet it rests on a remarkably simple logic: if this situation arises, then this requirement applies. Once that sentence clicks, everything else falls into place.

Unlike a static firewall that applies the same rules to everyone all the time, Conditional Access evaluates context in real time. The same person can sign in without the slightest friction from a managed workstation at the office, yet be prompted for MFA when connecting from an unknown network on the other side of the world. That ability to adapt to real risk is what makes Conditional Access a pillar of the Zero Trust model, where you never trust by default and always verify.

In this guide, you will understand the full mechanics of Conditional Access, discover the first rules to deploy for an SMB, learn to avoid the trap of a general lockout, and above all adopt the safe method that means testing before you enforce. No PowerShell required: just a clear grasp of the logic and a disciplined rollout.

The logic: conditions and grant controls

Each Conditional Access rule, which Microsoft calls a policy, first answers the 'who, what, where' question, then applies a decision. Assignments and conditions describe the context of the sign-in, while grant controls impose the requirements to meet in order to access. Understanding this separation is the key to designing precise rules that protect without getting in the way.

• Assignments: which users or groups are targeted, and which cloud apps or actions are in scope.
• Conditions: the sign-in risk computed by Entra, the device platform, the network location, the type of client app used.
• Grant controls: require MFA, require a compliant device, require a hybrid Entra-joined device, or simply block access.
• Session controls: limit what the user can do once signed in, for example preventing downloads on an unmanaged device.
• One user can be subject to several policies at once: they combine, and the most restrictive one wins.

An evaluation engine, not a simple rule list

It is essential to remember that Conditional Access evaluates every applicable policy at each sign-in, then combines their verdicts. There is no 'first matching rule wins' concept as on a classic firewall. If one policy requires MFA and another requires a compliant device, the user will have to satisfy both. This is powerful, but it means you must keep an overall view of your policies to avoid contradictory or accidentally blocking combinations.

The available conditions and signals

The richness of Conditional Access comes from the variety of signals it can evaluate. Each signal corresponds to a facet of the sign-in context, and you can combine them to target risky situations very precisely.

• User risk and sign-in risk, computed by Entra ID Protection from signals such as impossible travel or malicious IP addresses.
• The device platform: Windows, macOS, iOS, Android, so you can apply rules tailored to each system.
• The network location, to distinguish sign-ins from your trusted premises from those coming from outside.
• The client app type, notably to spot and block legacy authentication that bypasses MFA.
• The device state: compliant with Intune policies, Entra-joined, or completely unknown and unmanaged.

Three rules to get started

You do not need to cover everything on day one. A few core policies already deliver solid protection for an SMB and cover most common attack scenarios. The mistake would be to multiply rules before you have mastered the basics: start small, test, then extend gradually.

1. 1Require MFA for all users accessing Microsoft 365 apps, the most cost-effective protection against password theft.
2. 2Block legacy authentication, those old protocols that bypass MFA and remain a favored entry point for attackers.
3. 3Require a compliant, Intune-managed device to access the organization's most sensitive data.
4. 4Later, add a rule requiring MFA when Entra detects an elevated sign-in risk.

These rules deliberately overlap: general MFA protects everyone, blocking legacy authentication closes the most common bypass, and the compliant-device requirement adds a layer for critical data. Together they form a robust foundation you can enrich without starting over.

Avoiding the classic pitfalls

The vast majority of Conditional Access incidents come not from attacks, but from avoidable targeting mistakes. A poorly thought-out rule can block a whole team, an automated connector, or even the administrator who created it. A few principles sharply reduce that risk.

• Target clearly defined groups rather than 'all users' without thinking about service accounts and shared mailboxes.
• Remember that service accounts and automated identities cannot perform interactive MFA: plan controlled exclusions or use managed identities.
• Document each policy and its precise purpose, to avoid overlaps and combinations that block without anyone understanding why.
• Watch out for platforms not covered by your compliance policies: an unmanaged Mac can end up blocked by a rule designed for Windows.

A poorly targeted Conditional Access policy does not protect your organization, it paralyzes it. Precise targeting beats a severe rule.

The golden rule: test before you enforce

This is the single most important part of any Conditional Access deployment, and yet the one most often skipped in the rush. A poorly scoped policy can lock everyone out in a second, including you. Two precautions are therefore never optional before any enforcement.

Deploy in report-only mode first

Report-only mode evaluates your policy exactly as in production, but never applies its verdict. At every sign-in, Entra computes what would have happened and records it in the logs, without blocking or enforcing anything on the user. You get a precise snapshot of the rule's real impact before a single employee feels any change. Leave the policy under observation long enough to cover a full work cycle, then analyze the sign-ins that would have been blocked.

Exclude a break-glass emergency account

Always exclude a break-glass emergency account from all your Conditional Access policies. This admin account, protected by a long password stored in a safe place and exempt from the rules that could block it, guarantees you will never lock yourself out of your own tenant. It is your emergency exit if a policy goes wrong. Without it, a simple misconfiguration can cut you off from managing your environment, and the only remedy becomes opening a Microsoft support ticket.

A concrete deployment example

Take a 30-person SMB that wants to enforce MFA for all its users. The administrator first creates a break-glass account, excludes it from the future policy, then creates the rule 'Require MFA for Microsoft 365' and leaves it in report-only mode. For two weeks, they review the sign-in logs and discover that an old multifunction scanner sends emails via a legacy protocol incompatible with MFA. Rather than block that legitimate flow, they adjust the scope, plan the scanner's migration to a modern protocol, then finally switch the policy to 'On'. No user was caught off guard, no business flow was broken, and MFA is now enforced for everyone.

Why it matters for your compliance

Conditional Access is not just a technical tool: it is the concrete translation of several regulatory requirements. ISO 27001, NIS2 and GDPR all expect strong, risk-aware access control and robust user authentication. Each well-designed policy becomes documented evidence of that control, which you can present during an audit or to a demanding client.

• MFA directly answers the requirement for strong authentication of sensitive access.
• Blocking legacy authentication closes a well-known and regularly exploited bypass.
• Requiring a compliant device proves control over the endpoints that access your data.
• The report-only logs provide a usable record of your security decisions.

How AuPoint simplifies Conditional Access

Designing coherent Conditional Access policies, remembering report-only mode, never forgetting the break-glass account, and checking rule combinations takes time and an expertise that is rare in an SMB. AuPoint is the SaaS that makes Microsoft Intune and Conditional Access security and compliance easy. It translates Conditional Access into clear scenarios, previews the impact of each rule before activation, and automatically handles the report-only rollout as well as the break-glass account exclusion. You secure your Microsoft 365 access with no jargon and no PowerShell, with policies reversible in one click, and ISO 27001 and NIS2 compliance documented along the way.

FAQ

What license do I need for Conditional Access?

Conditional Access requires at least a Microsoft Entra ID P1 license, included in Microsoft 365 Business Premium as well as the E3 and E5 plans. Risk-based features, such as sign-in risk and user risk, require Entra ID P2. Most SMBs already hold the license they need to get started at no extra cost.

Does report-only mode really block no one?

No, and that is precisely its value. A report-only policy is active in the evaluation engine, but its verdict is never applied. The user sees no difference, while Entra logs what would have happened. You observe the real impact with no risk of a lockout, which makes it the ideal test tool before any enforcement.

How many break-glass accounts should I have?

Microsoft recommends having at least two emergency access accounts, hosted in the default domain, excluded from all Conditional Access policies, protected by long secrets, and stored in a safe place. Two accounts rather than one cover you if one becomes unavailable, locked or compromised at the wrong moment.

Conditional Access is the most powerful building block of Microsoft 365 security, provided you deploy it methodically: report-only first, break-glass account always excluded, and gradual extension. With AuPoint, you apply this method by default, with no jargon and no PowerShell, and you turn an intimidating topic into controlled protection. Discover AuPoint and deploy your first Conditional Access rules with full confidence today.