A tenant with no Conditional Access is a building with the doors propped open. Every account that knows a password can walk in from anywhere, on any device, through any protocol, and the only thing standing between an attacker and your data is whether someone guessed, phished, or sprayed the right credential. Conditional Access patterns are how you close those doors without locking out the people who belong inside. They are the proven, repeatable policy shapes that an identity team assembles into a baseline: require multifactor authentication for administrators, block legacy authentication that bypasses MFA entirely, require a compliant device for sensitive applications, step up authentication when a sign-in looks risky, and govern where and by whom access happens. Each one addresses a specific threat, and together they form a posture that an attacker has to defeat layer by layer rather than slip past in a single move.

The exposure created by getting this wrong is not abstract. A tenant that enforces MFA in the portal but leaves IMAP and SMTP open has an MFA bypass sitting in plain sight, and credential-spray tooling finds it within hours. A tenant that builds twenty overlapping one-off policies ends up with users locked out of email at random and admins afraid to touch the policy list because nobody can predict what a change will break. The difference between a tenant that holds and a tenant that leaks is rarely a single clever control. It is whether the team assembled a small set of well-understood patterns or invented bespoke rules one incident at a time.

This article is a working catalog. It defines each high-value pattern, shows the assignments, conditions, and controls that realize it, names the risk it mitigates, and explains how to layer the patterns so they reinforce rather than fight each other. By the end you should be able to stand up a defensible baseline from named, tested patterns instead of staring at a blank policy editor wondering where to begin.

What Conditional Access patterns are and why a baseline beats bespoke

Conditional Access is the policy engine inside Microsoft Entra ID that evaluates every sign-in attempt and decides what to do with it. Each policy reads like an if-then statement. If a set of assignments is true, meaning a particular combination of users, target resources, and conditions, then the engine applies one or more access controls, either granting access with requirements attached or blocking it outright. A policy that says “if an administrator signs in to a management portal, then require multifactor authentication” is the canonical shape. The assignments describe who and what and under which circumstances; the controls describe the gate they must pass through.

A Conditional Access pattern is one of those if-then shapes that the security community has tested, refined, and agreed upon as the right answer to a recurring threat. The pattern is not a single tenant’s policy. It is the reusable template behind that policy: the assignments you should target, the conditions that should trigger it, the control it should enforce, and the exclusions that keep it from locking out the wrong people. When you adopt a pattern, you are inheriting other people’s incident history so you do not have to repeat it.

What is the baseline-of-patterns rule?

The baseline-of-patterns rule says a strong posture is a small set of proven patterns assembled together, not a large pile of bespoke one-off policies. A handful of well-chosen shapes covers the overwhelming majority of identity threats, and because each shape is understood in isolation, the team can reason about how they combine. Bespoke policies, by contrast, accrete. Someone adds a rule after an incident, another rule after an audit finding, a third to satisfy a vendor, and within a year the policy list is an archaeology project nobody dares to disturb.

This rule matters because Conditional Access failures are almost never failures of capability. The engine can express nearly any rule you can describe. The failures are failures of design. They come from policies that overlap in ways no one anticipated, from a foundational gap that was never closed because nobody owned the baseline, and from changes made in production with no way to predict the blast radius. Assembling from a catalog of patterns turns an open-ended design problem into a checklist. You know the patterns that belong in any baseline, you adapt each one to your tenant’s specifics, and you layer them deliberately. The result is a posture you can explain to an auditor, hand to a new hire, and modify without holding your breath.

The patterns in this catalog are the ones that earn a place in nearly every baseline. Require MFA for administrators closes the highest-value accounts. Block legacy authentication removes the protocols that ignore MFA. Require a compliant or hybrid-joined device raises the bar for sensitive applications. Risk-based step-up uses Microsoft Entra ID Protection signals to demand stronger proof when something looks wrong. Location controls and guest governance handle the edges. None of these is exotic. Their value is precisely that they are boring, well-trodden, and known to work. The mental model to hold is that you are not inventing security; you are assembling it from parts that already exist, and the engineering skill is in the assembly, not the invention. For the deeper mechanics of how the engine evaluates and combines policies, the Conditional Access deep dive walks the evaluation order and the grant logic in detail, and this catalog assumes that foundation.

How the control works: signals in, controls out

Every pattern in this catalog is the same machine wired differently. Understanding the machine once means you can read any pattern without relearning it. The engine takes signals about a sign-in, matches them against the assignments and conditions of every enabled policy, and applies the union of the resulting controls. Knowing which signals exist and which controls they can trigger is the whole vocabulary of pattern design.

Which signals feed a policy?

The assignment side of a policy draws on a fixed set of inputs. The user or workload identity making the request, resolved through group membership and directory roles, answers the question of who. The target resource, which can be a cloud application, a user action such as registering security information, or the authentication context tied to a sensitive operation, answers what is being reached. The conditions narrow further: the client app type separating modern browser and mobile clients from legacy protocols, the device platform and whether the device is marked compliant or hybrid joined, the network location expressed as named IP ranges or countries, and the risk signals that Microsoft Entra ID Protection attaches to the sign-in and the user. Each pattern picks the subset of these signals that defines the threat it addresses and leaves the rest unset.

The control side is shorter. Grant controls either block access or grant it subject to requirements, and the requirements include requiring multifactor authentication, requiring a specific authentication strength such as phishing-resistant methods, requiring a compliant device, requiring a hybrid-joined device, requiring approval through terms of use, and requiring password change for risk remediation. When a policy lists several grant requirements you choose whether the user must satisfy all of them or any one. Session controls shape the session that follows a successful grant: sign-in frequency that forces reauthentication on an interval, persistent browser session behavior, and app-enforced restrictions that limit what a session can do inside an application. A pattern is nothing more than a chosen set of signals mapped to a chosen control.

Why report-only mode comes first

Report-only is the single most important operational feature in the engine, and every pattern in this catalog should pass through it before it goes live. A report-only policy is evaluated against real sign-ins exactly as an enabled policy would be, and the result is recorded in the sign-in logs, but the control is never enforced. Nobody is blocked, nobody is prompted, and you get a faithful preview of what the policy would have done to your actual traffic. The reason this matters is that Conditional Access changes are blunt. A policy that looks correct in the editor can lock out a service account, a conference-room device, or an entire office whose traffic you did not anticipate. Report-only turns that risk into data. You enable the pattern in report-only, you let it observe for a week or two, you read the workbook that shows which sign-ins would have been affected, and only when the preview matches your intent do you move it to on. Skipping this step is the most common way a well-designed pattern becomes an outage, and the discipline of always staging through report-only is what separates a baseline you can trust from one you are afraid of.

What the engine does when policies overlap

Multiple policies can match the same sign-in, and the engine does not pick one. It evaluates all matching policies and combines their controls. Block always wins; if any matching policy blocks access, the sign-in is denied regardless of what other policies grant. Among granting policies, the requirements accumulate, so a sign-in that triggers both an MFA policy and a compliant-device policy must satisfy both. This combination behavior is exactly why the baseline-of-patterns rule works and why bespoke sprawl fails. When patterns are few and each one owns a clear slice of the signal space, the union of their controls is predictable. When policies are many and overlap haphazardly, the union becomes a surprise, and the surprise usually arrives as a help-desk queue full of locked-out users. Designing for this combination behavior, rather than against it, is the core skill the catalog is meant to teach.

The InsightCrunch Conditional Access pattern catalog

This is the findable artifact of the article: a catalog that names each baseline pattern, lists the assignments and conditions that target it, the control it enforces, and the risk it removes. Read it as the assembly diagram for a baseline. Each row is a pattern detailed in the sections that follow, and the sections explain the exclusions, the rollout, and the edge cases that the table cannot hold.

Pattern	Assignments and conditions	Control enforced	Risk mitigated
Require MFA for administrators	Directory roles for privileged admins; target the admin portals and management resources	Grant access, require multifactor authentication or phishing-resistant strength	Compromise of high-value admin accounts through password-only sign-in
Block legacy authentication	All users; condition on client app set to legacy and other clients	Block access	MFA bypass through protocols that cannot present a second factor
Require compliant or hybrid-joined device	All users or a sensitive-app group; target sensitive applications	Grant access, require compliant device or hybrid Entra join	Data access from unmanaged, unpatched, or unknown endpoints
Risk-based step-up	All users; condition on sign-in risk medium or high, and user risk high	Grant access, require authentication strength; require password change on user risk	Sign-ins from compromised credentials, anomalous locations, and leaked passwords
Location and country controls	All users; condition on named locations or countries	Block access from disallowed regions, or step up from outside trusted networks	Access from regions the organization never operates in, and travel-impossible sign-ins
Guest and external access governance	Guest and external users; target internal applications and admin actions	Grant access with MFA and terms of use; restrict guest reach	Over-broad access by partners and unmanaged external identities
Require MFA for all users	All users; all resources, excluding the patterns above where they already apply	Grant access, require multifactor authentication	Password-only sign-in for the general workforce

