If you are part of a software company that wants to do business with highly regulated customers like hospitals, US federal government, etc., then you cannot avoid FIPS encryption for your tech stack. It is a key component of stringent compliance standards like FedRAMP, CMMC and HIPAA and applies to all data at rest or in transit. 

Most applications don’t encrypt their own traffic and instead, depend on a platform-managed network layer like a service mesh to encrypt internal traffic. This makes a service mesh the ideal platform tool to add FIPS-validated encryption across your entire internal network. However, the open source versions of popular service mesh solutions like Linkerd, Istio, and Cilium do not include FIPS-validated cryptographic modules. While 3rd party commercial vendors offer repackaged FIPS builds of these projects, Buoyant Enterprise for Linkerd is the only 1st party commercial offering with FIPS-validated cryptographic modules along with integrated real-time continuous monitoring capabilities for FedRAMP 20x readiness. 

Let us walk through an all-too-common scenario. Your infrastructure is built with open source projects but FIPS-validated cryptographic modules are part of the paid offering, so your procurement team decides to shop around. A vendor tells your team that they can repackage the open source project to create a container image that is FIPS compliant. The software bill of materials (SBOM) looks clean and the price is competitive so it gets the green light. Then a compliance auditor fails your stack because you could not provide answers to simple questions like 

• “ What is the CMVP certificate number of those components?” or
•  “What is the specific FIPS cryptographic module that encrypted the connection between this source and destination?”   

So before a procurement decision is made, it is important to understand how to evaluate a FIPS claim, either from the creators of the open source projects or from vendors repackaging them. 

There are three important considerations when looking at these

1. Is the compliance provable, at all times?
2. What are your CMVP certification numbers?
3. Is your data actually encrypted in transit?

Let’s go through each of these. 

Is the compliance provable, at all times? 

FIPS compliance is more than a one-time upfront claim. It is a continuous process, so compliance is only possible with on-demand reporting for regular audits and/or adhoc investigations. Federal compliance standards like FedRAMP are evolving and updated guidelines like FedRAMP 20X now require providers to continuously validate their key security indicators with automated checks, supported with point-in-time audits. Simply using the FIPS 140-3 validated modules with annual audits will not satisfy the regulatory requirements. 

This is especially important when it comes to service meshes like Linkerd since they add FIPS validated encryption to your Kubernetes infrastructure. Auditors want to know the effectiveness of your encryption coverage at any given time, including which FIPS module is encrypting which traffic. They need to know the Cryptographic Module Validation Program (CMVP) certificate per component and cipher suite for each individual traffic route. 

However, vendors who repackage a non-FIPS open source image usually don’t offer purpose built real-time compliance reporting. Instead, they push the burden onto the users through CLI/audit commands that require manual verification of the binaries. 

Talking to our customers, Buoyant knew their requirements first-hand and continues to be the only service mesh that includes comprehensive FIPS reporting through

• A real-time in-cluster dashboard that shows FIPS coverage across your mesh and cipher suites in-use per traffic route. 
• Automated visual markers to flag plaintext connections with source, destination and port so you can address it and maintain compliance. 
• An exportable CSV to create a System Security Plan
• An real-time API that outputs OSCAL-formatted JSON to enable continuous reporting and compliance with FedRAMP 20X certification requirements. 

Additionally, when you upgrade a third-party FIPS image, you often need to re-verify it's still compliant—running analysis tools, generating compliance docs, and getting sign-off from your compliance team. 

With BEL, FIPS-validated modules are an integral part of the build and release process, not a post-deployment step, so that you know that any Linkerd binary you deploy was already verified at compile time as built against a FIPS-validated module. For regulated environments, this eliminates the verification burden on each upgrade which can require weeks of re-validation work and/or require using vendor-specific analysis tools. 

If a vendor responds to this question with manual CLI commands or less, then take a step back and look at your timeline and team resourcing. Can you afford to take on this burden? Do you want to? Additionally, loop your audit or compliance team to ensure it meets the regulatory requirements such as FedRAMP 20X. 

What are your CMVP Certification numbers?

For compliance teams, there are two distinct and acceptable terms when it comes to FIPS: FIPS validated vs FIPS compliant. 

• “FIPS validated” means that the software’s implementation of the cryptographic module has received a certificate from a Cryptographic Module Validation Program (CMVP). The certificate confirms that the module(s) was independently verified by a NVLAP-accredited lab. Compliance officers need the CMVP number to verify the status of your technology stack.

