FIPS 140-3 Cryptographic Module Validation

Introduction: FIPS 140-3 Cryptographic Module Validation

FIPS 140-3, formally Federal Information Processing Standard Publication 140-3 (Security Requirements for Cryptographic Modules), is the mandatory United States and Canadian Federal standard governing the design, implementation and operational assurance of cryptographic modules that protect sensitive but unclassified (SBU) information. Approved by the U.S. Secretary of Commerce in March 2019 and effective from 22 September 2019, FIPS 140-3 supersedes FIPS 140-2 and represents a fundamental architectural shift: rather than defining its own security requirements text, FIPS 140-3 adopts the international standards ISO/IEC 19790:2012 (security requirements) and ISO/IEC 24759:2017 (test requirements) by reference, layering NIST-specific modifications on top through the SP 800-140x document series.

Validation is administered jointly by the National Institute of Standards and Technology (NIST) and the Canadian Centre for Cyber Security (CCCS) under the Cryptographic Module Validation Program (CMVP). Independent testing is performed by accredited third-party Cryptographic and Security Testing (CST) laboratories, and every validated module carries a certificate number published on the CMVP Validated Modules List. FIPS 140-3 is the gateway requirement for selling cryptographic products to the U.S. Federal Government, and it is increasingly demanded across regulated global sectors — finance, healthcare, critical infrastructure and defence supply chains — as objective, laboratory-verified evidence that a module's cryptography is correct, resistant to tampering and operated in an approved manner.

This guide is written for two audiences simultaneously. For the vendor / product team seeking validation, it maps the module design, documentation and testing lifecycle end to end. For the auditor, assessor or procurement officer, it provides a verification framework to confirm that a claimed FIPS 140-3 validation genuinely covers the deployed configuration, the correct security level and the operational assumptions of the environment. Throughout, we enumerate the eleven security requirement areas, the four security levels, the algorithm and self-test regime, and the CMVP submission process (including the FIPS 140-3 Implementation Guidance and the Entropy Source Validation requirement of SP 800-90B).

What is FIPS 140-3

FIPS 140-3 specifies the security requirements that a cryptographic module must satisfy to be trusted to protect sensitive information within a computer or telecommunications system. A 'cryptographic module' is the set of hardware, software, firmware, or some combination thereof that implements approved security functions (encryption, decryption, digital signatures, hashing, message authentication, key establishment, random bit generation) and is contained within a defined cryptographic boundary. The standard is deliberately technology-agnostic: the same requirement areas apply whether the module is a hardware security module (HSM), a smartcard, a software cryptographic library, a self-encrypting drive, a network appliance or a firmware component.

FIPS 140-3 differs from FIPS 140-2 in several material respects. It replaces the four Areas-of-old with eleven security requirement areas aligned to ISO/IEC 19790. It introduces non-invasive attack mitigation (side-channel resistance) as a formal requirement area. It strengthens the treatment of entropy through mandatory alignment with SP 800-90B for Level 2 and above (and requires an Entropy Source Validation, ESV, certificate). It mandates the concept of degraded operation and life-cycle assurance including a formal Cryptographic Module Security Policy. Modules must implement only CAVP-tested (Cryptographic Algorithm Validation Program) approved algorithms in the approved mode of operation, and any non-approved algorithms must be clearly delineated.

A key concept is the distinction between the 'approved mode of operation' and any non-approved mode. When a module is placed into its approved mode, only NIST-approved and allowed security functions may be invoked, self-tests must pass, and the module must enforce its security policy. Validation certifies the module at a specific overall security level (1 through 4), which is the minimum of the levels achieved across the eleven requirement areas — a module may claim higher levels in individual areas, but the overall rating is bounded by its weakest area.

Who must comply

FIPS 140-3 validation is legally mandatory for cryptographic modules used by U.S. Federal agencies to protect sensitive but unclassified information, and by extension for any vendor that wishes to sell such products into the Federal market. Its reach extends well beyond U.S. Government, however, because numerous downstream regulations, procurement frameworks and international schemes cite FIPS 140 validation as a prerequisite or a strong assurance signal.

