Key injection facility obligations under PCI PIN Security live in Normative Annex B, and they apply to any organisation that loads cryptographic keys into devices — whether for its own estate or on behalf of somebody else. Annex B is normative, meaning it carries requirements rather than guidance, and it brings 94 sub-requirements with it.
Key injection is also the activity most often performed without anyone recognising that it changes the organisation’s compliance position. Deploying terminals for a customer and loading their initial keys is running a key injection facility, whatever the department is called internally.
What this guide covers
- What Annex B adds to a key injection facility
- The secure room a key injection facility needs
- Clear-text injection: the dates and their real scope
- PC-based loading platforms
- Who else a key injection facility answers to
- Reconciliation and device tracking
- Base derivation keys and terminal types
- Preparing for an Annex B assessment
- Frequently asked questions
- Getting the documentation together

What Annex B adds to a key injection facility
Most of the 94 sub-requirements a key injection facility is subject to are shared with the main body — dual control, split knowledge, key strength, destruction, chain of custody. Eleven identifiers are unique to Annex B, and those eleven are what a facility misses if it treats the main body as sufficient:
- Injecting keys only using equipment that conforms to the criteria for secure cryptographic devices
- Maintaining current documentation of the facility architecture and key-management flows
- Dual control and split knowledge over loading keys into devices
- Additional controls where a PC-based loading platform allows clear-text key material outside a secure cryptographic device
- Preventing and detecting the loading of unencrypted keys by any one person
- Protecting against unauthorised key substitution and preventing devices operating without legitimate keys
- Separate base derivation keys per terminal type where required
- Participation in remote key establishment and distribution
- Reconciling injection against an inventory of pre-authorised devices
- Mutually authenticated channels between distributed facility components
- A physically secure room for key injection
The secure room a key injection facility needs
Where secret or private keys, or their components, appear in memory outside a secure cryptographic device during loading, a key injection facility must implement a physically secure room. The physical criteria are specific and they get inspected:
| Element | Requirement |
|---|---|
| Walls | Solid materials; where they do not reach the real ceiling, extended walls of sheetrock or wire mesh from real floor to real ceiling |
| Windows | Locked and protected by alarmed sensors, with the alarm mechanism active |
| Access | Controlled, recorded, and under two-person control |
| Surveillance | Covers activity, but positioned so it cannot capture key material or keypad entry |
| Recording devices | None present beyond those the procedure requires |
The wall requirement is the one that fails inspection. Checking at eye level is not enough — a suspended ceiling with open space above it means the extended walls have to be verified physically, above the tiles.
A caged environment is permitted as an alternative, where the facility’s outer physical barrier controls are in place and confirmed. Those barrier levels are defined in Normative Annex A for certification authority facilities and referenced from Annex B.
Clear-text injection: the dates and their real scope
Two dates removed the option for a key injection facility to inject clear-text keying material, and both are now past:
- 1 January 2024 for entities injecting on behalf of others
- 1 January 2026 for entities injecting devices for which they are the processor
Both are far narrower than they sound, and any key injection facility planning work should read the limits before budgeting:
They apply to new deployments of the more recent POI device generations. PCI SSC’s technical FAQs confirm that injecting clear-text keys into earlier device generations remains acceptable past both dates, until such time as a payment brand mandates those devices out of service.
Minor software updates were not caught. The same guidance says minor updates and patches that are not compliant with the encrypted key loading sunrise could continue to be deployed after the 2024 date. Major software updates to an existing estate must use compliant injection methods.
Read as a blanket ban, these dates produce a device replacement programme that was never required. Read correctly, they constrain new deployments of newer devices.
PC-based loading platforms
A related and separate phase-out concerns key injection facility platforms where clear-text key material can exist in ordinary memory outside a secure cryptographic device. That option closed on 1 January 2021 for entities loading keys on behalf of others, and on 1 January 2023 for entities loading only for devices they process for.
The determination worth making first is technical, not contractual: does any platform you use actually expose clear-text material outside a secure cryptographic device? Establish it by examination rather than from the vendor’s description, and record how you established it.
Who else a key injection facility answers to
Annex B is not the whole picture, because a key injection facility is almost always acting for someone whose own compliance depends on it.
Your customer remains accountable for the requirement even though you perform the work. That means they need evidence from you — which keys were injected into which devices, that separate base derivation keys were used where required, that derivation data was unique per device, and the reconciliation showing devices injected matched devices authorised. Their contract should give them the right to obtain it, and a general assurance scoped to your business as a whole will not satisfy an assessor looking at the service you actually provide them.
It also means your chain of custody has to join up with theirs. A device passing through a key injection facility does not leave the customer’s custody trail; it becomes a segment of it, and the records need to be produced in a form they can hold.
Reconciliation and device tracking
Two of the Annex B requirements work together to close the substitution risk, and they are the ones a key injection facility can implement most cheaply.
Every device is tracked by serial number at each loading session, with the key injected and the derivation data recorded against it. Separately, devices injected are reconciled against a list of devices pre-authorised by the customer, and devices despatched are reconciled against devices successfully injected.
Do the reconciliation before anything leaves the building. A device injected but absent from the pre-authorised list, or despatched with no recorded successful injection, is exactly the scenario the requirement exists to catch — and catching it after despatch is catching it too late.
Base derivation keys and terminal types
Where a key injection facility loads derived keys for more than one terminal type for the same entity, separate base derivation keys are required per terminal type in the circumstances the standard sets out. This sits on top of the segmentation strategy the processing entity owns, and the two are not the same axis: the customer segments by institution or by vendor, the facility by terminal type.
Agree the arrangement with the customer and record it, because where their strategy and yours differ, the stricter applies. And decide the position for a new terminal type before injecting it — defaulting it into an existing base derivation key’s population is exactly the concentration this requirement exists to prevent.
Preparing for an Annex B assessment
The assessor will want to watch an injection session performed the way it is normally performed, so the preparation that matters happens months earlier. Three things are worth testing on yourself first.
Can one person complete a session? Test it rather than reading the procedure. Attempt to enable a loading session with a single credential set and confirm it is refused, then check whether the room access log would show one person present.
Do the exception reports actually run? Preventing single-person loading is one requirement; detecting it is another. A report of sessions where the room held one person is the control that finds problems, and it only helps if somebody reviews it.
Does the reconciliation close? Devices authorised, devices injected, devices despatched — three numbers that should agree. Where they do not, the difference has to be investigated before anything ships, not explained afterwards.
Facilities that also establish keys without visiting devices take on Normative Annex A as well — see remote key distribution — and Qualified PIN Assessor covers what an Annex B assessment looks like on the day.
Frequently asked questions
Does deploying terminals make us a key injection facility?
If you load cryptographic keys into them, yes — Annex B applies regardless of what the function is called internally or whether injection is your main business.
Is clear-text key injection banned outright?
No. The restriction covers new deployments of the more recent POI device generations. Injection into earlier generations remains acceptable past both dates, until a payment brand mandates those devices out of service.
Do we need a secure room?
Only where key material appears in memory outside a secure cryptographic device during loading. A facility performing only encrypted key injection should record that determination and the evidence for it — a stronger position than operating a compliant room.
Where do we read Annex B?
In PCI PIN Security Requirements and Testing Procedures v3.1, free from PCI SSC’s document library after accepting their licence agreement.
Getting the documentation together
An Annex B assessment asks a key injection facility for artefacts a general security programme does not produce: a current architecture and key-flow statement, the secure room inspection record, per-session device serial tracking, and the pre-authorised device reconciliation.
Our PCI PIN Security Toolkit devotes a twelve-document section to Annex B alone, within 149 templates covering all 145 sub-requirements. See also our guides to PCI PIN scope, which determines whether Annex B applies to you, PCI PIN key blocks, which have to be established at injection for new deployments, and dual control and split knowledge.