FIPS 140–2: How it Evolved and Why It’s Important for Security

Tova Dvorin
5 min readApr 22, 2021


If there’s a term often heard at our Unbound office corridors and many a Zoom meeting, it’s FIPS 140–2. Never heard of FIPS? Then be warned. I am going to take you down a decades-long journey.

What is FIPS and Who is it For?

FIPS stands for “Federal Information Processing Standards” (FIPS) and are standards for cybersecurity produced by the National Institute of Standards and Technology (NIST) whenever required by the federal government.

The “Federal Information Processing Standards” (FIPS) are mandatory for all government organizations (specifically federal government organizations) in the United States — except for national security systems. While not mandatory,[1] it is recommended that all non-federal government organizations in the US, as well as private organizations, adopt FIPS.

The Evolution of FIPS 140

Like most security standards, FIPS (140 standards) are continuing to evolve — and there is an upgrade scheduled soon. However, before you can understand the impact of this upgrade to FIPS and how it will impact your organization let’s review the evolution of FIPS.

The Prequel: FIPS 140–1

It’s important to note that FIPS 140–2 is an updated version of the original cryptographic standards — which were released even further back in the technological timeline: the Proterozoic era known as the 1990s.

In January 1994, a working group of government employees and industry professionals composed FIPS 140–1, releasing the four security levels and eleven core security requirements to be evaluated.

Those four levels include:

  • Level 1 — All components must be “production-grade”
  • Level 2 — Security systems must meet requirements for physical tamper detection and response in case an attacker obtains physical access to the cryptographic module.
  • Level 3 — Security systems must also be tamper-resistant — i.e., make it physically difficult to physically access sensitive information in the module, preventing an attack in the first place. They must also use identity-based authentication systems and involve separation between cryptographic key interfaces.
  • Level 4 — The physical security requirements of the module are strictest and must be accident/disaster-proof.

Put into layman’s terms, the 11 core security requirements include:

  1. What information must be documented
  2. What information flows in and out, and how it’s partitioned
  3. Who holds what roles in terms of data authentication, and the authentication process itself
  4. Documentation of the high-level states the security module may be in, and how transitions occur between those states
  5. Physical security — tamper evidence and resistance, as noted in the “levels” section above
  6. The operating system the module uses and interfaces with
  7. Cryptographic key management — generating, storing, and using keys
  8. Electromagnetic integrity and compatibility
  9. Tests and test procedures
  10. Documentation to support the design quality of the module
  11. Whether or not the module can mitigate other attacks, and descriptions of how it mitigates those attacks.

Six years later, FIPS 140–1 was updated.

FIPS 140–2: Cryptography, 2001

Currently, the FIPS 140–2 certification criteria are based on the IT environment and technologies available at the time it was conceived — nearly twenty years ago, before data was mobile, before widespread use of the cloud, and before the device-driven data dream became a reality.

FIPS 140 as a semi-universal standard took off in the 2000s, when NIST first debuted FIPS 140–2 as a formal baseline to assess the security level of cryptographic modules.

First released in 2001, FIPS 140–2 took account of technological developments and changes, marking the technological equivalent of the Cambrian period in tech history: the slow switch from hardware to software, and the wider use of PINs and passwords.

Some of the many changes include:

  • Strengthening the requirements for secure authentication
  • More coverage of the ports and interfaces for a secure design and implementation of a cryptographic module
  • Updates to physical security requirements
  • Electromagnetic interference/electromagnetic compatibility (EMI/EMC); and
  • Mitigation of attacks which had not existed at the time FIPS 140–1 was released.

A full deep-dive of the changes can be found on the NIST website.

The Future of FIPS 140

Today, FIPS has taken on a life of its own. Now seen as the de facto cryptographic standard for premium hardware, data security, and financial providers on the international scale, attaining the highest FIPS 140–2 level has become another hallmark of brand quality in the IT market.

Technically, FIPS 140–2 has a successor: FIPS 140–3 — which was approved on March 22, 2019, went into effect on September 27, 2019, and will begin testing on September 22, 2020.[2]

FIPS 140–3 will include “updates, replacements, or additions” to current standards from the International Organization for Standardization/International Electrotechnical Commission (ISO/IEC).

How FIPS is Perceived

Our role in protecting our customers’ assets from cybersecurity threats offers us insight into many views around policy — and we find that when it comes to FIPS, enterprise organizations often have inaccurate views about whether FIPS is mandatory, as well as what it does and does not cover.

For greater context about how FIPS is perceived, IBM’s cryptosystems are equipped with FIPS 140–2 Level 4 security, and it is a main selling point in their LinuxOne systems. Most premium financial systems — at the bare minimum — pride themselves on FIPS 140–2 Level 3 security, mostly via legacy Hardware Security Module (HSM) systems.

What FIPS Does Not Secure

FIPS 140–2 standards are important indicators of cryptographic integrity and are mandatory for certain industries.

However, it is important to note that FIPS 140–2 does not cover every aspect of cryptographic key security, including:

  • Whether or not a cryptographic key security module eliminates the single point of failure in a key management system.
  • Key control and protection in external IT environments, e.g., “as-a-Service” models.
  • Policy regulation and governance across the entire cryptographic key management system — an important requirement for compliance in several industries that may supersede FIPS in some cases (e.g., in custodial situations in the financial sector); and
  • Crypto-agility and future-readiness — whether a cryptographic key management system is post-quantum ready, whether it can easily be updated for new system types, information types, cryptographic curves, or types of threats.

On a final note, it’s important to note that the digital IT transformation has greatly impacted the security threat environment across all networks and devices, with implications for cryptographic modules as well. Protection of keys in untrusted environments, crypto-agility, and real-time detection and response to potential key misuse are examples of emerging security needs that require consideration.

To learn more about FIPS 140–2, read our white paper.

[1] Allen, Thelma. “FIPS General Information.” NIST, 21 May 2018,

[2] Allen, Thelma. “Announcing Approval and Issuance of FIPS 140–3, Security Requirements for Cryptographic Modules.” NIST, 22 May 2019,

Originally published at on April 22, 2021.



Tova Dvorin

Content manager. Recovering reporter. Coffee enthusiast and chronic reader.