Data Encryption Standards: AES, RSA, and FIPS Compliance

Data encryption standards like AES, RSA, and FIPS compliance sit at the center of nearly every regulated security architecture in the United States. AES handles bulk data protection with a single shared key. RSA and its asymmetric siblings secure key exchanges and digital signatures using a public-private key pair. FIPS 140 validation is the federal government’s proof that a cryptographic product has been independently tested against a written standard. Get any one of them wrong and you face both breach exposure and regulatory penalties that now reach seven figures per year.

AES and Bulk Data Protection

Symmetric encryption uses one secret key shared between sender and receiver. The same key scrambles plaintext into ciphertext and reverses the process on the other end. The math is efficient enough to protect hard drives, database columns, and streaming connections in real time, which is why symmetric algorithms carry the load in almost every production system.

The Advanced Encryption Standard is the dominant symmetric algorithm worldwide. AES uses a fixed block size of 128 bits and supports three key lengths: 128, 192, and 256 bits. Each key length determines how many transformation rounds the data passes through. AES-128 runs 10 rounds, AES-192 runs 12, and AES-256 runs 14.¹ Each round applies byte substitutions, row shifts, column mixing, and key addition. Brute-forcing AES-256 with current hardware would take longer than the age of the universe.

Why the Mode Matters

The algorithm only scrambles data. How you apply it across a full message depends on the operating mode, and choosing the wrong one leaves gaps attackers exploit routinely. Older implementations often used Cipher Block Chaining (CBC), which encrypts each block sequentially and provides confidentiality but no built-in way to detect tampering. An attacker who flips bits in the ciphertext can sometimes manipulate the decrypted output without the recipient noticing.

Galois/Counter Mode (GCM) solves this. It encrypts and generates an authentication tag simultaneously. If even a single bit of the ciphertext or associated metadata changes, the tag fails and the receiver rejects the message. GCM also processes blocks in parallel rather than sequentially, so it runs faster on modern hardware. These advantages are why TLS 1.3, IPsec, and IEEE 802.1AE for Ethernet frame encryption all mandate or prefer AES-GCM.² If a system you own still uses AES-CBC without a separate integrity check, that’s the fastest improvement available.

RSA and the Asymmetric Family

Asymmetric encryption uses a matched pair of keys instead of a single shared secret. You publish one key openly and keep the other private. Anyone can encrypt a message with your public key, but only your private key can decrypt it. This eliminates the problem of safely distributing a shared key before you can communicate.

RSA is the most widely deployed asymmetric algorithm. Its security depends on the difficulty of factoring the product of two very large primes. Multiplying primes together is trivial for a computer; working backward from the product to discover the originals is computationally impractical at sufficient key lengths. Current implementations use 2048-bit or 4096-bit keys. NIST has signaled that RSA at the 112-bit security level (roughly 2048-bit keys) will be deprecated after 2030 and disallowed after 2035 as part of the transition to quantum-resistant algorithms.³

Elliptic Curve Cryptography achieves comparable security with much shorter keys. A 256-bit ECC key provides roughly the same protection as a 3072-bit RSA key. Smaller keys mean faster computations and less bandwidth during secure handshakes, which matters for mobile devices, embedded sensors, and anything running on constrained hardware.

The Diffie-Hellman key exchange protocol lets two parties create a shared secret over an insecure channel without ever transmitting the secret directly. It doesn’t encrypt data itself. It establishes the foundation for a symmetric session key that both sides use going forward. Most secure web connections use an ephemeral version of Diffie-Hellman (ECDHE in its elliptic curve form) during the initial handshake to achieve forward secrecy. If an attacker later compromises a server’s long-term private key, past sessions stay protected because each one used a unique temporary shared secret that no longer exists anywhere.

TLS 1.3 in Practice

TLS 1.3 is where these algorithms come together in the protocol that protects most web traffic. The specification made aggressive choices about which older methods to cut. Static RSA key exchange is gone. The Digital Signature Algorithm is gone. Custom Diffie-Hellman groups are gone. Only authenticated encryption modes survive; legacy ciphers like RC4 and plain CBC suites were removed entirely.²

