Understanding FIPS Validated vs. FIPS Compliant

Our last blog post looked at why FIPS 140 is so important. We also examined why obtaining a FIPS 140 certificate is so difficult and why maintaining that FIPS 140 certificate in active status is even more difficult. In this post, we will look at how being FIPS validated, which means your organization has a FIPS certificate in your name, fundamentally differs from being FIPS compliant (called by some 'FIPS Inside'), which means you use a FIPS certified encryption module that another organization obtained in its name. Ultimately, you will see that FIPS validation is preferable to FIPS compliance.

Naturally, many organizations will not find the traditional approach to achieving and maintaining FIPS 140 validation of their cryptographic modules particularly appealing. These organizations will then search for alternate paths that are more efficient, more predictable, and less costly. As organizations look for these alternative paths, it helps to remember the adage that “there is no free lunch.”  Someone must follow the traditional approach to achieve and maintain FIPS 140 validation, incurring the associated costs and headaches.   Otherwise, the solution is invalid.

Organizations looking to outsource the entire FIPS 140 validation lifecycle to someone else may consider a few choices. One popular path is to leverage a “free” open-source module that has achieved FIPS 140 validation. Another is to leverage an operating system or a cloud service provider with FIPS 140 validated libraries that it can use for encryption. By leveraging FIPS 140 validated modules from these sources, organizations can immediately become FIPS 140 compliant. Unfortunately, while taking the above approach may look like a silver bullet to solving the FIPS 140 problem, many organizations learn the hard way that it is not. There are at least two reasons for this.

Organizations Should Have CMVP Certificates in Their Names

First, FIPS 140 compliance itself may not be good enough. When an organization is FIPS compliant, it uses someone else’s FIPS 140 validated module. Their FIPS certificate is not in the organization’s name, but in the name of the original entity that created the module and shepherded it through the lab and CMVP. So, naturally, that certificate will not list the organization’s products, operating environments, or anything else specific to that organization. 

That is problematic because many government agencies and procurement officers will want to see that the CMVP certificate has the organization’s specific details.   Without that being the case, it may be challenging to demonstrate that the organization is actually using the FIPS 140 validated module in its solution and using it as intended. 

Some compliance regiments like Common Criteria will also require specific testing of the FIPS 140 validated module within the organization’s operating environment (OE), evidence of which needs to appear on the organization’s CMVP certificate. 

In short, organizations risk getting blocked out of deals by not having certificates in their names. That is also more likely to happen when competitors with their own CMVP certificates use them to give themselves an advantage in the procurement process. Consequently, for any organization serious about its public sector business, getting its own CMVP certificate is a smart move they should view as table stakes.

Reliance on Third Parties for FIPS 140 Compliance is Risky

Even if organizations are willing to risk it without their own CMVP certificates, there is another fundamental problem with relying on third parties for FIPS 140 compliance. Unless operating system vendors, cloud service providers, and open-source providers are contractually obligated to the organization to maintain their FIPS 140 validated modules and certificates in active status with CMVP, these cryptographic modules may not survive a NIST transition and become historical. As a result, any organization relying on those modules will no longer be FIPS 140 compliant when that happens. 

That may happen because a module’s OEM:

• decides that a particular module is no longer worth the effort to maintain
• decides to take their solutions in a different direction (e.g., end-of-life of a specific OS version)
• simply misses the boat, encounters issues, or gets delayed in making the needed updates to the module to keep it in good standing with NIST

If any of these happen, an organization may find itself in a tough position, especially if it happens at precisely the wrong time when it is trying to negotiate (or even just stay on) a major contract with a government agency.

The above risks are not theoretical and happen all the time. In fact, as of April 2023, fully 79% of the FIPS certificates in the CMVP database have been declared ‘historical’ by NIST. As a result, they can no longer be used as the basis for new government procurements, either by the organization named on the certificate or any organization claiming FIPS compliance based on that certificate. So why take the chance and gamble being left out of a lucrative contract because of FIPS?  

In our business, we constantly talk to companies that have learned the hard way that there is no free lunch regarding FIPS 140 validation. It is hard, non-stop work, and the best path is to find a trusted, experienced partner to whom you can outsource the whole process of achieving and maintaining FIPS 140 validation. Doing so will not be free, but if you consider all the costs and risks, it will represent the best value and the highest ROI.

Some organizations try to address this problem via a “rebranding” process where they work with a lab to duplicate an existing third-party CMVP certificate in its name. But, does that solve the problem? Only temporarily, mainly because, as we have mentioned previously, attaining certification is only part of the problem. Maintaining it over time is far more challenging. In our next blog post, we will examine why FIPS rebranding is insufficient.