Understanding FIPS 140: A Cornerstone of Cryptographic Security

What Is FIPS 140?

FIPS 140 (Federal Information Processing Standard 140) is a U.S. government computer security standard that specifies security requirements for cryptographic modules – the hardware or software components that perform encryption and other cryptographic functions.

In simpler terms, FIPS 140 sets the ground rules for how encryption engines (in everything from software libraries to hardware appliances) must be built and tested to be considered secure. The standard was developed by the National Institute of Standards and Technology (NIST) in the 1990s, with successive versions over the years: FIPS 140-1 was introduced in 1995, FIPS 140-2 in 2001, and the latest FIPS 140-3 in 2019. Each iteration has built upon the last to address new security challenges and technologies.

At its core, FIPS 140 defines a comprehensive set of criteria that a cryptographic module must meet. These criteria cover everything from the strength of algorithms to the physical tamper-resistance of devices. In fact, NIST outlines 11 critical areas that a cryptographic module’s design and implementation must address:

• Cryptographic Module Specification: Clear documentation of the module’s characteristics and functionalities.
• Ports and Interfaces: Control over all input/output to ensure data flows securely.
• Roles, Services, and Authentication: Definition of authorized roles (user, admin, etc.), the services they can use, and how the module authenticates them.
• Finite State Model: A specified model of all possible operational states of the module (e.g. powering up, self-test, normal operation, error states) to ensure predictable behavior.
• Physical Security: Protections against physical tampering (e.g. tamper-evident seals or hardened enclosures, especially at higher security levels).
• Operational Environment: Constraints on the module’s operating system or runtime environment to maintain security (or requirements that the module runs on a validated OS, etc.).
• Cryptographic Key Management: How keys are generated, stored, protected, and destroyed – the lifecycle of cryptographic keys must be securely handled.
• EMI/EMC (Electromagnetic Interference/Compatibility): Ensuring the module doesn’t emit electromagnetic signals that could be exploited to glean information, and that it operates reliably in expected electromagnetic environments.
• Self-Tests: The module must run startup and ongoing self-tests (e.g. known-answer tests for algorithms) to detect failures or corruption.
• Design Assurance: Rigorous development and documentation practices, showing the module was built with discipline (including source code management, bug tracking, etc.).
• Mitigation of Other Attacks: If applicable, the module should include countermeasures against specific attacks (for instance, side-channel attacks like timing analysis or power monitoring, at higher security levels).

By covering these areas, FIPS 140 enforces a holistic approach to cryptographic module security. It’s not just about using strong algorithms – it’s about implementing and handling them correctly. The standard’s criteria ensure that a crypto module will perform encryption and manage keys in a secure manner, even in the face of both cyber and physical threats.

Another key concept in FIPS 140 is the definition of security levels. FIPS 140-2 and 140-3 define four increasing levels of security (Level 1 through 4) for each of the criteria above, allowing the standard to apply to a wide range of modules from simple software libraries to high-security hardware devices. Level 1 is the most basic (essentially requiring at least one approved algorithm with no special physical security; e.g. a software library on a general-purpose OS). Level 2 adds requirements like role-based access and tamper-evident coatings or seals on hardware. Level 3 requires identity-based authentication and stronger physical tamper-resistance (for example, hardware modules that will zeroize keys if opened). Level 4 is the highest, aiming to provide robust protection even in extreme conditions – it might include active tamper detection and response (e.g. deleting keys if severe environmental anomalies are detected), and comprehensive fault protection to thwart side-channel attacks.

Each level builds on the previous, so higher-level modules meet all the requirements of the lower levels and then some. Organizations choose the level based on their security needs – for example, a software-only product might target Level 1 or 2, whereas a dedicated Hardware Security Module (HSM) for a military application might be designed for Level 3 or 4.

In summary, FIPS 140 is essentially a standardized vetting process for cryptographic engines. If a module is FIPS 140 validated, it means it has been independently tested and meets these stringent requirements, giving confidence that it can protect sensitive data effectively.

