← Back to Blog Research

ISO/IEC 19790: Cryptographic Module Security Requirements

14 min read

A correct algorithm in a poorly built module is no better than a broken algorithm. Cryptography in real systems lives inside modules: software libraries, smart cards, hardware security modules, embedded chips. Each module has to be evaluated as a whole. Are the keys protected? Is the random number generator working? Can an attacker probe the module physically and extract secrets? Does the module fail closed when something goes wrong?

The international standard for evaluating cryptographic modules is ISO/IEC 19790. It defines security requirements at four levels, from basic software protection to physically tamper-resistant hardware. The current version is ISO/IEC 19790:2012, with a revision under active development by ISO/IEC JTC 1/SC 27 and expected publication in 2026 to 2027. The US equivalent is NIST FIPS 140-3, finalized 22 March 2019 and effective for new validations as of 22 September 2020. The two standards are now aligned: FIPS 140-3 directly references ISO/IEC 19790:2012 for its technical requirements and ISO/IEC 24759:2017 for its test requirements.

This post walks through the four security levels, the eleven requirement areas, and the validation programs that evaluate modules against the standard. For software like QNSQY claiming compliance with international standards, ISO/IEC 19790 is the underlying technical specification.

Why Module Validation Matters

A cryptographic algorithm specification (FIPS 197 for AES, FIPS 203 for ML-KEM, FIPS 204 for ML-DSA) tells you what the algorithm should do. It does not tell you how to implement it correctly, how to protect keys, what to do if the random number generator fails, or how to verify the implementation matches the specification. That is what module validation does.

Validation provides:

Algorithm correctness: the module produces the right output on test vectors
Side-channel resistance: timing, power, electromagnetic attacks are mitigated
Tamper response: physical attacks are detected and keys are zeroed
Self-tests: the module checks itself before use
Operational security: roles, authentication, key management are enforced

Without validation, you have a cryptographic library. With validation, you have a cryptographic module that auditors and regulators can trust. Procurement officers in the U.S. federal government cannot legally accept non-FIPS-validated cryptography for protecting Sensitive But Unclassified information per FISMA, so validation status is a hard gate, not a marketing checkbox.

The Four Security Levels

ISO/IEC 19790 defines four security levels in clause 7, each adding requirements to the previous:

Level 1: Basic

The minimum. Approved algorithms, basic role-based authentication, software-only modules acceptable. No physical security requirements beyond standard production quality.

Software libraries running in normal operating systems typically target Level 1. Most cryptographic libraries (OpenSSL, BoringSSL, libsodium) when validated are validated at Level 1 or 1+.

Level 2: Tamper Evidence

Adds tamper-evident packaging or coatings. If someone tries to physically modify the module, signs of tampering are visible. Role-based authentication is required, with at least one cryptographic officer role distinct from the user role.

Smart cards and hardware tokens often target Level 2. The plastic case is designed to break or show damage if pried open.

Level 3: Tamper Resistance

Adds active tamper resistance. The module detects physical attacks and responds (zeros keys, shuts down). Identity-based authentication required. Environmental failure protection (out-of-range temperature, voltage triggers protection).

Hardware security modules (HSMs) typically target Level 3. They have meshes, sensors, and secure enclosures. Trying to drill into the module zeros all keys.

Level 4: High Tamper Resistance

The highest level. Physical attacks at any level are detected and result in key destruction. Environmental tolerances are tight. Multi-factor authentication required for cryptographic officers. Suitable for hostile environments.

National security grade HSMs and military equipment target Level 4. Few products are validated at this level because of cost. As of late 2025, fewer than ten Level 4 modules appear on the active CMVP list.

The Eleven Requirement Areas

ISO/IEC 19790 organizes its requirements into eleven areas in clauses 7.2 through 7.12. A validation report addresses each:

General requirements: scope, definitions, conformance
Cryptographic module specification: documented design, algorithm list, modes of operation
Cryptographic module ports and interfaces: data, control, status, power inputs and outputs
Roles, services, authentication: user, cryptographic officer, maintenance roles
Software/firmware security: integrity tests, code signing, secure boot
Operational environment: OS protection, virtualization considerations
Physical security: based on level, from production quality to active tamper response
Non-invasive security: side-channel attack resistance (timing, power, EM)
Sensitive security parameter management: key generation, storage, distribution, destruction
Self-tests: power-on tests, conditional tests, periodic tests
Life-cycle assurance: development, manufacturing, operations, end-of-life

A validated module has documentation and testing for each area.

Self-Tests

Self-tests are an underappreciated but critical area. Before a module performs cryptographic operations, it must verify itself. ISO/IEC 19790 clause 7.10 requires:

Power-on self-tests (POST): known-answer tests for each algorithm, integrity check on the module image
Conditional self-tests: ongoing checks during operation, like RNG entropy estimates
On-demand self-tests: ability for the user to trigger a re-run

If a self-test fails, the module enters an error state and refuses to perform cryptographic operations. This prevents subtle implementation errors from corrupting outputs.

QNSQY runs known-answer tests on startup for ML-KEM, ML-DSA, AES-256-GCM, ChaCha20-Poly1305, BLAKE3, SHA-256, HKDF, and Argon2id. The KAT count is 370 tests across 17 modules, including 525 ACVP JSON test vectors from NIST. If any KAT fails, QNSQY refuses to start. This is Level 1 self-test compliance applied to a software module.

Algorithm Validation: ACVP and CAVP

Before a module is validated, the algorithms it implements must be validated. NIST runs the Cryptographic Algorithm Validation Program (CAVP), and the international equivalent is run through accredited labs against the same test vectors.

The current method is ACVP (Automated Cryptographic Validation Protocol). Test vectors are JSON files, the lab requests vectors from NIST, the module under test produces outputs, and NIST verifies. Algorithms covered include all the FIPS-approved ones: AES modes, SHA-2, SHA-3, HMAC, HKDF, RSA, ECDSA, EdDSA, ML-KEM, ML-DSA, SLH-DSA.

QNSQY ships with ACVP test vectors for ML-KEM and ML-DSA built into its KAT suite. Future module validation through CAVP/ACVP would use the same vectors.

Module Validation: CMVP

The full module validation program in the US is CMVP (Cryptographic Module Validation Program). Internationally, CMVP-validated modules are widely accepted. CMVP itself uses ISO/IEC 19790 as its technical basis.

The process:

Vendor builds module with full documentation
Vendor selects an accredited testing laboratory (NVLAP-accredited in the U.S.)
Lab tests against ISO/IEC 19790 / FIPS 140-3 requirements at the target level
Lab submits test report to NIST
NIST reviews and issues validation certificate
Validated module appears on NIST's CMVP list

Validation takes 12 to 24 months and costs USD 100,000 to 500,000 depending on level and complexity. The CMVP backlog at NIST has at times exceeded 18 months for queue-to-coordination time alone, separate from lab testing duration. This is why most validated modules are commercial products: the cost is hard for open-source projects to absorb.

Common Criteria Alignment

Common Criteria (CC, ISO/IEC 15408) is the international standard for evaluating IT product security broadly. It covers more than cryptography: access control, audit logging, secure communication, etc. Cryptographic modules used in CC-evaluated products typically need ISO/IEC 19790 validation as part of their assurance package.

CC defines Evaluation Assurance Levels (EAL 1 to 7). EAL 4+ is common for security products. The CC evaluation references ISO/IEC 19790 for the cryptographic component.

For most QNSQY users, CC is not directly relevant. But for hospital IT systems, government applications, and military deployments, CC certification of the broader system can drive ISO/IEC 19790 requirements for the crypto components.

PQC and Module Validation

Post-quantum algorithms are being added to validation programs. CAVP added ML-KEM and ML-DSA test vectors in 2024 and 2025. The first FIPS 140-3 PQC-validated modules appeared in 2025.