The catalog is intentionally short. Seven patterns cover the threats that account for the large majority of identity compromise, and the order roughly tracks priority: protect the admins first, close the legacy bypass second, then layer device, risk, location, guest, and finally the all-user MFA floor. A tenant that has assembled these seven, staged each through report-only, and excluded its break-glass accounts from all of them has a baseline that an attacker cannot trivially walk through. Everything beyond these seven is refinement for a specific environment, not foundation. When a new requirement arrives, the first question to ask is whether it is a variation on a catalog pattern rather than a genuinely new shape, because most of the time it is.

Pattern one: require MFA for administrators

The first pattern protects the accounts an attacker wants most. A standard user account, if compromised, gives an intruder one mailbox and one set of files. A privileged administrator account gives them the directory, and with the directory they can grant themselves anything else. Microsoft has made this the default expectation across its own platform: starting in October 2024, signing in to the Azure portal, the Microsoft Entra admin center, and the Intune admin center to perform create, read, update, or delete operations requires MFA, with enforcement for the Microsoft 365 admin center and for command-line and automation surfaces following through 2025 and into 2026. Treat those Microsoft-enforced requirements as a floor, not a ceiling, and own an explicit administrator MFA pattern of your own so your posture does not depend on the rollout schedule of someone else’s enforcement.

Which accounts does this pattern target?

The assignment targets directory roles rather than a static group, because role-based targeting follows the privilege wherever it lands. A Conditional Access policy can be scoped to specific Entra roles, so you select the privileged ones: Global Administrator first, then the roles that can change identity and security posture such as Privileged Role Administrator, Security Administrator, Conditional Access Administrator, Authentication Administrator, User Administrator, and the application and Exchange and SharePoint administrators. Targeting the role means that when someone is later assigned Global Administrator, the policy covers them automatically without anyone remembering to add them to a group. The target resources are the management portals and, increasingly, the management API surface, so that the requirement applies wherever an admin exercises privilege.

The control is multifactor authentication, and for privileged roles the stronger choice is to require an authentication strength rather than generic MFA. Authentication strength lets you demand phishing-resistant methods, meaning FIDO2 security keys, Windows Hello for Business, or certificate-based authentication, rather than accepting a one-time code over SMS that a determined attacker can intercept through SIM swapping. The trade-off is registration effort: phishing-resistant methods require provisioning hardware keys or device-bound credentials, which is more work than enrolling a phone. For the small population of privileged admins, that effort is worth it, because these are the accounts whose loss is catastrophic. The general workforce can sit behind ordinary MFA while the admins sit behind phishing-resistant strength, and the pattern lets you draw that line precisely.

How do break-glass accounts fit?

Every organization needs at least two emergency access accounts, often called break-glass accounts, that can sign in when Conditional Access itself is misconfigured or when the MFA provider is down. These accounts are the recovery hatch, and the historical advice was to exclude them from all Conditional Access policies so a policy mistake could never lock everyone out. That advice has shifted as Microsoft’s mandatory MFA has closed the gap that exclusions relied on. The current guidance is to protect break-glass accounts with a strong, non-interactive factor that does not depend on the systems most likely to fail, meaning a FIDO2 passkey or certificate-based authentication, rather than leaving them with a password alone. The accounts are still excluded from the risk-based and device-based patterns that could trap them, but they should satisfy a phishing-resistant factor so that the recovery hatch is not itself the weakest link. Store the credentials offline, split knowledge across two custodians, alert on every sign-in, and review the accounts on a schedule. The administrator MFA pattern is the one most likely to lock you out if you get the exclusions wrong, so design the break-glass handling alongside it rather than afterward. Treat the specific enforcement dates and the recommended factor for these accounts as items to confirm against current Microsoft documentation before you finalize the policy, because the platform’s mandatory-MFA program continues to evolve.

Pattern two: block legacy authentication

The second pattern closes the door that the first one leaves open. Requiring MFA for administrators, or for anyone, accomplishes nothing if an attacker can sign in through a protocol that never asks for a second factor. Legacy authentication is the family of older protocols, including IMAP, POP3, SMTP, MAPI, and the authentication paths used by older Office clients and Exchange ActiveSync, that present a username and password directly and have no mechanism to satisfy an MFA challenge. When a sign-in arrives over one of these protocols, the engine cannot prompt for a second factor, so an MFA requirement scoped to modern clients is simply skipped. The result is an MFA bypass that exists by default in any tenant that has not explicitly blocked it.

The scale of the problem is what makes this pattern foundational rather than optional. Microsoft’s own telemetry has reported that the large majority of password-spray and credential-stuffing attacks ride on legacy authentication, on the order of more than ninety-nine percent of password-spray attempts and more than ninety-seven percent of credential-stuffing attempts targeting these older protocols. Organizations that disable legacy authentication see a substantial drop in successful compromise. The reason attackers favor these protocols is exactly that they ignore MFA: an automated tool can try thousands of credentials per hour against an IMAP endpoint and never face a prompt, whereas the same credentials hitting a modern browser sign-in would be stopped cold by the second factor. Blocking legacy authentication removes the one path that lets stolen passwords still work.

How do I find legacy authentication before I block it?

Blind blocking is how this pattern causes an outage, because legitimate traffic sometimes still rides legacy protocols: an old multifunction printer that scans to email over SMTP, a line-of-business application using a hardcoded IMAP connection, a service account in a script. The diagnostic step comes first. The Entra sign-in logs record the client app for every sign-in, and filtering the interactive and non-interactive sign-in views by the legacy client-app categories shows you exactly which accounts and which applications are still using these protocols. There is a dedicated workbook for triaging legacy authentication that aggregates this for you. Run the report, identify every legitimate dependency, and plan its migration to modern authentication or to a managed identity before the block goes live. Only after you know what will break should the policy move out of report-only.

What does the policy itself look like?

The pattern targets all users and conditions on the client app, selecting the legacy categories, then sets the grant control to block access. The exclusions matter as much as the inclusion. Exclude your break-glass accounts so a mistake cannot trap them, and exclude, temporarily and with a hard deadline, any account whose legacy dependency you have not yet migrated. One subtlety catches teams off guard: Conditional Access policies scoped to users do not block calls made by service principals, so a service-principal-based integration using a legacy flow is not stopped by this user-scoped policy. Workload identities require their own Conditional Access policies, and the right long-term fix for a service account in a script is to replace it with a managed identity that authenticates through a modern, certificate-backed flow. The setup mechanics for staging and enabling this policy are covered step by step in the guide to configure Conditional Access policies, which this pattern builds on. The retirement timeline for basic authentication in Exchange Online has moved over the years, so verify the current state of any remaining legacy dependency against Microsoft’s documentation rather than assuming a date.

Pattern three: require a compliant or hybrid-joined device

The third pattern raises the bar from who you are to what you are signing in from. MFA proves a user is who they claim to be, but it says nothing about the health of the machine in their hands. A correctly authenticated user on a personal laptop with no disk encryption, no patches, and an unknown malware posture is still a risk, because anything that machine touches is exposed to whatever already lives on it. Requiring a managed device for sensitive applications shifts access from any device a valid user holds to only devices the organization can vouch for.

There are two ways a device earns that trust, and they suit different estates. A device marked compliant has passed the policies defined in your mobile device management platform, typically Microsoft Intune, covering things like disk encryption, a minimum operating-system version, a screen lock, and the absence of known threats. Compliance is the modern, cross-platform path and works for Windows, macOS, iOS, and Android. A hybrid Entra joined device is a Windows machine that is joined to on-premises Active Directory and registered with Entra ID, which suits organizations with an established domain and Group Policy estate. The grant control can require either, or accept either one, depending on how mixed your fleet is. The pattern targets the applications that hold sensitive data rather than every application, because demanding a managed device to read a public status page is friction with no payoff, while demanding it to open the finance system is proportionate.