• U.S. Federal Government departments and agencies — required by FISMA and NIST SP 800-53 control SC-13 to use FIPS-validated cryptography for SBU data.
• Vendors selling to Federal agencies — hardware and software cryptographic products must carry a valid CMVP certificate covering the procured configuration.
• U.S. Department of Defense supply chain — DFARS / CMMC and DoD policies require FIPS-validated modules for covered defense information.
• Government of Canada departments — CCCS mandates validated modules through the joint CMVP.
• Payment industry participants — PCI DSS and PCI PIN / PCI HSM commonly recognise FIPS 140 validation for HSMs and key-management devices.
• Healthcare and life sciences — HIPAA Security Rule encryption safe harbour is satisfied using FIPS-validated cryptography.
• Critical infrastructure and OT vendors — energy (NERC CIP), telecommunications and industrial control providers frequently specify FIPS 140.
• Global regulated enterprises and cloud providers — FedRAMP requires FIPS-validated modules for data at rest and in transit within authorised boundaries.

Structure of FIPS 140-3

FIPS 140-3 organises its requirements into eleven security requirement areas derived from ISO/IEC 19790:2012, plus a set of cross-cutting concepts (approved mode, security policy, degraded operation, life-cycle assurance). For each area the standard defines graduated requirements across four security levels. The overall validation level equals the lowest level achieved in any single area. The table below summarises the eleven areas that structure both the module design and the assessment; these areas are elaborated control-by-control in the master assessment checklist that follows.

Master assessment checklist

This is the core section of the guide. It enumerates every FIPS 140-3 security requirement area and its constituent requirements, expressed as verifiable assertions. For each area a table lists what the assessor must verify and the typical evidence a vendor should produce. These map to the Derived Test Requirements (DTRs) of ISO/IEC 24759 as tailored by SP 800-140. Requirements marked Level 3/4 apply only at those security levels. No control area is omitted.

Area 1 — Cryptographic module specification

Area 2 — Cryptographic module interfaces

Area 3 — Roles, services and authentication

Area 4 — Software / firmware security

Area 5 — Operational environment

Area 6 — Physical security

Area 7 — Non-invasive security

Area 8 — Sensitive security parameter (SSP) management

Area 9 — Self-tests

Area 10 — Life-cycle assurance

Area 11 — Mitigation of other attacks

Scoping

Scoping a FIPS 140-3 validation is the single most consequential early decision, because the cryptographic boundary determines what is tested, what evidence is required, the achievable security level and ultimately the cost and duration of validation. A boundary drawn too wide pulls non-cryptographic code and hardware into the assessment, inflating effort; a boundary drawn too narrow may exclude functions the operator relies on and produce a certificate that does not cover the real deployment.

• Define the cryptographic boundary — the explicit set of hardware, firmware and software that will be validated. Everything inside must meet the requirements; everything outside is untrusted.
• Choose the module embodiment — single-chip, multi-chip embedded, or multi-chip standalone — as this drives the physical security requirements.
• Select the target overall security level (1–4) and, where beneficial, higher per-area levels, balancing market demand against cost.
• Enumerate the approved security functions in scope and confirm each has (or will obtain) a CAVP certificate.
• Identify the operational environments (OS + processor) to be listed on the certificate; each tested OE must be exercised.
• Determine the entropy source strategy — internal validated entropy (ESV) versus external entropy — and its impact on the achievable level.
• Delineate approved vs non-approved modes so the certificate scope and Security Policy are unambiguous.
• Confirm whether porting, rebranding (OEM) or sub-chip scenarios apply, and follow the relevant CMVP Implementation Guidance.

Implementation approach

A FIPS 140-3 validation is best run as a phased engineering and documentation programme executed in partnership with an accredited CST laboratory. The phases below sequence the work from readiness through certificate issuance and maintenance, with concrete activities and deliverables for each.

Phase 1 — Readiness and gap analysis

Activities: appoint a validation lead; select the CST laboratory; hold a scoping workshop to fix the cryptographic boundary, module embodiment and target level; perform a gap analysis of the current design against the eleven requirement areas; inventory algorithms against CAVP coverage; assess the entropy source against SP 800-90B. Deliverables: scoping document, boundary diagram, gap-analysis report, remediation backlog, project plan and budget.

Phase 2 — Design and remediation

