How to Approve an MFA Exception in Writing Under the Safeguards Rule

The FTC MFA requirements are one of the few parts of the Safeguards Rule that read like a hard rule. Most tax practices, auto dealers, mortgage brokers and lenders still have at least one system that cannot support multi-factor authentication: an older dealer management terminal, a shared scanner login, or a line-of-business application on a server in the back office. The rule plans for that, but it allows exactly one way out, and it has to be in writing. (SEC-registered advisers and broker-dealers follow Regulation S-P instead of this rule.)

Do the FTC MFA requirements allow any exceptions?

Yes, one. 16 CFR 314.4(c)(5) requires you to "implement multi-factor authentication for any individual accessing any information system, unless your Qualified Individual has approved in writing the use of reasonably equivalent or more secure access controls." There is no exception for seniority, convenience or cost.

The definitions in 16 CFR 314.2 set the scope. Multi-factor authentication means verifying at least two of three factor types: something the user knows (a password), something the user has (a token), or something the user is (a biometric). An information system is any set of electronic resources that contains customer information or is connected to a system that does, including specialized systems such as phone switches and environmental controls. A scanner, a phone system or a vendor portal can be in scope.

Small firms do not escape the requirement. The exemption in 16 CFR 314.6 for institutions with customer information on fewer than 5,000 consumers removes the written risk assessment, continuous monitoring or annual penetration testing, the written incident response plan and the board report. It does not remove MFA.

What counts as "reasonably equivalent or more secure"?

The replacement has to protect the system at least as well as MFA would. When the FTC finalized the amended rule in December 2021, a commenter asked it to accept "effective alternative compensating controls" for MFA. The final rule kept the stricter "reasonably equivalent or more secure" standard. That looser wording does appear in the rule, but only for encryption exceptions. A weaker control that is carefully documented is still a weaker control.

Controls that tend to meet the bar put a second factor in front of the system, even when the system itself cannot ask for one:

• A remote access gateway or VPN that requires MFA before anyone can reach the legacy application.
• Restricting access to managed firm devices whose own sign-in requires MFA or a hardware-bound credential.
• Network segmentation so the system is reachable only from a jump host that enforces MFA.

Controls that usually fall short include a longer password, a memo telling staff not to share logins, and the argument that a system sits on the internal network. The requirement covers "any individual accessing any information system," and the rule's definition of an information system is not limited to systems reachable from the internet. Internal access is covered.

If you need a yardstick for comparing authenticators, NIST SP 800-63B-4 sets out assurance levels and describes phishing-resistant options. It is federal guidance outside the Safeguards Rule, and it gives your Qualified Individual a recognized reference point when explaining why a replacement is equivalent.

Who is allowed to approve an MFA exception?

Only the Qualified Individual. Under 16 CFR 314.4(a), that is the person you designated to oversee and implement your information security program. It can be an employee, an affiliate or a service provider. If it is an outside provider, the firm keeps responsibility for compliance and must designate a senior member of its own staff to direct and oversee that person.

The owner, the office manager or the IT vendor cannot sign in the Qualified Individual's place unless they hold that role. When the person asking for the exception is the Qualified Individual, a sensible practice is to have a second senior person review it before it is signed. The rule does not require that second review, but it keeps the approval from looking like self-dealing.

What should the written approval include?

Enough that an examiner, an auditor or the FTC can see what was exempted, why, what replaced MFA, and when the decision will be revisited. The rule does not prescribe a form, so these items are good practice rather than a checklist from the regulation:

• Scope: the specific system, account or device, and the named users or roles covered. One approval per system keeps scope from creeping.
• Reason: why MFA cannot be used, backed by a vendor statement, version number or support ticket.
• Replacement controls: what protects the system instead, and a plain explanation of why it is reasonably equivalent or more secure.
• Evidence: a screenshot or export showing the replacement controls are configured and enforced.
• Monitoring: how access to the system is logged, which supports the user activity monitoring required by 16 CFR 314.4(c)(8).
• Expiry and triggers: a review date, plus events that end the exception early, such as a vendor upgrade that adds MFA support.
• Signature: the Qualified Individual's name, signature and date.

Where else does an MFA exception need to show up?

In the risk assessment, the board report and the annual program evaluation. An exception approved once and filed away is the gap examiners look for. Section 314.4 ties these together:

• Paragraph (b) requires a written risk assessment that describes how identified risks will be mitigated or accepted. An MFA exception is a risk decision and belongs there.
• Paragraph (i) requires the Qualified Individual to report in writing, at least annually, to the board or a senior officer on material matters, including risk management and control decisions. See what the Qualified Individual's board report must cover.
• Paragraph (g) requires you to evaluate and adjust the program after testing, monitoring and material changes. That is the natural point to confirm each exception is still needed.

Firms under the 5,000-consumer threshold are exempt from the written risk assessment and the board report, but the signed approval itself is still the only basis for operating a system without MFA.

What should you do this quarter?

Find every place MFA is missing, then either close the gap or document it properly. A practical sequence:

1. List every system that holds or connects to customer information, including service accounts, scanners, phone systems and vendor portals, and mark which ones enforce MFA.
2. For each gap, ask the vendor in writing whether MFA or single sign-on is supported, and on which version.
3. Where MFA truly is not available, design a replacement that puts a second factor in front of the system.
4. Write the approval with the items above and have the Qualified Individual sign and date it.
5. Add each open exception to the risk register and the next board report, and put the review dates on a calendar someone owns.

How does s90 help?

s90 maps where MFA is and is not enforced across your systems, designs access controls for the ones that cannot support it, and keeps each exception in a risk register with its evidence and expiry date. Your Qualified Individual gets the documentation needed for the annual board report. If you would like a second look at the exceptions you already have, we are glad to review them with you.