When should the requirement apply to every app?

The instinct to require a compliant device everywhere is understandable and usually wrong at the start. A tenant with a fully managed fleet and no contractors can move toward an all-application device requirement, and that is a strong posture. Most organizations are not there. They have contractors on unmanaged machines, executives who travel with personal tablets, and a long tail of web applications that people reach from anywhere. For those tenants the pattern works best scoped to the genuinely sensitive applications, with the rest of the estate protected by MFA and risk-based controls. The decision rule is the data behind the application. If a compromise of that application’s data would trigger a breach notification or a regulatory finding, it belongs behind a device requirement. If it would be an annoyance, it does not. Scoping by sensitivity keeps the requirement defensible and keeps the help desk from drowning in access requests from people on devices that cannot comply.

What breaks when you require a compliant device?

The predictable failure is users who own a valid credential but sit on a device the organization does not manage, and they hit a hard wall with a message they cannot resolve themselves. Browser-based access from an unmanaged machine stops working for the targeted apps, which is the point, but it surprises people who were used to checking the finance system from a home computer. The mitigation is communication and a managed-device path: tell people in advance, give them an enrollment route for the devices they need, and provide a managed alternative such as a virtual desktop for cases where enrolling the physical device is not possible. The other failure mode is the device that should be compliant reporting as non-compliant because of a lagging Intune evaluation or a single failed check, which locks out a legitimate, managed machine. Building the pattern through report-only catches the scale of both problems before they become tickets, and pairing the rollout with a self-service compliance-check view lets users see why their device was refused. This pattern depends on a working device-management foundation, so confirm Intune enrollment and compliance policies are healthy before you make device compliance a gate.

Pattern four: risk-based step-up with Identity Protection

The fourth pattern makes the baseline adaptive. The patterns so far apply the same control to every sign-in that matches their assignments, which is correct for a structural rule like blocking legacy authentication. But not every sign-in carries the same danger. A user signing in from their usual office on their usual laptop at nine in the morning is low risk; the same user appearing from an unfamiliar country minutes after a sign-in from headquarters is a strong signal that something is wrong. Risk-based patterns use Microsoft Entra ID Protection to score that danger and apply a stronger control only when the score warrants it, so legitimate users are not punished for normal behavior while suspicious sign-ins face an additional gate.

Identity Protection produces two kinds of risk. Sign-in risk is the probability that a specific authentication attempt is not the legitimate owner, computed from signals like an anonymous IP address, an unfamiliar location, an impossible-travel pattern, a known malware-linked address, or a token anomaly. User risk is the probability that an account itself is compromised, raised by signals such as leaked credentials found in a breach dump or a user reporting a suspicious MFA prompt. The two feed different controls. A risky sign-in is best handled by demanding stronger authentication for that attempt; a risky user is best handled by forcing a password reset to evict whoever holds the stolen credential.

How do I configure the two risk policies?

The sign-in risk pattern targets all users, excludes break-glass accounts, conditions on sign-in risk at medium and high, and grants access with a requirement to satisfy an authentication strength, ideally a phishing-resistant or passwordless strength, combined with a session control that reauthenticates every time so the risky session cannot persist. The user risk pattern targets all users, excludes break-glass accounts, conditions on user risk at high, and grants access only with a requirement to change the password through secure self-service password reset, which both proves control of the account and rotates the compromised secret. Microsoft’s recommended thresholds, medium and high for sign-in risk and high for user risk, balance protection against the noise of false positives at lower scores, though a high-sensitivity environment may choose to act on low sign-in risk and accept more prompts. There is an important platform change to plan for: the legacy risk policies configured directly inside Identity Protection are being retired, and the supported home for risk-based rules is Conditional Access. If your tenant still has the old Identity Protection risk policies enabled, plan their migration to Conditional Access policies, and verify the current retirement timeline against Microsoft’s documentation before you depend on the legacy location.

Why does risk-based step-up depend on licensing?

Risk-based Conditional Access is not available at every license tier, and this is the most common reason a team cannot adopt this pattern immediately. The risk signals from Identity Protection require the higher Entra ID licensing, and without it the sign-in-risk and user-risk conditions are simply unavailable in the policy editor. A tenant on a lower tier can still build every other pattern in this catalog, because admin MFA, blocking legacy authentication, device compliance, location controls, and guest governance do not depend on risk signals. The honest sequencing is to assemble the license-independent patterns first, which closes the largest gaps, and add risk-based step-up when the licensing is in place. Confirm your tenant’s entitlement before you design around risk conditions, because building a baseline that assumes a signal you cannot read leaves a hole where you thought you had a control. For the broader principle behind treating every sign-in as untrusted until proven, the Azure Zero Trust architecture article frames risk-based step-up as the verify-explicitly tenet in practice.

Pattern five: location and country controls

The fifth pattern uses where a sign-in comes from as a condition. Location is a weaker signal than identity or device health, because an attacker can route through a proxy in any country and a legitimate user travels, so this pattern is a supporting control rather than a primary gate. Used carelessly it creates false confidence and locks out traveling staff; used well it trims the attack surface and adds a cheap layer that catches the unsophisticated. The skill is knowing what location can and cannot tell you.

Named locations are the building block. You define them as IP address ranges, typically your corporate egress addresses and trusted partner networks, or as countries and regions. A location can be marked trusted, which both feeds these policies and influences risk scoring, because a sign-in from a trusted network is treated as lower risk. Once locations exist, two shapes are common. The first blocks access from countries where the organization has no presence and no reason to expect a sign-in, which removes a slice of automated attack traffic that originates from regions you never operate in. The second steps up authentication for any sign-in from outside the trusted networks, so being in the office is frictionless while being anywhere else triggers MFA.

Why is country blocking a trim and not a wall?

Blocking by country feels decisive and is easy to oversell. An attacker who wants in will route through an address inside an allowed country, often through a compromised machine or a commercial proxy, and the country block does nothing to stop them. What it does accomplish is removing the high volume of opportunistic, untargeted traffic that comes from regions outside your operating footprint, which reduces noise in your logs and stops the laziest attempts. Treat it as a way to shrink the haystack, not as a control you would rely on against a motivated adversary. The cost side is real: travelers, remote contractors, and anyone behind a VPN that exits in an unexpected country will be blocked, so the allow list has to reflect where your people actually go, and there must be a fast exception process. Because the protection is modest and the lockout potential is high, this pattern earns its place only when the location policy is precise and maintained, and it should never be the only thing standing between an attacker and a sensitive application.

How does location interact with the risk pattern?

Location and risk reinforce each other when configured together. Marking your corporate networks as trusted lowers the risk score for sign-ins that originate there, which means the risk-based step-up pattern prompts less often for people in the office and more often for people elsewhere, exactly the behavior you want. Conversely, a sign-in from an untrusted location combined with any other anomaly pushes the risk score up, so the risk policy catches it even without an explicit location rule. This interplay is why many mature baselines lean on the risk pattern with trusted-network tuning rather than on hard country blocks, because the risk engine weighs location alongside a dozen other signals instead of treating geography as a binary. If you adopt only one of the two, the risk-based pattern with well-defined trusted locations is the stronger choice. Location-only blocking is a reasonable addition for tenants that genuinely operate in a small, fixed set of countries, and a poor fit for global organizations whose staff move constantly.

Pattern six: govern guest and external access

The sixth pattern addresses the identities you do not own. Collaboration brings partners, contractors, and vendors into your tenant as guest users, and each guest is an account whose security posture is set by someone else’s organization, on devices you cannot manage, behind authentication you do not control. A guest with broad access is a soft entry point: compromise the partner’s account and the attacker inherits whatever you granted the guest. Governing external access means applying controls to guests that account for the lower trust you can place in them while still letting collaboration happen.

The pattern targets guest and external users as a distinct assignment, which Conditional Access exposes directly, and applies controls suited to their reduced trust. Requiring MFA for guests is the floor, because you cannot assume the partner organization enforces it, and an unauthenticated guest credential is as dangerous as an unauthenticated employee one. Requiring acceptance of a terms-of-use statement gives you a record that the external party agreed to your handling rules, which matters for audits and for partner agreements. Beyond Conditional Access itself, the external collaboration settings and cross-tenant access policies let you decide which partner tenants you trust, whether you accept their MFA claims so guests are not double-prompted, and which of your applications guests can even attempt to reach. The combination scopes guest reach to the minimum the collaboration requires.

