Acquirers, PIN processors, key-injection facilities and HSM service providers have long been assessed against key-management rules scattered across PCI PIN, PCI P2PE Domain 5 and payment brand programmes, and PCI SSC has now pulled them into one standard. The PCI Key Management and Operations (KMO) Requirements and Test Procedures, version 1.0, was published in September 2026. It covers the whole life of a cryptographic key, from generation to destruction, and the systems and people that handle it. This guide explains how KMO relates to PCI PIN and the other PCI standards, how its four domains and six listing service types fit together, where identity and machine credentials sit in it, and how to prepare for an assessment. It is written for key-management leads, HSM and payment operations teams, compliance managers at processors and acquirers, and assessors new to the standard.
Key takeaways
- KMO can stand in for a PCI PIN assessment. The standard says it is intended to duplicate the intent of the PCI PIN requirements, so an assessment against KMO may be performed instead of one against PCI PIN, and the same applies to P2PE Domain 5.
- Four domains, applied by service type. Domain 1 (core key life cycle) applies to everyone; Domains 2, 3 and 4 add remote HSM and HSM-as-a-Service, data-specific and environmental requirements depending on whether you are a DM, PPS, KIF, SSP, CA/RA or HaaS.
- No customised approach. KMO states that requirements and test procedures are assessed as written. Where a frequency is not set, you may define one, but it must be backed by a documented risk assessment.
- People hold key components, machines do not. Requirement 1A-5.2 says a key custodian must be an employee or contracted person, and its applicability note rules out a non-human system such as an AI agent.
- KMO does not replace PCI DSS. A key-management environment that stores, processes or transmits account data is still subject to PCI DSS, and KMO is not intended to replace the key-management requirements inside PCI DSS.
What it is and who it applies to
KMO defines security requirements, test procedures and guidance for entities that operate and manage cryptographic keys, and the systems that use them, to protect account data. The standard is written for on-site assessment by PCI-approved assessors qualified for KMO; some activities such as document review may be done remotely. PCI SSC maintains the standard, the reporting templates and the list of qualified assessors, while the participating payment brands decide who must comply and by when. The standard itself says it does not oblige anyone to buy or deploy a solution and that mandates come from the brands.
The initial focus is the key management covered today by PCI PIN and PCI P2PE. KMO is designed to be called by other standards and programmes (the "referencing standard/program"), which can decide which domains apply, which cryptography is acceptable and how often assessment happens. Appendix B sets those choices for PCI PIN and PCI P2PE.
How KMO relates to the other PCI standards
| Standard | Relationship stated in KMO v1.0 | What it means in practice |
|---|---|---|
| PCI PIN | KMO is intended to duplicate the intent of PCI PIN, so a KMO assessment may be performed instead of a PIN assessment | Confirm with your acquirer or the brand programme which assessment they expect and from when; this guide assumes no retirement date for PCI PIN |
| PCI P2PE | Duplicates the intent of P2PE Domain 5, so KMO may be used in place of Domain 5 | Decryption management and key-injection components can be assessed once under KMO |
| PCI MPoC | Intended to replace the PCI PIN requirements inside MPoC where the product supports PIN, and may cover other MPoC key management such as Attestation and Monitoring | MPoC back ends that handle PIN keys move to KMO. See the PCI Mobile Payments on COTS Guide |
| PCI PTS POI and PCI HSM | PTS secures the devices (SCDs); KMO secures keys during operations such as loading, signing and processing | Use PTS-approved or FIPS-validated devices, then evidence the operations around them under KMO |
| PCI DSS | Independent: a key-management environment may be part of a CDE or entirely separate | If it touches account data, PCI DSS still applies. See the PCI DSS 4.0 Guide |
| Secure Software and Secure SLC | No direct relationship | See the PCI Secure Software Standard and Secure SLC Guide for those |
The six listing service types
KMO supports listing for six service types, currently only for keys used in PIN processing or P2PE.
- Decryption Management (DM): manages the decryption environment for a componentised P2PE solution.
- PIN-Processing Service (PPS): performs PIN operations such as verification or translation and is not the card issuer.
- Key-Injection Facility (KIF): generates, conveys and loads keys for other entities, locally or remotely.
- Signing Service Provider (SSP): signs software or data packages such as firmware, applications and configuration files.
- Certification and Registration Authorities (CA/RA): sign public keys used for remote distribution of symmetric keys with asymmetric techniques; the RA vets certificate requests for the CA.
- HSM-as-a-Service (HaaS): manages an HSM cluster on behalf of tenants, including cloud services.
Structure and key requirements
Every section has a security objective, numbered security requirements, test procedures and guidance. Requirement numbers follow the pattern domain, control objective letter, section and item, for example 1A-5.2 or 4B-2.6.
| Domain | Control objectives and sections | Who it applies to |
|---|---|---|
| 1: Core Requirements | 1A Key-Management Implementation (1A-1 scope to 1A-8 key administration); 1B Secure Key Generation (1B-1); 1C Secure Key Transmission, Conveyance and Loading (1C-1); 1D Key Use and Operations (1D-1 uniqueness, 1D-2 compromise, 1D-3 archival and removal) | All service types; 1A-2 to keys the entity owns; 1A-5 where key components are managed; 1B-1 where keys are generated |
| 2: Remote HSM and HaaS | 2A Remote HSMs (2A-1); 2B HSM-as-a-Service (2B-1 key management, 2B-2 operations, 2B-3 service logs) | 2A to entities using remote HSMs; 2B to HaaS |
| 3: Data and Operation-Specific | 3A PIN, SCD and P2PE back-end requirements; 3B CA/RA and signing; 3C FIPS-validated HSMs; 3D cryptography outside an SCD; 3E optional best practice | By data type and function, for example 3A-1 to PIN processing services, 3B to CA/RA and signing |
| 4: Environmental Security | 4A physical environments (minimally controlled, controlled, controlled-plus, secure, storage and destruction); 4B logical (4B-1 secure networks, 4B-2 authentication controls) | PIN and P2PE implementations, with the environment type set by the key-loading method |
Requirements practitioners ask about first
- Scope and key inventory (1A-1): define the sensitive assets and keys in scope (1A-1.1), the roles and processes (1A-1.2), the in-scope systems (1A-1.3) and the details of every key relied on (1A-1.5). Appendix C gives an example key table. 1A-1.6 and 1A-1.7 require monitoring of algorithm viability and a plan for cryptographic vulnerabilities and cryptoperiod expiry.
- Audit trails (1A-3): audit trails for higher-level key generation (1A-3.6), kept securely for at least two years after the related keys are destroyed (1A-3.10), with enough detail to be auditable (1A-3.12).
- Key forms (1A-8): secret and private keys exist only in the approved key forms (1A-8.1), and cleartext handling has its own controls through 1A-8.10.
- Compromise handling (1D-2): no reloading where compromise is suspected (1D-2.1), inspection before new keys go into a suspect system (1D-2.2), formal key-owner acceptance before redeployment (1D-2.3), documented analysis (1D-2.4), replacement with an uncorrelated key (1D-2.5), replacement of every subordinate or dependent key (1D-2.6), and a notification procedure naming who is told (1D-2.7).
- PIN handling (3A-1): online PINs in an ISO 9564 PIN-block format (3A-1.1); cleartext PINs never outside an SCD approved to PCI PTS or FIPS 140-2/3 Level 3, or a COTS application approved to PCI MPoC (3A-1.4); no translation into ISO 9564 format 1 from another format unless UKPT key management is enforced (3A-1.5).
- HSM tenancy (2B-1): clear responsibility for key ownership and HSM maintenance (2B-1.1), tenant isolation so one tenant's compromised key cannot affect another's (2B-1.3), and a unique provisioning key per tenant for online provisioning (2B-1.7). 2B-3.4 requires logs to show which virtualisation systems and processing elements took part in an action.
Cryptographic minimums for PIN and P2PE
Appendix B sets minimum key sizes for PCI PIN and PCI P2PE: 112-bit TDEA, 2048-bit RSA, 224-bit ECC, 2048/224 for DSA and DH, 128-bit AES, and NIST PQC security level 1. For P2PE, 112-bit TDEA requires a UKPT scheme. Appendix B also lists acceptable key blocks: for TDES the TDKW method from ANSI X9.102 or ANSI X9.143; for AES ISO 20038 or Mechanism 2 of ISO/IEC 19772; for asymmetric transport ASC X9 TR-34, RSA OAEP and ECDH key agreement. Equivalent methods must bind key-usage information to the key and be reviewed by an independent expert whose review is public. Key check values for TDES are capped at the leftmost 24 bits and described as legacy only.
Frequencies
KMO defines its timeframes precisely: daily means every day of the year, quarterly means every 90 to 92 days, annually every 365 days (366 in a leap year) or the same date each year, "immediately" means without delay and "promptly" as soon as reasonably possible. Build schedules to those definitions, not to business calendars.
Identity and NHI requirements
KMO is a key-management standard, but a large share of its controls are identity controls: who may touch key material, how systems authenticate, and how machine access to HSMs is limited.
| Requirement | Identity point | What to evidence |
|---|---|---|
| 1A-5.1 to 1A-5.7 | Key custodians: minimum number consistent with split knowledge, annual training, signed and countersigned role acknowledgement, no custodian able to reconstruct a key | Custodian register, training records, signed forms, component-to-custodian mapping |
| 1A-5.2 | Custodians must be employees or contracted personnel; not a non-human system such as an AI agent | HR or contract link for each custodian; no service account or automation listed as a custodian |
| 1A-7.1 to 1A-7.5 | System authentication: dual control cannot be defeated by one person holding all authentication resources; unique identification of individuals; default codes changed; codes changed on staff change or suspected compromise; authentication keys stored securely | Smart card and PIN allocation records, HSM role configuration, change logs |
| 4B-2.1 to 4B-2.3 | Unique IDs before access; shared or generic IDs only by documented, management-approved exception; inactive accounts removed or disabled within 90 days | Account lists for HSM management hosts and key-management servers, exception register |
| 4B-2.4 | Third-party remote access accounts enabled only when needed and monitored | Vendor access tickets and session logs |
| 4B-2.5, 4B-2.6 | Re-authentication after 15 minutes idle; MFA for all non-console administrative access and access to key-management systems such as HSMs (may be at network segment level) | Session policy, MFA configuration, jump host design |
| 4B-1.4 | Key-management systems not directly reachable from public networks, except over mutually authenticated channels such as mTLS from a POI | Network and data-flow diagrams (4B-1.1, 4B-1.2), firewall rules |
- Automation and AI agents: scripts, orchestration tools and agents may drive HSM APIs, but they cannot hold or combine key components in a custodian role. Treat the credentials they use (API client certificates, HSM partition credentials, cloud HSM tokens) as privileged machine identities with owners and rotation. See the HSM Deployment and Operations Guide.
- Dual control is an identity design problem: 1A-7.1 fails if one administrator can obtain both smart cards or both PINs needed for a key-loading function. Map each HSM role to named people and check that no person, and no automation account, can satisfy the quorum alone.
- Authentication keys are keys: 1A-7.5 brings the keys used for authentication, including signing, into the same storage protection as other keys. Client certificates used by applications to reach HSMs belong in the key table.
Implementation steps
- Confirm the mandate: ask your acquirer, the payment brands or your P2PE or MPoC programme which assessment they expect, PCI PIN or KMO, and the timeline. Read the KMO Program Guide for listing rules.
- Pick your service types: decide whether you are a DM, PPS, KIF, SSP, CA/RA or HaaS, or several. The applicability matrix and worked examples in the standard (local HSM, HaaS for multiple tenants, KIF loading PIN and P2PE keys, signing service, CA/RA) show which sections follow.
- Build the key table: list every key with purpose, algorithm, length, key block format, location, hierarchy parent, cryptoperiod and owner (1A-1.5). Include keys used for authentication and signing.
- Map environments: classify each room and system against the 4A environment types for the loading methods you use (manual loading, cleartext injection, key establishment, remote symmetric or asymmetric loading, generation, derivation, calculation).
- Close identity gaps: rebuild the custodian register, remove shared accounts or record approved exceptions, enforce MFA to HSM management, and review vendor remote access (1A-5, 1A-7, 4B-2).
- Rehearse a compromise: walk through 1D-2 with a tabletop: which keys sit below the suspect key, who must be notified, and how replacement uncorrelated keys are loaded.
- Run a gap assessment: use a KMO-qualified assessor or an internal review against the test procedures. Since there is no customised approach, fix gaps rather than writing alternative controls.
- Plan for change: record the algorithm-monitoring process and migration plan (1A-1.6, 1A-1.7), including TDEA phase-out and readiness for post-quantum algorithms once standardised. See the NIST SP 800-57 and 800-131A Crypto Transition Guide.
Evidence and assessment
KMO assessments are intended to be on site, and test procedures use examination and interview. Assessors sample, and the standard includes guidance for them on sampling. Expect them to observe a key ceremony or review its records.
| Area | Typical evidence | Useful metric |
|---|---|---|
| Key inventory | Key table, hierarchy diagram, cryptoperiod register | Keys in production with no table entry (target zero) |
| Key ceremonies | Scripts, sign-in sheets, tamper-evident bag logs, video where used | Ceremonies with complete dual-control records |
| Custodians | Register, signed acknowledgements, training dates | Custodians overdue for annual training |
| Access | HSM role configuration, MFA settings, account reviews | Inactive accounts older than 90 days; shared IDs without approved exception |
| Logging | HSM and key-management audit trails, HaaS tenant logs | Days of audit trail retained after key destruction (at least two years) |
| Vulnerabilities | Scan results, patch records for systems near HSMs | Critical patches installed within one month (4B-1.7) |
For the ceremony itself, the Cryptographic Key Ceremony Template gives a starting script.
Mapping to other frameworks
| KMO area | NIST SP 800-53 Rev 5 | NIST CSF 2.0 | ISO/IEC 27001:2022 Annex A |
|---|---|---|---|
| Key life cycle (Domain 1) | SC-12, SC-12(1), SC-13 | PR.DS-01 | A.8.24 Use of cryptography |
| Dual control and custodians (1A-5, 1A-7) | AC-5 | PR.AA-05 | A.5.3 Segregation of duties |
| Audit trails (1A-3, 2B-3) | AU-9 | PR.PS-04 | A.8.15 Logging |
| Physical environments (4A) | PE-3 | PR.AA-06 | A.7.1 to A.7.4 |
| Administrative MFA (4B-2.6) | IA-2(1) | PR.AA-03 | A.8.5 Secure authentication |
| HaaS and remote HSMs (Domain 2) | SA-9, SR-6 | GV.SC-07 | A.5.23 Cloud services |
The deeper guidance on key life cycles sits in NIST SP 800-57 Part 1. See the Cryptographic Key Management Guide.
Common pitfalls
- Treating KMO as a renamed PIN audit: the domain structure, HaaS requirements and environment model are new. Re-map controls rather than relabelling an old PIN report.
- Automation in a custodian role: a script that holds or combines components, or a shared operator account used during ceremonies, conflicts with 1A-5.2 and 1A-7.2.
- Incomplete key tables: authentication, signing and transport keys are left out because they do not protect PINs directly, though 1A-1.5 covers every key relied on for security services.
- Replacing only the compromised key: 1D-2.6 requires every subordinate or dependent key to be replaced too, and 1D-2.5 forbids a replacement correlated with the old one, for example a variant.
- Assuming the cloud provider covers it: HaaS tenants still need defined key ownership (2B-1.1) and access to their own logs (2B-3.2). Read the provider's KMO listing and scope. See the Shared Responsibility Models Guide.
- Expecting a customised approach: KMO allows none. Entity-defined frequencies need a documented risk assessment behind them.
Practitioner checklist
- Confirm with your acquirer or brand programme whether KMO or PCI PIN applies and when.
- Decide your KMO service types and record the applicable domains and sections.
- Complete a key table covering every key, including authentication and signing keys.
- Check every custodian is an employee or contractor, trained in the last 12 months and has a countersigned acknowledgement.
- Prove no single person or automation account can satisfy a dual-control quorum.
- Enforce MFA for non-console administrative access to HSMs and key-management systems.
- Remove or disable accounts inactive for 90 days and record any shared ID exceptions.
- Keep audit trails for at least two years after the related keys are destroyed.
- Exercise the key-compromise procedure, including subordinate keys and notifications.
- Document your algorithm-monitoring process and migration plan for TDEA and future algorithms.
Standards and references
- PCI SSC: Key Management and Operations (KMO) Requirements and Test Procedures v1.0
- PCI SSC: Request for Comments on the PCI KMO v1.0 Standard
- PCI SSC: PCI DSS v4.0.1 Requirements and Testing Procedures
- NIST: SP 800-57 Part 1 Rev. 5, Recommendation for Key Management
- NIST: SP 800-53 Rev. 5, Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: PCI DSS 4.0 Guide · HSM Deployment and Operations Guide · Cryptographic Key Management Guide · PCI Mobile Payments on COTS Guide · Cryptographic Key Ceremony Template. This guide summarises the PCI KMO standard and is not legal advice.