PCI PIN Security Requirements: A Complete Guide to v3.1 in 2026

PCI PIN Security Requirements govern how a cardholder’s PIN, and every cryptographic key that protects it, is generated, moved, loaded, used, administered and destroyed. The PCI PIN Security Requirements are a separate standard from PCI DSS, they apply to a different population of organisations, and they are assessed by a different kind of assessor.

If you acquire PIN-based transactions, process them for someone else, inject keys into devices, or operate a certification authority for remote key distribution, this is the standard that governs it. This guide sets out what the current version contains, who it binds, and the handful of things that are most often reported incorrectly.

What this guide covers

• What version of the PCI PIN Security Requirements is current
• Who the PCI PIN Security Requirements apply to
• How the PCI PIN Security Requirements are structured
• The four scope columns of the PCI PIN Security Requirements
• When you have to comply with the PCI PIN Security Requirements
• Four things people get wrong about the PCI PIN Security Requirements
• What the PCI PIN Security Requirements ask you to document
• How compliance with the PCI PIN Security Requirements is assessed
• Frequently asked questions
• Getting the documentation together

What version of the PCI PIN Security Requirements is current

The current version is PCI PIN Security Requirements and Testing Procedures v3.1, published March 2021. It replaced v3.0 of August 2018, which had itself replaced v2.0 of December 2014 — the first version to carry testing procedures alongside the requirements.

One point of confusion is worth clearing up immediately. The Attestation of Compliance that accompanies an assessment carries its own version number, currently v3.3 of February 2026, and that number was deliberately aligned to the v3.x family. It is not the standard’s version. There is no PCI PIN v3.3, and the February 2026 attestation still targets v3.1.

Who the PCI PIN Security Requirements apply to

The PCI PIN Security Requirements are written for acquiring institutions and their agents — processors, key-injection facilities and certificate processors — responsible for PIN transaction processing. It is not a merchant standard in the way PCI DSS is.

Scope is decided by what you do, not by how much of it you do. There is no transaction threshold below which the PCI PIN Security Requirements stop applying, and no light-touch tier for smaller volumes. If your organisation performs an in-scope activity, the requirements for that activity apply in full.

How the PCI PIN Security Requirements are structured

The PCI PIN Security Requirements organise into seven Control Objectives, containing 33 numbered Requirements, which break down into 145 distinct sub-requirement identifiers. Those seven objectives follow the key lifecycle in order:

1. PINs are processed using equipment and methodologies that keep them secure
2. Keys are created by a process that makes no key more probable than another
3. Keys are conveyed or transmitted securely
4. Key loading to hardware security modules and PIN-acceptance devices is handled securely
5. Keys are used in a way that prevents or detects unauthorised usage
6. Keys are administered securely
7. Equipment used to process PINs and keys is managed securely

Alongside the main body sit two normative annexes: Annex A for symmetric key distribution using asymmetric techniques, and Annex B for key-injection facilities. Both are normative, meaning they carry requirements rather than guidance.

The four scope columns of the PCI PIN Security Requirements

The applicability appendix of the PCI PIN Security Requirements divides its 145 sub-requirements across four columns. An organisation is subject to every column covering an activity it performs.

Those four figures overlap heavily and must never be added together. Adding them produces 380, a number that does not exist. The standard contains 145 distinct identifiers; an entity subject to more than one column satisfies the union of those columns, not their sum. An acquirer that also runs a key-injection facility is not facing 190 requirements — it is facing the combined set, most of which appear in both columns.

When you have to comply with the PCI PIN Security Requirements

There is no industry-wide deadline, because PCI SSC does not set one. The standard states plainly that the individual payment brands set the effective date for compliance. If you are looking for a single date that applies to everyone, it does not exist — contact the payment brands you work with.

What the standard does set is a phase-in for particular requirements, and every one of those dates is now in the past:

Four things people get wrong about the PCI PIN Security Requirements

Each of these is a limit on a requirement that reads much broader than it is, and each is sourced from the standard or from PCI SSC’s own technical FAQs.

Phase 3 did not retrofit anything. POI deployments that existed before 1 January 2025 are not required to convert to key blocks, though they may choose to. New deployments must. A programme built on the assumption that the whole estate had to convert will produce work that was never required.

