PCI Certification

PCI has two very different kinds of evidence, and most mistakes about payment HSMs come from mixing them up. Device approval says a product model was designed and evaluated to PCI’s device requirements. Entity assessment says an organisation runs its payment operations — PIN processing, encryption, key management — to PCI’s operational requirements. This section is about the first: PCI PIN Transaction Security (PTS) Hardware Security Module (HSM) approval.

What the approval covers

PCI SSC describes the PTS HSM standard as guidance for designing HSMs for the payments industry, “and for protecting those HSMs up to the point of initial deployment. Other security requirements apply at the point of deployment for the management of HSMs involved with the financial payments industry.” [PCI SSC, PTS Hardware Security Module (HSM) — standard page, read 24 September 2026]

That sentence sets the boundary. An approval tells you about:

• a device model, at the hardware and firmware versions named on its listing;
• evaluated against one major version of the PTS HSM requirements (v3.x, v4.x, v5.x);
• by an independent PCI-recognized laboratory, whose report PCI SSC reviews before it approves and lists the device.

It does not tell you how a bank, processor or cloud operator installs, administers or keys that device. Those are entity questions, answered by PIN, P2PE or KMO assessments (the boundary lesson below). PCI also says who must use listed products is not its call: compliance programmes “are managed by the payment brands”. [PCI SSC, PTS Hardware Security Module (HSM) — standard page, read 24 September 2026]

Versions are part of the claim

The public Program Guide v1.9 (June 2020) sets two rules that still explain how listings read. First, “all initial evaluations under a major version … shall constitute a new evaluation and shall receive a new approval number.” Second, “any firmware changes to an approved device must result in a new firmware version.” [PTS Program Guide v1.9] So an approval number belongs to one requirements version, and the listing names the exact firmware versions it covers. Operational standards rely on that: PIN Security v3.1 Req 1-4 requires the approval listing to match the deployed devices’ vendor, model, hardware version, firmware version and approval number. [PIN v3.1 requirement text (ROC template)]

v1.9 is a superseded guide. It is used here because it is public; the current Device Testing and Approval Program Guide (listed in the Document Library on 18 May 2026) is licence-gated and not read for this module.

Restricted or unrestricted

An HSM approval can be restricted: valid only when the HSM is deployed in at least a Controlled Environment as defined for PCI and in the device’s PCI HSM Security Policy. Unrestricted approval “is valid in any operational environment.” The listing states which, under Additional Information. [PTS listing field definitions]as of 24 September 2026 Two real listings in the workshop show both: payShield 10K (4-40266) reads “Approved usage: Restricted” and Atalla AT1000 (4-70041) reads “Approved usage: Unrestricted”. A restricted approval moves a question to the deployment: the assessor of the entity running it checks where it is installed.

The clocks

These are scheme clocks — what PCI’s device programme is doing. They are not market PQC deadlines, which this module never types into prose. as of 24 September 2026

Read the table the way a vendor would. Orrin N7 (fictional) could still be submitted for a new v4 approval until 30 June 2027; a v4 approval would then run to April 2033. A v5.0 approval would sit on the v5.x row. Nothing public states a separate v5.0 “effective date”, so do not invent one — the documents above are the dates that exist.