Conditional Access in Plain English

Picture a good bouncer at a private event. He is not there to keep people out. He is there to let the right people in quickly, and to ask more questions when something does not add up. He has a guest list. He glances at the ID. He notices you showed up at two in the morning for an event that ended at eleven. Most nights nobody notices him.

That is Conditional Access: the rules sitting between your staff and your company’s email, files, and applications, deciding on every sign-in whether to wave the person through, ask for a second proof of identity, or say no. The name sounds like it belongs on a networking exam, which is a shame, because the idea is simple and the payoff is large. Here is what it checks, which rules are worth the trouble, and the account you must create first.

What the Bouncer Can Actually Check

Microsoft describes Conditional Access as combining signals like user, device, and location to automate decisions and enforce access policies for resources. A policy is really a sentence: when these conditions are true, require this, or block it. The conditions are broader than most owners expect.

• Who is signing in. Specific people, groups, or administrative roles. You can also carve out exclusions, which matters more than it sounds.
• What they are trying to reach. Microsoft calls these target resources: individual applications and services, user actions like registering a device, and authentication contexts for sensitive operations.
• What device they are on. The platform, meaning Windows, macOS, iOS, or Android, and device attributes such as whether the machine is managed by your organization.
• Where the request is coming from. Network locations, defined ahead of time as known organizational locations, typically your office network’s public address.
• What app is doing the asking. Client app types, which separates modern applications from older ones that authenticate in outdated ways.
• How risky the sign-in looks. Sign-in risk and user risk signals, which Microsoft supplies through Microsoft Entra ID Protection. These are judgments about whether a login looks like the person it claims to be.

The important word is “combining.” Any one signal alone is blunt. Together they let you write a rule that is strict about the unusual and invisible for the ordinary.

Why This Beats Blanket Restrictions

Plenty of small businesses solve access problems with a wall. No email on phones. No work from outside the office. Everyone types a code every time, forever.

Walls fail predictably. They do not get removed when they become inconvenient. They get routed around. Somebody forwards work email to a personal account to answer a client from the parking lot. Somebody keeps a text file of passwords because there are nine and they change monthly. Your controls look great on paper while the data walks out a side door.

Conditional Access lets you be strict where strictness is cheap and lenient where it is not. Someone signing in from their managed laptop, at your office, at ten in the morning gets through without friction. That same account from an unrecognized device at three in the morning gets asked for more, or stopped. Same rule, different answer. That is why good policies make staff complain less, not more.

The Handful of Policies Most Small Businesses Benefit From

Microsoft’s deployment plan is organized in phases, and the ordering is instructive: foundation items first, then core authentication, then advanced protections. Small businesses get most of the value from the first two.

1. Block legacy authentication. Microsoft lists this first for a reason. Older sign-in methods predate modern multifactor authentication and cannot honor it, so leaving them on is a bypass around everything else you build. Highest value policy on the list.
2. Protect the multifactor registration process. Microsoft’s plan calls for securing the security information registration page. If an attacker can enroll their own second factor on a stolen account, your multifactor authentication is protecting them, not you.
3. Require strong authentication for administrators. Microsoft recommends enforcing phishing-resistant methods for privileged roles. Administrator accounts are worth far more to an attacker, so hold them to a higher standard. Our explainer on what a YubiKey is covers what phishing-resistant hardware looks like.
4. Require strong authentication for everyone else. The same idea applied broadly, in Microsoft’s second phase.
5. Protect guest and external access. Contractors, vendors, and partners with accounts in your environment should not run on the same assumptions as employees.
6. Add risk-based rules once the basics are done. Microsoft puts restricting high-risk sign-ins and high-risk users in its later phase. Do not start here.

Notice what is not on that list: rules blocking entire countries, or locking every login to the office network. Those are occasionally right, but they break travel, remote work, and phones in ways that generate more support calls than prevented incidents.

The Account You Must Create First

This is the part we insist on. Before enabling a single enforcing policy, create emergency access accounts, sometimes called break glass accounts. Microsoft is unambiguous: it recommends excluding them from your policies to prevent lockout due to policy misconfiguration, and notes that if all administrators are locked out, an emergency access account can be used to sign in and recover access.

The failure mode is easy to picture. You write a policy requiring a managed device. It applies to administrators too. Your managed device dies. Nobody can get in to fix the policy keeping everybody out. Microsoft’s guidance here is specific.

• Create two or more. Not one. Two, so a single failure does not lock you out.
• Make them cloud-only. Microsoft specifies they should use the default onmicrosoft.com domain and should not be federated or synchronized from an on-premises environment, so an outage on your own systems cannot take them with it.
• Exclude them from policies that block or restrict sign-in. Microsoft adds a nuance: report-only policies do not block access, so they need no exclusion.
• Use a strong, separate authentication method. Microsoft recommends phishing-resistant options such as a passkey or certificate-based authentication, different from what your normal administrator accounts use.
• Do not tie them to a person, and store the credentials physically. Microsoft’s guidance is secure, fireproof safes in separate locations, available to more than one administrator.
• Test them on a schedule. Microsoft recommends validating that they can sign in and perform administrative tasks at least every ninety days. An untested emergency account is not an emergency account.

Test in Report-Only Mode Before You Enforce

Every policy can be saved in a mode that evaluates without enforcing. Microsoft explains that after saving a policy in report-only mode, you see the effect on real-time sign-ins in the sign-in logs, and the aggregate effect in an insights and reporting workbook. All the thinking, none of the blocking.

Microsoft’s plan recommends leaving policies in report-only for at least a week before enforcing. Take that seriously. A week catches the traveling salesperson, the accountant who works Sundays, and the shared tablet nobody mentioned. There is also a What If tool that simulates a sign-in and shows which policies apply, the fastest way to see why someone is or is not affected.

The Bottom Line

Conditional Access is a simple idea buried under an unfortunate name. Decide who gets in, from what, from where, and how hard to look at each request. Then write it down as rules the system enforces, instead of hoping everyone remembers the policy.

Start narrow. Block legacy sign-in methods, protect your administrators, create your emergency accounts, and run everything in report-only for a week. Boring is the right temperature for identity work. It pairs with sorting out your second-factor strategy, covered in YubiKey versus passkey versus MFA.

If you want a second set of eyes before flipping a policy to enforcing, or you are unsure whether your setup still has a legacy sign-in hole, we do this work for businesses across Denton County. Contact us today.

Sources:

• Plan a Microsoft Entra Conditional Access deployment, Microsoft Learn
• Manage emergency access admin accounts in Microsoft Entra ID, Microsoft Learn