Introduction to Federal Information Processing Standards (FIPS)

note

If you are not familiar with the distinction between cryptographic modules and cryptographic algorithms, we recommend reading our short primer on Cryptographic Modules vs Cryptographic Algorithms first. It clarifies the terminology and scope used throughout this whitepaper.

Introduction

Publication Date: August 25, 2025

Federal agencies and cloud service providers in the federal systems space are required to use FIPS-validated cryptography to protect sensitive data. This mandate is codified through federal laws, regulations, and frameworks for protecting data at rest and in transit. In practice, this means that any encryption employed to secure federal information must be performed by cryptographic modules that have been tested and validated under NIST's Cryptographic Module Validation Program (CMVP). Simply using strong algorithms like AES or SHA-256 is not sufficient as the implementation of the underlying cryptographic module which provides those algorithms must be formally validated.

This whitepaper provides a an overview of FIPS 140-2 and 140-3 standards, the concept of FIPS-validated cryptography, the Cryptographic Module Validation Program (CMVP), and Security Policies.

The target audience includes compliance teams and engineers aiming to bring commercial offerings into FedRAMP, FISMA, DoD CC SRG, or CMMC compliance. The focus of this whitepaper is on industry standards and best practices relevant to achieving FIPS 140-3 validated cryptography in real-world systems rather than on any specific product or tool that may be referenced.

Who requires FIPS 140-3 Validation and Why does it Matter?

Federal Information Processing Standards-validated cryptography is a term that might or might not be immediately familiar to those reading this whitepaper. For the readers who have worked in federal systems, maintained authorizations for systems which have achieved authorizations/certifications such as FedRAMP, GovRAMP, or CMMC L2, they will certainly be familiar with this termonology. On the other hand, to readers who are new to federal systems and the associated compliance frameworks, FIPS-validated cryptography is a term which was introduced as a requirement which they must meet.

Whether a seasoned veteran or fresh to the industry, many who work to implement FIPS validated cryptography must struggle to read through dozens of NIST Special Publications, assessor guidance, and articles from their peers. The first question everyone who has faced this struggle asks is, "What is the authoritative source that says FIPS validated cryptography is required?"

The following table is the answer to that question, listing the framework, the specific guidance which requires FIPS validated cryptography, and the authoritative source documentation for reference.

FIPS-Validated Cryptography Mandates

Framework / Industry	Requirement	Authoritative Source
All U.S. Federal agencies (FISMA scope)	If an agency specifies that information must be cryptographically protected, the cryptography must be FIPS 140-2/140-3 validated (non-validated cryptography is treated as no protection).	NIST CMVP overview page (“Use of Cryptographic Modules by Federal Agencies and Departments”).
OMB Circular A-130 (implements FISMA)	Requires agencies to use only cryptographic modules that are validated under FIPS 140 when protecting Federal information systems covered by FISMA.	OMB Circular A-130, Appendix I & III.
FedRAMP - Low, Moderate, High	FedRAMP policy sets normative requirements for cryptographic module selection and use, aligning with FIPS 140 validation for protections in scope.	FedRAMP “Policy for Cryptographic Module Selection and Use”.
CUI environments via NIST SP 800-171 (e.g., DFARS 252.204-7012 contractors)	3.13.11: “Employ FIPS-validated cryptography when used to protect the confidentiality of CUI.”	NIST SP 800-171 r2 control text (and r3 mapping).
CMMC 2.0 (Level 2)	SC.L2-3.13.11 mirrors NIST 800-171: use FIPS-validated cryptography when protecting CUI.	DIB SCC CyberAssist explainer of SC.L2-3.13.11.
FBI CJIS Security Policy (criminal justice information)	When CJI is transmitted outside a physically secure location, encryption must use a FIPS 140-validated module (≥128-bit symmetric key); applies to LMR and data in transit/at rest per current guidance.	CJIS Security Policy docs & state CJIS guidance summarizing the FIPS mandate.

Readers responsible for systems subject to these frameworks often ask a practical question: what is the rationale for requiring FIPS‑validated cryptography rather than simply relying on a strong algorithm such as AES-256?