Why Is FIPS 140 Important?

FIPS 140 has become one of the most important benchmarks for cryptographic security in government and industry. For a Chief Information Security Officer (CISO) or any cybersecurity professional, seeing that a product’s cryptography is “FIPS 140 validated” provides a strong assurance that the encryption won’t be the weak link in their security chain. Here are a few key reasons why FIPS 140 is so crucial:

• Assurance of Proper Implementation: Cryptography is notoriously hard to implement correctly – subtle bugs or design flaws can completely undermine an encryption algorithm’s security. FIPS 140 validation means the module’s implementation and operational procedures have been independently reviewed, tested, and vetted by experts before deployment. In other words, the cryptographic module isn’t just using approved algorithms; it’s using them in the right way and with the necessary safeguards. This addresses a real-world concern: many security incidents have occurred not because AES or RSA algorithms were broken, but because they were implemented or used improperly. FIPS 140 validation vastly reduces this risk by catching implementation flaws.
• Use of Strong, Approved Algorithms: The FIPS 140 standard works hand-in-hand with NIST’s cryptographic algorithm standards. It permits only approved, modern algorithms (and mandates minimum key lengths and strengths) for a module to pass. For example, AES (128-bit or higher) is FIPS-approved for symmetric encryption, while older ciphers like DES are disallowed except in certain legacy contexts. SHA-2 and SHA-3 hash functions are approved, whereas broken or weak hashes like MD5 and SHA-1 are deprecated or forbidden. FIPS 140-3 explicitly requires a minimum security strength of 112 bits for any cryptographic function. This means when you see “FIPS 140 validated,” you can be confident the module isn’t using outdated or insecure crypto algorithms. The standard essentially enforces state-of-the-art cryptography by design.
• Mandatory for U.S. Federal Use (and Beyond): FIPS 140 validation is not just a best practice – it’s often a legal or contractual requirement in the public sector. U.S. federal agencies, including the Department of Defense and the Intelligence Community, require products to use FIPS 140-validated cryptography for protecting Sensitive but Unclassified (SBU) data. In fact, federal policy (e.g., FISMA and FedRAMP for cloud services) stipulates that if encryption is used to protect data, it must be a FIPS-validated module. This requirement flows down to federal contractors and often into regulated industries like finance and healthcare that handle sensitive data. As a result, FIPS 140 has become a de facto industry standard – even organizations not strictly required by law to use it will adopt FIPS-validated crypto to meet customer expectations or to comply with broader security frameworks. For example, security benchmarks like NIST 800-171 (for protecting Controlled Unclassified Information) and the emerging CMMC program for defense contractors also lean on FIPS 140 for cryptographic requirements. A product that is not FIPS compliant might be automatically disqualified for use in many government projects and may be viewed with skepticism by enterprise customers who demand high assurance.
• Confidence Through Rigor: One of the biggest benefits of FIPS 140 is the rigor of the validation process (which we’ll detail in the next section). When a module passes, it means that not only were its algorithms tested, but also its handling of keys, its resistance to tampering, the quality of its random number generation, and more have all been evaluated. This comprehensive vetting gives CISOs confidence that the crypto won’t silently fail. As Cisco’s security team put it, being FIPS-validated means the encryption methods “have been independently reviewed and tested” and “endured extensive security analysis” to ensure they provide adequate security. In an era of supply-chain concerns, that independent validation is extremely valuable – it’s not just the vendor claiming their encryption is secure; it’s backed by a government-standard process and a certification listing.
• Wide Recognition and Interoperability: FIPS 140’s importance also stems from its wide recognition. It’s a bi-national standard (USA and Canada jointly oversee it) and is aligned with international standards (ISO/IEC 19790, see below), which means a FIPS-validated module is recognized broadly as meeting a high bar. This can simplify compliance across multiple regulations and even multiple countries. It also encourages vendors to design products in a way that others can trust and integrate; for example, if you use a FIPS-validated library in your software, your customers (or your auditors) don’t need to vet the crypto from scratch – the validation certificate serves as a common point of trust.

