Understanding FIPS 140-3, Storage Validation, And You

Security, Storage

Working with SLED customers for over a decade I often see security requirements like “FIPS 140-3” or “CJIS compliance.” While very simple on the surface, it’s easy to get wrapped around the axle in understanding where these requirements come from, how they’re met, and whether the complicate-ass nature of how these things are documented is just a deep state conspiracy to necessitate the use of AI RAG just to understand the basics.

If you’ve clicked into this article because you’ve been asked to ensure FIPS 140-3 validation (or similar), I’ll cover the key details up front. If you’re a masochist for spending too much time reading about technical validations, like me, the rest of the article is for you.

There’s a lot of meat to chew through when it comes to these standards and it’s a very complicated web of documents, some old, some new, that overlap, supersede, and sometimes change formats all together.Just the facts, ma’am

FIPS (Federal Information Processing Standards) is a set of guidelines, generally mandated by the US federal government, and defined by NIST (US National Institute of Standards and Technology). FIPS 140 is a standard that defines requirements for secure cryptographic modules that house and protect sensitive data. The second version, FIPS 140-2, is being sunset on September 21st, 2026, and superseded by version 3, FIPS 140-3. Going forward to be “FIPS validated” will mean being in compliance with the guidelines outlined in FIPS 140-3.

There within FIPS 140-3 there are four different levels of security. Level 1 is baseline centered around the cryptographic module that is encrypting data. Level 2 adds physical security to the protection of data, while Level 3 and Level 4 provide additional levels of physical security. Most customers I’ve worked with need FIPS 140-3 Level 1 as a baseline. It’s important to understand which level of compliance you need when looking at data storage systems.

Once you know if you need to be FIPS 140-3 validated, and at which level, the simplest thing is to ask your data storage vendor. They’ll know what they’ve got on the truck and whether those will meet your compliance needs. You shouldn’t have to go research that validation yourself, though any validated devices will be documented via NIST for reference/auditing.

For example, NetApp has FIPS 140-3 validation for ONTAP, certification #5271 on NIST’s website. Within that cert there’s a Security Policy report that details everything… what FIPS 130-3 level is validated, what hardware and software is within scope, what algorithms are validated, even how to enable it.

It’s also important to understand that just because you’re getting something that’s FIPS 140-3 validated, that doesn’t mean that your system is in compliance. If it’s something that can be configured by software it can be configured incorrectly (or potentially never turned on). There are a handful of algorithms that have been “disallowed” by NIST, if you were to configure one of those instead of an “acceptable” algorithm you’ll be out of compliance.

Big ass disclaimer time… I’m not a lawyer or professional interpreter of government requirements. I’m just a layman trying to interpret disjointed/complicated documentation. My intent for this to not be your source of truth when it comes to compliance controls, but a source of (hopefully accurate) information to help you along your journey.

If you’ve made it this far I can only assume you don’t have a ChatGPT subscription and found this helpful. If you’d like to get into the weeds with me please keep reading!

Validated/Certified/Complaint/Capable?

The devil’s in the details when it comes to semantics…

Validated – This is the term you want to see when seeking FIPS compliance. A cryptographic module that has been tested by an accredited lab and approved by NIST through the CMVP (NIST’s validation program, see the next section) process is “FIPS 140-2 validated” or “FIPS 140-3 validated.” It has a certificate number on the CMVP active list. This is the only term that carries actual compliance weight.

Certified – This term is often used interchangeably with validated in common usage, and NIST themselves sometimes use it, but strictly speaking the CMVP issues validations, not certifications. Certifications are more associated with Common Criteria. In practice “FIPS certified” is widely understood and not wrong enough to cause problems, but “validated” is more precise.

Capable – This term will pop up from time to time in marketing and has no legal/technical weight. It’s accurate enough to know that the system is capable of using an algorithm that is FIPS 140-3 compliant, but there hasn’t been any validation by NIST.

Complaint – I only use this term in the context of a customer running a properly configured FIPS 140-3 system, aka “We’re properly configured so are complaint.” If a vendor says they’re compliant it’s equivalent to capable as described above.

Clear as mud, right?

Federal Information Processing Standards (FIPS)

Before getting into FIPS 140-2 and 140-3 it’s best to have an explanation of what FIPS actually is. I was going to write up a decent enough explanation, but it turns out CJISSECPOL (you’ll find out what that is later) has a good write-up on FIPS which I’ll just share here,

Origin of FIPS 140-2

On July 17, 1995, the National Institute of Standards and Technology (NIST) established the Cryptographic Module Validation Program (CMVP) to validate cryptographic modules to Federal Information Processing Standards (FIPS) Security Requirements for Cryptographic Modules, and other FIPS cryptography based standards. The CMVP is a joint effort between NIST and the Communications Security Establishment Canada (CSEC). FIPS 140-2, Security Requirements for Cryptographic Modules, was released on May 25, 2001 to supersede the original FIPS 140-1. Modules validated as conforming to FIPS 140-1 and FIPS 140-2 are accepted by the Federal Agencies of both countries for the protection of sensitive information.