FIPS 140-3 validation matters because it verifies much more than the presence of a strong algorithm. It provides assurance that the entire cryptographic module is designed, implemented, and operated correctly. Modules are tested by accredited laboratories and certified through the NIST CMVP, which produces auditable evidence that satisfies FedRAMP, FISMA, and many DoD and state procurement requirements. Using a non validated library that implements a strong algorithm still leaves risk from implementation bugs, insecure modes, weak entropy, mishandled keys, and configuration drift. It can also block an Authorization to Operate, so adopting a validated module streamlines assessments and reduces compliance and liability risk.

NIST FIPS 140-2 and FIPS 140-3: What Are They?

FIPS 140-2 and FIPS 140-3 are successive versions of the Federal Information Processing Standards (FIPS) that specifies security requirements for cryptographic modules. FIPS 140 (current version 140-3) defines the minimum security requirements that a cryptographic module must meet if it is to be used for protecting sensitive information in U.S. government systems. The standard covers 11 different areas of cryptographic module design/implementation, with each area rated from Security Level 1 (lowest) to 4 (highest) based on the robustness of the controls.

FIPS 140-2 was published in 2001 and remained the standard in use for roughly two decades. FIPS 140-3 is the newer standard released by NIST in 2019. The transition from 140-2 to 140-3 is still currently ongoing and as of September 22, 2021, new CMVP validations are only issued against FIPS 140-3. Though existing FIPS 140-2 module certificates remain valid for up to five years after validation and can still be used by federal agencies, this transition period is soon coming to an end. The Cryptographic Module Validation Program (CMVP) has identified the final date for any FIPS 140-2 validations:

FIPS 140-2 active modules can be used until [September 21, 2026] for new systems. After this date, FIPS 140-2 validation certificates will be moved to the Historical List.

National Institute of Science and Technology Cryptographic Module Validation Program

FIPS 140-2 validated modules will gradually phase out, but agencies may continue to use them for now while vendors work on 140-3 certifications. FIPS 140-3 does not radically change the cryptographic requirements from 140-2, but it updates the testing and documentation processes and adopts the ISO framework.

For readers either looking to implement FIPS-validated cryptography in a new system, the soon to come full phase out of FIPS 140-2 crypographic modules leaves one strong implication: Use FIPS 140-3 validated cryptographic modules whenever possible, and avoid FIPS 140-2 validated cryptographic modules at all costs.

For those maintaining current systems which might leverage many FIPS 140-2 validated cryptographic modules, this same information comes with the strong recommendation to review the full list of all cryptographic modules in use, their current FIPS 140 version, and the sunset date for each module. If a plan to transition modules has not been implemented, immediate action should be taken to:

1. Identify if the current vendor providing the cryptographic module has a newer certification for the FIPS 140-3 validated version of the cryptographic module.
2. If no currently validated version for FIPS 140-3 is available, review the CMVP In Process list to determine if they are currently working on achieving a FIPS 140-3 certification on the cryptographic module and where in the process that module currently is.
3. If neither a current certification for FIPS 140-3 or a In Process certification is present, begin identifying next steps to migrate to an alternative FIPS 140-3 validated cryptographic module, following your change management and significant change processes, and migrating to the new module prior to your current module has gone sunset.
4. If you are unable to migrate cryptographic modules prior to the sunset date, begin tracking on your Plan of Actions & Milestones and identifying any mitigating factors or justifications to provide to your federal agency for any potential risk adjustments or operational requirements to extend the remediation window. This step is entirely dependant on your federal agency's risk tolerance and the scope of impact of the cryptographic module in question to your system's security and privacy posture.

What is FIPS-Validated Cryptography?

FIPS-validated cryptography refers to cryptographic operations performed by a module (software library, hardware device, or firmware) that has undergone independent lab testing and government validation per the FIPS 140 standards. It is not enough to simply use FIPS-approved algorithms (like AES, RSA, SHA) in principle; the implementation of those algorithms must be validated by the CMVP. In other words, FIPS-validated cryptography means using a cryptographic module that appears on NIST's validated modules list and operating it in an Approved Mode in accordance with the security policy.