In essence, FIPS 140 is important because it turns cryptography – which can be an arcane and error-prone art – into something measurable, testable, and trustworthy.

For CISOs, it’s a way to manage risk: by insisting on FIPS-validated encryption, they leverage NIST’s stringent process to weed out weak crypto implementations. Organizations “serious about cybersecurity” often invest heavily to ensure their cryptographic tools are FIPS-compliant, precisely because doing crypto right is not easy. FIPS 140 gives them a proven recipe (and a testing yardstick) for doing it right.

How NIST Evaluates Cryptographic Modules (The FIPS 140 Validation Process)

FIPS 140 is not just a document of recommendations – it is tied to a formal validation program run by NIST and its partners. This program is known as the Cryptographic Module Validation Program (CMVP). Understanding how CMVP works is key to appreciating the value of FIPS 140 and what it means to be “FIPS validated.”

Joint Effort by NIST and CCCS: The CMVP is jointly operated by NIST in the U.S. and the Canadian Centre for Cyber Security (CCCS, part of Canada’s CSEC). This partnership means a FIPS 140 certificate is recognized by both U.S. and Canadian governments. The program was established in the late 1990s and has been evolving alongside the FIPS 140 standards. These two agencies oversee the program’s policies and approve the final validation certificates.

Independent Testing Laboratories: NIST itself doesn’t directly test vendor products for FIPS 140; instead, testing is performed by independent accredited laboratories. These labs are accredited through NIST’s National Voluntary Laboratory Accreditation Program (NVLAP) and Canada’s equivalent, to ensure they have the expertise and follow strict testing procedures. When a company (vendor) wants a cryptographic module validated, they engage one of these accredited labs to perform a thorough evaluation of the module against the FIPS 140 criteria. The testing process is exhaustive – labs will verify that the module’s algorithms are correctly implemented (often by running known-answer tests or using NIST’s algorithm test vectors), examine the source code and hardware design for compliance with each requirement area, inspect the module’s physical security features, and witness the module performing its self-tests, among many other tasks.

Documentation and Security Policy: Part of the evaluation involves scrutinizing the module’s documentation. Vendors must provide a detailed design and security document (often called a “Cryptographic Module Security Policy”) describing how the module meets each FIPS 140 requirement. This document becomes public upon validation, serving as a reference for users about the module’s secure usage. The lab and NIST review this policy to ensure it accurately reflects the module’s design and FIPS compliance. For example, the Security Policy will list all the approved algorithms the module implements, the module’s FIPS 140 security level, its operational environment, how to put it in a FIPS-approved mode, and so on.

Approval and Certification: Once the lab is satisfied that the module meets all applicable requirements, it submits a test report to NIST and CCCS. The agencies then perform their own review of the results. If everything is in order, NIST/CCCS will issue a FIPS 140 validation certificate for the module. The module is then added to NIST’s public list of validated cryptographic modules, which is the authoritative reference for anyone to verify a product’s FIPS status. Each certificate lists the module by name and version, the vendor, the laboratory that tested it, the security level achieved, and other specifics (like supported algorithms and the exact hardware/software version). As of late 2023, well over 900 modules had active FIPS 140-2 certificates, and the number of validated modules continues to grow under FIPS 140-3.

It’s worth noting that NIST uses the term “validated” rather than “certified.” The distinction is subtle – in common parlance people say “FIPS certified” – but NIST prefers “validated” because the government itself isn’t the testing body; instead, it validates the results from the accredited lab and then issues a validation certificate. In practice, “FIPS 140 certified” and “FIPS 140 validated” are used interchangeably to mean a module has successfully passed this process. What matters is that there is an official NIST certificate number for the module.

