What the FTC Safeguards Rule requires for access, MFA and activity logs

The FTC Safeguards Rule (16 CFR Part 314) applies to financial institutions under the FTC’s jurisdiction. For access, it requires four things. Only authorized users get in, and each one sees only the customer information their job needs (314.4(c)(1)). Anyone using your information systems signs in with multi-factor authentication (MFA) (314.4(c)(5)). You monitor and log what authorized users do (314.4(c)(8)). And you oversee the service providers who handle customer information (314.4(f)). In practice, that means three records for every account: who may use it, who did use it, and when each person’s access ended. The broader legal idea of reasonable security is covered in What is reasonable security?

Who the rule covers

The rule covers customer information held by financial institutions under the FTC’s jurisdiction. The definition of “financial institution” in 314.2 reaches businesses whose activities are financial in nature or incidental to financial activities. The FTC’s guide lists mortgage lenders and brokers, payday lenders, finance companies, check cashers, collection agencies, tax preparation firms and investment advisers that don’t have to register with the SEC. The rule’s own list adds others, such as retailers that extend their own credit, auto dealers that lease cars for more than 90 days, and finders. The FTC’s guide says the rule doesn’t cover institutions that another agency enforces against under section 505 of the Gramm-Leach-Bliley Act.

Size doesn’t remove the access rules. Section 314.6 exempts institutions holding information on fewer than 5,000 consumers from four items. They are the written risk assessment, continuous monitoring or periodic penetration testing and vulnerability assessments, the written incident response plan, and the annual report to the board. Access controls, MFA and logging still apply to them.

What the rule asks for access

Two definitions in 314.2 decide how far these reach. An “authorized user” is any employee, contractor, agent, customer or other person allowed to access your information systems or data. An “information system” is any set of electronic resources that holds customer information or is connected to one. So a cloud app that holds customer records is an information system, and a temp or a vendor’s employee who signs in to it is an authorized user.

Applying it to shared logins

A shared login is one username and password used by several people. The rule doesn’t mention shared logins. But three of its requirements are harder to meet with one.

Authentication is the first. Under (c)(1)(i), you authenticate authorized users. A shared password proves that someone knows it, not which person typed it. MFA is the second. Under (c)(5), each person signing in needs a second factor. If the code goes to one person’s phone, everyone else has to ask that person each time. Logging is the third. Under (c)(8), you log what authorized users do. The app’s history names the shared account, not the person who used it.

To answer all three, keep a list of who may use each shared login. Add a way to confirm which person is signing in, and keep a record that names that person. Splitting the login into one user per person is the simplest fix where the app allows it. When it doesn’t, see When shared accounts can’t be split into personal ones.

Applying it to people who leave

Someone who leaves is no longer an authorized user, so under (c)(1)(i) their access has to end. The rule sets no number of days. The FTC’s guide asks you to review access controls periodically and reconsider whether each user still needs access. Because “authorized user” includes contractors and agents, the same applies when a temp’s assignment ends or a contractor finishes.

For a personal account, disabling the user ends access. For a shared login, the person who left still knows the password, so it has to change, and everyone still using it needs the new one. Why that gets hard as people come and go is covered in The limits of changing shared passwords every time someone leaves. Keep the date you ended each person’s access with the list of what they could use.

Applying it to service providers

Section 314.4(f) sets three duties for service providers: choose ones able to keep appropriate safeguards, require those safeguards by contract, and assess them periodically based on their risk. When a vendor’s people sign in to your systems, they are also authorized users, so (c)(1), (c)(5) and (c)(8) apply to them as they do to your staff. That means you need to know which of the vendor’s people use your accounts. Sample contract wording is in What your vendor contract should say about accounts. The questions to ask are in How to write the account questions in a vendor security questionnaire.

What to keep in all three cases

The same records answer each part of the rule, whether the user is an employee, a temp or a vendor’s person:

1. A list of each system that holds customer information, with the people allowed to use each account.
2. A record of each sign-in that names a person, including on shared logins.
3. The date each person’s access ended, and for shared logins, the date the password changed.
4. Your Qualified Individual’s written approval for any system where you use an alternative to MFA.

The records matter after an incident too. Since May 2024, a covered institution must notify the FTC as soon as possible, and no later than 30 days after discovering certain events (314.4(j)). The trigger is unencrypted information of at least 500 consumers acquired without authorization. How sign-in records help you tell what was accessed is in What access logs need to show when you decide whether to notify a breach.