Multi-factor authentication rollouts fail in a predictable way: IT flips it on for everyone at once, help desk tickets spike, users experience it as an unexplained obstacle rather than a protection, and the whole initiative gets remembered as the time IT made everyone's job harder, rather than as the control that closed the single most exploited gap in business email compromise.
Most resistance to MFA is a rollout problem, not a real objection to security. Employees who understand specifically what the control protects and see a predictable, well-explained setup process resist far less than employees handed a new requirement with no context.
On one rollout, we started with administrators and finance, then a pilot department with a champion who could answer questions, then everyone else team by team. Legacy protocols that can't do MFA, such as old scan-to-email devices and some multifunction printers, were found in the sign-in logs before enforcement, so the first day didn't fail on the scanner in the accounts office.
A staged rollout beats a universal cutover almost every time. Start with the systems that carry the most risk, email and any shared business platform, rather than every application simultaneously. Roll out by team or user tier rather than the whole organisation on the same day, so the help desk absorbs a manageable volume of setup questions instead of a flood.
The other lever that matters is choosing a friction-appropriate method per use case. A hardware key or authenticator app push for staff at desks most of the day is a very different experience than the same requirement for field staff with unreliable mobile signal. Treating both groups identically is a common cause of avoidable frustration.
MFA rollout is a communication project with a technical component, not the reverse. The organisations that get pushback treated it as a switch to flip; the ones that don't treated it as a change to explain. The IT team owns the user conversation; senior engineering should own the identity design.
Need security controls built and verified, not just reported? Security Engineering
All resources