• “FIPS compliant” means that the provider is using a FIPS-validated module that is maintained by a separate organization. This is a common practice: for example, a vendor adding FIPS-validated modules to an open-source project, or a provider using libraries that contain validated modules. 

A compliance officer needs to be certain that a vendor claiming to supply FIPS builds actually is supplying FIPS builds. The vendor needs to be able to show the CMVP certificate number for every component that performs cryptography, along with the version for every FIPS module in use. This means that one number is almost never the full answer. For example, BEL’s control plane and its micro-proxy are implemented in different languages, so they use different modules. To go further, ask which module encrypts which traffic path, and whether the CMVP certificate(s) is active or historical. As of September 21st 2026, all FIPS 140-2 certificates have been moved to ‘historical’ in favor of FIPS 140-3, so they are no longer considered active validations. 

A vendor who answers in exact detail has done the work. A vendor who gives a single number, points you to a third party’s certificate without naming it, or says “we’re FIPS” without a number probably hasn’t.

Is your data actually encrypted in transit?

To have FIPS-validated traffic encryption within your entire meshed infrastructure, you need every component of your service mesh, including its proxy, to be built against FIPS-validated cryptographic modules. For the data-in-transit to actually be encrypted by these FIPS modules requires the modules to be correctly linked and available on both ends of the connection. 

How the module is linked into the binary determines whether that FIPS module is actually enabled at runtime. Static linking copies the module into the binary, while dynamic linking loads it from a shared library at startup. Many open source projects use dynamic linking, which makes creating FIPS builds appear straightforward. Linkerd’s Rust micro-proxy is statically linked, so any 3rd party vendor that dynamically links the FIPS-validated modules to Linkerd will have a FIPS image that doesn’t actually use the modules at runtime. That would take more engineering than swapping a shared library, and it’s the part to ask a vendor about directly.

The encryption between a connection is only FIPS-validated if both ends - client and server - use the FIPS-validated modules. A FIPS proxy talking to a non-FIPS proxy leaves that connection outside the validated boundary, as does a FIPS proxy sending to a destination outside the mesh. In both cases, the FIPS module sits in your binary, but the data travels under non-validated encryption (or sometimes even as plaintext). While a configuration enforcement can prevent an incident, a compliance officer will still demand the evidence i.e. the exact module encrypting each connection. 

As stated earlier, Buoyant real-time FIPS reporting tools (dashboard, exports and OSCAL API) show FIPS status for every connection in the mesh, and flags any connection that isn’t correctly complying with the FIPS standard.

Ask any vendor to show you a mixed-proxy connection and an unmeshed destination, and what their tooling reports for each. 

‍

Conclusion

If you are evaluating FIPS images of an open source project, bring your compliance and security teams in early during the evaluation stage to ensure you’re not left holding the bag during an audit. A failed audit can result in project delays by up to 18 months, termination of federal contracts due to your revoked certifications (FedRAMP, CMMC etc) and at worst, expensive penalties. Before you sign a contract, use the three questions above to stress-test the claim.

FAQs

Can anyone other than Buoyant add FIPS support to open source Linkerd?

It's possible, but adding Federal Information Processing Standards (FIPS) support would take significant time, expertise, and close collaboration with the Linkerd maintainers at Buoyant. We keep FIPS commercial because the builds need ongoing maintenance and resources.

How does the Linkerd FIPS dashboard help with compliance audits?

The in-cluster FIPS dashboard shows which FIPS modules are in use in real time, with source, destination, and port. Your audit team gets a live, exportable system of record instead of gathering evidence after the fact.

What's the difference between Linkerd edge releases and Buoyant Enterprise for Linkerd stable releases?

BEL stable releases ship quarterly with SLAs for bug fixes and CVE remediation, which regulated environments need. Open source Linkerd edge releases are production-ready too, but they ship much more often and come with no long-term support commitment.

Can you make dynamically linked open source projects FIPS compliant?

Possibly. Many open source projects dynamically link to OpenSSL for cryptography, and you may be able to swap in a FIPS-compliant version of that library at runtime. Before you rely on one, ask detailed questions and bring your security and compliance teams into procurement.

Why does Linkerd use Rust for its proxy if FIPS requires external cryptographic modules?

Linkerd's micro-proxy runs in every pod, so it has to stay reliable without adding performance overhead. Rust gives us the memory safety and performance that a job needs. We made a deliberate trade-off, accepting harder compliance work in exchange for safety.