Rolling Out Multi Factor Authentication Without a Revolt

You can turn multi factor sign in on this afternoon. There is a toggle in the administrative console and the toggle works. What takes weeks is everything the toggle does not know about.

The failures in a rollout are almost never about the second factor itself. They are about the printer that emails scanned documents, the accounts package with a saved password, the shared mailbox three people use, and the director who is abroad on the day you enforce it.

So plan it as a change to how people work rather than as a security project. You need an inventory of what cannot do it, a pilot, an order of rollout, a support plan for the week it lands, and a written rule for exceptions. You also need to tell people before it happens rather than afterwards. Done that way it is quiet. Done as a surprise on a Monday morning it produces a queue at the help desk, a director on the phone to your managing director, and a set of permanent exemptions that nobody ever revisits.

Start with a list of everything that signs in with a username and password and is not a person sitting at a keyboard. That list is longer than anyone expects, and it is where rollouts break.

The usual entries are multifunction printers and scanners that send mail, backup software with a mailbox account, a CRM that polls an inbox, monitoring tools, the finance package with a stored password, a bespoke application written years ago, and any integration set up by somebody who has since left the company.

For each one, decide the route now. Move it to a modern authentication method where the vendor supports one. Give it an application credential your identity platform can issue and revoke. Or, where nothing else exists, restrict it hard: one account, one source address, no interactive sign in, no permissions beyond what it needs, and an alert if it is used from anywhere else.

Then switch off the legacy protocols that let a password work on its own. Enforcing multi factor while leaving basic authentication enabled on the mail platform is a locked front door with an open window beside it, and the window is what gets checked first.

Pilot, then privileged accounts, then everybody. That order is not what most people pick, and it is what keeps the noise down.

Pilot with a small group who are technical enough to describe what broke and patient enough not to escalate it. Spread them across departments rather than taking them all from IT, because IT does not use the finance package or the warehouse terminal. Run it long enough to cover a full cycle of the business, month end included.

Then administrators, and be stricter here than anywhere else. Separate administrative accounts, no mailbox on them, and a phishing resistant method rather than a code typed into a browser. These are the accounts an attacker is actually trying to reach.

Then the rest of the company in waves, department by department, with each manager told in advance and a named person available during their wave. Finish with the people who travel. Their problems are the ones that need somebody awake in the right time zone.

Every company has accounts that belong to a function rather than to a person. The sales inbox. The login on the reception machine. The social media account three people use. The supplier portal registered under an address that stopped being a real person two staff changes ago.

Where the platform allows it, stop sharing the login altogether. A shared mailbox with delegated access lets each person sign in as themselves, gives you a record of who did what, and takes the shared credential out of the problem. The same applies to any portal that supports named users.

Where you genuinely cannot split it, put the credential and its second factor seed in a team vault in your password manager, restricted to the people who need it, and treat any staff change as a reason to rotate it. This is worse than named accounts and everybody involved should know that it is worse.

The account with no owner is the dangerous one. Give every shared login a named person responsible for who holds it, and review that list on a fixed date. An account owned by a department is owned by nobody.

Every rollout produces exceptions. Somebody on holiday. Somebody whose phone will not install the app. An application waiting on a vendor upgrade. Exceptions are fine. Exceptions without an end date are how a rollout quietly reverses itself over a year.

Give every exception four things: a named owner, a written reason, a compensating control and a date it expires. Put them all in one security group so the whole set is visible in one place. An empty group means you are finished. A group that never shrinks means you are not rolling out multi factor, you are maintaining a list.

The compensating control matters more than the paperwork. An account without a second factor should be restricted by location, by device, by what it can reach, or by all three. An exception with no compensating control is an unprotected account with an apology attached to it.

Review the group on a fixed date with the owners present. Most exceptions turn out to be solvable once somebody has to explain them out loud, and the ones that are not solvable become a line in next year's budget instead of a permanent hole.

Codes by text message are the weakest option that still counts as a second factor. The number can be moved to a new SIM by somebody persuasive, and the code can be typed into a fake login page as easily as a password can. It is still far better than nothing, and for some staff it is the only thing that will work.

A code from an authenticator app is a clear step up, because there is nothing in transit to intercept. A push notification is easier again, and brings its own problem, covered below. Number matching, where the person types a value shown on the screen into the app, removes most of that problem and should be enabled if your platform offers it.

Passkeys and hardware security keys are the methods that actually resist phishing, because the credential is bound to the real site and will not work on a convincing copy of it. If you can only afford to protect one group this way, protect the administrators, then finance.

Give everybody more than one method. A single phone is a single point of failure, and a lost phone with no backup method turns into a help desk call that ends with somebody being helpful and bypassing the control.

Once multi factor is on, the attack moves. The password gets stolen exactly as before, and then the attacker sends approval prompts until somebody presses approve. Often at two in the morning, often for several nights running, until the person taps it to make the phone stop buzzing.

Number matching removes most of this outright, since there is nothing to approve without the value on the screen. Beyond that, cap how many prompts an account can receive in a short period, alert when an account generates a burst of denied approvals, and tell people plainly that an unexpected prompt means their password is already stolen and needs reporting today.

The other route runs through your help desk. Somebody rings, says they have a new phone, and asks for their second factor to be reset. Without a verification step, that call bypasses everything you have built. Decide now how identity gets proven on that call, and make it something an outsider cannot research: a callback to the number held in the HR record, confirmation from the person's manager, or a code delivered through a channel the caller does not control.

Write the procedure down and let the help desk apply it to senior people too. The pressure to make an exception is always highest for the accounts where an exception costs the most.

Tell people what is happening, why, and what they need to do, before anything changes. Use screenshots from your own environment rather than the vendor's, because the vendor's screens never quite match. Give a clear enrolment window with an end date and a named person to ask during it.

Expect the ordinary objections and have real answers ready. No, it does not install anything that can read their personal phone. Yes, there is an option for people who will not use a personal device, which is a hardware key or a callback to a desk phone. No, they will not be asked for a code every time they open their mail, provided you set the session lifetimes sensibly.

Be careful with the remember this device setting. A long window makes the rollout feel painless and quietly gives away most of the protection, because a stolen session is exactly what an attacker is trying to obtain. Keep it short enough to matter, and require a fresh check for administrative actions and for sign ins from an unfamiliar location.

Then plan for ordinary human failure. The lost phone. The new phone with nothing on it. The key left at home. A temporary access pass that expires the same day handles nearly all of these without anybody senior getting involved, and the day that exists is the day the rollout stops feeling like a fight.