14 FIPS compliance is a foundational requirement for organizations that support U.S. federal agencies, defense programs, and many regulated workloads. It governs how cryptography must be implemented, validated, and operated. For storage and infrastructure teams, FIPS compliance directly affects: Encryption at rest Encryption in transit Key management architecture Product selection and procurement Audit readiness Although often referenced in procurement documents, FIPS compliance is not simply a contractual term. It is a technical standard that defines how cryptographic modules must behave in order to protect sensitive information. Understanding what FIPS compliance actually covers—and what it does not—is essential for architects, security teams, and technical evaluators. What is FIPS compliance? FIPS stands for Federal Information Processing Standards, a set of standards issued by the National Institute of Standards and Technology (NIST). In cybersecurity discussions, FIPS almost always refers to FIPS 140, the standard that defines security requirements for cryptographic modules. FIPS compliance means that a cryptographic module: Uses NIST-approved algorithms Meets defined security requirements Has been validated under the Cryptographic Module Validation Program (CMVP) A cryptographic module may be hardware, software, firmware, or a hybrid combination. It is the component that performs encryption, decryption, hashing, key generation, and related cryptographic functions. Importantly, FIPS applies to cryptographic modules—not entire systems. A storage platform is not universally “FIPS certified.” Instead, specific cryptographic components within that platform may be FIPS validated. That distinction is significant during audits and federal procurement reviews. FIPS 140-2 and FIPS 140-3 There are two primary versions of the standard in active discussion: FIPS 140-2, widely deployed for many years FIPS 140-3, the current version aligned with ISO/IEC 19790 New cryptographic module validations now follow FIPS 140-3. However, many existing environments still rely on previously validated FIPS 140-2 modules during transition periods. Both versions define security requirements across similar domains, including algorithm use, key management, self-testing, authentication, and physical security. Organizations evaluating FIPS compliance should confirm which version applies to their environment and whether specific agencies have updated requirements tied to FIPS 140-3. The 2026 transition: what it means for FIPS 140-2 users FIPS 140-2 has been widely deployed for more than two decades. However, a formal transition is approaching. On September 21, 2026, the Cryptographic Module Validation Program (CMVP) will move all remaining active FIPS 140-2 certificates to the Historical List. This change has practical implications for federal agencies and vendors. Impact on new procurements After this date, federal agencies are generally prohibited from including FIPS 140-2 modules in new acquisitions. Products that rely solely on 140-2 validation may no longer meet procurement requirements. Vendors that have not transitioned to FIPS 140-3 risk being excluded from new federal opportunities. Existing systems Modules moved to the Historical List may continue to operate in existing systems. However, their status reflects legacy validation. Significant system changes—such as operating system upgrades, major software revisions, or architectural modifications—may trigger requirements to adopt FIPS 140-3 validated modules. Planning considerations The transition to FIPS 140-3 is not immediate. The validation process can take 18 to 24 months due to laboratory testing and CMVP review timelines. Organizations supporting federal workloads should: Confirm whether their vendors have active FIPS 140-3 certificates Verify whether modules are currently in validation Align product roadmaps with procurement timelines Early verification reduces procurement risk and avoids unexpected compliance gaps. FIPS compliant vs. FIPS validated vs. FIPS mode The terminology around FIPS compliance is frequently misunderstood. Three common terms require clarification. FIPS validated This is the formal designation. A cryptographic module is FIPS validated only after: Testing by an accredited laboratory Review under the CMVP program Listing on the NIST validated modules database Validation is specific to a module version and configuration. If the implementation changes, validation may no longer apply. FIPS compliant This is a broader term. It often means: The product uses FIPS-validated cryptographic modules The product can operate in a FIPS-approved configuration However, the term “FIPS compliant” does not automatically imply formal validation. FIPS mode Many software and storage platforms offer a “FIPS mode.” When enabled, this mode typically: Restricts the system to NIST-approved algorithms Disables non-approved cryptographic functions Enforces stricter configuration constraints FIPS mode supports operational alignment with FIPS requirements but does not replace validation. For technical evaluators, the key question remains: Which cryptographic modules are validated, and under which certificate numbers? What FIPS 140 actually evaluates FIPS 140 validation is structured and technical. It evaluates cryptographic modules across multiple domains. Approved cryptographic algorithms Modules must implement NIST-approved algorithms such as: AES for symmetric encryption SHA-2 or SHA-3 for hashing RSA or ECC for public-key cryptography Approved deterministic random bit generators Algorithms must also be validated under the Cryptographic Algorithm Validation Program (CAVP). Key management FIPS requires secure generation, storage, distribution, and destruction of cryptographic keys. Critical security parameters must be protected in memory and in persistent storage. Self-tests Modules must perform: Power-up self-tests Conditional self-tests during operation If a self-test fails, the module must enter an error state and prevent further cryptographic operations. Roles and authentication Depending on the required level, modules must enforce: Role-based authentication Identity-based authentication Administrative and operational functions must be clearly separated and controlled. Physical security For hardware cryptographic modules, FIPS defines requirements for: Tamper evidence Tamper resistance Tamper response mechanisms These requirements vary depending on the security level. Operational environment FIPS validation considers the operating environment of the module, such as: General-purpose operating systems Constrained or embedded systems Validation is tied to specific operating environments. FIPS compliance levels FIPS 140 defines four increasing levels of security. Level 1 Basic cryptographic functionality Approved algorithms Minimal physical security requirements Common for software-based modules in standard environments. Level 2 Role-based authentication Tamper-evident physical mechanisms for hardware modules Frequently required for federal systems handling sensitive information. Level 3 Identity-based authentication Stronger tamper resistance Protection of cryptographic keys against extraction Used in higher-assurance federal environments. Level 4 Protection against environmental attacks Advanced physical security controls Typically limited to specialized, high-security use cases. When evaluating FIPS compliance, confirm which level is required and whether it aligns with workload sensitivity. What FIPS validation does not cover FIPS validation is focused on cryptographic modules. It does not guarantee: Overall system security Secure network architecture Identity and access management controls Application-layer protections Operational best practices A storage platform may use FIPS-validated cryptography while still requiring proper configuration, monitoring, and governance. In many federal environments, FIPS compliance is only one element within broader frameworks such as FedRAMP or DoD security requirements. FIPS compliance in storage environments For storage teams, FIPS compliance primarily affects encryption and key management. Encryption at rest If object storage encrypts data at rest, the cryptographic module performing encryption must be FIPS validated. Approved key lengths and modes of operation must be used. Architects should verify that: The encryption library is validated The deployed version matches the validated configuration FIPS mode enforces approved algorithms only Encryption in transit TLS implementations may rely on FIPS-validated libraries. When FIPS mode is enabled, only approved cipher suites should be available. Configuration drift can introduce non-approved cipher suites if not carefully managed. Key management systems If an external Key Management System (KMS) is used, confirm that: The KMS cryptographic module is validated Key generation and storage align with federal guidance Key lifecycle controls are documented Software-defined storage In software-defined storage architectures, FIPS validation often applies to the underlying cryptographic library. Teams should verify: The exact module version The validated operating system environment Whether patches or updates affect validation status FIPS compliance requires alignment between implementation and validated configuration. How to evaluate FIPS compliance in practice Technical buyers should approach FIPS compliance methodically. Request validation details Ask vendors for: CMVP certificate numbers Module names and versions Validation levels Verify these against the NIST database. Confirm configuration alignment Validation applies only to specific configurations. Confirm: Operating system versions Library versions Build configurations If these differ from the validated environment, compliance may not apply. Verify FIPS mode enforcement Determine: How FIPS mode is enabled Whether non-approved algorithms are disabled How compliance is monitored Operational controls should prevent accidental use of non-approved cryptography. Plan for lifecycle changes Upgrading a cryptographic library may require revalidation or transition to a new certificate. Lifecycle planning should account for this impact. FIPS compliance and federal workloads Federal and defense workloads often require: Use of FIPS-validated cryptographic modules Operation in FIPS-approved mode Documentation of cryptographic controls FIPS compliance provides a standardized assurance baseline. It reduces ambiguity about acceptable cryptographic implementations. For storage platforms supporting federal object storage, archives, or backup repositories, FIPS validation helps establish trust in the cryptographic foundation of the system. A practical perspective on FIPS compliance FIPS compliance is a narrowly defined but technically rigorous validation of cryptographic modules. It is neither a marketing label nor a comprehensive security certification. For storage and infrastructure teams, effective FIPS compliance involves: Selecting products that use validated cryptographic modules Ensuring deployed configurations match validated environments Enabling and enforcing FIPS-approved modes Maintaining documentation for audits and procurement reviews Planning for lifecycle transitions When implemented carefully, FIPS compliance strengthens cryptographic assurance and supports federal and regulated workloads. A clear understanding of what is validated, how it is configured, and how it is maintained allows organizations to deploy secure storage architectures aligned with federal standards and operational requirements.
