Cryptographic Product Certification: Fundamentals

Most confusion about certification starts with one sentence: “our HSM is certified.” Certified by whom, for what, and which part of it? This module distinguishes evaluation criteria from certification schemes and asks what each certificate actually covers. Once you know the scope, you also know which questions a certificate leaves open — and those are the ones a buyer, an evaluator or an auditor will ask next.

Throughout the module we follow one product: the Orrin N7fictional, a network-attached hardware security module (HSM), sold as an on-premises appliance and as a multi-tenant cloud HSM service. It sells into four markets — US federal agency, EU qualified trust service provider, smart-card / secure-element manufacturer, payment processor — and its vendor is adding ML-KEM and ML-DSA, with optional hybrid. Every scheme sees a different object inside this one product.

Words used in this table

CSTL (Cryptographic and Security Testing Laboratory)

An independent lab, accredited under NIST’s lab accreditation program (NVLAP), that tests cryptographic modules. The CMVP reviews its reports and issues the validation certificates.FIPS 140-3 Cryptographic Module Validation Program Management Manual (NIST CSRC, Cryptographic Module Validation Program page; NIST CSRC, Testing Laboratories page)

CCRA (Common Criteria Recognition Arrangement)

An agreement among governments to recognize each other’s Common Criteria certificates. Its aim is that a certified product can be bought or used without being evaluated again. Article 2 of the arrangement sets which certificates it covers.(Arrangement on the Recognition of Common Criteria Certificates in the field of Information Technology Security, 2 July 2014 (ratified 8 September 2014), Preamble and Articles 1 and 2; Common Criteria Portal)

Security Target (ST)

The document that states the security requirements for the specific product, or part of a product, being evaluated. The evaluation checks the product’s own security controls against it.Common Criteria for Information Technology Security Evaluation, CC:2022 Release 1, Part 1 Regulation (EU) 2024/482 (EUCC)

Protection Profile (PP)

A statement of security needs for a type of product, not for one specific product.Common Criteria for Information Technology Security Evaluation, CC:2022 Release 1, Part 1

ITSEF (IT Security Evaluation Facility)

An evaluation lab that is accredited, licensed or approved to carry out evaluations within a certification scheme, independently of the product’s developer.(Arrangement on the Recognition of Common Criteria Certificates, 2 July 2014, Annex A (glossary) (not sourced in the Library)) Regulation (EU) 2024/482 (EUCC)

PTS HSM (PIN Transaction Security Hardware Security Module)

The PCI standard of security requirements for HSMs used in payments. PCI-recognized labs evaluate HSMs against it, and PCI SSC lists the approved devices.(PCI SSC, PTS Hardware Security Module (HSM) standards page)

P2PE (Point-to-Point Encryption)

Encryption that protects payment account data from the point where a merchant accepts the card to a secure point of decryption. PCI publishes security requirements and test procedures for P2PE solutions, components and applications.PCI SSC — Point-to-Point Encryption (P2PE) standard page (PCI SSC glossary)

KMO (Key Management and Operations)

A PCI standard, published as version 1.0 on 14 September 2026. It sets requirements for managing cryptographic keys that protect payment account data, from generation to destruction.PCI Perspectives blog, 14 September 2026 (PCI SSC, Key Management and Operations (KMO) standards page)

QPA (Qualified PIN Assessor)

An assessor qualified and trained by PCI SSC to assess environments where PINs are processed against the PCI PIN Security Requirements.(PCI SSC, PIN Security standards page; PCI SSC glossary)

AVA_VAN

The Common Criteria family called vulnerability analysis. The evaluator assesses whether flaws could let an attacker break the product’s security requirements. It has five levels, AVA_VAN.1 to AVA_VAN.5, and each asks for more rigor than the one before.Common Criteria 2022 Part 3 — Security Assurance Components (R1) Regulation (EU) 2024/482 (EUCC)

One question per scheme

Notice what the table does not contain: a column that ranks the schemes. There is no exchange rate between a FIPS level, an EAL and a PCI approval, because they measure different things about different objects. A FIPS 140-3 validation says a defined module meets FIPS requirements (FIPS 140-3 — Security Requirements for Cryptographic Modules, as modified by SP 800-140A–F). A Common Criteria certificate says a TOE met the claims in its Security Target, to the depth of a named assurance package (Common Criteria 2022 Part 3 — Security Assurance Components (R1)). EUCC does the same under EU law (Commission Implementing Regulation (EU) 2024/482 — the EUCC cybersecurity certification scheme), with two assurance levels: substantial (AVA_VAN 1–2) and high (AVA_VAN 3–5). PCI SSC approves a payment device, and separately its standards assess the entities that run payment operations.

PCI is two questions, not one

The PCI row is the one learners most often collapse. PTS HSM approval covers the device — model, hardware version, firmware version — “up to the point of initial deployment”, after a PCI-recognized lab evaluates it and PCI SSC reviews and lists it (PCI SSC Publishes PCI PTS HSM v5.0 (PCI Perspectives blog)). PIN Security, P2PE and KMO assess how an acquirer, a solution provider or a key-injection facility operates. The same Orrin N7 can be a listed device, a component of a processor’s PIN environment, and the decryption HSM in a P2PE solution — three different assessments, one box.

Terms that must stay distinct

Algorithm standard

Defines an algorithm — for example FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA).

Algorithm validation (CAVP / ACVP)

Evidence that an identified implementation correctly performs identified algorithm operations and parameters. It is not a module certificate.

