The Payment Card Industry (PCI) Security Standards Council (PCI SSC) has added the PCI Key Management Operations (PCI KMO) standard to its portfolio, focused on the security of cryptographic key management operations. The standard defines security requirements, test procedures, and guidance for entities involved in the operation and management of systems that use cryptographic keys to secure account data. Its purpose is to serve as a common reference for the on-site assessment of key management implementations, allowing different PCI SSC standards and programs to rely on a single set of requirements whenever they need to evaluate this area. Although some aspects of the standard can be performed remotely (such as document reviews), it is generally designed for on-site assessments of key management implementations.
Unlike a standalone standard, PCI KMO was created as a cross-functional component of the PCI ecosystem: it consolidates into a single document the key management requirements that were previously dispersed across other standards, and does so through an objective-based approach that provides flexibility for entities to achieve security goals according to their own implementation.
Scope of the Standard
The scope of PCI KMO is defined by two complementary dimensions: the key lifecycle and the elements surrounding it. PCI KMO requirements cover the complete lifecycle of a cryptographic key, from its generation to its destruction, as well as the security of the procedures, systems, and equipment used to manage and operate those keys throughout their lifecycle.With regard to its scope within the PCI portfolio, the standard has a deliberately limited starting point that will expand over time. PCI KMO is intended to address the generic key management requirements of various PCI SSC standards and programs, and its initial focus is to cover the key management requirements contemplated by the PCI PIN (Personal Identification Number) and PCI P2PE (Point-to-Point Encryption) standards.
A central aspect of the design is that PCI KMO does not operate autonomously, but rather in service of a “referencing standard/program.” The applicability of each domain and its sub-requirements, the frequency with which an assessment is performed, and certain specific terms used within the standard may be defined by the referencing standard or program. This means that the specific scope of an assessment, including which keys, which systems, and which acceptable cryptography are covered, is determined by the program that invokes PCI KMO, while the requirements to be assessed reside within PCI KMO itself.
For use with PCI PIN and PCI P2PE, version 1.0 of the standard also includes Appendix B (“Scope and Defined Terms for Specific Programs”), which establishes the scope and specific terms applicable to those two programs, including minimum key sizes, acceptable key blocks, and acceptable KCV (Key Check Value) methods.
Acceptable Methods for Generating or Loading Keys
The standard explicitly contemplates the set of methods by which a cryptographic key may be installed in a system. These methods are as follows:Manual key loading — two or more custodians enter full-length key components or key shares through a process that enforces dual control and split knowledge.
Clear-text key injection — a key, normally an initial key, is transferred from one system to another in clear text. This method is not permitted for certain implementations and programs.
Key establishment/negotiation — a cryptographic protocol is used to create a shared key between two systems without sharing sensitive values that an intermediary could use to derive the value of that key.
Remote key loading (symmetric) — a key is transferred between two systems encrypted under a pre-shared symmetric key.
Remote key loading (asymmetric) — a key is transferred between two systems protected through asymmetric cryptography.
Key generation — a key is generated through a random or pseudo-random process.
Key derivation — a key is generated through a non-reversible process, such as a one-way cryptographic function.
Key calculation — a key is generated through a reversible process, such as the use of variants.
Applicable Service Types and Components
PCI KMO supports the listing of different service types, which represent the services that an entity may provide or perform within the context of key management. In version 1.0 of the published standard, six service types are defined, and these types currently apply only to keys used in PIN processing or P2PE implementations; over time, additional component and key types may be added. The service types defined by the standard are:Decryption Management (DM) — an entity that manages the decryption environment that may support a componentized P2PE solution.
PIN-Processing Service (PPS) — an entity that performs PIN operations (such as verification and/or translation) and is not the card issuer.
Key-Injection Facility (KIF) — an entity that provides cryptographic key services for other entities or KMO service types, including, but not limited to, the generation, transport, and/or (local) loading of keys. A KIF may include both local and remote key-loading functions.
Signing Service Provider (SSP) — an entity that provides software or data package signing services, such as firmware, applications, or configuration files, for other entities or KMO services.
Certification/Registration Authorities (CA/RA) — an entity that provides signing services for public keys, such as X.509 certificates or others, for use in the remote distribution of symmetric keys through asymmetric techniques; an RA performs registration services on behalf of a CA to validate certificate requests that the CA will issue.
HSM-as-a-Service (HaaS) — an entity that manages a cluster of HSMs (Hardware Security Modules).
The distinction between key generation, transport, and loading services is maintained at the level of the P2PE components supported by a listed KMO service (that is, one published in the PCI SSC listings): a KIF may map to a P2PE KIF component (if it provides key generation and loading services), to a P2PE KLCP (if it provides loading services only), or to a P2PE KMCP (if it provides generation services only); a DM maps to a P2PE DMS, and a CA/RA maps to a P2PE CA/RA. The PPS and HaaS types do not map to any P2PE component type.
Relationship with Other PCI Standards
PCI KMO is designed to integrate with the rest of the PCI portfolio without replacing it. Each standard or program that references PCI KMO may individually define which sets of requirements apply, as well as the acceptable systems and cryptography within the scope of the assessment. The standard is explicit in stating that it does not replace other standards: it does not supersede the requirements of any other PCI standard, nor does it constitute a recommendation from the Council or require merchants, service providers, or financial institutions to acquire or deploy such solutions.The relationships with the various standards can be grouped into three categories according to their nature.
Standards Whose Assessment May Be Replaced by PCI KMO. In these cases, PCI KMO is intended to duplicate the intent of the requirements of the other standard, so that an assessment against PCI KMO can be performed instead of the original assessment:
PCI PIN — an assessment against the requirements of PCI KMO may be performed instead of an assessment against the requirements of PCI PIN. However, in practice, it is each payment brand that determines which type of assessment must be performed and whether it is possible to replace a PCI PIN assessment with a PCI KMO assessment.
PCI P2PE — PCI KMO duplicates the intent of the requirements of Domain 5 of PCI P2PE, so it may be assessed instead of the requirements contained within that domain.
PCI MPoC (Mobile Payments on COTS) — PCI KMO may serve as a replacement for the assessment against PCI PIN requirements currently required by the PCI MPoC standard when the MPoC product provides PIN support, and it may also be suitable for replacing other PCI MPoC key management requirements, including those used for Attestation and Monitoring (A&M) operations in an xPoC implementation (a generic term used for payment solutions on COTS devices, such as MPoC, SPoC, or CPoC).
Standards with an Independent or Complementary Relationship
PCI DSS (Payment Card Industry Data Security Standard) — there is an independent relationship between the two standards. A key management environment may be part of a Cardholder Data Environment (CDE) or may be completely separate from any CDE, and if it stores, processes, or transmits account data, it is subject to PCI DSS according to the compliance programs of the payment brands. PCI KMO is not currently intended to replace the key management requirements that are part of PCI DSS.
PCI PTS POI (PIN Transaction Security, Point of Interaction) — the relationship is one of functional complementarity. PCI KMO provides detailed requirements on how cryptographic keys are secured during operations such as key loading and cryptographic signing and processing activities, while the PCI PTS standards (PCI PTS POI and PCI HSM) provide requirements on how tamper-resistant payment systems are secured in the form of Secure Cryptographic Devices (SCDs). The key management aspects specific to PCI PTS POI device deployments are covered by the PCI PIN and PCI P2PE programs, according to the relationship described above for each of them.
Standards with No Direct Relationship. The PCI KMO standard has no direct relationship with the PCI Secure Software and PCI Secure SLC (Secure Software Lifecycle) standards.
Objective-Oriented Approach
One of the distinguishing features of PCI KMO is that its requirements are objective-oriented. For an objective-oriented approach to be successful, entities are expected to maintain a robust risk management practice as an integral part of their regular operations. This approach gives entities flexibility to implement security controls based on identified risks, but the entity must be able to demonstrate how the implemented controls are supported by the results of its risk identification and management practices.This orientation is reflected in the way each requirement is presented. The structure consists of four elements: the Security Objective, which identifies the high-level security objective that the entity must achieve and is stated broadly to provide flexibility regarding the methods used to achieve it; the Security Requirements, which are the specific security controls or activities that must be implemented to support the objective; the Test Procedures, which describe the assessment activities that assessors must perform to validate whether the entity meets a requirement; and the Guidance, which provides additional information to help entities and assessors understand the intent of each requirement and may include best practices and examples without replacing or extending the requirements to which it refers.
It is important to highlight an important nuance regarding the scope of this flexibility: although test procedures are generally written at a high level to allow flexibility in assessments, the PCI KMO standard does not permit a risk-based approach to the assessment itself, and the requirements must be evaluated exactly as they are written.
Domains of the Standard and Their Objectives
The standard is organized into four domains that address different aspects of cryptographic key security and management.
Domain 1 — Core Requirements
This is the central domain of the standard. Domain 1 is the “core” domain, addressing the key lifecycle from generation through destruction, and it is also used to define the scope of any specific PCI KMO assessment, including all keys and systems involved. Its requirements apply to all key management operations implementations that may fall within the scope of the referencing standard or program. It is composed of four control objectives:1A — Key Management Implementation.
Objective: the scope and cryptographic systems governed by these requirements are clearly, accurately, and completely defined.
1B — Secure Key Generation.
Objective: cryptographic keys and the associated key management used to secure sensitive assets are created through secure processes that ensure the key is sufficiently random and possesses adequate strength for the operations it performs.
1C — Secure Key Transmission, Transport, and Loading.
Objective: keys are secured whenever they are transported, transmitted, or loaded.
1D — Key Usage and Operation.
Objective: keys are used in a manner that prevents or detects their unauthorized use.
Within this domain, control objective 1A also covers the lifecycle of cryptographic devices within scope (including SCDs), not only that of keys. Systems within scope are secured and validated prior to use, confirming that they have not been modified, substituted, tampered with, or improperly used before deployment. They are managed securely during operation through secure configuration, removal of default values, and connection to networks that meet logical security requirements. At the end of their deployment lifecycle, or when returned for repair, they are secured through the irreversible deletion of all keys and secret or private key material, as well as protection against tampering if they are to be redeployed. For POI devices and HSMs, this validation that they have not been tampered with requires returning them to their supplier. These requirements do not apply to transaction-originating COTS (Commercial Off-The-Shelf) devices that are part of a validated xPoC implementation.
Domain 2 — Remote HSM and HSM-as-a-Service Requirements
This domain covers the use of remote HSMs, in alignment with the recently published PCI HSM v5 standard. It applies both to HSMs managed and operated remotely by a single entity for its own purposes (Control Objective 2A) and to HSM-as-a-Service (HaaS) providers that deliver the service to one or more HSM tenants (Control Objective 2B), including cases where the service is provided to a single tenant.The exclusion for tenant keys that a HaaS provider handles in an encrypted key block outside an SCD, without the ability to decrypt or operate on them, is maintained.
It contains two control objectives:
2A — Remote HSMs.
Objective: HSMs are managed securely over out-of-scope networks.
2B — HSM-as-a-Service (HaaS).
Objective: HSM services are operated securely.
Domain 3 — Data- and Operation-Specific Requirements
This domain covers requirements specific to different types of sensitive assets and systems within scope, such as requirements for systems that secure PIN data and/or are required to use SCDs. It also includes specific requirements for CA/RA and signing operations, HSMs, cryptographic operations performed outside an SCD, and an optional best-practice section that is not mandatory for compliance in this version but may become mandatory in future revisions of the standard.Where requirements in this domain conflict with those in Domain 1, the requirements of this domain take precedence.
It includes five control objectives:
3A — Data-Specific Security Requirements.
Objective: data requiring specific controls is processed securely in accordance with industry standards.
3B — CA/RA and Signing Requirements.
Objective: CA/RA and signing operations are performed securely in accordance with industry standards.
3C — HSM-Specific Security Requirements.
Objective: HSMs are deployed and operated securely.
3D — Cryptographic Operations Outside an SCD.
Objective: cryptography performed outside an SCD is executed securely. This applies only when the referencing standard or program permits the exposure of operational cryptographic keys in clear text within backend systems outside an SCD.
3E — Best Practice Requirements (Optional).
Objective: industry best practices are implemented to secure sensitive assets. Their assessment and reporting are optional; they are not required to achieve full validation of a PCI KMO assessment in this version, although some of these requirements may become mandatory in future versions of the standard.
Domain 4 — Environment Security Requirements
The physical and logical security of an environment is an important part of the overall security architecture. This domain provides different levels of physical security that may be applied as required by a specific KMO requirement or by the referencing standard or program.Control objective 4A is structured into five cumulative levels (each higher level must also comply with the requirements of the lower levels), aligned where possible with ISO 13491-2 (2023).
Its two control objectives are:
4A — Physical Environment Requirements.
It is structured into five cumulative levels: minimally controlled environments (4A-1), controlled environments (4A-2), controlled-plus environments (4A-3), secure environments (4A-4), and secure storage and destruction (4A-5).
Note: the published objective for 4A literally reuses the wording of objective 3A (“data requiring specific controls”), with the addition of “physical”; this is the text currently in force in version 1.0 of the standard.
4B — Logical Environment Requirements.
Objective: logical environments (network, authentication methods, etc.) that may impact the security of sensitive assets are secured. Its requirements are structured to align, where possible, with those of PCI DSS. Implementations that have undergone a PCI DSS assessment within the previous year may reuse content and evidence from that assessment, although the assessor must confirm that the scope of the PCI DSS assessment covers at least the entire scope of the PCI KMO assessment.
The KMO Program
Alongside the standard, PCI SSC published the PCI KMO Program Guide, which defines the certification process and program roles. Notable aspects include the following:Three-year lifecycle. A KMO listing remains valid for 36 months: initial acceptance, annual attestation in Year 1, annual attestation in Year 2, and a full reassessment at the end of the third year.
Publication in listings. As with other PCI standards, validated KMO services are published in the PCI SSC validated KMO services list. Appendix B of the Program Guide (“Elements for the List of Validated KMO Services” - different from Appendix B of the standard itself, mentioned in the “Scope of the Standard” section) details the information published for each listing: provider name, location, KMO service type, supported KIF functions, supported cryptography, assessor company, and attestation/reassessment dates.
Assessment and listing on a per-service basis. Although a single assessment may cover multiple KMO services, each must be reported in an independent ROV. Only KMO services validated by a KMO assessor company and individually accepted by PCI SSC are listed separately. The ROV for each KMO service must be submitted separately through the portal, and submissions grouping multiple KMO service types are not accepted.
Change management. Changes that impact the security of a listed KMO service (Delta Changes) follow their own assessment and acceptance process, separate from the full reassessment performed every three years.
Technical FAQs. PCI SSC publishes technical FAQs for the KMO standard that become mandatory once published and must be considered during every assessment.
A single assessor for any assessment. The program is designed so that a single KMO assessor can perform any type of assessment under the standard. However, the KMO Assessor Qualification Requirements have not yet been published.
No connection with the PCI PIN program. There is no connection between the PCI PIN and PCI KMO compliance programs. For details regarding each compliance program, entities must refer to the corresponding CAE (Compliance Acceptance Entity) or payment brand.
Alignment with PCI HSM v5. The standard was created in alignment with the recently published PCI HSM v5 requirements, which largely explains the expansion of Domain 2 to cover remote HSMs.
Future scope. PCI SSC has indicated that future revisions of PCI KMO may address specific needs related to other data types, such as those covered by the PCI Card Production Standards.
PCI KMO represents a step toward consolidating cryptographic key management requirements into a single reference framework that spans multiple PCI SSC programs. Its objective-oriented approach, its organization into four domains, and its ability to replace the assessment of standards such as PCI PIN and PCI P2PE position it as a framework that simplifies the evaluation of key cryptography without altering the compliance obligations established by each payment brand.
For entities providing cryptographic services, from KIFs and key distribution providers to HSM-as-a-Service operators, as well as for assessors, understanding its structure and its relationships with the rest of the PCI ecosystem will be essential for successfully approaching assessments under this new framework.
References
🔗PCI Security Standards Council. (2026). PCI Key Management and Operations (KMO) Security
Requirements and Testing Procedures, Version 1.0. PCI SSC.
🔗PCI Security Standards Council. (2023). PCI PIN Security Requirements and Testing
Procedures, Version 3.1. PCI SSC.
🔗PCI Security Standards Council. (2018). PCI Point-to-Point Encryption (P2PE) Standard, Version
3.0. PCI SSC.
🔗PCI Security Standards Council. (2024). PCI Data Security Standard (PCI DSS), Version 4.0.1.
PCI SSC.
🔗PCI Security Standards Council. (2023). PCI PIN Program Guide, Version 3.1. PCI SSC.
🔗PCI Security Standards Council. (2026). P2PE Program Guide, Version 3.2. PCI SSC.
🔗 PCI Security Standards Council. (2024). PCI DSS Program Guide, Version 4.0. PCI SSC.
