Use FIPS 140-3 and the certificate when the question is whether a specific cryptographic module is validated for a claimed use. Use for the international module requirements and for the test requirements. Always name the edition: FIPS 140-3 and current CMVP guidance still identify ISO/IEC 19790:2012 with its 2015 correction and ISO/IEC 24759:2017, while ISO published ISO/IEC 19790:2025 and ISO/IEC 24759:2025 as the current standalone editions and withdrew the older editions.
Side-by-side comparison
FIPS 140-3 vs ISO/IEC 19790 and ISO/IEC 24759: practical differences
This side-by-side view helps distinguish validation claims from the ISO/IEC requirements and test standards referenced by FIPS 140-3.
The validation and federal-use side: use it for certificate scope, federal procurement claims, security levels, approved algorithms, module evidence, and program guidance.
Second framework
ISO/IEC 19790 and ISO/IEC 24759
The international standard-reference side: use it for cryptographic module security requirements and test-requirements framing, not as a standalone certificate.
FIPS 140-3 vs ISO/IEC 19790 and ISO/IEC 24759: practical differences
FIPS 140-3 covers cryptographic modules used in security systems and validation of those modules, including the defined module boundary, security level, interfaces, roles, services, and operational environment.
covers security requirements for cryptographic modules; covers test requirements for cryptographic modules. The public ISO cited sources support this scope-level distinction, not a detailed clause mapping.
Vendors, CST laboratories, reviewers, federal buyers, and Canadian federal users rely on the FIPS/CMVP result to evaluate validated cryptographic modules.
The FIPS side matters when a product claim, federal procurement response, system authorization, customer contract, or module release depends on FIPS 140-3 validation or approved cryptography evidence.
The ISO side matters when a customer, lab, or policy asks which international cryptographic module requirements or test requirements sit behind the FIPS 140-3 work.
FIPS/ work products include module specification, security policy, service and approved-mode descriptions, operational-environment details, algorithm validation evidence, test reports, entropy and self-test support, and change-impact records.
Build the deliverable list from guidance for a FIPS claim, then use ISO references only where the source material or customer request actually cites them.
Keep ISO references as standards support: the requirements citation, the test-requirements citation, and any separately reviewed ISO text or procurement crosswalk.
FIPS 140-3 superseded FIPS 140-2, became effective after approval, and is supported by guidance that changes over time; validation evidence should track the guidance version used for the submission or change review.
ISO published :2025 as edition 3 and withdrew ISO/IEC 19790:2012 and Cor.1:2015. FIPS 140-3 and the April 9, 2026 implementation guidance still name the 2012 requirements edition with its 2015 corrections.
Record the edition used by each claim. Do not treat the standalone 2025 ISO edition as an automatic replacement for the edition and NIST modifications used in a validation.
FIPS 140-3 assurance runs through validation, with testing by accredited CST laboratories and acceptance by U.S. and Canadian federal agencies for protected information uses described in the source material.
ISO references can explain the underlying security and test framework, but they should not absorb FIPS-specific certificate, approved-mode, CAVP, or evidence requirements.
FIPS 140-3 covers cryptographic modules used in security systems and validation of those modules, including the defined module boundary, security level, interfaces, roles, services, and operational environment.
covers security requirements for cryptographic modules; covers test requirements for cryptographic modules. The public ISO cited sources support this scope-level distinction, not a detailed clause mapping.
Vendors, CST laboratories, reviewers, federal buyers, and Canadian federal users rely on the FIPS/CMVP result to evaluate validated cryptographic modules.
The FIPS side matters when a product claim, federal procurement response, system authorization, customer contract, or module release depends on FIPS 140-3 validation or approved cryptography evidence.
The ISO side matters when a customer, lab, or policy asks which international cryptographic module requirements or test requirements sit behind the FIPS 140-3 work.
FIPS/ work products include module specification, security policy, service and approved-mode descriptions, operational-environment details, algorithm validation evidence, test reports, entropy and self-test support, and change-impact records.
Build the deliverable list from guidance for a FIPS claim, then use ISO references only where the source material or customer request actually cites them.
Keep ISO references as standards support: the requirements citation, the test-requirements citation, and any separately reviewed ISO text or procurement crosswalk.
FIPS 140-3 superseded FIPS 140-2, became effective after approval, and is supported by guidance that changes over time; validation evidence should track the guidance version used for the submission or change review.
ISO published :2025 as edition 3 and withdrew ISO/IEC 19790:2012 and Cor.1:2015. FIPS 140-3 and the April 9, 2026 implementation guidance still name the 2012 requirements edition with its 2015 corrections.
Record the edition used by each claim. Do not treat the standalone 2025 ISO edition as an automatic replacement for the edition and NIST modifications used in a validation.
FIPS 140-3 assurance runs through validation, with testing by accredited CST laboratories and acceptance by U.S. and Canadian federal agencies for protected information uses described in the source material.
ISO references can explain the underlying security and test framework, but they should not absorb FIPS-specific certificate, approved-mode, CAVP, or evidence requirements.
How to choose between FIPS 140-3 and ISO/IEC 19790 and ISO/IEC 24759
Choose FIPS 140-3 and when the visitor needs validation status, certificate scope, or a yes-or-no answer about whether the module is accepted as validated for the claimed use.
Choose or when the visitor needs the international requirements or test standard, and name the edition.
When a request mixes compliance and validation language, name both layers: the exact ISO edition for the requirement or test basis, and the FIPS/ certificate evidence for validation status.
FIPS 140-3 is the published Federal Information Processing Standard for security requirements for cryptographic modules. It applies to federal agencies using cryptography-based security systems and is the basis for validation of modules used to protect sensitive information.
FIPS 140-3 is based on :2012/Cor.1:2015 for module requirements and :2017 for testing. NIST's SP 800-140 series modifies specified ISO annexes and test sections, while implementation guidance supplies program decisions and clarifications.
:2025 and :2025 are the current standalone ISO editions, and ISO lists the 2012 requirements edition, its 2015 correction, and the 2017 test edition as withdrawn. The April 9, 2026 implementation guidance still maps to ISO/IEC 19790:2012 with the 2015 corrections and ISO/IEC 24759:2017. Do not assume that citing either 2025 edition proves conformity with the older editions and NIST modifications used for a FIPS 140-3 validation.
Use FIPS 140-3 when the claim is about validation, federal-agency acceptance, certificate scope, or a FIPS-labeled procurement requirement.
Use when the claim is about international cryptographic-module requirements, and state whether the claim concerns the 2025 edition or the 2012 edition incorporated into the current FIPS/ material.
Use :2017 for the test-requirements frame referenced by FIPS 140-3 and current guidance; use ISO/IEC 24759:2025 for the current standalone ISO test standard.
Do not describe or as a substitute for validation unless the procurement or assurance document explicitly allows that.
A FIPS claim requires more than a standards citation. FIPS 140-3 names four qualitative security levels and covers module specification, interfaces, roles, services and authentication, software and firmware security, operational environment, physical security, non-invasive security, sensitive security parameter management, self-tests, life-cycle assurance, and mitigation of other attacks.
guidance turns those requirements into validation operations: module boundary and service descriptions, algorithm certificate handling, approved security service indicators, operational-environment records, entropy and SSP evidence, self-test expectations, CVE management, and change-impact decisions.
Start FIPS evidence with the module boundary, version, operating environment, security level claims, roles, services, and approved versus non-approved services.
Attach algorithm claims to CAVP certificate evidence where guidance requires it.
Keep approved-mode indicators, security policy text, test reports, entropy support, self-test behavior, and change records together with the certificate scope.
Rerun the comparison when the module boundary, implementation, operational environment, validated algorithms, or public claim changes.
defines cryptographic module security requirements, and defines cryptographic module test requirements. The current standalone editions are ISO/IEC 19790:2025 and ISO/IEC 24759:2025. For the FIPS route, the baseline remains the older editions named in FIPS 140-3 and current material, together with the applicable NIST modifications, Derived Test Requirements, management manual, and implementation guidance.
An ISO citation explains the requirements or test-standard layer. It does not establish a module's validation status, certificate scope, approved services, or tested operational environments.
Record the exact ISO edition. Do not collapse the 2012/2015 and 2025 requirements editions, or the 2017 and 2025 test editions, into an undated claim.
Use FIPS and citations to support validation status, certificate scope, submission evidence, and U.S./Canadian federal acceptance claims.
Keep any deeper ISO clause mapping outside this page unless the source text is available and reviewed directly.
Flag customer requests that ask for "ISO 19790 compliant" evidence when they actually require a FIPS 140-3 validated module.
Keep three evidence sets separate: the FIPS 140-3 validation claim, the requirements reference, and the test-requirements reference. They overlap, but the labels answer different procurement and assurance questions.
For customer-facing claims, avoid broad wording such as "ISO/FIPS compliant" unless the statement identifies the module, version, boundary, certificate status, operational environment, and the source that supports the claim.
FIPS claim record: module name, version, boundary, security level, certificate identifier or status, operational environment, validated algorithms, and security policy link or artifact.
ISO requirements record: the exact edition, the procurement language, and the requirement area being discussed. Do not silently substitute the 2025 edition for the 2012 edition named by FIPS 140-3.
Test-method record: the or /DTR test reference named by the lab, assessor, or customer.
Gap record: unsupported equivalence assumptions, missing certificate scope, expired or changed operational environments, and evidence reused from a different module.
This comparison helps separate CMVP validation evidence from ISO requirement and test references before making procurement, audit, or public security claims.
Program guidance for FIPS 140-3 validation evidence, binding/embedding, approved service indicators, CAVP certificates, change impact, and CMVP operating expectations.
"CAVP addresses the testing of Approved Security Functions"