MFA strategy for business

A business enables multi-factor authentication across its email platform and considers the account takeover risk addressed. Some months later an administrator receives a call from someone claiming to be from IT, reads out a six-digit code, and the attacker is in. The second factor worked exactly as designed and was handed over voluntarily.

This is the gap between having MFA and having an MFA strategy. Enabling it is a configuration change. Deciding which factors are acceptable for which accounts, ensuring coverage reaches the accounts that actually matter, and designing a recovery path that is not weaker than the authentication it protects — those are the decisions that determine whether the control holds under pressure.

The business case is not in dispute. Credential theft is the most common route into a business, and a stolen password alone becomes far less useful when a second factor is required. The question is not whether to deploy MFA but how, and the how is where most of the residual risk lives.

The factors, honestly compared

Vendors present MFA as a binary. It is a spectrum, and the differences are consequential.

The line that matters is between the first four and the last two. A hardware key or passkey is bound cryptographically to the site it was registered for, so a convincing replica at a similar address simply does not work — there is nothing for the user to type and nothing for the attacker to relay. Every other factor depends on the user correctly identifying the site they are on, which is the judgement phishing is designed to defeat.

What NIST says about SMS

The position is more precise than the common summary that SMS is banned. NIST SP 800-63B states that use of the public switched telephone network for out-of-band verification is restricted, and notes that NIST may adjust that restricted status over time based on the evolution of the threat landscape. Where it is used, the guidance is that verifiers should consider risk indicators such as device swap, SIM change, number porting or other abnormal behaviour.

Read practically, that means SMS is not forbidden and is not a good primary choice. For a business it is a reasonable fallback where a user genuinely cannot use anything else, and a poor default for administrators or anyone with financial authority.

Coverage is where most deployments fall short

MFA is usually rolled out to the platform that made it easiest — email and document storage — and stops there. The accounts an attacker most wants are frequently outside that boundary.

• Administrative accounts on every platform, including ones bought by departments outside IT. These are the highest-value targets and are often the last covered.
• The domain registrar and DNS provider. Control of DNS is control of everything reachable by name, including the ability to redirect mail and issue certificates.
• Hosting and cloud provider consoles, where a compromise permits creating, deleting and exfiltrating at will.
• Financial systems, payment platforms and banking portals.
• Remote access and VPN gateways, covered in the remote access article.
• Any application still holding its own separate user list, which conditional access at the identity provider never sees.
• Break-glass and emergency accounts, which need MFA and a documented, controlled exception path.

The second item is the one most often missed and among the most damaging. A registrar account without MFA is a single credential standing between an attacker and the ability to redirect a company's mail, obtain certificates in its name, and take over accounts elsewhere through password resets.

Recovery is the weakest link by design

Every MFA deployment needs an answer for the user who has lost their phone. Whatever that answer is becomes the real strength of the control, because an attacker will use it rather than attacking the factor itself.

The common recovery paths, in descending order of weakness, are: a help desk that resets MFA after verifying identity by voice, a recovery code emailed to the user, security questions, and a pre-issued backup code the user stored somewhere. The first is the one attackers target most, because it depends on a human under time pressure making an identity judgement from a phone call.

1. 1

   Register two factors at enrolment, not one

   A second registered factor removes most recovery events entirely. Two hardware keys, or a key plus an authenticator app, means losing one is an inconvenience rather than a lockout.

2. 2

   Define help desk verification in writing

   What must be established before an MFA reset, and what is never sufficient. A voice that sounds right and knows the employee number is not sufficient, and staff need explicit permission to refuse.

3. 3

   Use a callback to a number on record

   For any reset with material consequences, a callback to an independently held number breaks the attack, because the attacker does not control that number.

4. 4

   Escalate for privileged accounts

   Resetting an administrator's MFA should require approval from a second person. The inconvenience is proportionate to what the account can do.