Continuous Testing and Assurance: The evaluation doesn’t stop at one point in time. FIPS 140 requires modules to be revalidated if they are changed in certain ways (for instance, if you modify the code or add new algorithms, you may need to undergo a “delta” validation or a new full validation). Additionally, modules can be revoked or moved to a historical list if weaknesses are found later or if the standard is updated (more on the transition to 140-3 soon). This means vendors have to maintain the robustness of their crypto modules over time. Some modules also undergo algorithm-specific validations (like separate NIST validation programs for AES, RSA, etc.) as part of or alongside FIPS 140 – ensuring, for example, that their AES implementation passes NIST’s AES Known Answer Tests.

Scope of Validation – Modules not Entire Products: It’s important to understand that FIPS 140 validation applies to the cryptographic module within a product, which might be a specific library, chip, or subsystem – not necessarily the whole product itself. For example, a web application isn’t “FIPS validated” as a whole; rather, the SSL/TLS library it uses (maybe an OpenSSL FIPS module) could be validated. A security appliance might have a FIPS-validated hardware security module or firmware inside it. This modular approach is by design: it allows one validated crypto engine to be used in many products. As long as the product uses that engine properly, it can claim to be using “FIPS 140 validated cryptography.” We’ll discuss in a later section what it means for a product to be FIPS compliant and how vendors leverage validated modules.

In summary, the NIST evaluation process for FIPS 140 is rigorous and multi-layered – involving vendor documentation, independent lab testing, and government review. It ensures that by the time a cryptographic module is FIPS-validated, it has gone through a gauntlet of checks. The result is a high-confidence assurance that the module adheres to best security practices. This rigorous process is exactly why many organizations trust FIPS 140 – it’s a lot more than a vendor’s claim or a quick self-attestation; it’s an intensive vetting of the cryptography under the hood.

FIPS 140-2 vs FIPS 140-3: Why and How the Standard Evolved

For nearly two decades, FIPS 140-2 (issued in 2001) was the gold standard for cryptographic modules. However, technology doesn’t stand still for long, and by the 2010s it was clear that an update was needed. Enter FIPS 140-3, which was approved in March 2019 and became effective on September 22, 2019 – officially superseding FIPS 140-2. The introduction of FIPS 140-3 is a significant milestone, so let’s explore when and why FIPS 140-3 replaced FIPS 140-2, and what changed.

Alignment with International Standards: One of the primary reasons for the new FIPS 140-3 standard was to better align with global standards and modernize the program. Rather than reinventing the wheel, FIPS 140-3 explicitly adopts ISO/IEC 19790:2012 as the technical basis for security requirements, and ISO/IEC 24759:2017 for testing requirements. In practice, this means FIPS 140-3 is largely harmonized with the international community – a cryptographic module that meets FIPS 140-3 should also meet the ISO standard (and vice versa). This change helps in several ways: it fosters international recognition of FIPS validations, reduces duplicated effort for companies that sell globally, and allows FIPS to benefit from the collective wisdom of the international crypto community. The move toward ISO also came with some procedural changes in how the validation program is managed (for example, adopting ISO nomenclature and documentation formats), but technically, FIPS 140-3 does not radically overhaul the FIPS 140-2 requirements. Instead, it tweaks and extends them. There are “few major technical requirement changes” noted by NIST, but a lot of behind-the-scenes improvements in clarity and consistency thanks to the ISO alignment.

Stronger Testing and Modernized Requirements: While the core concepts (like the 11 requirement areas and 4 security levels) remain, FIPS 140-3 introduced some enhancements to address lessons learned since the 140-2 era. For example, FIPS 140-3 more explicitly addresses non-invasive physical attacks (like power analysis, radiation, or other side-channel attacks) in its higher security levels, ensuring modules have countermeasures where appropriate. It also refines the requirements around authentication and integrity testing of software, and strengthens guidance on how and when certain self-tests can be deferred or run (these were topics in draft updates and workshop discussions during the development of 140-3). In short, FIPS 140-3 raises the assurance bar – as one commentary put it, it involves “much more rigorous testing and validation” than 140-2. The changes are evolutionary, not revolutionary, but they address emerging attack vectors and incorporate best practices that have evolved since 2001.

