Skip to main content
  1. Index/

FIPS 140-2 / FIPS 140-3

Table of Contents

FIPS 140 (Federal Information Processing Standard, Publication 140) is the US and Canadian government standard that defines security requirements for cryptographic modules — the hardware, software, or firmware components that perform cryptographic operations (encryption, decryption, hashing, signing, key management). It is published by NIST (National Institute of Standards and Technology) and jointly administered with CCCS (Canadian Centre for Cyber Security) through the Cryptographic Module Validation Program (CMVP). The standard has two active versions: FIPS 140-2 (published 2001, no longer accepting new submissions since April 2022) and FIPS 140-3 (effective September 2020, the current standard for all new validations). FIPS 140-2 certificates remain valid until 21 September 2026, after which they move to the Historical list — meaning only FIPS 140-3 validated modules will be accepted for new federal procurements. FIPS 140 defines four security levels (Level 1 through Level 4), with Level 1 being the baseline for software modules and Level 4 requiring physical tamper-active hardware. Compliance is mandatory for all US federal agencies and their contractors under FISMA, for Canadian federal systems, and is widely adopted by regulated industries (finance, healthcare, critical infrastructure) globally. Non-validated cryptography is treated as providing no protection — effectively plaintext — regardless of the algorithm strength. Validation is a formal, lab-based process: vendors submit modules to accredited Cryptographic and Security Testing (CST) laboratories, which test against the standard and submit results to CMVP for certificate issuance.

Red Hat maintains one of the most comprehensive FIPS validation portfolios of any Linux vendor. As of 2025–2026, Red Hat holds active FIPS 140-3 certificates for multiple cryptographic modules across RHEL 8 and RHEL 9: OpenSSL FIPS Provider, NSS Cryptographic Module, libgcrypt, GnuTLS, and the Kernel Cryptographic API — validated on Intel, IBM Z (s390x), and IBM Power architectures. RHEL 9 and RHEL 10 are FIPS 140-3 only releases, while RHEL 8 maintains a mix of FIPS 140-2 and 140-3 certificates. Red Hat enables FIPS mode at the operating system level: when enabled (at install time or via fips-mode-setup), RHEL enforces that only validated cryptographic implementations are used system-wide — disabling non-approved algorithms, configuring TLS to use only FIPS-approved cipher suites, and ensuring the kernel self-tests its crypto on boot. This system-wide FIPS enforcement propagates upward through the stack: OpenShift inherits RHEL’s FIPS boundary, meaning all platform cryptography (etcd encryption, API server TLS, service mesh mTLS, image signing) uses validated modules without per-application configuration. Red Hat’s FIPS strategy follows a “validate once, inherit everywhere” model — because all higher-level Red Hat products (OpenShift, Ansible, RHACS, Quay) rely on RHEL’s cryptographic libraries, a single set of CMVP certificates covers the entire product portfolio. For federal customers, this eliminates the need to independently validate each software component and ensures continuous compliance as FIPS 140-2 certificates expire in September 2026.

Additional Information
#

Related

FedRAMP

The Federal Risk and Authorization Management Program (FedRAMP) is a US government-wide program, codified into law by the FedRAMP Authorization Act of 2022, that provides a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services used by federal agencies. FedRAMP is administered by the General Services Administration (GSA) and is mandatory — any cloud service (SaaS, PaaS, IaaS) that stores, processes, or transmits federal data or metadata must achieve FedRAMP authorization before it can be used by US government agencies or their contractors. The program defines three impact levels: Low (limited adverse effect), Moderate (serious adverse effect), and High (severe or catastrophic effect — applies to law enforcement, emergency, financial, and health systems). Each level maps to NIST SP 800-53 Rev 5 control baselines: FedRAMP High requires implementation of approximately 421 controls. Authorization is achieved through either an Agency ATO (a specific agency sponsors the assessment) or the newer FedRAMP 20-X experimental accelerated path. Once authorized, cloud service providers (CSPs) must maintain continuous monitoring — monthly vulnerability scans, annual penetration testing, and Plan of Action & Milestones (POA&M) reporting — or risk revocation. Authorized services are listed on the FedRAMP Marketplace.

NIST 800-53

NIST Special Publication 800-53 is published by the National Institute of Standards and Technology (NIST), a US federal agency within the Department of Commerce. The current version is Revision 5 (September 2020, updated December 2020), which defines over 1,000 security and privacy controls organized in 20 control families (Access Control, Audit and Accountability, Configuration Management, Incident Response, System and Communications Protection, Supply Chain Risk Management, etc.). NIST 800-53 is mandatory for US federal agencies and their contractors under FISMA (Federal Information Security Modernization Act) and serves as the control baseline for FedRAMP (cloud), CMMC (defense contractors), and many state/local government programs. Beyond the US, it is widely adopted internationally as a comprehensive reference catalog — organizations in finance, healthcare, and critical infrastructure worldwide use NIST 800-53 as their control framework. The standard defines three baselines (Low, Moderate, High) corresponding to the potential impact of a security breach. NIST 800-53 is not a certification itself but the control catalog against which systems are assessed; formal authorization (ATO — Authority to Operate) is granted by an authorizing official after an assessor verifies control implementation using NIST SP 800-53A assessment procedures. The companion OSCAL (Open Security Controls Assessment Language) standard, also from NIST, provides machine-readable formats for expressing 800-53 controls and assessment results.

AES (Advanced Encryption Standard)

AES (Advanced Encryption Standard), standardised as NIST FIPS 197 in 2001, is the symmetric block cipher that underlies virtually all data encryption in modern infrastructure. It was selected through a five-year open competition that evaluated 15 candidate algorithms; the winner, Rijndael (designed by Joan Daemen and Vincent Rijmen), became AES. A block cipher takes a fixed-size block of plaintext and a key and produces a fixed-size block of ciphertext — AES always operates on 128-bit (16-byte) blocks, regardless of key size. Three key lengths are standardised: AES-128 (128-bit key, 10 rounds), AES-192 (192-bit key, 12 rounds), and AES-256 (256-bit key, 14 rounds), providing 128, 192, and 256 bits of security respectively against classical attacks. AES-256 is the conservative choice for data with long confidentiality requirements and is mandated by CNSA 2.0 for national security systems; AES-128 is widely deployed in TLS and provides adequate security for most workloads. The internal structure — SubBytes, ShiftRows, MixColumns, AddRoundKey — is fully public and has withstood over two decades of cryptanalysis; the best known attacks against full-round AES are theoretical and computationally infeasible, requiring work far beyond brute force but not threatening practical security.