Multi factor authentication is a second check when somebody signs in, usually a prompt on a phone. It is the single most effective change most organisations can make, because a stolen password on its own stops being enough.
It also has a reputation for causing a difficult week. That happens when it is switched on for everybody at once, without warning. Staged over a fortnight it is straightforward.
Why it matters more than a stronger password
Passwords leak in bulk, through breaches at other companies where staff reused the same one. An attacker with a working password and no second check is simply a user.
The most common outcome is not dramatic. It is an invoice quietly redirected, or a mailbox rule that forwards everything to an outside address for months.
Before you start: the four things to prepare
- A list of accounts. Including shared accounts, old accounts and anything used by a machine rather than a person.
- A break glass account. One administrator account kept aside with its own second factor, so a mistake cannot lock everybody out.
- A plan for staff without a work phone. Options include a personal phone with only the authenticator application, a hardware key, or a desk phone callback.
- A named person to answer questions during the rollout week.
A fortnight that works
Days one to three. Enable it for the technical staff and the people who will be helping. They find the local quirks before anybody else meets them.
Day four. Send one short message to everybody. What is changing, why, what they will see, what to do if it does not work and who to contact. One page, no jargon.
Days five to eight. Enable it for one department. Choose a department that is busy but not in its peak week, and keep the helper available.
Days nine to twelve. Everybody else, in two groups rather than one.
Day thirteen. Deal with the exceptions: the shared mailboxes, the machine accounts, the one application that does not support it.
Day fourteen. Check the sign in logs for accounts that have not registered, and follow those up individually.
The exceptions that always come up
An old application that signs in with a username and password and cannot present a second factor. A scanner or copier that sends email. A shared account used by several people on a rota.
Each of these has a proper answer, and the proper answer is rarely to leave the account without protection. Usually it means moving the device or application to a different method of sending mail, or replacing the shared account with named accounts and shared access.
What to tell staff, in plain words
Say that passwords on their own are no longer enough, that this is now normal for banks and for most workplaces, and that it will add a few seconds when they sign in on a new device rather than every time.
Avoid describing it as a policy requirement. People cooperate better with a reason than with a rule.
After it is on
Review who is still not covered, once a quarter. New accounts, contractors and anybody who was granted an exception during the rollout have a way of staying outside it.
Also check that your administrators have it. An unprotected administrator account undoes most of the benefit.
The methods, compared
Not all second factors are equally good, and the differences matter more than most guidance admits. These are the options in the order we would recommend them.
An authenticator application with number matching. The person receives a prompt and has to type a number shown on the screen they are signing in from. This is the current default recommendation because it defeats the most common attack, where somebody is bombarded with approval prompts until they tap yes to make it stop. If you do nothing else from this article, turn number matching on.
A hardware key. A small device that plugs in or taps. It is the strongest option and the least convenient to distribute. Worth it for administrator accounts, for finance staff who authorise payments, and for anybody who has already been targeted.
An authenticator application with a simple approve button. Better than nothing and better than text messages, but vulnerable to the prompt bombardment above. Treat it as a stepping stone rather than a destination.
A code from an application. The six digit rotating code. Useful as a fallback when somebody has no signal, because it works offline.
A text message. The weakest common method, because a determined attacker can have a number transferred to a new card. Acceptable as a temporary measure for a person with no smartphone, not acceptable for an administrator.
A telephone call to a desk phone. Rarely used now, but genuinely useful for a shared reception role or for somebody who cannot use a mobile at work.
Two practical points. Register at least two methods per person, otherwise a lost or broken phone becomes a lockout that somebody has to resolve manually. And keep one administrator account with a hardware key, set aside and not used day to day, so a mistake in the rollout cannot lock everybody out of the tenancy at once.
Finally, review the registered methods once a quarter. People change phones, and an old device still registered against an account is a door left open long after anybody remembers it exists.
Where to read more
We set this up as part of Microsoft 365 work and as part of cybersecurity. Day to day account problems afterwards are handled through IT support.
Ask us to look at your sign in settings and we will tell you what is currently protected and what is not.