Rolling out MFA and Conditional Access without locking people out

Start by finding what will break

The organisations that get to a hundred percent are not the ones with better tooling. They are the ones that did the rollout in an order that made a lockout impossible.

Before enabling anything, spend a session finding the accounts that do not have a human attached to them. These are what break MFA rollouts, and they are almost never on the initial list.

• Service accounts running scheduled tasks, backups, integrations, or line-of-business connectors
• Shared mailboxes and shared logins on systems that never supported individual accounts
• Legacy protocols still in use by an old scanner, a copier that emails documents, or an application that authenticates with a username and password only
• External and guest accounts belonging to partners, contractors, or auditors
• Break-glass accounts, or the absence of them

Your identity provider's sign-in logs will tell you most of this. Filter for successful authentications that did not use modern authentication, and for accounts whose sign-in pattern looks like a machine rather than a person.

Create the break-glass account first

Before any policy is enforced, create at least one emergency access account that is excluded from every Conditional Access policy you will build. Give it a long, randomly generated password stored offline, and monitor it so any use raises an alert.

This feels excessive until the day a policy misfires and the account you would normally use to fix it is the account the policy just blocked. Two such accounts, stored separately, is the common recommendation, and the cost of having them is close to zero.

Report-only before enforcement

Modern Conditional Access lets you run a policy in report-only mode. The policy evaluates every sign-in and records what it would have done, without doing it.

Use it. Turn the policy on in report-only, leave it for a week or two of normal working, then read the results. What you are looking for is any sign-in that would have been blocked and should not have been. That list is your work queue, and it is almost always shorter than people fear and different from what they predicted.

Skipping this step is what causes the bad morning. Report-only converts a guess into evidence for the cost of waiting a fortnight.

Roll out in rings

Do not go from nothing to everyone. Move in groups, and make the first group the one best equipped to handle a problem.

1. IT and the people running the project. They will hit the issues first and can diagnose them.
2. A friendly pilot group, ideally one department with a manager who has agreed to it and a mix of device types.
3. Everyone else, in batches small enough that your service desk can absorb the questions from one batch before the next starts.
4. Privileged accounts, enforced strictly and separately, usually with stronger requirements than the general population.

Between rings, look at the service desk tickets. If the same question comes up more than twice, fix the communication rather than answering it thirty more times.

Pick the factor before you pick the policy

Not all second factors are equal, and the choice affects both security and adoption.

SMS codes are better than nothing and are the weakest common option, because they can be intercepted or redirected. Authenticator apps with number matching are the practical default for most organisations. Hardware keys are the strongest option and are worth the cost for administrators and anyone handling payments or sensitive data, even if you do not deploy them everywhere.

Whatever you choose, decide in advance what happens when someone loses their phone. A reset process that requires a human to verify identity in a defined way is part of the rollout, not an afterthought. Attackers know that the help desk is often the weakest link in an otherwise strong MFA deployment.

What to enforce beyond the second factor

MFA answers "is this the right person". Conditional Access lets you also ask "on what device, from where, to reach what". A few policies cover most of the value:

• Require MFA for all users, with break-glass accounts excluded
• Block legacy authentication protocols outright once you have confirmed nothing depends on them
• Require a managed or compliant device for access to the systems that would hurt most
• Require MFA for any administrative role, every time, with no trusted-location exemption
• Apply stricter conditions to sign-ins from outside the countries you actually operate in

Each of these should go through the same report-only cycle. Blocking legacy authentication in particular is the one that most often surprises people, because a device nobody remembers is still using it.

Communicating it

The technical rollout is the easier half. Tell people what is changing, why, and what they need to do, once before and once on the day. Give them a named place to go when it does not work. And be honest that it adds a step, rather than claiming it will be invisible: people forgive a small friction they were warned about and resent one they were told would not happen.

The finish line

A rollout is not done at ninety percent. The remaining ten percent is where the risk concentrates, because it is the accounts that were too awkward to fix. Track them explicitly, give each one an owner and a resolution, and close them out.

An MFA deployment with a documented list of exceptions, each with a reason and a date, is a defensible position. One with an undocumented tail is the same risk you started with, wearing a project name.