Why developers need to understand FIPS compliance

Key Takeaways

• FIPS establishes mandatory data protection requirements for systems in use by US federal systems and is required by regulations like FedRAMP.
• FIPS considerations should be taken into account when selecting libraries, configuring crypto modules, choosing base images, or documenting security controls for audits.
• FIPS 140-2 and 140-3 are related to cryptography and apply to base images and containerized applications.
• Common challenges for meeting FIPS regulations include library mismatches, performance impacts, and mismatches.
• Leveraging echo’s FIPS-validated container images is a great way to speed up FedRAMP compliance.

What Is FIPS Compliance and Who Enforces It?

Federal Information Processing Standards (FIPS) is a set of US government standards that define the mandatory cryptographic algorithms, validation processes, and security requirements for protecting sensitive federal data.

FIPS ensures hardened and standardized data protection for Federal agencies. In addition to government agencies, many private sector organizations and regulated industries use FIPS, as they are commonly accepted as a rigorous and reliable security framework.

There are currently 13 active and validated FIPS modules:

1. FIPS 205 - Stateless Hash-Based Digital Signature Standard
2. FIPS 204 - Module-Lattice-Based Digital Signature Standard
3. FIPS 203 - Module-Lattice-Based Key-Encapsulation Mechanism Standard
4. FIPS 202- SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions
5. FIPS 201-3 - Personal Identity Verification (PIV) of Federal Employees and Contractors
6. FIPS 200 - Minimum Security Requirements for Federal Information and Information Systems
7. FIPS 199 - Standards for Security Categorization of Federal Information and Information Systems
8. FIPS 198-1 - The Keyed-Hash Message Authentication Code (HMAC)
9. FIPS 197 - Advanced Encryption Standard (AES)
10. FIPS 186-5 - Digital Signature Standard (DSS)
11. FIPS 180-4 - Secure Hash Standard (SHS)
12. FIPS 140-3 - Security Requirements for Cryptographic Modules
13. FIPS 140-2 - Security Requirements for Cryptographic Modules

FIPS 140-2 and FIPS 140-3 modules focus on cryptographic modules. NIST (the National Institute of Standards and Technology) issues, promotes, enforces, and verifies the FIPS 140-2 and 140-3 standards through its Cryptographic Module Validation Program (CMVP).

Important to know: In September 2026, FIPS 140-3 validation certificates will no longer be accepted for new systems (only existing ones) and FIPS 140-3 will be required.

In most cases, FIPS is mandatory for Federal agencies per the FISMA (Federal Information Security Management Act of 2002 federal law). It is also required for FedRAMP authorization. However, in some specific cases it is not required. For example, national security systems do not always need to apply FIPS. The “Applicability” section in each standard details when it is required and when it is not.

Why FIPS Compliance Matters for Developers

FIPS applies to systems in use by:

• Federal agencies and their partners, like defense contractors
• Federal agency systems’ supply chains
• Private organizations that have voluntarily chosen to adopt FIPS
• Regulated sectors that have voluntarily chosen to adopt FIPS

This means that developers encounter FIPS compliance whenever their software handles sensitive data for government agencies, defense contractors, or regulated and private sectors adopting federal requirements. They will also encounter FIPS compliance when their software is in use inside such a system, as part of the supply chain.

In the development stage, meeting FIPS compliance affects cryptographic libraries, protocols, configuration defaults, and base images used in an application. These need to be selected early and initialized correctly, because hardening existing software to meet FIPS compliance is an excruciating and difficult process. In addition, FIPS compliance also impacts dependency choices, since it limits possibilities.

In the build, testing, and release stages, developers have to document cryptographic usage, track provenance (which modules, which versions, from where), and run tests that prove the system behaves the same when FIPS mode is enabled.

At runtime, Ops teams need to ensure environments are compliant, e.g, with runtime scanning and ensuring containers are compliant.

In addition, developers will need to respond to security questionnaires, vendor assessments, FedRAMP inheritances, and auditors to demonstrate proof that crypto is handled according to FIPS 140-3 or FIPS 140-2 compliance..

FIPS Standards Explained

There are currently 13 active and validated FIPS modules:

1. ‍FIPS 205 - Stateless Hash-Based Digital Signature Standard
   The digital signature algorithm to detect unauthorized modifications to data and to authenticate the identity of the signatory.‍
2. FIPS 204 - Module-Lattice-Based Digital Signature Standard
   The standard used to generate and verify digital signatures.‍
3. FIPS 203 - Module-Lattice-Based Key-Encapsulation Mechanism Standard
   The key-encapsulation mechanism to establish a shared secret key over a public channel.‍
4. FIPS 202- SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions
   The standards of cryptographic SHA-3 family functions for binary data.‍
5. FIPS 201-3 - Personal Identity Verification (PIV) of Federal Employees and Contractors
   The standard for a Personal Identity Verification (PIV) system to authenticate individuals who require access to federally controlled facilities, information systems, and applications.‍
6. FIPS 200 - Minimum Security Requirements for Federal Information and Information Systems
   The standard that specifies minimum security requirements for information and information systems supporting Federal executive agencies, and a risk-based process for selecting security controls.‍
7. FIPS 199 - Standards for Security Categorization of Federal Information and Information Systems
   The standard for categorizing federal information and information systems according to an agency's level of concern for confidentiality, integrity, and availability, along with the potential impact.‍