Why It Matters: The transition to FIPS 140-3 is significant for CISOs and product teams because it future-proofs cryptography compliance. If you have products or systems that currently rely on a FIPS 140-2 validated module, you need to monitor the roadmap of that module – is the vendor providing a FIPS 140-3 updated version? Many are: for instance, OpenSSL, Bouncy Castle, and others have been working on FIPS 140-3 validations for their libraries. If a module doesn’t get re-validated under 140-3, it will effectively expire in 2026. The good news is that most major players have embraced FIPS 140-3. The new standard also helps in addressing modern expectations (like stronger algorithms and side-channel protections) and cements the trust in cryptographic modules by using an internationally vetted approach.

For context, FIPS 140-2 was an extremely successful standard – it had nearly a thousand validated modules and was adopted worldwide – but by 2019 it was showing its age (it hadn’t been fundamentally updated since its publication in 2001). FIPS 140-3 ensures the standard remains relevant in the face of evolving threats and technologies (for example, new forms of cryptanalysis or the need for modules that implement post-quantum algorithms in the near future). By aligning with ISO standards, it also avoids divergence – there was an increasing need to not have separate U.S. vs international criteria for crypto modules. Now a single, universal baseline exists.

In summary, FIPS 140-3 replaced FIPS 140-2 to modernize the standard, incorporate international best practices, and maintain the high assurance pedigree of FIPS for the next generation of cryptographic modules. The transition is well underway, and by 2026 FIPS 140-2 will be fully retired from active use – marking the end of an era and the full adoption of 140-3 going forward.

FIPS 140 “Certified” vs “Validated”: What It Means for Products and Systems

We’ve discussed FIPS 140 as a standard for cryptographic modules, and how modules get validated. But what does it mean when a vendor claims their product or system is “FIPS 140 certified” (or FIPS 140 validated)? As a CISO evaluating products, it’s important to understand this terminology so you know what you’re actually getting.

Firstly, it’s useful to clarify the wording: strictly speaking, products aren’t FIPS 140 certified – cryptographic modules are. However, vendors often advertise that their product is compliant with FIPS 140, meaning the product’s encryption components use a validated module. The term “FIPS 140 certified” is used in marketing, but the correct term that NIST uses is “FIPS 140 validated.” In practice, you can treat them as the same notion, with the understanding that there is an official certificate behind the scenes.

When a product is said to be FIPS 140-2 or FIPS 140-3 validated, it implies that the cryptographic engine within that product has undergone the FIPS 140 validation process and received a certificate. For example, a secure VPN appliance might contain an embedded cryptographic chip, and that chip’s firmware was validated to FIPS 140-2 Level 2 – thus the appliance can be advertised as FIPS 140-2 compliant. Similarly, a software application (say, a secure messaging app) might be using a FIPS-validated software library (like a FIPS-mode OpenSSL) for all its encryption; the app itself isn’t directly validated, but it is compliant because all cryptography is handled by a validated module.

From a user or buyer’s perspective, FIPS 140 validation means two big things:

1. The cryptography meets a known standard – You are not getting some home-brew or unverified encryption algorithm; you’re getting NIST-approved algorithms implemented in a tested way. This drastically reduces the risk of hidden crypto vulnerabilities.
2. Independently tested security – As explained, an independent lab tested the crypto module. So when a product is FIPS 140 validated, you can trust that claim because you can actually look up the module’s certificate on NIST’s website. It’s not just the vendor’s promise; it’s been validated by a third party (with NIST overseeing it).

For vendors, there are two ways to achieve FIPS 140 compliance in their product:

• Obtain their Own FIPS 140 Certificate: This means the vendor designs or selects a cryptographic module, runs it through the CMVP process themselves (with a lab), and gets a certificate issued specifically naming their module and company. Some big companies do this for custom modules or unique hardware. It gives them full control and their certificate can list their product names and versions. It’s also necessary if their customers (like certain government agencies) demand that the crypto be validated specifically under the vendor’s name. However, this approach is costly and time-consuming, because going through a full validation (and maintaining it through updates) is a significant effort.
• Leverage an Existing Validated Module: This is a very common approach – sometimes called “FIPS 140 inside” or simply being FIPS compliant by inheritance. For example, a company building a new VPN software might decide to use OpenSSL’s FIPS-validated module (instead of writing their own crypto). By doing so, they immediately get FIPS-grade crypto without having to validate from scratch. Cisco has used this approach by developing a generic crypto module that they got FIPS-validated, which they can then embed in many of their products – thus each product can claim FIPS compliance by virtue of using that module. Likewise, many software vendors rely on the cryptographic services of the operating system (like Microsoft’s or Red Hat’s), which are FIPS validated, or use libraries from companies like SafeLogic or WolfSSL that sell ready-made validated modules. This approach is more efficient, but it comes with a caveat: formally, the FIPS certificate is in the name of the module provider, not the product vendor. In most cases this is fine – it still meets the requirement of using validated crypto. But some strict procurement scenarios (particularly in government) prefer or require that the certificate be in the actual product vendor’s name, to avoid ambiguity. Generally, using an existing module is acceptable for compliance, but it means you are trusting the third-party that maintains that module’s validation status. If that third-party lets their certificate expire or doesn’t update to FIPS 140-3, your product might suddenly fall out of compliance. So it’s important to have assurances from your crypto library supplier.

In summary, when a product is FIPS 140 validated, it means its cryptographic component was validated to FIPS 140. This gives the product a stamp of approval for use in high-security environments. As a consumer or CISO, you should ask “Which module is validated, and what level?” A genuine claim will be backed by a certificate number you can verify. Also, be mindful of terms like “FIPS 140 compliant” – typically this means the product uses FIPS-validated algorithms or modules but may not have a certificate of its own. For practical purposes, if the crypto module is indeed validated, you’re covered. But it’s wise to ensure the module is listed on NIST’s validation site and is appropriate for the product’s platform and version.

One more nuance: FIPS 140 validation often has a notion of “FIPS mode”. Many products or libraries run in either a regular mode or a FIPS-approved mode. For instance, Windows and Linux systems have configurations to run in FIPS mode, which ensures only FIPS-approved crypto algorithms are used by applications. OpenSSL (in version 3) has a FIPS provider that you can enable for FIPS mode. As a CISO, if you need FIPS compliance, it’s not enough that a product has a validated module somewhere – you need to deploy and configure it in a way that the module is actually used for all cryptography. Vendors will usually provide guidance for operating their product in FIPS mode (for example, a setting that ensures it only uses the validated cryptographic module). This is important operationally: a product might include both a validated library and a non-validated one for different features; the FIPS compliance statement will assume you configure it to use the validated one exclusively.

In essence, “FIPS 140 validated” is a badge of trust. It’s the cryptographic equivalent of a safety certification on electrical equipment. It means the product’s cryptography was built to a high standard and verified by experts. For organizations, deploying FIPS-validated solutions is often a non-negotiable requirement whenever sensitive data is involved, not only to satisfy regulations but to ensure strong security in practice.

Common FIPS-Validated Cryptography Libraries and Modules

Over the years, many cryptographic libraries – both open-source and proprietary – have achieved FIPS 140 validation. As a security professional, it’s useful to know some of the major ones, since these are the building blocks found in many enterprise and government systems. Here we highlight a few of the common cryptography libraries/modules that are FIPS validated (under FIPS 140-2 and/or 140-3):