Clear-text key injection is not banned outright. The restriction applies to new deployments of the more recent POI device generations. Injection into earlier generations remains acceptable past both the 2024 and 2026 dates, until a payment brand mandates those devices out of service.

Fixed key is only prohibited with TDEA. The 1 January 2023 prohibition covers fixed key for TDEA PIN encryption. Fixed key used with AES is unaffected.

The ISO Format 4 dates are suspended, not replaced. v3.1 suspended the sunrise dates that v3.0 had set, and PCI SSC is re-evaluating them. Those dates were for supporting the format, not for using it, and no replacement date has been published. Anyone quoting you an ISO Format 4 deadline is quoting a withdrawn one.

What the PCI PIN Security Requirements ask you to document

Eight of the 33 numbered Requirements ask for procedures to exist and be followed, six of those require them to be demonstrably in use, and several ask separately that affected parties be aware of them. Awareness is a requirement in its own right: a correct procedure that the custodians have never read fails it, even where every operation was performed properly.

In practice the PCI PIN Security Requirements generate two kinds of artefact. There are the standing documents — the key management policy, the ceremony procedure, the loading procedures per device type. And there are the records those procedures throw off: ceremony attendance sheets, conveyance and receipt logs, tamper-evident packaging registers, key loading logs, destruction certificates, device chain-of-custody trails.

The records matter more. A procedure with no records behind it is the single most common finding, and it is not one you can close in the weeks before an assessment, because the records have to have been produced as the work happened.

How compliance with the PCI PIN Security Requirements is assessed

Assessment is an onsite engagement performed by a Qualified PIN Assessor, a qualification distinct from the QSA scheme used for PCI DSS. There is no self-assessment questionnaire; unlike PCI DSS, there is no self-assessment route at all.

The testing leans heavily on observation. An assessor will want to watch a key ceremony or a loading session performed the way it is normally performed, and will sample records across the whole period rather than only recent ones. Documented procedures that have produced no records read as procedures nobody follows.

The cycle is two years, not one. A listing on PCI SSC’s list of PIN service providers shows as expired two years after the date the assessor signs the attestation — not two years from submission, and PCI SSC does not prorate for a past-dated attestation. Submitting late shortens the listing rather than moving it.

Frequently asked questions

Do the PCI PIN Security Requirements replace PCI DSS?

No. They are separate standards covering different things, and an organisation can be subject to both. PCI DSS governs the cardholder data environment; PIN Security governs PIN and key management. See our guides to PCI DSS scope and PCI DSS documentation for the other side of that boundary.

Where can I get the standard?

Free, from PCI SSC’s own PIN Security page, after accepting their licence agreement. The licence permits you to read and use it; it does not permit redistribution, which is why documentation packs paraphrase it rather than reproducing its text.

How many requirements are there?

Seven Control Objectives, 33 numbered Requirements, and 145 distinct sub-requirement identifiers. How many apply to you depends entirely on which activities you perform.

Is there a certification?

No. The process produces an attestation of compliance and, optionally, a listing on PCI SSC’s website. Nobody is “PCI PIN certified”, and a vendor claiming to sell you certification is describing something that does not exist.

Where to go next

Each part of the standard has its own guide: PCI PIN scope works out which requirements apply to you, PCI PIN key blocks covers Requirement 18-3 and the three phases, dual control and split knowledge covers the pair of controls that fails most often, Qualified PIN Assessor explains the assessment itself, and the two normative annexes are covered in key injection facilities and remote key distribution. If you also hold PCI DSS obligations, PCI PIN vs PCI DSS sets out the boundary.

Getting the documentation together

The PCI PIN Security Requirements tell you what has to be true. It does not give you the ceremony scripts, custody records, loading logs, destruction certificates or evidence registers an assessor asks to see — and the requirements that ask for procedures to be “demonstrably in use” are satisfied by records produced routinely, not by documents written the month before an assessment.

Our PCI PIN Security Toolkit is 149 editable templates covering all 145 sub-requirements across all four scope columns, including both normative annexes, structured on the standard’s own seven Control Objectives. It reflects the version and the position described above, including the four limits most material gets wrong. See also our PCI DSS v4.0.1 guide if both standards apply to you.