Cryptographic module validation (CMVP)

A defined module evaluated against FIPS 140-3 as modified by SP 800-140A–F, under the Management Manual and the Implementation Guidance.

Modules in Process (MIP)

A queue position with a status (Cost Recovery, Pending Review, Pending Resubmission, Review, Comment Resolution – Lab/CMVP, Finalization); the Implementation Under Test list is separate. Not evidence of any outcome.

Historical (CMVP)

Federal Agencies should not include Historical modules in new systems, but the certificates are not revoked. FIPS 140-2 modules moved there on 21/22 September 2026, and NIST still supports buying and using them for existing systems.

Target of Evaluation (TOE)

The exact product, or part of a product, evaluated under Common Criteria.

Security Target (ST)

The product-specific security claims and requirements a CC evaluation checks.

Protection Profile (PP)

Reusable security requirements for a class of products, which a Security Target may claim.

Evaluation Assurance Level (EAL)

A predefined Common Criteria assurance package — how thoroughly the claims were checked. Not a cryptographic strength or a "security score".

EAL4+

EAL4 plus specifically named assurance components. The "+" means nothing until the list is read.

EUCC

The EU Common Criteria-based scheme under Implementing Regulation (EU) 2024/482 (applies from 27 February 2025), amended by 2024/3144 and 2025/2462. Levels: substantial (AVA_VAN 1–2) and high (AVA_VAN 3–5).

eIDAS 2.0

Regulation (EU) 2024/1183, amending eIDAS and establishing the European Digital Identity Framework. A regulation — not a Protection Profile.

PCI PTS HSM approval

Device approval "up to the point of initial deployment" after evaluation by a PCI-recognized lab. Not a FIPS or CC certificate.

PCI PIN / P2PE / KMO assessment

Assessment of an entity’s operations (acquirer, solution provider, key-injection facility) — not of a device.

Shortcuts a certificate never supports

Each of these sentences appears in real marketing, procurement and even training material. Each is false. Learn the correct statement beside it; the capstone checks your claims against this list.

• EAL4+ is equivalent to FIPS 140-3 Level 4.

  They measure different things. An EAL is how thoroughly a TOE’s claims were evaluated; a FIPS level is a set of security requirements a module meets. Neither converts into the other.

• Passing ACVP means the module is FIPS validated.

  ACVP / CAVP validates algorithm implementations. It is necessary evidence for a module validation, but only the CMVP issues the module’s validation record.

• Using a NIST-standardized PQC algorithm makes a product FIPS validated.

  An algorithm standard says what ML-KEM is. Validation says a specific implementation, inside a specific module, was tested and reviewed.

• A module on the CMVP Modules-in-Process list is FIPS validated, or "validation pending at Level N".

  The MIP list shows a queue position and a status. It is not evidence of any outcome or level.

• eIDAS 2.0 is a Protection Profile.

  eIDAS is a regulation with device and trust-service requirements. Establish the applicable Article 30 assessment basis and designated certification body. A Protection Profile may support that assessment; EUCC applies only where that scheme is used.

• EUCC is simply the EU version of a CCRA certificate, recognized identically everywhere.

  EUCC is an EU legal scheme with its own rules and levels. EUCC certificates may carry the CCRA mark if they also meet the requirements of the CCRA (CCMC-011, March 2025), and the document proposes that all CCRA participants then mutually recognise certificates bearing that mark.

• A FIPS Level 3 HSM automatically satisfies PCI PTS HSM, or an eIDAS / QSCD Protection Profile.

  PTS HSM approval and PP certification are separate evaluations. But see the nuance below: some PCI entity requirements accept a FIPS Level 3 HSM.

• PCI PTS HSM approval proves every exposed PQC algorithm was independently validated under ACVP.

  PTS approval is a device-security approval. It is not algorithm validation.

• A PCI listing’s PQC flag means a specific PQC algorithm or parameter set is approved.

  For v3-and-higher HSMs the listing notation “is for the existence of PQC support”. Algorithm detail is in the Security Policy; readiness detail comes from the vendor.

• An old EAL4+ claim is automatically comparable with a current CC:2022 or EUCC evaluation.

  The criteria version, the PP version, the augmentations and the attack landscape all differ. Compare the named components, not the label.

Three more shortcuts concern timing and process — a market deadline treated as a certification route, SP 1800-40 read as vendor self-certification, and Executive Order 14412 treated as if it had already changed the CMVP. They are taught in the deadlines section.

Worked example: one sentence, four customers

Suppose the Orrin N7 datasheet says: “FIPS 140-3 Level 3 validated.” Assume the validation is real. What has each customer learned?

• US federal agency: the answer to its question — if the validated module version and approved mode are the ones it will run. Scope is the next question.
• EU qualified trust service provider: nothing about the Protection Profile its eIDAS assessment expects. Identify the device, its Article 30 assessment basis and the designated certification body. EUCC evidence may be relevant where that scheme is used; a FIPS certificate alone does not establish QSCD certification or qualified-service status.
• Secure-element manufacturer: possibly useful evidence about a tool in its production site — whether its evaluator accepts it is a question to ask.
• Payment processor: not device approval. Possibly enough for its PIN or P2PE HSM requirement. Its own operations still need their own assessment.

One true sentence; four different amounts of information. The Which scheme answers the question? workshop step lets you practise this with real procurement claims.

Go deeper, one scheme at a time: FIPS 140-3 Certification, Common Criteria, EUCC & eIDAS Certification and PCI Certification.