Challenges specific to PQC validation:

Test vector volume: ML-KEM and ML-DSA have many parameter sets, each with thousands of test vectors. ACVP scales to handle this.
Side-channel testing: PQC algorithms have new side-channel surfaces (lattice arithmetic, polynomial multiplication). Validation is updating to test these.
Hybrid mode: validating a module that uses hybrid (X25519 + ML-KEM) requires validation of both classical and PQC algorithms plus the combiner.

QNSQY uses hybrid by default, which means a future CMVP validation would need to cover ML-KEM, X25519, ML-DSA, Ed25519, AES-GCM, ChaCha20-Poly1305, HKDF, and the HKDF-based combiner that produces the encryption key from both KEM secrets.

Key Zeroization

A subtle requirement that ISO/IEC 19790 emphasizes in clause 7.9.7: when a key is no longer needed, it must be zeroed in memory. Just freeing the buffer is not enough; the bytes must be overwritten so memory dumps do not leak the key.

In Rust, the zeroize crate handles this. Wrap secret types in Zeroizing, and Drop will overwrite the bytes. QNSQY uses Zeroizing, Zeroizing>, and similar for all sensitive material: passwords, derived keys, KEM shared secrets.

Module validation tests zeroization by checking memory after the key is dropped. If the key bytes are still readable, the test fails. The associated test procedure is documented in ISO/IEC 24759:2017 clause 6.9 and the implementation guidance in NIST SP 800-140 series.

Operational Environment

The operational environment requirement (Area 6 of ISO/IEC 19790) considers where the module runs:

Trusted OS: Linux, Windows, macOS with proper hardening
Virtualization: hypervisor security must be considered
Containerization: Docker, Kubernetes deployment patterns
Mobile platforms: iOS, Android with their security models

QNSQY targets Linux primarily, with Windows and macOS support. The operational environment for a Level 1 software module includes the OS process isolation, file system permissions, and memory protection. This is enough for software modules but not for higher levels.

Side-Channel Considerations: Non-Invasive Security

Area 8 of the standard, non-invasive security, is one of the most rapidly evolving zones. ISO/IEC 19790:2012 defined the requirement at a high level, leaving testing methodology to companion standards. The 2025 revision is expected to incorporate ISO/IEC 17825:2024, which gives concrete test methods for timing analysis, simple power analysis, differential power analysis, and template attacks.

For Level 3 and Level 4 modules, the lab measures power consumption traces during cryptographic operations, looks for data-dependent variations, and runs statistical tests for leakage. A common metric is the t-test specified in NIST IR 7966 and the Test Vector Leakage Assessment methodology. Modules that fail leakage tests must add masking, randomization of operation order, or hardware countermeasures before they can pass.

For software-only Level 1 modules, the bar is lower but not zero. Constant-time implementations of secret-dependent code paths are expected. QNSQY's underlying primitives use constant-time AES (AES-NI when available, fallback bitsliced implementation), constant-time ChaCha20, and constant-time ML-KEM polynomial arithmetic per the PQClean reference design. The lattice operations in ML-KEM and ML-DSA have well-known cache-timing risks if implemented naively, which is why the validated implementations use constant-time table accesses.

Life-Cycle Assurance and Vendor Documentation

Area 11 of ISO/IEC 19790, life-cycle assurance, is the area that surprises first-time vendors most. It is not a runtime check, it is a documentation and process requirement. The lab examines:

Configuration management: how source code is versioned, who has commit access, how reviews are recorded
Delivery: how the module is shipped to the customer, how integrity is preserved in transit
Development environment: how the build is reproducible, how the toolchain is locked
Guidance documents: the security policy, the user guide, the cryptographic officer guide

For an open-source software module, this is partially solved by Git, signed releases, and reproducible builds. For a hardware module, the manufacturing process needs documented controls. The 2024 update of NIST SP 800-140 series further specifies acceptable practices.