The remaining cipher suites in TLS 1.3 are AES-128-GCM, AES-256-GCM, ChaCha20-Poly1305, and two AES-CCM variants. Every key exchange must now provide forward secrecy, meaning fresh ephemeral keys per connection. MD5, SHA-1, and SHA-224 are explicitly prohibited for signature hashing.² Any system still negotiating TLS 1.0 or 1.1 should have those protocol versions disabled. They are considered fundamentally insecure.

Hashing: The Third Leg

A hash function takes input of any size and produces a fixed-length output that acts as a digital fingerprint. Change a single character in the source and the output changes completely. Unlike encryption, hashing is one-way: you cannot reconstruct the original data from the hash. That’s why hashing is the standard tool for verifying file integrity, storing passwords, and authenticating software updates.

SHA-256, part of the SHA-2 family, is the workhorse of modern hashing. It produces a 256-bit output and remains resistant to collision attacks, where an attacker tries to craft two different inputs that produce the same hash. Digital certificates, code signing, and blockchain transactions all rely on SHA-256 to prove data hasn’t been altered.

MD5 was the earlier standard, but researchers demonstrated practical collision attacks. Two completely different files can be crafted to produce an identical MD5 hash, which makes it worthless for any security-sensitive purpose. It still appears in non-security contexts like verifying downloads for accidental corruption, but forensic and legal applications require SHA-2 or better. Courts have dismissed digital evidence authenticated with compromised hashing methods.

NIST published SHA-3 (FIPS 202) as a fallback in case a structural weakness is ever discovered in SHA-2. The two families use fundamentally different internal designs. SHA-2 relies on the Merkle–Damgård construction; SHA-3 uses a sponge construction built on the Keccak permutation.⁴ That design diversity is the point. An attack technique that breaks SHA-2 is unlikely to work against SHA-3. SHA-3 also resists length-extension attacks, a category of vulnerability that affects SHA-2.

What FIPS 140 Compliance Actually Requires

NIST publishes the Federal Information Processing Standards to set security requirements for cryptographic hardware and software modules. FIPS aren’t universally mandatory across every federal system; each standard’s applicability section specifies when it applies.⁵ In practice, FIPS 140 validation is required for any cryptographic product used in federal information systems, and most healthcare and financial organizations treat it as a baseline because their regulators expect it.

The September 2026 Cutover

FIPS 140-2 has been the dominant validation standard for over two decades, and its expiration is close. On September 22, 2026, all remaining FIPS 140-2 certificates move to the historical list, meaning they are no longer active validations.⁶ Any organization relying on a product validated only under FIPS 140-2 needs to plan its transition now. After that date, only FIPS 140-3 modules appear on the active validated modules list.

FIPS 140-3 incorporates updated international standards and places greater emphasis on software security and physical environment testing. It retains four security levels. Each level increases the rigor of tamper protection, identity authentication, and environmental safeguards.⁷ Level 1 covers basic requirements. Level 2 adds tamper-evident coatings and role-based authentication. Levels 3 and 4 require progressively stronger physical tamper resistance and environmental failure protection.

What Validation Costs and Takes

Getting a product validated under FIPS 140-3 requires testing by an accredited third-party lab followed by NIST review. NIST’s cost recovery fees for the review portion depend on security level and submission type. For a full new submission, NIST charges between $16,000 and $19,000 depending on the security level, with extended cost recovery fees of $3,000 to $4,000 if additional review time is needed.⁸ Those figures cover only NIST’s portion. Lab testing fees are separate and vary by complexity, so total validation costs frequently run well above the NIST fees alone. The entire process from initial testing through final NIST approval often takes six months to a year.

FedRAMP and Federal Cloud

Cloud service providers seeking FedRAMP authorization face documentation requirements on top of the module validation itself. Under the Rev. 5 baselines, providers must document every encryption function performed on the system in a dedicated appendix within their System Security Plan, covering data at rest, data in transit, authentication, digital signatures, and hashing.⁹ The federal zero trust strategy (OMB M-22-09) goes further, requiring agencies to encrypt all traffic, including internal network traffic, and to use key management tools that generate audit logs for any data decryption attempts.¹⁰

