Join our Newsletter — 33% off our NHI Course

FIPS 140-2

FIPS 140-2 is a U.S. government standard for testing the security of cryptographic modules used to protect sensitive data. It specifies how hardware, software, and firmware must handle encryption, key management, self-tests, and tamper response across defined security levels, helping organizations validate cryptographic controls in regulated environments.

What FIPS 140-2 Actually Covers

FIPS 140-2 is about validated cryptographic modules, not just algorithms on paper. The standard evaluates whether the hardware, software, or firmware that performs cryptographic operations is designed and implemented to meet defined security requirements for protecting sensitive data.

That distinction matters because organizations often rely on the module boundary as the thing being approved. If the cryptographic module is not the validated component, then the surrounding product, integration, or configuration may still leave encryption controls weaker than expected.

Security Functions Inside the Module Boundary

The standard looks at how a module handles core cryptographic functions such as encryption, key management, self-tests, and tamper response. Those functions are central to whether the module can be trusted to protect secrets and data in regulated environments.

FIPS 140-2 also ties security expectations to defined assurance levels, so the question is not only whether cryptography exists but whether the module behaves predictably under failure, initialization, and tamper conditions. That makes it especially relevant where organizations need evidence that the cryptographic boundary is controlled and testable.

Where Organizations Use It

FIPS 140-2 is commonly used when procurement, compliance, or internal security policy requires validated cryptography for sensitive workloads. It is often paired with product selection decisions, government-aligned deployments, and environments where regulated data must be protected by approved cryptographic implementations.

In practice, the standard helps separate a general-purpose cryptographic feature from a module that has gone through formal testing. For teams comparing products, the useful question is whether the exact module, configuration, and deployment mode are within the validated scope rather than assuming the whole product inherits the validation.

For a broader grounding in cryptography concepts that sit around FIPS validation, see the Cryptography Basics Guide.

How to Read FIPS 140-2 in Practice

FIPS 140-2 should be read as a control validation standard, not as a substitute for broader key management or encryption governance. A validated module can still be misused if keys, certificates, or deployment settings are handled poorly outside the module boundary.

That is why teams usually combine FIPS validation checks with reviews of key lifecycle, approved algorithms, and system configuration. The standard supports trust in the module, but operational security depends on how the module is selected, deployed, and maintained.

When comparing cryptographic platforms, the Encryption Buyer’s Guide helps frame FIPS checks alongside HSM, KMS, and policy decisions, while the Cryptographic Key Management Guide focuses on the lifecycle controls that FIPS validation does not replace.

Risk and Threat Considerations

Weak or misapplied cryptographic validation can create a false sense of assurance. If teams assume a product is secure simply because it advertises cryptography, they may miss whether the specific module is validated, whether the deployment stays inside the approved boundary, or whether tamper and self-test failures are actually handled as intended.

Failure mechanism: The cryptographic module is either not validated, is used outside its approved configuration, or is integrated in a way that bypasses the assurances the standard is meant to provide.

Impact: Sensitive data may be protected by controls that do not meet regulatory or assurance expectations, which can weaken compliance evidence and increase exposure if the implementation fails under stress or compromise.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework Control / Reference Relevance
NIST SP 800-53 Rev 5 SC-13 — Cryptographic Protection FIPS 140-2 validates cryptographic modules used to protect data.
IA-7 — Cryptographic Module Authentication The standard governs module behavior that underpins trusted cryptographic operation.
SC-12 — Cryptographic Key Establishment and Management FIPS 140-2 explicitly covers key management behavior inside cryptographic modules.
Recommendation — Require validated cryptographic modules for approved protection of sensitive data. Use approved cryptographic mechanisms to authenticate components and protect trusted transactions. Enforce controlled key establishment and management within validated cryptographic components.
ISO/IEC 27001:2022 A.8.24 — Use of cryptography FIPS 140-2 supports selecting approved cryptographic implementations for protected data.
Recommendation — Require approved cryptographic implementations and validate their secure use.

Practitioner Guidance

Why practitioners should care: FIPS 140-2 is often a procurement and assurance checkpoint as much as a technical one. Teams need to verify the exact module and operating mode, not just the product name, because validation scope can be narrower than the marketing claim.

Governance implication: Treat FIPS validation as a documentable control requirement tied to approved cryptographic components, then make sure configuration, patching, and key handling preserve that validated state. The Encryption Policy Template is useful here because it connects approved algorithms, key ownership, and rotation expectations to policy language.