Activities: implement design changes to close gaps (self-tests/KATs, zeroisation, integrity mechanism, role/authentication logic, output inhibition, tamper mechanisms for L3/4); implement or integrate an approved DRBG and validated entropy source; build the finite state model; enforce the approved mode. Deliverables: updated module firmware/software/hardware, FSM, updated design documentation, configuration-management baseline.

Phase 3 — Algorithm and entropy validation

Activities: run CAVP algorithm testing through the Automated Cryptographic Validation Test System (ACVTS) for every approved algorithm; obtain CAVP certificates; run entropy analysis and submit for an ESV certificate under SP 800-90B. Deliverables: CAVP algorithm certificates, ESV/entropy assessment report and certificate, algorithm-to-service mapping.

Phase 4 — Documentation and Security Policy

Activities: author the Non-Proprietary Cryptographic Module Security Policy (mandatory, published with the certificate), Crypto-Officer and User guidance, delivery and secure-operation procedures; assemble vendor test evidence; map every requirement to the ISO/IEC 24759 DTRs. Deliverables: Security Policy, guidance documents, complete evidence package.

Phase 5 — Laboratory testing

Activities: the CST laboratory performs conformance testing, source-code and design review, physical security testing (L3/4), operational testing across each tested OE, and produces the test report and functional test evidence; iterate on findings. Deliverables: laboratory test report (per ISO/IEC 24759), physical security test results, resolved finding log.

Phase 6 — CMVP submission and certificate

Activities: the laboratory submits the package to the CMVP; the module enters the Modules In Process (MIP) list; NIST/CCCS review, raise comments, and on resolution issue the certificate and publish the module on the Validated Modules List. Deliverables: CMVP certificate number, published Security Policy, entry on the validated list.

Phase 7 — Maintenance and change management

Activities: manage post-validation changes through the appropriate SP 800-140B scenario; monitor algorithm transitions and sunset dates; plan re-validation before certificate expiry. Deliverables: change scenario submissions, updated certificates, re-validation plan.

Capability and level model

FIPS 140-3 defines four security levels of increasing rigour. The overall validation level is the minimum level attained across all eleven areas. Levels are cumulative — each higher level adds requirements to the one below. The table summarises the defining characteristics of each level.

Assessment and audit approach

Whether performed by the CST laboratory for validation or by an internal/procurement auditor confirming a claimed validation, the assessment follows a disciplined sequence anchored in the ISO/IEC 24759 test requirements and the CMVP process.

1. Confirm the scope: identify the exact module name, hardware/firmware/software versions and the cryptographic boundary being assessed.
2. Verify the certificate: locate the CMVP certificate on the Validated Modules List (or MIP status) and confirm it covers the versions and operational environments in use.
3. Confirm the security level: check the overall level and per-area levels against the deployment's assurance needs.
4. Review the Security Policy: read the published Non-Proprietary Security Policy for approved mode, roles/services, SSPs, self-tests and operator obligations.
5. Validate algorithm coverage: cross-check each approved algorithm to its CAVP certificate and confirm the entropy source has an ESV certificate where required.
6. Examine design and source evidence: for validation, perform source-code and design review against each of the eleven areas' DTRs.
7. Perform functional and self-test verification: exercise the module in approved mode, trigger self-tests and confirm error-state and output-inhibition behaviour.
8. Conduct physical security testing (L2+): inspect tamper evidence, and for L3/4 exercise tamper-response zeroisation and EFP/EFT.
9. Verify SSP lifecycle: confirm key generation, protected entry/output, storage and zeroisation operate as specified.
10. Assess operational configuration: confirm the module is deployed in approved mode on a tested OE and that operator guidance is followed.
11. Document findings and remediate: record non-conformities, obtain corrective evidence and re-test.
12. Confirm ongoing validity: verify the certificate has not lapsed and that no unvalidated change has been introduced (change management).

Evidence request list

The following categorised evidence set supports either a validation submission or an audit of a claimed validation.

