For most of the past three decades, cryptography sat quietly in the background of financial services. Security and PKI teams managed it, compliance functions rarely saw it, and everyone treated it as a technical detail rather than a governance concern. That era has ended. The GLBA Safeguards Rule now carries an explicit encryption mandate for non-bank financial institutions, and it is one of the sharpest examples of how far cryptography has moved into the compliance conversation.
The stakes are no longer abstract. Under the updated rule, your encryption status helps determine the penalties you face and whether a data breach is even reportable to the Federal Trade Commission at all. Encryption is not a nice-to-have control sitting next to the compliance program. It is the control the program turns on.
This article walks through the rule section by section: what it requires, how it maps to specific cryptographic controls, and how to prove your program to an examiner.
What the GLBA Safeguards Rule requires for encryption
The FTC’s Safeguards Rule implements GLBA Section 501(b) for financial institutions under FTC jurisdiction. The amended Rule was published on December 9, 2021 and took effect on January 10, 2022. Compliance with certain provisions, including the encryption and MFA requirements, was required by June 9, 2023. The amendments replaced a principles-based approach with the prescriptive program elements now set out in Section 314.4. One of those elements is an explicit encryption mandate, which is a significant departure from the flexible, “reasonable measures” posture that came before.
The core requirement lives in Section 314.4(c)(3): encryption of customer information both at rest and in transit. Where encryption is not feasible, the Qualified Individual must review and approve effective alternative controls. This is one of the few Safeguards Rule provisions with almost no interpretive flexibility. The default expectation is encryption, and any departure from it has to be documented and justified.
The rule also defines what encryption means. Under Section 314.2(f), encryption is a transformation of data consistent with current cryptographic standards, accompanied by appropriate safeguards for the cryptographic key material. In other words, scrambling data is not enough on its own. The keys that protect it have to be protected too.
Why encryption status decides your breach reporting obligation
The financial and legal stakes make the encryption mandate impossible to treat as optional. Civil penalties reach $100,000 per violation for the institution, and officers and directors can be personally fined up to $10,000. Those numbers put the requirement squarely on the desk of senior leadership, not just the security team.
A breach-notification amendment added a reporting obligation to the FTC, and it took effect on May 13, 2024. The amendment ties directly to encryption. A “notification event,” defined at Section 314.2(m), is the unauthorized acquisition of unencrypted customer information. When such an event involves 500 or more consumers, it must be reported to the FTC within 30 days.
Read that definition twice, because the operative word is unencrypted. Encryption status is not just a security control here. It is the determining factor in whether an incident triggers a federal reporting obligation at all. An institution that can demonstrate its exposed data was encrypted may have a materially different disclosure posture than one that cannot.
Who the GLBA Safeguards Rule applies to
The Safeguards Rule reaches financial institutions under FTC jurisdiction, and that definition extends well beyond traditional banks. It covers non-bank lenders, mortgage brokers, tax preparers, auto dealers offering financing, and other businesses that meet GLBA’s “financial activity” test. If your business touches consumer financial data as part of its core activity, you should assume you are in scope until you have confirmed otherwise.
The rule also names two roles worth understanding. The Qualified Individual is the designated person responsible for overseeing and implementing the information security program. Service providers are the third parties handling customer information on your behalf, and they are contractually required to maintain appropriate safeguards for the data they touch.
Scope does include one narrowing provision. Under Section 314.6, institutions maintaining customer information on fewer than 5,000 consumers are exempt from several requirements, specifically Sections 314.4(b)(1), (d)(2), (h), and (i). Note what that exemption does not cover: the encryption and MFA requirements still apply. Being a smaller institution does not lift the encryption mandate.
How the GLBA Safeguards Rule maps to cryptographic controls
This is the heart of the rule for security and PKI teams. The Safeguards Rule addresses cryptography through several interlocking control areas, each tied to a specific section.
Encryption of customer information (§314.4(c)(3))
Encryption of customer information at rest and in transit, with Qualified-Individual-approved, documented compensating controls in the narrow cases where encryption is genuinely infeasible.
Multi-factor authentication (§314.4(c)(5))
MFA for any individual accessing any information system, unless the Qualified Individual has approved in writing the use of reasonably equivalent or more secure access controls.
Qualified Individual oversight and board reporting (§314.4(a))
Centralized reporting on the status of cryptographic controls, feeding the Qualified Individual’s oversight duties and the required annual report to the board.
Vendor and service provider assurance (§314.4(f))
Cryptographic due-diligence evidence that supports the safeguards you are contractually required to demand from service providers handling customer information.
Breach notification determination (§314.2(m) / §314.4(j))
A documented process for determining whether exposed customer information was encrypted. That determination drives the 30-day FTC notification obligation, so the process itself is a control worth building deliberately.
Secure application development (§314.4(c)(4))
Code-signing and secure development practices for in-house applications that access or transmit customer information. This area is lighter than the others, but it belongs in the picture.
How to prepare for a GLBA examination
Examiners focus on demonstrated evidence, not policy statements alone. A polished policy binder will not carry an examination if you cannot show the controls working in practice. Treat the rule as an audit-readiness checklist and be ready to produce evidence in each of these areas:
- Encryption coverage evidence across your systems, showing customer information protected at rest and in transit.
- Written, Qualified-Individual-approved compensating controls anywhere encryption is not used.
- MFA deployment evidence for all access to systems containing customer information.
- Service provider contract language requiring appropriate safeguards, including encryption, for the data they handle.
- Breach notification readiness: a documented process for determining, within the required timeframe, whether an incident involved unencrypted customer information.
- The annual board reporting package, including the status of encryption and other technical safeguards.
- Retained Qualified Individual approvals for compensating controls and MFA alternatives.
- A cryptographic key inventory, with evidence that key material is protected.
The through-line across all of these is the same: know where your cryptographic assets are, and be able to show they are controlled.
What comes next: post-quantum readiness for financial institutions
The forward-looking version of GLBA compliance follows a simple discipline: know what cryptography you have, prove you control it, and be ready to change it. The exceptions GLBA offers today, such as the Qualified-Individual-approved compensating controls, are defined by what current standards recognize as sufficient. Those standards evolve, which means yesterday’s compliant implementation can quietly become tomorrow’s audit finding.
Post-quantum cryptography is where that trajectory gets a deadline. In 2024, NIST finalized the first post-quantum cryptographic standards, starting a global countdown to replace the algorithms most systems rely on today. For institutions holding customer data with years-long sensitivity, the risk is harvest-now-decrypt-later: data captured today can be stored and decrypted once quantum capability arrives. That is why crypto-agility, the ability to change cryptography without re-architecting everything, matters now rather than later.
How Keyfactor can help
Each GLBA obligation maps to an operational capability, and that mapping is where compliance becomes something you can actually run. The goal here is evidence, not marketing: a control you can demonstrate on demand.
- AgileSec supports vendor and service provider assurance, producing the cryptographic due-diligence evidence your contracts require.
- EJBCA supports encryption of customer information, certificate-based MFA, and the breach-notification determination that hinges on encryption status.
- SignServer supports secure application development and code signing for in-house applications that access customer information. The same provision requires procedures for evaluating, assessing, or testing the security of externally developed applications used to transmit, access, or store customer information.
- Keyfactor Command supports Qualified Individual oversight and the centralized reporting that feeds the annual board report.
Taken together, these turn scattered cryptographic obligations into a single system of record that can answer an examiner’s questions.
Conclusion and call to action
Under the GLBA Safeguards Rule, encryption is no longer a background technical detail. It is the control that decides your penalties, your breach reporting obligation, and your examination outcomes. Institutions that internalize that shift stop treating compliance as operational drag and start treating it as a competitive capability, one that lets them move faster through due diligence and recover more cleanly from incidents.
If you want the full framework-by-framework breakdown, explore Keyfactor’s Cryptographic Compliance Guide for Financial Services, which maps GLBA alongside the other regulations shaping cryptographic compliance in the sector.
Request a Demo to see how Keyfactor turns the GLBA Safeguards Rule’s encryption mandate into controls you can prove.
Got GLBA Safeguards Rule questions? We’ve got answers.
What does the GLBA Safeguards Rule require for encryption?
Section 314.4(c)(3) requires encryption of all customer information both at rest and in transit over external networks. Where encryption is not feasible, the Qualified Individual must approve effective alternative controls in writing. The requirement is categorical, with one narrow exception for documented infeasibility.
When did the updated GLBA Safeguards Rule take effect?
The Final Rule updating the Safeguards Rule took effect on June 9, 2023, replacing a principles-based approach with nine prescriptive program elements. A further amendment adding breach notification to the FTC took effect on May 13, 2024.
Who has to comply with the GLBA Safeguards Rule?
It applies to financial institutions under FTC jurisdiction, including non-bank lenders, mortgage brokers, tax preparers, and auto dealers offering financing. Any business meeting GLBA’s “financial activity” test can fall in scope, along with the service providers that handle customer information on its behalf.
What are the penalties for a GLBA Safeguards Rule violation?
Civil penalties reach $100,000 per violation for the institution, and officers and directors can be personally fined up to $10,000. Encryption status also determines whether an incident meets the definition of a notification event and triggers the FTC reporting obligation.
When does a GLBA incident have to be reported to the FTC?
A “notification event” is the unauthorized acquisition of unencrypted customer information involving 500 or more consumers. It must be reported to the FTC within 30 days. If the exposed data was encrypted, the disclosure posture can be materially different.
Who is the Qualified Individual under the GLBA Safeguards Rule?
The Qualified Individual is the designated person responsible for overseeing and implementing the information security program. This role approves compensating controls where encryption is infeasible, approves MFA algernatives in writing, and delivers the required annual report to the board on encryption and other technical safeguards.
Does the GLBA Safeguards Rule require multi-factor authentication?
Yes. Section 314.4(c)(5) requires MFA for anyone accessing any information system. Certificate-based options are available for stronger, phishing-resistant assurance.