How does this pattern apply least privilege to guests?

Least privilege for guests is mostly about reach rather than strength. A guest invited to collaborate on one project rarely needs visibility into the rest of the tenant, yet the default invitation can grant more directory visibility and application access than the collaboration requires. The pattern pairs the Conditional Access controls with an entitlement discipline: invite guests into the specific groups and applications they need, use access packages and access reviews so a guest’s access expires or is recertified rather than lingering forever, and restrict the directory information guests can enumerate. Conditional Access enforces how a guest must authenticate; the entitlement controls decide what they can touch once authenticated. Both are needed, because strong authentication into an over-broad grant still leaves an over-broad grant. The most common guest failure is not weak authentication but stale access: a contractor finished a project two years ago and their guest account still works, still has MFA, and still reaches an application nobody remembers granting. Access reviews are the antidote, and they belong in this pattern even though they live outside the Conditional Access editor.

When should guests face a device requirement?

Demanding a compliant device from a guest is usually impractical, because the guest’s device belongs to their organization and is enrolled in their management, not yours. Forcing compliance on a guest’s machine either blocks legitimate collaboration or pushes you into managing devices you do not own. The proportionate posture for guests is strong authentication plus narrow reach plus expiring access, reserving device requirements for the rare case where a guest is issued an organization-managed device for a sensitive engagement. If a guest genuinely needs access to data sensitive enough to demand a managed device, the cleaner answer is often to issue them a managed identity in your tenant for the duration rather than treating their external account as if it were internal. This keeps the guest pattern focused on what it does well, governing the authentication and the reach of external identities, and avoids stretching it into device management that fits employees far better than partners.

Pattern seven and the floor: require MFA for all users

The seventh pattern is the broad floor beneath the rest. Once the admins are protected, legacy authentication is blocked, sensitive apps demand a managed device, risky sign-ins step up, and guests are governed, there remains the everyday workforce signing in to everyday applications. Requiring MFA for all users sets the baseline that a password alone is never enough for anyone, which is the single control with the largest measured effect on account compromise. Microsoft’s published figures put the reduction in account-takeover risk from MFA in the high nineties of percent, and that number is why this floor belongs in every tenant regardless of size or industry.

The pattern targets all users, excludes break-glass accounts, and grants access with a multifactor requirement across the resources not already covered by a stronger pattern. In practice the all-user MFA floor and the admin and risk patterns overlap, and that overlap is intentional and safe because of how the engine combines controls. An admin signing in satisfies both the all-user MFA floor and the stronger admin authentication-strength pattern, and because requirements accumulate, the admin faces the stronger of the two. The floor guarantees nobody falls through a gap; the stronger patterns raise the bar for the populations that need it. The order to assemble them is to build the floor knowing the targeted patterns will layer on top, rather than trying to carve the floor into mutually exclusive slices.

Layering patterns without conflict and applying least privilege

A baseline is more than its patterns; it is the way they combine. The engine’s combination behavior, where block wins and grant requirements accumulate, is what lets a small catalog produce a coherent posture, but only if the patterns are designed to layer cleanly. The principle is that each pattern should own a distinct slice of the signal space and a distinct control, so that when two patterns match the same sign-in their controls add up to something sensible rather than something contradictory.

How do I keep patterns from fighting each other?

Conflicts come from two patterns trying to govern the same decision in incompatible ways, and they are designed out rather than debugged after. The discipline is one control concern per pattern. The admin pattern owns authentication strength for privileged roles; the device pattern owns the device requirement for sensitive apps; the legacy pattern owns the block on old protocols; the risk pattern owns the adaptive step-up. None of them tries to do another’s job. Because block always wins, you place the structural blocks, meaning legacy authentication and disallowed locations, with full awareness that they override every grant, and you never write a grant policy that assumes it can rescue a sign-in a block policy has already denied. Because grant requirements accumulate, you accept that a privileged admin on a sensitive app from a risky sign-in will face the union of admin strength, device compliance, and risk step-up, and you confirm through report-only that the union is reachable rather than an accidental lockout. Naming each pattern, documenting which slice it owns, and reviewing the set as a whole before enabling anything is what keeps the baseline legible. When a new requirement arrives, you ask which existing pattern owns that concern and extend it, rather than adding a fresh policy that quietly overlaps three others.

What does least privilege look like applied to these patterns?

Least privilege in Conditional Access is not a single setting; it is the shape of the whole baseline. It shows up as scoping each strong control to the population that needs it rather than the whole tenant: phishing-resistant strength for admins, not everyone; device compliance for sensitive apps, not every page; guest reach narrowed to the project at hand. It shows up as preferring the narrowest assignment that achieves the goal, role-based targeting for admins so privilege and protection move together, and sensitivity-based targeting for apps so the gate matches the data. It shows up in the exclusions being as small and as deliberate as possible, because every exclusion is a hole, and the only standing exclusions in a healthy baseline are the break-glass accounts and the temporary, deadline-bound exceptions for dependencies still being migrated. The opposite of least privilege here is the all-or-nothing baseline that either demands the strongest control of everyone, generating friction and exception sprawl, or demands a weak control of everyone, leaving the high-value accounts under-protected. The patterns let you draw the lines where the risk actually sits, and drawing them precisely is least privilege in practice. The sign-in context that determines which population a user falls into, and how the token reflects it, is covered in Microsoft Entra ID authentication explained, which underpins the assignment logic these patterns rely on.

The common misconfigurations and the breaches they enable

Patterns fail in predictable ways, and the failures are worth naming because each one maps to a real breach path. A baseline assembled without attention to these is a baseline with a door left open, and attackers are systematic about finding the open door.

The MFA-without-legacy-block gap

The most common and most damaging misconfiguration is enforcing MFA while leaving legacy authentication open. The tenant looks protected: MFA is on, the dashboard is green, the auditor is satisfied. But because legacy protocols cannot present a second factor, an attacker with a valid password signs in over IMAP or SMTP and the MFA requirement is never evaluated. This is not a theoretical gap; it is the path behind a large share of business-email-compromise incidents, where credential-spray tooling finds the one account whose password matches a breach dump and authenticates over a legacy protocol that ignores the MFA the organization thought it had. The fix is the second pattern, and the lesson is that admin MFA and the legacy block are not two independent choices but two halves of one control. Enabling the first without the second is worse than doing nothing, because it produces the confidence of protection without the substance.

The exclusion that became a permanent hole

Exclusions are necessary and dangerous. A break-glass account must be excluded so a policy mistake cannot lock everyone out. A service account on a legacy protocol might be excluded while its migration is planned. The danger is that exclusions are easy to add under pressure and almost never removed, so the temporary exception for one service account becomes a permanent unmonitored hole that an attacker eventually finds. The breach path is direct: the excluded account is the one account in the tenant that the patterns do not protect, so it is the account an attacker works to compromise. The mitigation is to treat every exclusion as a defect with a deadline. Document why it exists, when it will be removed, and who owns the removal, and review the exclusion list as a standing item. A baseline with five standing exclusions is a baseline with five accounts an attacker would love to own. The only exclusions that should outlive a quarter are the break-glass accounts, and even those should be alerted on every time they sign in.

The bespoke-policy sprawl that nobody understands

The slower failure is sprawl. A tenant that did not assemble from patterns ends up with policies named after the incident or the person who created them, with overlapping assignments and contradictory exclusions, and after a year nobody can answer the question of what would happen if a given user signed in. The breach path here is subtler than an open protocol: it is the gap that opens because no human can reason about the combined behavior of thirty interacting policies, so a sign-in that should have been blocked is granted by an unexpected interaction, and nobody notices because nobody understands the set. Sprawl also breeds fear, and fear breeds stagnation, because a team that cannot predict the effect of a change stops making changes, and a baseline that stops evolving falls behind the threats. The cure is consolidation back to named patterns: map the existing policies onto the catalog, identify which patterns they were trying to implement, rebuild those patterns cleanly, and retire the rest. It is painful and it is the only path back to a baseline you can reason about.

The report-only policy that never went live

