Policy Guide: Building a Multifactor Authentication Policy

Most small businesses have turned on multifactor authentication somewhere. Fewer have written down where it is required, which methods count, who can grant an exception, and what happens when someone gets around it. That written piece is the policy, and it is what turns MFA from a setting into a control you can defend.

This is the first in a series of policy guides, each built around one control. The goal is a short document your team will follow, tied to the frameworks you may be measured against.

Why MFA needs its own policy

Stolen and guessed passwords are one of the most common ways attackers get into business accounts, and MFA is one of the most effective ways to make a stolen password useless on its own. But MFA rollouts drift. A new cloud app gets added without it. A vendor account is exempted "temporarily." An executive asks to skip it on their phone. A year later, the gaps are where the attacks land.

A policy fixes the drift by answering four questions in advance: where MFA is required, what methods are acceptable, who can approve an exception, and how compliance is checked.

What the frameworks say

Here is how MFA shows up in the frameworks our clients deal with most:

• FTC Safeguards Rule. 16 CFR 314.4(c)(5) requires MFA "for any individual accessing any information system," unless the Qualified Individual approves an equivalent, reasonably secure control in writing. The rule defines MFA as at least two of knowledge, possession, and inherence factors.
• HIPAA Security Rule. 45 CFR 164.312(d) requires procedures to verify that a person seeking access to ePHI is who they claim to be. The current rule does not name MFA specifically. HHS has proposed making MFA an explicit requirement, but that proposal is not final. Your risk analysis is where MFA gets justified today, and for remote and email access it almost always will be.
• NIST SP 800-171. Requirement 3.5.3 calls for MFA for local and network access to privileged accounts and for network access to non-privileged accounts.
• CIS Controls v8.1. Control 6 includes safeguards requiring MFA for externally exposed applications, for remote network access, and for administrative access.
• NIST Cybersecurity Framework 2.0. MFA falls under the Protect function's identity management, authentication, and access control category (PR.AA).

If you write one policy that meets the strictest of these for your business, you meet the rest.

The sections your MFA policy needs

Keep the policy to two or three pages. Procedures and screenshots can live elsewhere.

1. Purpose and scope

State that the policy covers all workforce members, contractors, and service providers who access company systems. Name the system categories in scope rather than listing every app, so the policy does not go stale every time you add software.

2. Where MFA is required

A good default list:

• Email and collaboration platforms
• Remote access of any kind: VPN, remote desktop gateways, remote support tools
• All administrative and privileged accounts, including cloud admin consoles
• Any system holding regulated data: the EHR, the DMS, the ERP, payroll, banking
• Password managers
• Vendor and service provider accounts that reach your systems

Then add one sentence that does the heavy lifting: any new system that stores or provides access to company or customer data must support MFA before it goes live, or receive an approved exception.

3. Approved methods

Rank them. Phishing-resistant methods such as FIDO2 security keys and passkeys go first, then authenticator apps that use number matching or a one-time code. Plain approve or deny push prompts should be phased out; NIST's current digital identity guidance, SP 800-63B-4, no longer accepts them because they invite fatigue approvals. Text message and phone call codes should be allowed only where nothing better is supported, since the same guidance treats codes sent over the phone network as a restricted option.

For administrators and finance staff who move money, require the strongest method available.

4. Exceptions

Exceptions will happen. A legacy system cannot support MFA, or a shared clinical workstation needs a different approach. The policy should say:

• Who can approve an exception (for FTC Safeguards entities, the Qualified Individual, in writing)
• What compensating controls are required, such as network restrictions or a separate jump host
• That every exception has an expiration date and a review

An exception list nobody reviews becomes the permanent architecture.

5. Enrollment, recovery, and lost devices

Spell out how new users enroll, how a lost phone or key is reported, and how identity is verified before MFA is reset. Help desk resets are a favorite target for social engineering. Require a verification step that does not rely only on information an attacker could find, such as a callback to a number already on file or a manager confirmation.

6. Monitoring and enforcement

State that MFA coverage is reviewed on a set schedule, that sign-in logs are monitored for repeated MFA prompts and unusual locations, and that users must report prompts they did not initiate. Tie violations to your sanction or disciplinary process. HIPAA covered entities already need a sanction policy under 164.308(a)(1), so reference it.

7. Ownership and review

Name the policy owner, the approval authority, the effective date, and the review cycle. Review at least once a year and when systems change.

Rolling it out without a revolt

The policy is easier to adopt if the first step is a coverage report: which accounts have MFA, which do not, and which systems do not support it. That report also becomes your evidence. Communicate the reason in plain terms, give people a date, and have someone available to help on that day. Start with administrators and remote access, where the risk is highest.

Watch for MFA fatigue. If users get prompts they did not trigger, they should deny them and call IT, not approve them to make the noise stop. Number matching helps a lot here.

What evidence to keep

When someone asks whether your MFA control works, you want to hand them:

• The signed policy with its effective date
• A current coverage report from your identity platform
• The exception register with approvals and expiration dates
• A record of the last review

Our earlier posts on MFA bypass techniques and the hidden weaknesses of MFA cover the attack side in more depth.

How we help

TRNSFRM writes and implements security policies for businesses that answer to HIPAA, the FTC Safeguards Rule, and NIST. See our NIST overview, or score yourself with the free compliance checklist. If you want help writing an MFA policy that matches your actual systems, book a free 45-minute Compliance Gap Audit.