To achieve validation, a vendor submits their cryptographic module to an accredited laboratory for testing against all applicable FIPS 140 criteria. Upon passing tests and review, NIST issues a certificate for that module. The module is then identified by a certificate number on the NIST CMVP validated modules list, along with a published Security Policy document describing its proper usage.

It's important to distinguish FIPS-validated cryptography from terms like “FIPS-compliant” or “FIPS-capable.” Many software libraries might claim they use “FIPS-approved algorithms” or have a “FIPS mode,” but unless the module has actually gone through CMVP testing and received a certificate, it is not FIPS-validated. True FIPS validation gives assurance that the implementation of algorithms (and the module's overall design) meets the standard - including aspects like generating keys properly, protecting key material, running self-tests, resisting tampering, etc. This assurance is why FedRAMP and government policies insist on validated modules rather than just trusting any library that implements AES. In short, FIPS-validated cryptography means using a NIST-certified cryptographic module, whereas just using AES or SHA-256 in a non-certified library would not satisfy the requirement.

NIST Cryptographic Algorithm Validation Program (CAVP)

The CAVP is the NIST program that validates implementations of approved cryptographic algorithms. Where the CMVP assesses an entire cryptographic module, the CAVP focuses on algorithm correctness. Vendors receive algorithm certificates when an implementation conforms to NIST test requirements.

Each entry on the validated algorithms list identifies the vendor, the specific algorithm and mode, supported parameters such as key sizes, the certificate number, and any caveats or operational notes. Practitioners can use this list to confirm that a library or hardware core has a validated implementation of an approved algorithm.

CAVP validation is a prerequisite for CMVP module validation. A module submitted to the CMVP must incorporate algorithm implementations that already hold matching CAVP certificates for the claimed algorithms, modes, and key sizes. Algorithm validation alone does not satisfy FIPS 140-3 because it does not evaluate module-level design, key management, entropy sources, or physical and operational controls.

In practice, review the module's CMVP certificate together with the underlying CAVP algorithm certificates to verify that the algorithms in the deployed build are validated. This reduces the risk of relying on non-validated builds that would not meet compliance requirements.

NIST Cryptographic Module Validation Program (CMVP)

The CMVP is the joint NIST (U.S.) and CCCS (Canada) program that conducts and coordinates these FIPS 140 validations. Under CMVP, independent labs perform the actual testing of cryptographic modules against the FIPS 140 criteria. The CMVP then validates the results and issues a certification if the module passes. The program maintains a searchable public list of all validated cryptographic modules on the NIST Computer Security Resource Center site. This list is the definitive reference that auditors and compliance officers will check to confirm whether a given product's cryptography is FIPS validated.

Each entry on the validated modules list includes details such as: the vendor, module name/version, certificate number, validation level for each area, and a PDF of the module's Security Policy. For example, if Microsoft says that Windows 11 cryptography is FIPS 140-3 validated, one can go to NIST's CMVP site and find Microsoft's validated modules listed with their certificate numbers.

The NIST CMVP is the gatekeeper for FIPS compliance. It ensures cryptographic modules meet the standard. When building or assessing a federal system, one must identify which cryptographic module is being used for each security function and verify its CMVP validation status. Fortunately, CMVP makes this straightforward via its public listings and documentation. Many operating systems and libraries used in cloud and enterprise environments already have validated modules available.

Cryptographic Module Security Policy

For each validated cryptographic module, a Security Policy document is published to describe how the module meets FIPS requirements and how it should be used securely.

The Security Policy is essentially the manual for a FIPS-validated module's proper operation. It includes:

• A description of the module and its boundaries (hardware, software, firmware components).
• The cryptographic algorithms it implements.
• The FIPS-approved modes of operation, the roles and services.
• The rules that must be followed such as how to initialize in FIPS mode and what to avoid to stay in compliance.
• The list of both Approved algorithms and any Non-approved but allowed algorithms.
• Self-test procedures, error states, and any physical security mechanisms.

An important part of the security policy is the delineation of mode of operation. There are two modes which any FIPS validated cryptographic module can be in:

1. Approved Mode.
2. Non-Approved Mode.

A cryptographic module must be running in its approved mode of operation, as described in the security policy, to be considered "FIPS validated." If the cryptographic module is running in a non-approved mode, the vendor provides no guarantee to the FIPS validation of the cryptographic module or the functions run by the module.

