Conditional Access, the control most teams skip

You enforced multi-factor authentication months ago. You remember the rollout: the help desk tickets, the one executive who could not find the authenticator app, the week of "is this you?" pings. It worked. You moved on. There were 40 other things on the list, and a login prompt with a code in it felt like the finish line for identity security.

Then a login shows up in the sign-in logs that should not exist. Right password, valid second factor, a sign-in from a device and a place that make no sense for the person it belongs to. The account was not weak. The session was hijacked, or the user got phished into approving a prompt, and the second factor did its job and let the attacker in anyway. Nothing was misconfigured. The control you turned on simply was not designed to ask the next question: should this sign-in be allowed at all, given everything you know about it?

That next question is Conditional Access. It is sitting in the same Microsoft Entra admin center you already pay for, mostly unused, doing a fraction of what it could. This is about why teams skip it, what it buys you, and how to turn it on without becoming the person who locked out the sales floor on a Tuesday.

Multi-factor authentication answers one question: can you prove you are you. Conditional Access answers a harder one: given who you are, what you are using, and where you are coming from, should this sign-in proceed, and on what terms.

It works as a set of if-then rules that Entra evaluates at sign-in. The "if" is signals: the user or group, the app being reached, the device state, the location, and a risk score Microsoft calculates from how the sign-in behaves. The "then" is a decision: allow it, block it, force a fresh multi-factor prompt, or require a managed and compliant device. (Microsoft documents Conditional Access in Entra.)

The practical difference looks like this:

• A sign-in to your finance app from an unmanaged personal laptop can be required to pass an extra check, or blocked outright.
• A session that started in one country and resumes an hour later from another can be challenged before it touches your data.
• Legacy authentication protocols that cannot do multi-factor at all can be blocked, closing the back door that quietly undoes your whole rollout.

None of that is a new product. It is policy you write on top of identity you already own.

If Conditional Access is this useful and already paid for, the obvious question is why it sits idle in so many tenants. The answer is not ignorance. It is operating cost, the kind that does not show up on an invoice.

Conditional Access is unforgiving. A policy written carelessly does not produce a warning; it produces a help desk on fire. Block the wrong app and a team cannot work. Require a compliant device before your devices are enrolled and you have locked out the people you were trying to protect. The downside of a mistake is immediate and loud, and it lands on the same overworked person who would have configured it. So the rational move, for a team of one or two, is to leave it alone. The control that could prevent the worst incident is the control nobody has a safe afternoon to touch.

A control you own but never roll out is not protection. It is a license you are paying to leave switched off.

This is the shape of the real gap at small companies. It is rarely a missing tool. The capability is bought, documented, and waiting. What is missing is the time and the method to roll it out without breaking the business, then the ongoing attention to keep it tuned as people and apps change. Security here is an operating problem, not a shopping problem.

The good news is that Microsoft built a safety net specifically for this, and using it is the whole trick. Conditional Access has a report-only mode that evaluates a policy against real sign-ins and records what it would have done, without enforcing anything. (Microsoft documents report-only mode for Conditional Access policies.)

A safe rollout follows a sequence, never a single switch:

1. Create a break-glass account that is excluded from every policy, so a misfire can never lock you out of your own tenant. Microsoft recommends emergency access accounts for exactly this. (Microsoft documents emergency access accounts.)
2. Write each policy in report-only mode and let it run against live traffic for a week, then read the sign-in logs to see who it would have affected.
3. Start with the policies that carry the least surprise: block legacy authentication, require multi-factor for everyone, protect the admin portals.
4. Promote one policy at a time from report-only to enforced, watch for a day, and only then move to the next.

The method is boring on purpose. Boring is what keeps the sales floor working while the protection goes live. The hard part was never the clicking; it was knowing the order, reading the logs with care, and having the hours to do it well, not at 11 p.m. between other fires.

Go back to that impossible sign-in in your logs. The uncomfortable part was not that you lacked a tool to stop it. You owned the tool the entire time. It was sitting one blade over from the multi-factor setting you were so proud of, waiting for someone with a safe afternoon and a tested sequence to switch it on.

That is the quiet truth about security at a small company. The license is almost never the thing standing between you and a real incident. The thing standing in the way is hours, method, and the nerve to roll out an unforgiving control without breaking the people who depend on it. Conditional Access is not a product you are missing. It is work you have not had time to do.

So the question worth sitting with is this: how much of the protection you are already paying for is switched off right now, not because you decided against it, but because nobody had the afternoon to turn it on safely?