Companies serving federal agencies must ensure their systems use FIPS-validated modules. Failing to meet these requirements can result in contract termination and debarment, which prohibits participating in federal procurement contracts and covered nonprocurement transactions.¹¹

The Post-Quantum Deadline

Quantum computers threaten the mathematical foundations of RSA, ECC, and Diffie-Hellman. A sufficiently powerful quantum computer running Shor’s algorithm could factor large integers and compute discrete logarithms efficiently, breaking these asymmetric systems entirely. No such machine exists today, but the threat is real enough that NIST has already published replacement standards. Data encrypted today and stored by an adversary could be decrypted once quantum hardware matures, a scenario known as “harvest now, decrypt later.”

In August 2024, NIST published three post-quantum standards. FIPS 203 (ML-KEM) is a key encapsulation mechanism based on module lattice problems, replacing RSA and ECDH for establishing shared secrets.¹² FIPS 204 (ML-DSA) is a digital signature algorithm also based on module lattice problems, replacing RSA and ECDSA for signing documents and authenticating software.¹³ FIPS 205 (SLH-DSA) is a hash-based signature standard derived from SPHINCS+, offering a backup built on different mathematical assumptions than ML-DSA.¹⁴

NIST’s draft transition guidance sets a timeline. Classical asymmetric algorithms like RSA and ECDSA at the 112-bit security level will be deprecated after 2030 and disallowed entirely after 2035. Even algorithms at 128-bit security or higher face the same 2035 disallowance date.³ AES itself is not threatened in the same way. Grover’s algorithm only halves its effective security, so AES-256 retains 128 bits of security against quantum attack.

Key Lifecycle Management

Even the strongest algorithm becomes worthless if the keys protecting it are poorly managed. NIST SP 800-57 defines four phases every cryptographic key must pass through.¹⁵

Pre-operational. The key has been generated but is not yet in use. Access policies and intended usage are established here.
Operational. The key is active. It may be designated for encryption only, decryption only, or both.
Post-operational. The key is no longer used for new encryption but remains accessible to decrypt previously protected data. Archived keys sit in this phase.
Destroyed. Key material has been permanently erased. Metadata like the key’s name and usage period may be retained for auditing.

Skipping phases creates risk. Organizations that never formally decommission old keys leave potential decryption material sitting in systems no one monitors. Organizations that never archive post-operational keys lose the ability to decrypt historical records they may need for litigation or compliance audits. A documented policy that tracks each key through all four phases is what auditors expect under HIPAA, GLBA, FedRAMP, and most cyber insurance underwriters.

Penalties for Encryption Failures

HIPAA

HIPAA doesn’t technically mandate a specific encryption algorithm, but it lists encryption as an addressable implementation specification. Failing to encrypt protected health information without a documented equivalent safeguard draws enforcement attention. Civil penalties are adjusted for inflation annually. For 2026, the penalty tiers range from $145 per violation when the organization didn’t know and couldn’t reasonably have known about the issue, up to a minimum of $73,011 per violation for willful neglect that goes uncorrected. The annual cap for the most severe tier is $2,190,294.¹⁶

Criminal penalties operate separately. Knowingly obtaining or disclosing individually identifiable health information without authorization carries up to a $50,000 fine and one year in prison. If the offense involves false pretenses, the ceiling rises to $100,000 and five years. If the information was obtained with intent to sell or use for personal gain, the maximum is $250,000 and ten years.¹⁷

Gramm-Leach-Bliley Act

The GLBA Safeguards Rule requires financial institutions to implement security measures that protect customer information, and encryption is explicitly identified as a way to significantly reduce breach risk. Criminal penalties for knowingly obtaining financial information through fraud or deception include fines and up to five years in prison. When the offense is part of a pattern of illegal activity involving more than $100,000 in a 12-month period, the imprisonment ceiling doubles to ten years.¹⁸ Repeated noncompliance can also trigger administrative action affecting an institution’s participation in federal programs.¹⁹

SEC Cybersecurity Disclosure