The last misconfiguration is the one that looks like diligence. A team builds the right patterns, stages them all through report-only, and then never flips them to on, because flipping carries risk and nobody owns the decision. The result is a tenant whose dashboard shows a full set of policies, all of which are observing and none of which are enforcing. The breach path is that the controls the organization believes it has do not actually run. The fix is process rather than technology: every report-only policy needs an owner, a review date, and a decision to either enable it or explain why not. Report-only is a stage, not a destination, and a policy that has sat in report-only for six months is either ready to enable or no longer needed. The discipline that makes the patterns work is the same discipline that gets them out of report-only and into enforcement once the preview confirms they are safe.

How to verify the posture

A baseline you cannot verify is a baseline you are guessing about. Verification answers two questions: would this policy do what I intend before I enable it, and is the enabled set actually behaving as designed in production. Conditional Access gives you tools for both, and using them is the difference between a posture you can defend and one you hope is working.

How do I preview a policy before enabling it?

Two tools preview a policy without affecting users. Report-only mode, covered earlier, evaluates a policy against real sign-in traffic and records what it would have done, which is the truest preview because it uses your actual users on your actual applications and devices. The companion workbook breaks down report-only results so you can see how many sign-ins each policy would have affected, which users, and which applications, turning the preview into a decision you can make on evidence. The second tool is the What If evaluator, which lets you describe a hypothetical sign-in, specifying a user, an application, a device state, a location, and a client app, and reports which policies would apply and what controls would result. What If is for targeted questions, such as confirming that a specific admin on a specific app would be required to use phishing-resistant authentication, while report-only is for understanding the aggregate effect on real traffic. Use both: What If to check the cases you can name, report-only to catch the ones you did not anticipate.

What do I watch after a policy is live?

Once a policy is enforcing, the sign-in logs are the source of truth. Each sign-in record shows which Conditional Access policies were evaluated, which applied, and what the result was, so you can confirm that the patterns are firing on the sign-ins you expect and not firing on the ones you do not. Filtering the logs by policy result reveals failures, and a spike in failures after a change is the signal to investigate before the help-desk queue fills. Beyond the raw logs, the Conditional Access insights and the sign-in workbooks aggregate the picture over time, showing trends in MFA prompts, blocks, and risk-driven step-ups. The verification habit is to set a baseline of normal after enabling a pattern, then watch for deviation, because a sudden change in how often a policy applies usually means either an attack or a misconfiguration, and both deserve attention. Verification is not a one-time gate at enablement; it is an ongoing read of whether the assembled patterns still match reality as the tenant and its threats change.

How do I know the baseline still covers the threats?

Coverage drifts even when individual policies do not change, because the environment moves around them. New applications appear and may not be covered by the device pattern. New admin roles are assigned and need the admin pattern’s protection, which role-based targeting handles automatically but which still deserves a check. New partner relationships add guests who need the guest pattern. A periodic review maps the current catalog against the current environment and asks where a new gap has opened. The questions are concrete: is every privileged role inside the admin pattern, is legacy authentication still blocked with no new exclusions, is every sensitive application behind the device requirement, are the risk thresholds still appropriate, and have any exclusions outlived their deadline. Running this review on a schedule, and after any significant environment change, is how a static-looking baseline stays aligned with a moving target. The patterns make the review tractable, because you are checking a short list of named shapes rather than auditing thirty bespoke policies one interaction at a time.

How to make the baseline auditable and repeatable

A pattern clicked together in the portal is a pattern that exists only in one tenant’s memory. The moment you need to reproduce it in a second tenant, recover it after an accidental deletion, review what changed last quarter, or prove to an auditor what the policy actually says, the portal-only approach fails. Making the baseline auditable and repeatable means expressing the patterns as code, putting that code under version control, and deploying it through a reviewed pipeline, so the catalog becomes a managed artifact rather than a collection of manual clicks.

What does a pattern look like as code?

Conditional Access policies are objects in the Microsoft Graph, and every property you set in the portal maps to a field you can author in JSON or a deployment template. A policy that blocks legacy authentication, expressed against the Graph, reads as an assignment and a control set:

{
  "displayName": "Baseline - Block legacy authentication",
  "state": "enabledForReportingButNotEnforced",
  "conditions": {
    "users": {
      "includeUsers": ["All"],
      "excludeUsers": ["<break-glass-object-id-1>", "<break-glass-object-id-2>"]
    },
    "applications": { "includeApplications": ["All"] },
    "clientAppTypes": ["exchangeActiveSync", "other"]
  },
  "grantControls": {
    "operator": "OR",
    "builtInControls": ["block"]
  }
}

The policy begins in enabledForReportingButNotEnforced, which is report-only, so the same artifact that defines the enforced policy first defines the preview. Flipping state to enabled is the one-line change that promotes it, and because that change goes through the pipeline it is reviewed, recorded, and reversible. The break-glass object identifiers live in the exclusion list as a deliberate, visible part of the policy rather than a forgotten click.

How do I deploy and review the catalog?

You author each pattern as a file, store the files in a repository, and deploy them with a script that calls the Graph. A minimal PowerShell deployment using the Microsoft Graph module reads the policy definitions and creates or updates them:

Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess"
$patterns = Get-ChildItem -Path ./policies -Filter *.json
foreach ($file in $patterns) {
    $body = Get-Content $file.FullName -Raw
    New-MgIdentityConditionalAccessPolicy -BodyParameter $body
}

With the patterns in a repository, every change is a pull request. A reviewer sees the diff, meaning exactly which assignment or control changed, before it reaches the tenant, which catches the accidental all-users block or the removed exclusion that the portal would have let through silently. The repository becomes the audit trail: the history shows who changed what and when, the review record shows who approved it, and recovery from a bad change is a revert rather than a frantic reconstruction from memory. Standing up a second tenant becomes running the same deployment against a new target, so the baseline is reproducible by construction. Version control also makes the report-only-to-enforce promotion legible, because the commit that flips the state is the documented moment a pattern went live, with a name attached to the decision.

What naming and tagging keep the catalog legible?

Names are the cheapest documentation and the most neglected. A baseline whose policies are named after the catalog patterns, with a consistent prefix and a clear statement of assignment and control, can be read top to bottom and understood. A convention such as a Baseline - prefix followed by the pattern and its scope, for example Baseline - Require phishing-resistant MFA for admins and Baseline - Require compliant device for finance apps, tells anyone reading the policy list what each one does without opening it. The state belongs in the name during rollout, so a [Report-only] marker makes it obvious at a glance which patterns are previewing and which are enforcing, and removing the marker is part of promoting the policy. The naming convention lives in the repository alongside the policy files, so it is enforced by review rather than by hope. Legible names, version control, and a reviewed pipeline together turn the catalog from tribal knowledge into an asset the next engineer can inherit and an auditor can read.

Security defaults, Microsoft-managed policies, and your own catalog

Before assembling a custom catalog, it helps to know what the platform already offers and where the handoffs are, because choosing the wrong starting point either leaves you under-protected or duplicates work the platform does for free.

Security defaults are the entry-level option, available without the licensing that Conditional Access requires. They turn on a fixed set of protections for the whole tenant: they require all users to register for MFA, prompt for it when the platform judges it necessary, require MFA for administrators, and block legacy authentication. For a small organization on the free tier with no special requirements, security defaults are a reasonable floor and far better than nothing. Their limitation is exactly that they are fixed. You cannot scope them, exclude an account, target a specific application, or tune the behavior, so the moment you need a break-glass exclusion or an application-specific rule you have outgrown them. Security defaults and custom Conditional Access policies are mutually exclusive; enabling one requires disabling the other.

Microsoft-managed Conditional Access policies are a newer middle ground. The platform now creates and maintains a set of recommended policies in tenants that meet the criteria, covering shapes like requiring MFA for admin portal access and applying user-risk and sign-in-risk controls. These managed policies start in report-only so they do not surprise anyone, and an administrator can review them, exclude break-glass accounts, and move them to enforcement. They are a fast way to get the highest-value patterns running without authoring them, and you can duplicate a managed policy to create a customized version you own. The trade-off is that a managed policy is shaped by Microsoft’s general recommendation rather than your specific environment, so you adopt them as a head start and then extend with your own catalog where your needs differ.

Your own catalog is where the rest of this article lives. Custom Conditional Access policies give you the scoping, exclusions, targeting, and tuning that the managed and default options cannot, which is what the baseline-of-patterns rule depends on. The pragmatic path for most organizations is layered: start from security defaults if you are on the free tier, adopt the Microsoft-managed policies once you have the licensing as a fast baseline, and then build out the custom catalog to cover the patterns and the scoping the managed set does not reach. Confirm which managed policies are available to your tenant and their current behavior against Microsoft’s documentation, because the managed-policy program is active and its coverage expands over time.

