ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
Remote key distribution under PCI PIN Security is governed by Normative Annex A, which covers symmetric key distribution using asymmetric techniques. It splits into two sub-annexes with different requirement sets, and it is the part of the standard most often left unexamined because nobody answered the scoping question that pulls it in.
If you establish keys in devices without physically visiting them, or you operate a certification authority for that purpose, Annex A applies to you on top of everything in the main body.
Annex A1 covers remote key distribution operations proper — the act of establishing keys in devices using asymmetric techniques. Annex A2 covers certification and registration authority operations, which is what supports it.
| Sub-annex | Applies to | Sub-requirements |
|---|---|---|
| Annex A1 | Entities performing remote key distribution using asymmetric techniques | 85 |
| Annex A2 | Entities operating a certification or registration authority for that purpose | 105 |
An organisation may be subject to one, both, or neither. Using a third party’s authority does not remove your accountability — it moves where some of the evidence lives, and you need the contractual right to obtain it.
The A1 requirements for remote key distribution concentrate on making sure the right parties, and only the right parties, can establish keys with your devices:
The authorisation control deserves particular attention because of where it has to be enforced. A device that will establish keys with whatever host reaches it is vulnerable no matter how well the network is segmented, so the check has to happen at the device, with network controls as an additional layer rather than the only one.
One A1 requirement is unlike anything else in the standard: the key-establishment and distribution procedures must be designed so there is no means available within the implementation design for an interception attack to succeed.
That is not a control you can point at. It is a reasoned argument that has to be written down, and it is the requirement organisations find hardest to evidence. A usable statement answers concrete questions: how does the device know it is talking to the legitimate host, how does the host know it is talking to the legitimate device, how is that trust established initially before any shared secret exists, what prevents relay and substitution, what prevents replay, and what prevents a downgrade to a weaker algorithm.
The initial trust anchor is where these attacks concentrate, because it is the one point at which no shared secret yet exists. Record how the anchor reaches the device, when, who controls it, and what an attacker would need to substitute it.
A2 is the densest requirement set in the standard, and much of it reads like general IT security. It is not — these are requirements against a specific system whose compromise invalidates every certificate it ever issued.
The obligations run from governance through to the building: a certificate policy and a separate certification practice statement, an explicit certificate security policy the system actually enforces, separation of duties over critical authority functions so no one person can misuse the system undetected, hardening of any authority system not operated exclusively offline, defined audit trail contents with log integrity protected by a signature or message authentication code, authentication management with pre-expired initial passphrases, clock synchronisation across both the key-management systems and the physical security estate, and three tiers of physical barrier around the facility.
Annex A2 requires three tiers of physical security around the authority, and this is the source of a piece of vocabulary that gets misused:
These describe physical layers around a building. They are not tiers of organisation: there is no such thing as a “Level 1” or “Level 2” entity under this standard, and a vendor describing your business that way is using vocabulary that does not exist. Normative Annex B references these same barrier levels when permitting a caged key injection environment.
The commercial reason organisations adopt remote key distribution is that it removes the need to touch a device to key it. That is genuine, and it interacts with two other parts of the standard in ways worth planning for.
It changes the key injection facility position. Where initial keys are established remotely rather than injected, some Annex B obligations recede — but the facility still injects whatever the device needs to accept a remote establishment in the first place, so Annex B rarely disappears entirely.
It also interacts with key blocks. For a new deployment using master and session key management, the key block protection keys have to be established inside the device at injection so that session keys can be updated after deployment. Remote key distribution is how those updates then happen, and asymmetric methods may be used for establishing the initial keys.
The sequencing matters: decisions about remote key distribution have to be made before a device is injected, not after it is in the field.
Two certificate requirements cause more remediation in remote key distribution than the rest of A2 combined, and both are usually broken by a default rather than a decision.
Single purpose. Certificates used with remote key distribution must serve one function only, with those associated with encipherment distinct from those associated with signature. A single certificate carrying both key encipherment and digital signature usage breaks it, and that combination is the default in many certificate templates.
New key pairs on renewal. A key pair may not be reused for certificate renewal or replacement, and each pair must result in only one certificate. Renewing over the existing key pair is the default behaviour of most renewal tooling, so the process has to be built to generate rather than reuse — and the configuration verified, because requesting a profile and receiving it are different things.
Both are testable in minutes: compare public keys across your certificate inventory for reuse, and inspect issued certificates for more than one usage in the extension.
Where a third party operates the certification authority on your behalf, that is a legitimate position — and it does not make Annex A2 disappear from your file.
Record which third party performs the function, their PCI PIN status, and the evidence you hold. Then check the one thing people skip: is that evidence scoped to the scheme you actually use, or is it a general assurance about their business? A scoped assurance and an unscoped one are not the same artefact, and an assessor will ask which you have.
Most of Annex A can be tested rather than inspected, and doing so before an assessment turns a set of assertions into evidence.
Present an unauthorised host to a device and attempt key establishment; it should be refused by the device, and refused again with the network control bypassed. If it only fails at the network layer, the control is the network, not the device, and that is a finding waiting to happen.
Attempt to have the authority issue a certificate with two usages in the extension, and confirm it refuses. Compare public keys across the certificate inventory to catch pairs reused across renewals. Attempt each critical authority function with one operator’s credentials and confirm either that it stops, or that the detection control fires and someone actually reviews the output.
Related reading: PCI PIN key blocks, which have to be established at injection for new deployments, dual control and split knowledge over authority key material, and Qualified PIN Assessor.
No. Entities performing remote key distribution are subject to the transaction processing requirements as well as the additional Annex A criteria. The sets stack.
You remain accountable. Record the arrangement, hold their evidence, and confirm it is scoped to the service they perform for you.
Nothing — the standard has no such tier. The levels it names are physical barriers around a certification authority facility, not classifications of organisation.
In PCI PIN Security Requirements and Testing Procedures v3.1, free from PCI SSC’s document library after accepting their licence agreement.
Remote key distribution asks for documents most security programmes have never produced: a certificate policy, a certification practice statement, a written design assurance against interception, and the facility records behind three barrier tiers.
Our PCI PIN Security Toolkit devotes a twenty-eight document section to Annex A across both sub-annexes, within 149 templates covering all 145 sub-requirements. See also our guides to PCI PIN scope, which determines whether Annex A applies to you, the PCI PIN Security Requirements as a whole, and key injection facilities under Annex B.
September 8, 2026
September 8, 2026
September 8, 2026
September 8, 2026
September 8, 2026