Public companies face a separate disclosure obligation. If a company determines that a cybersecurity incident is material, it must file a Form 8-K within four business days describing the nature, scope, and timing of the incident, along with its material impact on the company’s financial condition.²⁰ The materiality determination itself must happen without unreasonable delay after discovery. If some information isn’t available when the initial filing is due, the company must say so and file an amendment within four business days once the information becomes available.²¹ Delays for national security reasons require written authorization from the Attorney General and are limited to 30-day increments.

The Breach Notification Safe Harbor

Most states exempt organizations from breach notification requirements when the compromised data was encrypted and the encryption key was not also exposed. The specific language varies, but the principle is consistent: if the data is unreadable to the unauthorized party, there is no actionable breach to report. This safe harbor gives encryption a direct, measurable financial benefit by avoiding notification costs, credit monitoring, and reputational damage. A safe harbor claim falls apart if the key was stored alongside the data it protected, so organizations relying on this protection need current algorithms and separate key management.

Export Controls for Encryption Products

If you develop or distribute products with encryption functionality, the Export Administration Regulations apply. Encryption items are classified under Export Control Classification Number (ECCN) 5A002 and related categories. Exporting without proper authorization violates federal law.

License Exception ENC provides a streamlined path for most commercial encryption exports. It authorizes exports of encryption products classified under ECCN 5A002, 5B002, and related software and technology categories without requiring an individual license for each transaction.²² The specific requirements depend on the sensitivity of the product. Some exports to private sector end users and U.S. subsidiaries require no classification or reporting. Less sensitive products can be self-classified with an annual report submitted to BIS by February 1. More sensitive items like network infrastructure products and cryptanalytic tools require a classification request and a 30-day waiting period before export.

No version of License Exception ENC authorizes exports to countries in Country Groups E:1 or E:2, which include countries subject to comprehensive U.S. sanctions. The exception also prohibits exports when the exporter knows or has reason to know the product will be used to compromise the confidentiality or availability of information systems without authorization.²² Software companies releasing open-source encryption code and hardware vendors shipping devices with built-in encryption both fall under these rules, and the classification determines which reporting obligations apply.

1
National Institute of Standards and Technology. FIPS 197, Advanced Encryption Standard (AES)
2
Internet Engineering Task Force. RFC 8446 – The Transport Layer Security (TLS) Protocol Version 1.3
3
National Institute of Standards and Technology. NIST IR 8547 – Transition to Post-Quantum Cryptography Standards
4
National Institute of Standards and Technology. SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions (FIPS PUB 202)
5
National Institute of Standards and Technology. Compliance FAQs: Federal Information Processing Standards (FIPS)
6
National Institute of Standards and Technology. FIPS 140-3 Transition Effort
7
National Institute of Standards and Technology. Security Requirements for Cryptographic Modules (FIPS 140-3)
8
National Institute of Standards and Technology. NIST Cost Recovery Fees – Cryptographic Module Validation Program
9
FedRAMP. Rev 5 Transition Overview Presentation
10
The White House. M-22-09 Federal Zero Trust Strategy
11
eCFR. 2 CFR 182.630 – Debarment
12
National Institute of Standards and Technology. FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard
13
National Institute of Standards and Technology. FIPS 204, Module-Lattice-Based Digital Signature Standard
14
National Institute of Standards and Technology. Post-Quantum Cryptography Standardization
15
National Institute of Standards and Technology. Recommendation for Key Management: Part 1 – General (SP 800-57)
16
Federal Register. Annual Civil Monetary Penalties Inflation Adjustment
17
GovInfo. 42 USC 1320d-6 – Wrongful Disclosure of Individually Identifiable Health Information
18
Office of the Law Revision Counsel. 15 USC 6823 – Criminal Penalty
19
Federal Student Aid. Updates to the Gramm-Leach-Bliley Act Cybersecurity Requirements
20
U.S. Securities and Exchange Commission. Form 8-K
21
U.S. Securities and Exchange Commission. Disclosure of Cybersecurity Incidents Determined To Be Material
22
eCFR. 15 CFR 740.17 – Encryption Commodities, Software, and Technology (ENC)