A phased rollout plan for the baseline

Assembling the catalog is a sequence, not a single deployment, and the sequence matters because some patterns protect the rollout of others and because each pattern needs its own report-only soak. A rollout that enables everything at once is a rollout that produces a help-desk surge and a rushed rollback. The phased plan trades a little time for a lot of safety.

The first phase establishes the safety net before anything else: create and harden the break-glass accounts, confirm they can sign in with a phishing-resistant factor, and set up alerting on their use. Nothing else proceeds until the recovery hatch is proven, because every subsequent pattern carries lockout risk and the break-glass accounts are the insurance against it. The second phase closes the two highest-value, lowest-controversy gaps: require MFA for administrators and block legacy authentication. Both are staged through report-only, both have their reports read against real traffic, and both are enabled once the preview confirms no surprise. These two patterns deliver the largest risk reduction for the least disruption, so they come first among the enforcement steps.

The third phase broadens the MFA floor to all users and introduces location tuning by marking the corporate networks as trusted, which lowers prompt frequency for in-office sign-ins and prepares the ground for risk-based controls. The fourth phase adds the device requirement for sensitive applications, which depends on a healthy device-management foundation and a communication plan, so it follows once Intune compliance is confirmed and users have been told. The fifth phase adds risk-based step-up, which depends on the higher licensing and on Identity Protection signals being available, and it is sequenced late because it is the most sensitive to false positives and benefits from the trusted-location tuning done earlier. The sixth phase governs guests and external access, paired with access reviews so external access expires rather than lingers. Each phase is its own report-only soak and its own enablement decision, and each is reversible because each pattern lives in version control. Running the phases in this order means that at every step the tenant is more protected than before, the break-glass safety net is always in place, and no single phase carries enough blast radius to take the organization down. The rollout is a place to assemble and test the full baseline in report-only before committing, and pairing it with hands-on practice in a sandbox lets the team rehearse each phase before touching production. You can run the hands-on Azure labs and command library on VaultBook to build and test a pattern baseline in report-only against a practice tenant, working through each phase of this plan before you apply it to a live directory.

Patterns beyond the core seven

The catalog covers the threats that belong in every baseline, but several additional patterns earn a place once the core is solid. They are refinements rather than foundations, and adopting them prematurely is how a clean baseline starts to sprawl, so they come after the seven are assembled and verified.

Authentication context lets you attach a step-up requirement to a specific sensitive action rather than to an entire application, so a user can browse a record system freely but must satisfy phishing-resistant MFA the moment they attempt a high-impact operation inside it. This is a precise tool for applications that mix routine and sensitive actions, and it avoids the blunt choice between gating the whole app and gating none of it. Sign-in frequency as a session control forces reauthentication on an interval for high-value sessions, which limits how long a stolen session token remains useful, and it pairs naturally with the admin and risk patterns where a long-lived privileged session is a liability. Persistent browser session controls decide whether a user stays signed in across browser restarts, and turning persistence off for sensitive populations reduces the window in which a borrowed or compromised browser carries a live session.

App-enforced restrictions let a session reach an application but limit what it can do inside, such as allowing a browser session to view but not download content from an unmanaged device, which is a middle path between full access and a hard block for cases where some access is reasonable but data exfiltration is the concern. Token protection, an evolving control, binds a session token to the device that obtained it so a stolen token cannot be replayed from another machine, which addresses the token-theft attacks that defeat MFA after the fact. Terms-of-use acceptance, beyond its role in the guest pattern, provides an auditable record of agreement for any population where you need proof that the user accepted handling rules. Each of these is a real control with a real use, and each should enter the baseline the same way the core patterns did: named, staged through report-only, scoped to the population that needs it, and added to the version-controlled catalog so it does not become an untracked one-off. The test for adopting one is whether it addresses a threat the core seven leave open in your specific environment, and if it does not, it does not belong in your baseline no matter how interesting it is.

Keeping the baseline healthy over time

A baseline is not a project that ends; it is a system that needs an owner. The patterns degrade not because they break but because the world around them changes, and a baseline with no one responsible drifts back toward the open-door state it was built to prevent. Three operational habits keep it healthy, and all three are cheap compared to the incident they avert.

The first habit is ownership. One named person or team owns the catalog, approves changes through the pipeline, and is accountable for the posture. Ownership is what prevents the bespoke-policy sprawl that comes from many hands adding rules without coordination, and it is what ensures the report-only-to-enforce decisions actually get made. The owner does not have to make every change, but every change passes through their review, so the catalog stays coherent. The second habit is the scheduled review, run quarterly and after any major environment change, that walks the catalog against the current tenant and asks the coverage questions: every privileged role inside the admin pattern, legacy authentication still blocked, sensitive applications behind the device requirement, risk thresholds still appropriate, and every exclusion still justified with a live deadline. The review is short because the catalog is short, which is the dividend the baseline-of-patterns rule pays back.

The third habit is monitoring that turns the baseline into a sensor. Because every sign-in records which policies applied, the enforced patterns become a continuous signal of what is happening in the tenant. A surge in risk-based step-ups can be the first sign of a credential-spray campaign. A spike in device-compliance failures can mean an Intune problem or a fleet that fell behind on patches. A sudden appearance of legacy-authentication attempts after months of none can mean a new application was deployed with an old connection string or that an attacker is probing for the gap. Watching these signals means the baseline does double duty, enforcing the posture and reporting on the threats it faces, and an owner who reads the signals catches problems while they are small. A healthy baseline is one with an owner who reviews it on a schedule and reads what it reports, and those habits cost far less than the breach that an unowned, unreviewed, unmonitored baseline eventually allows.

The verdict

A strong Conditional Access posture is not a feat of invention. It is the disciplined assembly of a small set of proven patterns: protect the administrators with strong, phishing-resistant authentication, block the legacy protocols that bypass MFA entirely, require a managed device for the applications that hold sensitive data, step up authentication when Identity Protection flags risk, control the locations and the guests at the edges, and set an MFA floor beneath everyone. That is the whole baseline, and its power comes from being short enough to reason about and proven enough to trust. The teams that struggle with Conditional Access are almost never struggling with the engine’s capability; they are struggling with design, and the catalog is the answer to a design problem.

The two failures to avoid are the open door and the maze. The open door is the foundational gap, most often MFA enforced while legacy authentication stays open, which produces the confidence of protection without the substance and is the path behind a large share of account-compromise incidents. The maze is bespoke sprawl, the pile of overlapping one-off policies that nobody can reason about, which opens gaps through unpredictable interactions and breeds the fear that stops the baseline from evolving. The baseline-of-patterns rule routes around both: a small catalog of named shapes, each owning a distinct concern, each staged through report-only before enforcement, each expressed as version-controlled code, and the whole set owned and reviewed on a schedule. Assemble those seven patterns in that disciplined way and you have a posture an attacker must defeat layer by layer, an auditor can read, and the next engineer can inherit. Invent your own policies one incident at a time and you have a maze with an open door somewhere in it that you will find out about from the breach report. The catalog exists so you do not have to learn that lesson the expensive way.

Frequently asked questions

What are the proven Conditional Access patterns every baseline should include?

A defensible baseline assembles a short set of tested shapes rather than inventing rules from scratch. The patterns that earn a place in nearly every tenant are: require multifactor authentication for administrators, ideally with a phishing-resistant strength; block legacy authentication so older protocols cannot bypass MFA; require a compliant or hybrid-joined device for sensitive applications; step up authentication when Microsoft Entra ID Protection flags a risky sign-in or a risky user; control access by location for organizations with a fixed operating footprint; govern guest and external access with MFA, narrow reach, and expiring grants; and set an all-user MFA floor beneath everyone. Each pattern addresses a specific threat, and because each is understood in isolation, the combined set is predictable. The reason to work from this catalog is that the patterns carry other organizations’ incident history, so you inherit lessons instead of repeating them, and the engineering effort goes into adapting and layering proven shapes rather than designing security from a blank policy editor.

How do I require MFA for administrators in Microsoft Entra?