8. FIPS 198-1 - The Keyed-Hash Message Authentication Code (HMAC)
   The mechanism for message authentication using cryptographic hash functions.‍
9. FIPS 197 - Advanced Encryption Standard (AES)
   The Rijndael block cipher family members approved to transfer data in blocks of 128 bits, as a cryptography foundation.‍
10. FIPS 186-5 - Digital Signature Standard (DSS)
    The algorithms that can be used to generate a digital signature.‍
11. FIPS 180-4 - Secure Hash Standard (SHS)
    ‍The hash algorithms that can be used to generate message digests, which detect whether messages have been changed.‍
12. FIPS 140-3 - Security Requirements for Cryptographic Modules
    The standard for designing and implementing cryptographic modules. Applicable to all federal agencies that use cryptographic-based security systems to protect sensitive information in computer and telecommunication systems.‍
13. FIPS 140-2 - Security Requirements for Cryptographic Modules
    Requirements related to the secure design and implementation of a cryptographic module.

How to Make Software FIPS-Compliant

Building FIPS-compliant software requires consistent use of validated modules and strict documentation around cryptographic operations. Here’s how to get started:

1. Create a “crypto bill of materials”: a table of where and how crypto is used, by which library, for what data.
2. Pick the FIPS-validated crypto module you’ll standardize on. Coordinate with infra/DevOps so the runtime and OS images are also FIPS-capable.
3. Add a crypto package/module, refactor new code to use it, then gradually migrate old crypto calls behind it.
4. For each crypto operation in your inventory, document “current algorithm → FIPS-approved algorithm” and implement changes. Add guardrails (lint, tests, or runtime checks) to prevent regressions.
5. Wrap RNG and key operations in your crypto abstraction and back them by FIPS-validated primitives or KMS/HSM APIs.
6. Create or pull FIPS-enabled base images and host configurations. Choose a reputable registry, like echo, with images that are designed from the get-go to meet FIPS’ official security policy and pass a formal auditor review. This includes using a CMVP certificate appropriate to the image runtime, testing to ensure non-approved algos are blocked and fail, validation processes, consistency across all images, and more. With echo, it’s seamless to pull these FIPS-compliant images into Dockerfiles without any migration headache.
7. Document which config flags must be set (kernel params, JVM opts, OpenSSL config, etc.).
8. Add checks in CI/CD to verify FIPS mode is actually enabled where required.
9. Tag each non-FIPS usage as either “must be replaced” or “out of FIPS scope.” Remove, migrate, or hard-isolate accordingly.
10. Extend your test suite with explicit FIPS-focused tests and add CI checks that fail if non-FIPS algorithms or modules are detected in a “FIPS build.”
11. Document everything.

Common Challenges Developers Face in the FIPS Process

The most common challenges developers run into during the FIPS process include:

• Discovering “hidden crypto” inside dependencies
• Inconsistent environments where local dev, CI, and production don’t all run in FIPS mode.
• Using non-FIPS algorithms by default because libraries don’t enforce secure defaults.
• Language/runtime constraints, such as Go builds without BoringCrypto or Java apps without a FIPS-certified provider.
• Finding a FIPS-compliant base image registry
• Breaking existing features when switching from non-FIPS to FIPS-approved algorithms.
• Performance slowdowns with FIPS modules.
• Legacy interoperability issues, where external systems still use deprecated algorithms.
• Difficulty abstracting crypto because encryption/signing calls are scattered across the codebase.
• Managing keys correctly when moving from app-controlled keys to KMS/HSM-backed FIPS-validated modules.
• Debugging failures in FIPS mode, because error messages from crypto providers are often cryptic.
• Difficulty proving compliance because documentation, evidence, and traceability are required.
  

FAQs

Does FIPS compliance apply outside the United States?

FIPS compliance is a US federal requirement, but many international organizations adopt it because it offers a recognized baseline for secure cryptographic operations. Global enterprises may implement FIPS to align with partners, meet procurement rules, or streamline cross-border security certifications, even when not legally required.

What happens if a cryptographic module loses its FIPS status?

A module can lose its status if its validation expires or if NIST revokes it due to discovered vulnerabilities. Software relying on that module must transition to a validated alternative to maintain compliance. Agencies may stop accepting solutions that depend on a revoked module until developers upgrade and document the new cryptographic path.

How is FIPS compliance verified and documented?

Verification for cryptograpy occurs through the CMVP validation program, which tests cryptographic modules and assigns certificate numbers. Developers document compliance by referencing these certificates, detailing how their software uses the validated functions, and providing configuration steps ensuring FIPS mode operation. Auditors review this documentation during federal security assessments or procurement evaluations.

Are open-source cryptography libraries eligible for FIPS validation?

While open-source crypto libraries can be validated if they undergo the CMVP testing process, often backed by a commercial sponsor, it’s an extremely complex process. The key factor is whether the module is tested, validated, and distributed exactly as reviewed by NIST, which is why it’s recommended to choose a vendor like echo, which offers FIPS-validated components.

Does using a cloud provider automatically make an application FIPS compliant?

No. A cloud provider may offer FIPS-validated cryptographic services, but using the platform does not make an application automatically compliant. Applications must still call validated modules, avoid non-approved algorithms, and document cryptographic usage. Compliance is shared: the provider handles validated infrastructure, while developers must ensure their own code adheres to FIPS requirements.