What is FIPS 140-2?

Federal Information Processing Standard (FIPS) is a standard developed and recommended (often mandated) for use in federal-government-operated IT systems by the following two government bodies:

• The National Institute of Standards and Technology (NIST) in the United States
• The Communications Security Establishment (CSE) in Canada

FIPS 140-2 specifies the security requirements a cryptographic module must meet when utilized within a security system protecting sensitive information within information systems (computer and telecommunication systems). FIPS 140-2 specifies which encryption algorithms can be used and how encryption keys are to be generated and managed.

Let’s dive into FIPS 140

FIPS 140 is highly focused on data security with different levels of protection, Level 1 through Level 4. Here’s a high level summary of each level. Since FIPS 140-2 is being sunset, I’m just going to use the updated level requirements for FIPS 140-3 as dictated by ISO/IEC 19790:2025, Section 5.

Level 1 – Basic security requiring at least one approved cryptographic function. No physical security mechanisms beyond production-grade components. Typically for software encryption.

Level 2 – Adds tamper-evident physical mechanisms (seals, coatings, or pick-resistant locks) and role-based authentication. Requires an audit mechanism for software modules. Typical for secured data center environments.

Level 3 – Adds tamper-detection and response (zeroing on breach), identity-based authentication, and environmental failure protection. Keys must enter/exit encrypted or via a trusted path. Hardware/firmware only, software modules cannot achieve this overall rating. Designed for commercial HSMs and payment systems.

Level 4 – Highest level. Complete physical envelope detects penetration from any direction and immediately zeros all SSPs. Requires multi-factor identity-based authentication, mandatory split-knowledge for key entry, and fault injection protection. Designed for physically unprotected environments and military/intelligence/high-threat deployments.

ISO/IEC 19790:2025 also has a detailed table with all the different details that go into each security level. Since that document is not freely available I went and created a helpful infographic to save and reuse. I used Claud to create this initially, and then heavily modified it, to the point that I should’ve just built it from scratch. ¯\_(ツ)_/¯

Different organizations will have different requirements about what level of compliance they need to adhere to. To that end, whenever I talk about FIPS validation, I always give the full phrase, such as “FIPS 140-3 Level 1” just to make sure everyone is on the same page.

The majority of compliance conversations I’ve been a part of fall under Level 1. And, being a storage guy historically, those convos involve encryption at rest. Storage arrays, or their drives, have their cryptographic modules validated by NIST through a process called the Cryptographic Module Validation Program (CMVP).

In the context of storage, in a system that is FIPS 140-2 Level 1 validated, you have a certified cryptographic module (software encryption, or hardware based encryption) that’s capable of being encrypted with one of NIST’s approved algorithms.

And on to our main attraction, FIPS 140-3

FIPS 140-2 was superseded by FIPS 140-3 in 2019, with CMVP starting the following year. Any crypto modules that were FIPS 140-2 validated will be sunset, moved to a “Historical” status, on September 21st, 2026.

A big part of FIPS 140-3 was a shift from following a NIST based standard to ISO/IEC (ISO/IEC 19790:2012 and ISO/IEC 24759:2017 specifically) to be better aligned with the international community. On one hand this is great, on the other hand it’s resulted in primary documentation that’s light on details with specific details locked behind the ISO/IEC paywall. It also doesn’t help that NIST isn’t keeping up with ISO/IEC, if you check the standards you’ll see they’ve been updated in 2025, while FIPS hasn’t.

FIPS 140-3 being aligned with ISO/IEC, in addition to somewhat simplifying business requirements, also has a benefit for producers. By standardizing practices it makes it easier for producers to knock multiple compliance concerns out with one stone. Unfortunately for folks specifically seeking FIPS validation, NIST is the bottle neck when it comes to validation. By some accounts CMVP is nearly a year behind schedule.

A really important thing to call out is while NIST is using ISE/IEC standards, it’s just using them as a baseline. The FIPS 140-3 document throws this at you by first telling you the ISO/IEC standards, but then provides a list of some 13 different NIST SP 800 annex modification documents. These, at least, are publicly published.

Focusing on Cryptography

While there’s a whole bunch of improvements between FIPS 140-2 and 140-3, I’m just going to focus on the cryptography elements that go in Level 1. This is a really big part of, and I’d say, the foundation of FIPS 140-3 compliance. If you’re not using a validated algorithm, then anything else you do is moot.

The FIPS 140-3 documentation references NIST SP 800-140C as the source for CMVP approved security functions. If you just Google “NIST SP 800-140C” you’re taken to this page, which was superseded by Rev 1, which in turn was superseded by Rev 2, which doesn’t really have any relevant data that I can tell, other than a link to another page for SP 800-140C.