Create a Conditional Access policy that targets directory roles rather than a static group, so protection follows the privilege automatically when someone is assigned a role later. Select the privileged roles, starting with Global Administrator and including Security Administrator, Privileged Role Administrator, Conditional Access Administrator, and the other identity and application administrators. Target the management portals and the management API surface as the resources. For the grant control, prefer requiring an authentication strength that demands phishing-resistant methods such as FIDO2 keys or Windows Hello for Business, rather than generic MFA that accepts an interceptable code. Exclude your break-glass emergency accounts so a misconfiguration cannot lock everyone out, and protect those accounts with a strong non-interactive factor instead. Stage the policy in report-only, read the results against real admin sign-ins, then enable it. Microsoft already enforces MFA on its admin portals, but owning an explicit pattern means your posture does not depend on someone else’s enforcement schedule, and authentication strength raises the bar above the platform minimum.

How do I block legacy authentication as part of the baseline?

First find what still uses it, because blind blocking causes outages. Filter the Entra sign-in logs, both interactive and non-interactive, by the legacy client-app categories to see which accounts and applications still authenticate over IMAP, POP3, SMTP, MAPI, or older Office clients, and use the dedicated legacy-authentication workbook to triage. Plan the migration of every legitimate dependency to modern authentication or to a managed identity. Then create a policy targeting all users, conditioned on the legacy and other-clients app categories, with the grant control set to block. Exclude your break-glass accounts and, temporarily and with a hard deadline, any unmigrated dependency. Stage in report-only, confirm the preview matches your inventory, then enable. Remember that user-scoped policies do not stop service principals, so a service-principal integration on a legacy flow needs a separate workload-identity policy, and the cleaner fix for a script account is a managed identity. Blocking legacy authentication closes the MFA-bypass path that most password-spray attacks rely on.

How do I require compliant devices without locking people out?

Scope the requirement to the applications that genuinely hold sensitive data rather than the whole tenant, because demanding a managed device to read a public page is friction with no payoff. Decide whether you will accept a device marked compliant by Intune, a hybrid Entra joined device, or either, based on how mixed your fleet is. Before enabling, confirm your device-management foundation is healthy, meaning Intune enrollment works and compliance policies evaluate correctly, because the pattern is only as reliable as the compliance signal beneath it. Communicate the change in advance and give people an enrollment path or a managed alternative such as a virtual desktop for cases where the physical device cannot comply. Stage through report-only to measure how many real sign-ins would be refused and from which devices, which surfaces both the unmanaged-device population and any compliant machines wrongly reported as non-compliant. Enable only when the preview is acceptable, and pair the rollout with a way for users to see why a device was refused so the help desk is not the only path to resolution.

How do risk-based Conditional Access policies step up authentication?

They use Microsoft Entra ID Protection, which scores two kinds of risk. Sign-in risk estimates whether a specific attempt is the legitimate owner, drawing on signals like anonymous IP addresses, unfamiliar locations, impossible travel, and known-malicious addresses. User risk estimates whether the account itself is compromised, raised by leaked credentials or a user reporting a suspicious prompt. You build two policies. The sign-in-risk policy targets all users, excludes break-glass accounts, conditions on medium and high sign-in risk, and grants access only after the user satisfies a strong authentication strength, with a session control that reauthenticates every time. The user-risk policy conditions on high user risk and grants access only after a secure password change, which both proves control and rotates the stolen secret. Microsoft’s recommended thresholds balance protection against false-positive noise. Note that risk signals require higher Entra licensing, and the legacy risk policies inside Identity Protection are being retired in favor of Conditional Access, so plan any migration and confirm the current timeline against Microsoft’s documentation.

How do I handle location and guest access in the baseline?

Treat location as a supporting control, not a primary gate, because attackers route through allowed countries and legitimate users travel. Define named locations from your corporate egress addresses and mark them trusted, which both feeds location policies and lowers risk scores for in-office sign-ins. A country block trims opportunistic traffic from regions you never operate in but will not stop a motivated adversary, so use it as a way to shrink the haystack while maintaining an accurate allow list and a fast exception process. For guests, apply a distinct pattern: require MFA because you cannot assume the partner enforces it, require terms-of-use acceptance for an auditable record, and use cross-tenant access settings to decide which partner tenants and applications guests can reach. Pair the Conditional Access controls with entitlement discipline, meaning access packages and access reviews so guest access expires rather than lingering, because the most common guest failure is stale access rather than weak authentication. Device requirements rarely fit guests, since their machines belong to their organization.

What licensing do Conditional Access patterns require?

Conditional Access itself requires Microsoft Entra ID P1, which covers the structural patterns: admin MFA, blocking legacy authentication, device compliance, location controls, guest governance, and the all-user MFA floor. Risk-based patterns require P2, because the sign-in-risk and user-risk signals come from Microsoft Entra ID Protection, which is a P2 capability. Organizations on the free tier without Conditional Access can still get a fixed floor from security defaults, which enforce MFA and block legacy authentication for the whole tenant but cannot be scoped, excluded, or tuned. The practical sequencing is to assemble the P1 patterns first, since they close the largest gaps and do not depend on risk signals, then add the P2 risk-based step-up when the licensing is in place. Confirm your tenant’s entitlement before designing around any signal, because building a baseline that assumes a condition you cannot read leaves a hole where you believed you had a control. Verify current licensing requirements against Microsoft’s documentation, as entitlements shift over time.

Why is report-only mode important when rolling out patterns?

Report-only mode evaluates a policy against real sign-ins exactly as an enabled policy would, records the result in the sign-in logs, but never enforces the control. Nobody is blocked or prompted, so you get a faithful preview of what the policy would do to your actual traffic before it can cause harm. This matters because Conditional Access changes are blunt: a policy that looks correct in the editor can lock out a service account, a conference-room device, or an entire office whose traffic you did not anticipate. Report-only turns that risk into evidence you can read in the companion workbook, which shows how many sign-ins, which users, and which applications each policy would have affected. The discipline is to stage every pattern through report-only, let it observe for a week or two, confirm the preview matches your intent, and only then move it to on. Report-only is a stage, not a destination, so every report-only policy needs an owner and a date to either enable it or explain why not, because a policy that only observes protects nothing.

How do Conditional Access policies behave when several apply at once?

The engine does not pick one policy; it evaluates every policy that matches the sign-in and combines their controls. Block always wins, so if any matching policy blocks access, the sign-in is denied no matter what other policies would grant. Among granting policies, the requirements accumulate, so a sign-in that triggers both an MFA policy and a compliant-device policy must satisfy both. This combination behavior is why a small catalog of patterns produces a coherent posture: when each pattern owns a distinct slice of the signal space and a distinct control, the union of their controls is predictable. It is also why bespoke sprawl fails, because many overlapping policies combine in ways no human anticipated, and the surprise arrives as locked-out users. Design with the combination in mind: place structural blocks knowing they override every grant, and accept that a privileged admin on a sensitive app during a risky sign-in faces the union of admin strength, device compliance, and risk step-up. Confirm through report-only that the union is reachable rather than an accidental lockout.

What are break-glass accounts and how do they fit the patterns?

Break-glass accounts, also called emergency access accounts, are privileged accounts not tied to a specific person, kept as a recovery hatch for when Conditional Access is misconfigured or the MFA provider fails. Every organization should have at least two. The historical advice was to exclude them from all Conditional Access policies so a policy mistake could never lock everyone out, but as Microsoft’s mandatory MFA has closed the gaps that exclusions relied on, the guidance has shifted toward protecting these accounts with a strong non-interactive factor that does not depend on the systems most likely to fail, such as a FIDO2 passkey or certificate-based authentication. They remain excluded from the risk-based and device-based patterns that could trap them, but they should still satisfy a phishing-resistant factor so the recovery hatch is not the weakest link. Store the credentials offline, split knowledge across two custodians, alert on every sign-in, and review them on a schedule. Design the break-glass handling alongside the admin MFA pattern, since that pattern is the one most likely to lock you out if the exclusions are wrong.

How do I migrate from bespoke Conditional Access policies to a clean catalog?

Start by mapping what you have onto the catalog. For each existing policy, ask which pattern it was trying to implement: admin MFA, legacy block, device compliance, risk step-up, location, guest, or the MFA floor. Group the policies by the pattern they belong to, which usually reveals that several overlapping policies were clumsy attempts at the same shape. Then rebuild each pattern cleanly as a single, well-named, version-controlled policy with deliberate assignments and minimal exclusions, staged through report-only so you can compare its behavior against the old set before cutting over. Run the new and old policies side by side in report-only where possible, confirm the new pattern covers what the old ones did, then retire the old policies. Pay special attention to exclusions during the migration, because the old policies likely accumulated standing exclusions that became permanent holes, and the rebuild is the chance to remove the ones without a live justification. The migration is painful and it is the only path from a maze you cannot reason about back to a baseline you can.