• OpenSSL FIPS Module: OpenSSL is the ubiquitous open-source cryptographic library used in countless applications (for TLS, secure communications, etc.). Because it’s so widely used, a special FIPS-compatible version of OpenSSL was created and validated. The most famous was the OpenSSL FIPS Object Module (v2.0), which was FIPS 140-2 validated and became the cryptographic core for many products. OpenSSL’s newer 3.x series has a FIPS 140-3 validated provider as well (the validation was achieved in coordination with the OpenSSL 3.0 release). This means that software using OpenSSL in FIPS mode is relying on a known validated module. Many Linux distributions (Red Hat, Ubuntu, etc.) provide OpenSSL built in FIPS mode for government use. OpenSSL’s FIPS module has historically been Level 1 (software module) and focuses on correctness of algorithms and software security.
• BoringCrypto (Google’s Open-Source Module): Google, recognizing the importance of FIPS for its cloud and Android platforms, took a somewhat different route. Google’s internal crypto library, known as BoringSSL (a fork of OpenSSL), includes a core module called BoringCrypto. Google went through the effort to get BoringCrypto validated, and it received a FIPS 140-2 certificate in the 2010s. More recently, BoringCrypto was one of the early modules to be FIPS 140-3 validated – in fact, as of 2023, Google’s BoringCrypto module received a FIPS 140-3 certificate (#4735). This module is used in many Google products (Chrome’s https, Android’s disk encryption, Google Cloud’s infrastructure) to ensure they meet FIPS requirements for government customers. What’s notable is that BoringCrypto is open-source (part of BoringSSL), showing that even tailored solutions can achieve validation.
• Bouncy Castle FIPS Library: Bouncy Castle is a popular open-source cryptography library, especially known in the Java and.NET world. The Bouncy Castle developers created a FIPS edition of their library (for both Java and C#) and got it validated. Bouncy Castle’s FIPS APIs have been FIPS 140-2 validated and are in process (or already completed) for FIPS 140-3medium.com. This is significant because it provides an open-source FIPS-validated option for Java applications (which historically often relied on proprietary offerings). Bouncy Castle’s FIPS version is separate from their regular version – it undergoes extra code review and testing. Today, Bouncy Castle FIPS is used in various products, and even some big tech companies incorporate it (for example, AWS’s TLS toolkit in certain services has used Bouncy Castle). Bouncy Castle provides both the crypto provider and a JSSE (Java SSL) implementation in FIPS mode.
• RSA BSAFE: This is a long-standing proprietary cryptographic library originally from RSA Security (now under Dell/EMC). BSAFE was widely used in commercial products especially in the early 2000s. It has had multiple versions FIPS 140-2 validated. BSAFE provides a full suite of encryption algorithms, and historically some companies chose it for the assurance of support and FIPS compliance. Unlike the open-source libraries above, BSAFE is closed-source. As noted by commentators, BSAFE is an example of a closed implementation that achieved FIPS validation, whereas OpenSSL and Bouncy Castle are open implementations – both approaches can meet the standard. Many high-end products (like certain firewalls, secure email gateways, etc.) integrated BSAFE under the hood to satisfy FIPS requirements.
• Microsoft Cryptographic Modules: Microsoft’s operating system cryptography libraries (e.g., the CryptoAPI and later CNG in Windows) have gone through FIPS validation. For instance, the Microsoft Enhanced Cryptographic Provider and later the Windows CNG Cryptographic Primitives library have FIPS 140-2 validations. This is why Windows has a “FIPS mode” you can enable – it ensures that only the FIPS-validated crypto provider is used. In effect, if you build an application on Windows and use Microsoft’s standard crypto APIs with FIPS mode on, you are using FIPS validated cryptography. Microsoft continues to update its modules and will be moving these validations to FIPS 140-3 as well. So, many enterprise products built on Windows automatically leverage Microsoft’s FIPS module.
• Linux Distributions (OpenSSL and Kernel Cryptography): Similarly, Red Hat Enterprise Linux has for years provided a FIPS-validated OpenSSL and a FIPS-validated kernel crypto module (for things like IPSec, etc.). Red Hat (and its derivatives) go through the validation of the underlying crypto so that government customers can deploy applications on Linux and be in compliance as long as they use the system crypto. Ubuntu has also obtained FIPS 140 validations for its libraries in certain editions of Ubuntu (notably for its customers in government and regulated industries). These platform-level modules might not be widely recognized by name outside the specific OS (they often have names like “Red Hat Core Crypto Module”), but they are heavily used since every application on those systems can rely on them.
• AWS Libcrypto (AWS-LC): Amazon Web Services took OpenSSL and BoringSSL as inspiration and created their own optimized crypto library called AWS-LC. AWS-LC has undergone FIPS 140-2 validation (as a derivative of OpenSSL’s FIPS module) for use in AWS’s cloud services. AWS is in the process of getting AWS-LC FIPS 140-3 validated, ensuring that all cryptographic operations in AWS that need FIPS compliance (for government cloud regions, etc.) have a validated backend. For cloud customers, AWS and other cloud providers often document which services use FIPS 140 validated modules and how to enable FIPS mode in cloud workloads.
• Other Specialized Modules: There are many other examples across the industry. WolfCrypt (from WolfSSL, a lightweight TLS library often used in embedded/IoT) has a FIPS 140-2 validated variant and is working on 140-3. The OpenSSL FIPS Object Module we mentioned was even used by Cisco and VMware in some of their products. Oracle’s Java platform in the past offered a FIPS-validated SunJSSE provider (though many Java apps opt for Bouncy Castle FIPS now). Even some newer entrants like Libgcrypt (the GnuPG/GnuTLS cryptographic library) have had FIPS-validated versions through Linux vendors.

On the other hand, it’s interesting to note some popular crypto libraries that are not FIPS validated. A notable example is libsodium (NaCl), a modern cryptographic library appreciated for its simplicity and safety for developers. Libsodium uses robust algorithms (many of which are actually strong), but it has not gone through the FIPS validation process. As a result, you are unlikely to see libsodium in systems that require FIPS compliance (like financial or critical infrastructure applications), because it “has not been rigorously tested against FIPS 140-2” or 140-3. This doesn’t mean libsodium is bad crypto – it means it hasn’t been formally vouched for by NIST. Organizations with compliance needs will choose a validated library instead, even if they might like libsodium’s API, because using it could put them out of compliance. This shows how FIPS 140 can influence technology choices.

Key Takeaway: If you’re building or procuring a system and FIPS 140 compliance is a requirement, you will likely be dealing with one of the well-known validated libraries or modules. Open-source options like OpenSSL, Bouncy Castle, and WolfCrypt mean you don’t have to reinvent the wheel – you can get a validated cryptographic core and build your product around it. Proprietary options like BSAFE or platform-specific modules are also available if they fit better. The main point is to ensure that whatever crypto library is in use, it has a current FIPS 140 certificate and that you operate it in the proper mode. Keep an eye on the version (the validation is specific to versions – e.g., “OpenSSL 1.0.2 XYZ Module version 2.0” might be validated, but if you upgrade to OpenSSL 1.1.1, you need the new validated module). Also, as the industry transitions to FIPS 140-3, ensure your crypto providers have a plan for compliance with the new standard.

Conclusion

FIPS 140 may sound like just another bureaucratic standard, but in practice it has been a cornerstone of trust in digital security infrastructure. It provides a common language and benchmark for cryptographic security that resonates from government agencies to private enterprises worldwide. For CISOs and cybersecurity professionals, FIPS 140 validation is a valuable indicator – it tells you that the cryptography underpinning a product has passed muster against an objective, stringent set of criteria.