• Scope and specification: cryptographic boundary diagram, module version identifiers (HW p/n, FW/SW versions), module embodiment declaration, tested operational environment list.
• Certificates: CMVP certificate number and validated-list entry, CAVP algorithm certificates, ESV/entropy certificate.
• Security Policy: the published Non-Proprietary Cryptographic Module Security Policy including approved-mode indicators.
• Roles and services: roles/services table, authentication mechanism description and strength analysis, service-to-SSP access matrix.
• Interfaces: interface specification and port mapping, output-inhibition and trusted-channel design.
• Software/firmware: integrity mechanism specification, build hashes, secure-load design, source-to-binary correspondence.
• Physical security: tamper-evidence placement, tamper-response circuit design, EFP/EFT test reports, photographs.
• SSP management: SSP inventory, DRBG and entropy design, key generation/establishment methods, zeroisation procedures and test results.
• Self-tests: pre-operational and conditional self-test inventory, KAT/CAST vectors and results, error-state behaviour evidence.
• Life-cycle assurance: configuration-management plan, finite state model, design documentation, delivery and operator guidance, vendor test results.
• Non-invasive / other attacks: mitigation descriptions and any applicable test results.
• Change management: any SP 800-140B change scenario submissions and updated certificates.

Roles and responsibilities

KPIs to track

• Percentage of approved algorithms with current, in-scope CAVP certificates.
• Entropy source status — ESV certificate obtained and current (Level 2+).
• Number of open gap-analysis findings versus closed, by requirement area.
• Self-test coverage — proportion of approved algorithms with a KAT/CAST.
• Time in the Modules In Process (MIP) queue and time to certificate issuance.
• Number of laboratory findings raised and mean time to remediation.
• Days remaining to certificate expiry / next re-validation trigger.
• Number of deployed configurations confirmed to match the validated versions and tested OEs.
• Count of change scenarios initiated and their CMVP acceptance rate.
• Algorithm-transition exposure — approved functions with an announced sunset date affecting the module.

Readiness checklist

• Cryptographic boundary and module embodiment are formally defined and documented.
• Target overall security level and per-area levels are agreed and justified.
• Every approved algorithm has a CAVP certificate covering the implementation.
• The DRBG is SP 800-90A approved and seeded by an SP 800-90B validated entropy source with an ESV certificate (Level 2+).
• Pre-operational and conditional self-tests (including a KAT/CAST per algorithm) are implemented and pass.
• Software/firmware integrity is enforced by an approved technique before operation.
• Roles, services and authentication meet the claimed level (role-based L2, identity-based L3/4).
• SSP generation, protected entry/output, storage and zeroisation are implemented and testable.
• Physical security mechanisms match the level (tamper-evidence L2; tamper-response and EFP/EFT L3/4).
• Data output is inhibited during self-tests, error states and key operations.
• The finite state model and design documentation are complete and consistent.
• The Non-Proprietary Security Policy, Crypto-Officer and User guidance are drafted.
• A configuration-management baseline fixes all tested versions.
• An accredited CST laboratory is engaged and the DTR evidence mapping is under way.

Common gaps

• Deploying a firmware/software version or operating environment that is not the one listed on the certificate, silently voiding the FIPS claim.
• Using an algorithm in the approved mode that lacks a matching CAVP certificate, or using a non-approved algorithm without delineating it from the approved mode.
• Inadequate entropy justification — no SP 800-90B assessment / ESV certificate, or an entropy source that under-delivers the claimed min-entropy.
• Missing or incomplete self-tests, particularly absent known-answer tests for one or more approved algorithms and missing pairwise consistency tests on key generation.
• Failure to inhibit data output during self-tests, error states or key generation/zeroisation.
• Weak or absent zeroisation of plaintext CSPs, especially on tamper events at Level 3/4.
• Authentication strength below the required false-acceptance limits, or plaintext feedback of authentication data.
• An imprecise cryptographic boundary that mixes validated and non-validated components.
• Physical security shortfalls — tamper-evidence not covering all removable covers, or EFP/EFT not exercised across the specified range.
• Operating the module outside its approved mode in production, or operator guidance that does not describe how to invoke approved mode.
• Neglecting change management, so post-validation updates are shipped without an SP 800-140B scenario.
• Confusing algorithm (CAVP) validation with module (CMVP) validation and claiming full FIPS 140-3 on the basis of algorithm testing alone.

FIPS 140-3 mapped to other frameworks

How CyberSigma helps

Frequently asked questions

Need help with FIPS 140-3?

CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.