Can Conditional Access protect service accounts and automation?

Conditional Access policies scoped to users do not block calls made by service principals, so a user-scoped policy does not protect or restrict automation that authenticates as a service principal. For workload identities you need Conditional Access for workload identities, which is a separate set of policies that target service principals directly and can restrict them by location or block risky ones. The better long-term answer for automation is to replace user-based service accounts and stored secrets with managed identities, which authenticate through a modern, certificate-backed flow that does not carry a password to steal and does not rely on legacy protocols. When you block legacy authentication, audit your automation, because a script using a legacy flow as a service principal will not be caught by the user-scoped block and may continue running unprotected. Inventory every non-human identity, move interactive service accounts to managed identities where the platform supports it, and apply workload-identity Conditional Access to the service principals that remain, so automation is governed rather than an unmonitored exception.

What is the difference between requiring MFA and requiring authentication strength?

Requiring MFA accepts any registered second factor, including a one-time code over SMS or a voice call, which satisfies the requirement but can be defeated by SIM swapping or phishing of the code. Requiring an authentication strength lets you demand a specific class of method, and the strongest built-in option is phishing-resistant, which accepts only FIDO2 security keys, Windows Hello for Business, or certificate-based authentication. The trade-off is registration effort, because phishing-resistant methods require provisioning hardware or device-bound credentials rather than enrolling a phone. The right call is to scope authentication strength by population: require phishing-resistant strength for administrators and other high-value accounts whose compromise is catastrophic, and accept ordinary MFA for the general workforce where the registration burden of hardware keys outweighs the marginal risk reduction. Authentication strength is the modern grant control, and it is increasingly the recommended choice for risk-based step-up as well, since a risky sign-in is exactly the moment you want proof that cannot be phished. Plan a registration campaign before you require phishing-resistant strength, because the gate is only as good as the methods users have enrolled.

How often should I review the Conditional Access baseline?

Run a structured review quarterly and after any major environment change, such as a merger, a new line-of-business application, or a shift in the partner ecosystem. The review walks the catalog against the current tenant and asks the coverage questions: is every privileged role inside the admin pattern, is legacy authentication still blocked with no new exclusions, is every sensitive application behind the device requirement, are the risk thresholds still appropriate, and has any exclusion outlived its deadline. The review is short because the catalog is short, which is one of the dividends of assembling from patterns rather than maintaining sprawl. Between reviews, monitor continuously, because the sign-in logs record which policies applied to every sign-in, turning the enforced baseline into a sensor for the threats it faces. A surge in risk step-ups, device-compliance failures, or legacy-authentication attempts is a signal worth investigating while it is small. Coverage drifts even when policies do not change, because new applications, roles, and partners appear around a static baseline, so the scheduled review is what keeps a stable-looking posture aligned with a moving environment.

Should I use security defaults or custom Conditional Access policies?

Security defaults are the free-tier floor: they require MFA registration, prompt for MFA when the platform judges it necessary, require MFA for admins, and block legacy authentication, with no licensing beyond the base tier. They are a reasonable starting point for a small organization with no special needs and far better than nothing. Their limitation is that they are fixed: you cannot scope them, exclude an account, target a specific application, or tune the behavior, and the moment you need a break-glass exclusion or an application-specific rule you have outgrown them. Custom Conditional Access policies, which require Entra ID P1 or P2, give you the scoping, exclusions, and targeting that the baseline-of-patterns rule depends on. Security defaults and custom policies are mutually exclusive, so enabling custom Conditional Access means turning security defaults off. The pragmatic path is to use security defaults while on the free tier, adopt the Microsoft-managed policies as a fast head start once you have the licensing, and then build the custom catalog to cover the patterns and scoping the managed and default options cannot reach.

What are Microsoft-managed Conditional Access policies?

Microsoft-managed policies are recommended Conditional Access policies that the platform creates and maintains in eligible tenants, covering high-value shapes such as requiring MFA for admin portal access and applying user-risk and sign-in-risk controls. They start in report-only so they do not surprise anyone, and an administrator can review them, exclude break-glass accounts, and promote them to enforcement. They are a fast way to get the highest-value patterns running without authoring them by hand, and you can duplicate a managed policy to create a customized version you own and control. The trade-off is that a managed policy reflects Microsoft’s general recommendation rather than your specific environment, so you adopt them as a head start and extend with your own catalog where your needs differ. Treat them as one layer in a strategy that also includes your custom patterns, review what the platform has created in your tenant rather than assuming it matches your intent, and confirm the current coverage of the managed-policy program against Microsoft’s documentation, because it is an active program whose scope expands over time.

How do I make Conditional Access policies repeatable across tenants?

Express each policy as code rather than clicking it in the portal. Conditional Access policies are Microsoft Graph objects, so every property maps to a field you can author in JSON, store in a repository, and deploy with a script using the Microsoft Graph PowerShell module or the Graph API directly. With the patterns in version control, standing up a second tenant is running the same deployment against a new target, and recovery from an accidental deletion is a redeploy rather than a reconstruction from memory. Version control also gives you the audit trail, because the commit history shows who changed what and when, and the review record shows who approved it, so every change passes a reviewer who sees the diff before it reaches the tenant. Begin each policy in report-only within the artifact, so the same definition that previews the policy also enforces it once you flip the state, and that flip becomes a documented, reviewed, reversible decision. Reproducibility, auditability, and safe promotion all come from treating the catalog as managed code rather than tribal knowledge held in one administrator’s portal session.

What happens if I block legacy authentication and something breaks?

If you have staged through report-only and read the results, little should break, because the preview shows you every account and application still using legacy protocols before enforcement. If something does break after enabling, the sign-in logs tell you precisely what: filter for the blocked sign-ins and the client-app field identifies the legacy protocol and the account involved. The usual culprits are an old multifunction printer scanning to email over SMTP, a line-of-business application with a hardcoded IMAP connection, or a service account in a script. The immediate mitigation is a temporary, deadline-bound exclusion for the specific account while you migrate it to modern authentication or a managed identity, and the permanent fix is that migration rather than a standing exclusion. Resist leaving the exclusion open, because the unmigrated account becomes exactly the MFA-bypass hole the pattern was meant to close. Because the policy lives in version control, adding and later removing the exclusion are both reviewed changes with a record, so the temporary exception does not quietly become permanent the way a forgotten portal click would.

Do these patterns replace a full Zero Trust strategy?

No. The patterns are a strong identity-layer baseline, and identity is the first and most important pillar of Zero Trust, but Zero Trust is broader. The verify-explicitly principle, which says every access request is authenticated and authorized on all available signals, is exactly what risk-based step-up and device compliance implement, so these patterns are Zero Trust applied to sign-in. But Zero Trust also covers least-privilege access through fine-grained authorization and just-in-time elevation, network microsegmentation, data classification and protection, and assume-breach practices like comprehensive logging and lateral-movement containment, which Conditional Access does not address on its own. Treat the catalog as the identity foundation that the rest of a Zero Trust program builds on, not as the whole program. The patterns get the most consequential identity controls in place, and from there the work extends to authorization, network, data, and monitoring. An organization that has assembled this baseline has done the single most impactful piece of a Zero Trust journey, but it has not finished it, and conflating the two leaves the other pillars unaddressed while the dashboard suggests completeness.

Where can I practice building a Conditional Access baseline safely?

Build and test the baseline in report-only against a non-production tenant before you touch a live directory, so you can rehearse each phase of the rollout, observe how the patterns combine, and read the report-only workbook without any risk of locking out real users. A practice tenant lets you deliberately misconfigure a policy and watch the What If evaluator and the sign-in logs reveal the effect, which builds the intuition that makes production changes safe. You can run the hands-on Azure labs and command library on VaultBook to work through assembling each pattern, staging it through report-only, and expressing it as code against a sandbox tenant, which lets the team practice the full phased plan end to end before applying it anywhere it matters. Rehearsing the assembly, the layering, and the report-only-to-enforce promotion in a safe environment is how a team turns the catalog from a document into a skill, so that when the patterns go into a production tenant the moves are familiar and the outcomes are predictable rather than discovered live.