The security policy document is publicly available for every CMVP-validated module. Reading the security policy of a similar module before starting validation is the most practical preparation step for a new vendor.

FAQ

Is ISO/IEC 19790 the same as FIPS 140-3?

Technically yes, FIPS 140-3 references ISO/IEC 19790:2012 directly for its requirements. The differences are in the validation programs (CMVP vs lab-by-lab international validation) and in the documentation requirements. A module validated under FIPS 140-3 is effectively also compliant with ISO/IEC 19790. See NIST FIPS guide.

What level should my module target?

For software libraries: Level 1. For smart cards and tokens: Level 2 or 3. For HSMs: Level 3 or 4. The level depends on the threat model and deployment environment. Higher levels are exponentially more expensive.

Is QNSQY validated under ISO/IEC 19790?

Not currently. QNSQY's design aligns with Level 1 software requirements (KAT self-tests, key zeroization, role separation between user and cryptographic functions, ACVP test vectors). Formal CMVP validation is on the roadmap as the product matures. Hospitals and other regulated users are advised to track the validation status. See pricing.

How long does validation take?

12 to 24 months from contract with a testing lab to CMVP certificate. Cost is USD 100,000 to 500,000+ for a full Level 1 software module validation. Higher levels and complex modules push toward the upper end.

Does ISO/IEC 19790 cover PQC?

The 2012 version predates PQC standards. The 2025 revision will explicitly cover ML-KEM, ML-DSA, SLH-DSA. In the meantime, PQC algorithms are being added through CAVP/ACVP test vectors and CMVP transition guidance. The framework adapts; the underlying requirements (self-tests, zeroization, side-channel resistance) apply equally to PQC.

What is the difference between ISO/IEC 19790 and ISO/IEC 24759?

ISO/IEC 19790 specifies the security requirements a module must satisfy. ISO/IEC 24759 specifies the test methods a laboratory uses to verify compliance. The two standards are companion documents: a vendor reads 19790 to know what to build, and a lab reads 24759 to know how to test. NIST SP 800-140 series adapts both standards for CMVP, with sub-publications (800-140A through 800-140F) covering specific topic areas like documentation requirements, software/firmware security, and approved security functions.

Are open-source projects ever validated?

Yes, but rarely as the open-source project itself. The common pattern is that a commercial vendor takes a frozen snapshot of the open-source code, integrates it into a product, and submits the integrated module for validation. The Red Hat Enterprise Linux OpenSSL FIPS module and Canonical's Ubuntu cryptographic module are examples. The validation certificate names the vendor and the specific build, not the upstream project. Open-source projects can support this pattern by maintaining a stable validation branch and documenting the build environment so vendors can reproduce it.

Sources

ISO/IEC 19790:2012, "Information technology, Security techniques, Security requirements for cryptographic modules." https://www.iso.org/standard/52906.html
ISO/IEC 24759:2017, "Information technology, Security techniques, Test requirements for cryptographic modules." https://www.iso.org/standard/72515.html
NIST FIPS 140-3, "Security Requirements for Cryptographic Modules." https://csrc.nist.gov/pubs/fips/140-3/final
NIST CMVP Program. https://csrc.nist.gov/projects/cryptographic-module-validation-program
NIST Implementation Guidance for FIPS 140-3 and the Cryptographic Module Validation Program. https://csrc.nist.gov/CSRC/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf
NIST SP 800-140 series, "FIPS 140-3 Derived Test Requirements (DTR)." https://csrc.nist.gov/projects/cryptographic-module-validation-program/sp-800-140-series-supplemental-information
ISO/IEC 17825:2024, "Information technology, Security techniques, Testing methods for the mitigation of non-invasive attack classes against cryptographic modules." https://www.iso.org/standard/85356.html

Protect Your Data Before Q-Day Arrives

QNSQY's NIST-standardized post-quantum encryption protects data against both current and quantum-era threats.

Try QNSQY