5. 5

   Log and review resets

   MFA resets are a small, high-signal category. A pattern of them, or one at an unusual hour, is worth looking at.

Passwords still exist, and the rules have changed

MFA does not remove passwords for most businesses, and the guidance on managing them has moved considerably from what most policies still encode.

NIST SP 800-63B advises that verifiers should not impose composition rules — requiring mixtures of character types, or prohibiting repeated characters — for memorised secrets. It also advises that verifiers should not require memorised secrets to be changed arbitrarily or periodically, while requiring that a change be forced where there is evidence of compromise.

Both recommendations exist because the older rules produced predictable behaviour: complexity requirements produced a common substitution pattern, and forced ninety-day rotation produced an incrementing number on the end. The current position is longer passwords, screened against known-breached lists, changed when there is a reason rather than on a calendar. Many businesses still run the older policy and believe it is the stricter one.

Rolling it out without a revolt

MFA deployments fail socially more often than technically. Three things determine whether it goes smoothly.

• Enrol before enforcing. Give users a window to register their factors while the old method still works, so the deadline is not the first time they encounter it.
• Start with the people who can absorb friction — IT and administrators — then widen. They will find the rough edges before the rest of the business does.
• Reduce the frequency of prompts for ordinary work on compliant devices. Trusted-device and session-length settings exist precisely so that security and usability are not opposed, and leaving them at defaults is what generates complaints.
• Explain the specific attack rather than citing policy. Staff who understand that someone will eventually phone them asking for a code behave differently from staff who were told about a compliance requirement.
• Have the recovery path working before enforcement day, because that is when it will first be needed at volume.

Common mistakes

A representative scenario

A composite of situations we see repeatedly; no client detail is included.

A business with MFA on its email platform suffers a finance-team compromise. The attacker phoned an employee, presented as internal IT resolving a mail issue, and asked them to read back a code. Payment instructions were altered on two supplier records before the change was noticed.

The review found MFA enabled and correctly configured for email, absent on the domain registrar, absent on the hosting console, and absent on two departmental applications holding customer data. Push notifications were plain rather than number-matched. Recovery was handled by the help desk on a voice call with no written verification standard. Password policy still enforced ninety-day rotation and character complexity.

The remediation started with coverage rather than with stronger factors, because an uncovered account is a worse gap than a weaker factor. Registrar, DNS, hosting and both departmental applications were brought in. Number matching was enabled. Hardware keys were issued to the finance team and to administrators, on the basis that phishing-resistant factors belong where compromise is most expensive rather than everywhere at once. Help desk verification was written down with a callback requirement and a second approver for privileged resets. Password rotation was removed and breached-password screening enabled.

Implementation checklist

• MFA covers every user, not only administrators.
• Coverage extends beyond email to registrar, DNS, hosting and cloud consoles, financial systems, remote access, and any application with its own user list.
• Phishing-resistant factors are deployed for administrators, finance, and anyone with the authority to move money or change access.
• Push notifications use number matching rather than simple approval.
• SMS is a fallback rather than a default, and is not used for privileged accounts.
• Every user registers at least two factors at enrolment.
• Help desk MFA reset has a written verification standard, and staff have explicit permission to refuse.
• Privileged MFA resets require a second approver.
• MFA resets are logged and reviewed.
• Break-glass accounts exist, are protected, and their use raises an alert.
• Password policy has dropped forced periodic rotation and composition rules in favour of length and breached-password screening.
• Staff have been told plainly that nobody legitimate will ever ask for a code.

Frequently asked questions

Conclusion

MFA is among the highest-return security controls available, and the return depends on decisions that are easy to skip. Which factors, for which accounts, with what recovery path, and whether the coverage reaches the registrar and the hosting console rather than stopping at email.

The single most useful thing to tell the business is not technical. Nobody legitimate will ever ask for an authentication code, and any request for one is an attack in progress. Staff who understand that stop the attack that defeats every factor except the phishing-resistant ones.