FIPS 140-2 and FIPS 140-3 are U.S. federal standards published by the National Institute of Standards and Technology (NIST) that define security requirements for cryptographic modules: the hardware or software components responsible for encryption, key management, decryption, and authentication. For infrastructure teams in federal agencies, defense contracting, healthcare, and financial services, FIPS validation is a compliance baseline that storage systems must meet before a deployment receives authorization to operate.
The standard defines four security levels. Level 1 covers software-only cryptographic requirements with no physical security rules. Level 2 adds tamper-evidence requirements. Level 3 requires physical tamper resistance. Level 4 demands complete physical protection against environmental attacks. Most software storage encryption implementations target Level 1 or Level 2. FIPS 140 does not certify an entire storage system: it certifies the cryptographic module within that system, a defined boundary of hardware, firmware, or software that performs cryptographic functions.
What FIPS 140 Certifies
FIPS 140 certifies a cryptographic module: a bounded implementation of cryptographic functions including encryption, key generation, key storage, and random number generation. For a storage platform, the relevant module is typically the component that performs AES-256 encryption of data at rest and manages encryption keys.
Certification is conducted by a CMVP-accredited Cryptographic Module Testing (CMT) laboratory. A module that passes receives a certificate from the Cryptographic Module Validation Program (CMVP), maintained jointly by NIST and the Canadian Centre for Cyber Security. Each validated module receives a certificate number that can be verified on the NIST CMVP website.
A critical distinction exists between “FIPS-compliant” and “FIPS-validated.” A product described as FIPS-compliant may use only FIPS-approved algorithms (AES-256-GCM, SHA-256, and so on) without having undergone CMVP testing. FIPS-validated means the specific module implementation holds a CMVP certificate. Regulated teams should require validated status, not a compliance claim, when evaluating storage systems.
FIPS 140-2 vs FIPS 140-3: What Changed
FIPS 140-2 was published in 2001 and remained the dominant standard for two decades. FIPS 140-3 was published in 2019, aligned to ISO/IEC 19790:2012, and began superseding 140-2 for new certifications from September 2021. Key changes include more rigorous entropy source testing, additional lifecycle assurance requirements for software modules running in general-purpose OS environments, and deprecation of some legacy algorithms permitted under 140-2.
Existing FIPS 140-2 certificates remain valid until expiration. New validations issued after September 2026 must comply with FIPS 140-3. For procurement decisions, teams should verify whether a module holds a current certificate, regardless of which version it was certified under.
🚀 Running storage in a FIPS-regulated environment? Simplyblock’s self-hosted deployment keeps all cryptographic operations within your infrastructure perimeter, with no cloud key management dependency. 👉 See FIPS-compliant Kubernetes storage
FIPS and Kubernetes Storage
Kubernetes storage has multiple layers that may need FIPS evaluation: the host OS’s cryptographic modules (used for block device encryption), the CSI driver’s use of TLS for control plane communications, and any application-layer encryption managed by the storage platform.
For teams running Red Hat® OpenShift®, FIPS mode is a cluster-level configuration that enforces FIPS 140-2 approved cryptographic modules across the entire platform, including nodes and internal OpenShift components. Storage systems deployed on an OpenShift FIPS-mode cluster must not introduce non-FIPS cryptographic modules via their CSI driver or storage daemon. Any driver that statically links a non-validated crypto library violates the cluster’s FIPS posture.
The practical implication: FIPS compliance for storage is not just about enabling AES-256 encryption at rest. It requires verifying that the specific cryptographic library used by the storage system holds a valid CMVP certificate, and that the CSI driver is compatible with the OS’s FIPS-enforced crypto policy.
How Simplyblock Addresses FIPS Requirements
Simplyblock is designed for self-hosted, on-premises deployment, which means cryptographic operations remain entirely within the infrastructure perimeter rather than depending on cloud provider key management services. This architecture directly addresses the control and auditability requirements that FIPS-regulated environments impose.
Simplyblock’s encryption uses AES-256 algorithms consistent with FIPS-approved standards. For teams deploying on OpenShift with FIPS mode enabled, simplyblock runs without introducing non-compliant cryptographic modules through the CSI path. The platform’s architecture avoids external key management dependencies, simplifying the audit trail for storage encryption operations.
For teams building toward FedRAMP authorization or meeting DoD IL-level requirements, the FIPS-compliant Kubernetes storage use case covers deployment considerations and how simplyblock fits into a FIPS-regulated OpenShift or Kubernetes environment.
Related Terms
FIPS 140 sits within a broader set of security and compliance concepts relevant to platform engineers in regulated industries.
- Kubernetes Storage Encryption
- What Is Erasure Coding
- NVMe Namespace Isolation
- Multi-Tenant Kubernetes Storage
- What Is OpenShift
Questions and Answers
What is the difference between FIPS 140-2 and FIPS 140-3 for storage systems?
FIPS 140-3 (2019) updates 140-2 (2001) by aligning to ISO/IEC 19790:2012, adding stricter entropy source testing, stronger lifecycle assurance for software modules, and deprecating some legacy algorithms. For storage teams, the practical impact is that new CMVP certificates issued after September 2021 are issued under 140-3. Existing 140-2 certificates remain valid until expiration, so both versions are currently in circulation.
Does FIPS-compliant mean the same as FIPS-validated?
No. FIPS-compliant typically means a product uses FIPS-approved algorithms but has not undergone CMVP testing. FIPS-validated means the specific cryptographic module has been tested by an accredited lab and holds a certificate number in the NIST CMVP database. Regulated environments should require FIPS-validated status, not a compliance claim.
Can a Kubernetes CSI driver break FIPS compliance on an OpenShift FIPS cluster?
Yes. If a CSI driver or storage daemon links a non-validated cryptographic library, it can violate the FIPS posture of the cluster even when OpenShift itself is in FIPS mode. Platform teams should verify that the storage vendor’s CSI driver uses only the system’s validated cryptographic modules and does not bundle its own crypto library.
What FIPS 140 level does storage encryption typically target?
Most software-based storage encryption implementations target Level 1 or Level 2. Level 1 requires use of approved algorithms with no physical security requirements. Level 2 adds tamper-evidence. Levels 3 and 4 apply primarily to hardware security modules (HSMs) used for key management rather than to storage encryption modules themselves.
Is AES-256 encryption sufficient to satisfy FIPS 140-2 requirements?
Using AES-256-GCM is necessary but not sufficient. The algorithm must be implemented within a validated cryptographic module that holds a CMVP certificate. Key generation, random number generation, and authentication mechanisms must also use validated implementations. Using an approved algorithm in an unvalidated library does not satisfy FIPS 140-2 validation requirements.