While this page says “Approved Security Functions,” that’s not actually the case. Best I can tell it’s just a list of every algorithm that NIST has ever reviewed. Note that it lists SHA-1. In the first section on the page, 6.2.1 Transitions, there’s a link to yet another document, 800-131A Revision 2, Transitioning the Use of Cryptographic Algorithms and Key Lengths. This document finally details out what algorithms are strong enough to be “acceptable”, and which are no longer allowed (note the aforementioned SHA-1 is now “disallowed” for signature generation).

Storage platforms that are encrypting data will need to use one of the algorithms detailed as acceptable.

FIPS and PQC

Post-Quantum Cryptography (PQC) is a set of encryption algorithms designed to withstand the future ability of quantum computing to crack older encryption keys. You often hear of quantum decryption as a looming threat, where every bit of stolen data that was encrypted can now be cracked open. Thus PQC is quickly becoming a must.

Two key algorithms, ML-DSA and SLH-DSA are encapsulated under FIPS 204 and FIPS 205 respectively. Both of those are listed under SP 800-140C, but for some reason not 800-131Ar2. Why this discrepancy? I haven’t a damned clue.

Again, the important thing here is to check with your vendor and make sure that they’ve been properly validated for a PQC algorithm. Just because they’re FIPS 140-3 validated, it doesn’t mean they’ve been validated with the algorithm you want to use.

How does this apply to Cybersecurity Maturity Model Certification (CMMC)?

CMMC incorporates NIST SP 800-171 security requirements, which in turn references FIPS 140-3 for encryption standards. To fulfill CMMC Level 2 requirements organizations must use encryption methods that are FIPS 140-3 validated.

But wait, there’s more…

Criminal Justice Information Services’ Security Policy

Criminal Justice Information Services (CJIS), a division of the FBI, has a Security Policy (CJISSECPOL, yes, that’s the short version), designed and distributed to validate the security Criminal Justice Information (CJI.. you thought we were done with acronyms? Hah!). CJIS compliance is directly applicable to organizations that deal in CJI. This includes law enforcement agencies, folks that run background checks, and the organizations that support that kind of work. This creates several areas where governmental organizations find overlap between FIPS and CJIS compliance.

The latest CJISECPOL, Version 6.0, released 12/27/2024, largely refers to FIPS 140-2, with a note FIPS 140-2 validation expiration in the section on Cryptographic Protection. The sections where FIPS 140-3 pops up are tied to the encryption of data at rest and in transit….

SC-13 Cryptographic Protection

a. Determine the use of encryption for CJI in-transit when outside a physically secure location; and
b. Implement the following types of cryptography required for each specified cryptographic use: cryptographic modules which are Federal Information Processing Standard (FIPS) 140-3 validation, or FIPS validated algorithm for symmetric key encryption and decryption (FIPS 197 [AES]), with a symmetric cipher key of at least 128-bit strength for CJI in-transit.

SC-28 SC-28 Protection of Information at Rest

Protect the confidentiality and integrity of the following information at rest: CJI when outside physically secure locations using cryptographic modules which are certified FIPS 140-3 with a symmetric cipher key of at least 128-bit strength, or FIPS 197 with a symmetric cipher key of at least 256-bit strength.

Based on my reading of that, as FIPS 197 is just the details of AES, I suppose as long as you’re running AES-256 you don’t need to worry about FIPS 140-3 validation? To that I say avoid any ambiguity and grab a system with FIPS 140-3 validation and run an appropriate algorithm.

In Summary

So, to summarize, shit’s complicated. There are lots of really smart people who know this like the back of their hand, I’m just someone who knows enough to be dangerous and occasionally goes down a rabbit hole trying to connect all the dots. The majority of my conversations go something like this…

“Do you need run on a FIPS 140-3 complaint system?”

“Do you know what level of FIPS 140-3 you need?”

I then work with the vendor to say “Hey, customer needs FIPS 140-3 Level 1. So, so what’cha, what’cha, what’cha got?”

If you do the same, and just make sure you configure the system to use an acceptable algorithm, you’ll be right as rain.

The hard part (burying the lede) is that with validation lagging behind the September deadline is quickly approaching and there’s a high risk of compliance gaps. While FIPS 140-3 isn’t new, from my standpoint it seems like adoption/validation has been lacking. At the very least understand your requirements and communicate them with your partners.

Hope all this has been helpful and not as mind numbing as it has been for me.

Special Thanks

Special thanks to Matt Trudewind, a security expert at NetApp (I dare say the storage security expert), who helped answer a bunch of questions and point me toward the right documentation. Also thanks to everyone who proof read this, and I blame them any unaccounted typos.

Additional Resources

Publication History

  • June 6, 2026 – Initial publication