Typically, the security policy will explicitly state how to configure or instantiate the module such that it runs in FIPS-approved mode, and it will list which algorithms are FIPS-approved versus which are non-approved. For example, a module's policy might list SHA-256, SHA-384, AES, RSA, DRBG, etc. as FIPS-approved algorithms available, while also listing MD5 or SHA-1 for non-digital-signature use as “non-approved algorithms” that are present but not to be used in FIPS mode. The policy will often note if some non-approved algorithms are only allowed in specific circumstances. The most common example of this is the usage of SHA-1 which may be allowed for hashing but disallowed for digital signatures.

Why is the security policy important to implementers and assessors? Because it tells you how to deploy the module in compliance. For instance, if you have a FIPS-validated OpenSSL module, its Security Policy will explain that you must call a specific FIPS_mode() enabling function or load a FIPS provider, and that certain algorithms must not be used or the module will transition to a non-approved state. It will also enumerate any configuration settings required.

The security policy is where one finds the allowed configurations and cryptographic primitives for a given module. When ensuring your system is FIPS validated, you often need to consult these documents to verify that you are using the module correctly. The security policy also provides the mapping of the module's certificate number and version. In practice, a good starting point is to locate the Security Policy PDF for each crypto module in your product and review the “FIPS Approved algorithms” and “Non-Approved algorithms” sections, as well as any guidance about module initialization.

Conclusion

Federal programs and sector frameworks require FIPS-validated cryptography where they govern your system. Validation attaches to a cryptographic module, not to an algorithm name by itself, and it only counts when the module is operating in its Approved mode as defined in its Security Policy. The CMVP list and the module's published Security Policy are the authoritative sources for what is validated and how it must be configured.

Implementing FIPS validated cryptography across your stack is one of the largest engineering tasks associated with configuring systems to meet federal requirements. Cryptography spans all layers of a system's technology stack, from operating systems, to containers, to data at rest.

AutomataSECURE has published The Automata FIPS (AFIPS) Model to provide the first industry standard and best practices on mapping Federal Information Processing Standards (FIPS) 140 validated cryptography within a system.

Glossary

A-130: OMB Circular A-130, which implements FISMA requirements for federal information systems.

ATO: Authorization to Operate, the formal management decision that authorizes a system to operate and accepts risk.

CJIS: Criminal Justice Information Services program and policy set that governs protection of criminal justice information.

CAVP: The NIST Cryptographic Algorithm Validation Program (CAVP) provides validation testing of Approved (i.e., FIPS-approved and NIST-recommended) cryptographic algorithms and their individual components.

CMVP: Cryptographic Module Validation Program, the joint NIST and CCCS program that validates cryptographic modules and publishes certificates.

CMMC: Cybersecurity Maturity Model Certification.

CNG: Cryptography API: Next Generation, Microsoft's cryptographic platform.

CSP: Cloud Service Provider.

Cryptographic module: The hardware, software, or firmware that implements cryptographic functions and is assessed as a unit under FIPS 140. The module's boundary and services are defined in its Security Policy.

Controlled Unclassified Information: Information that law, regulation, or governmentwide policy requires to have safeguarding or disseminating controls, excluding information that is classified under Executive Order 13526, Classified National Security Information, December 29, 2009, or any predecessor or successor order, or the Atomic Energy Act of 1954, as amended.

FedRAMP: Federal Risk and Authorization Management Program for assessing and authorizing cloud services for use by federal agencies.

FIPS: Federal Information Processing Standards.

FIPS 140-2: Earlier version of the cryptographic module standard. Certificates move to the Historical List after September 21, 2026.

FIPS 140-3: Current cryptographic module standard. Builds on ISO and uses validation levels 1 through 4.

FISMA: Federal Information Security Modernization Act.

NIST: National Institute of Standards and Technology.

OMB: Office of Management and Budget.

Security Policy: The published document for a validated module that defines the module boundary, roles, services, Approved mode configuration, allowed algorithms, and self-tests.

SP: Special Publication, a NIST series of guidance documents.

TLS: Transport Layer Security protocol for network encryption.