What is PCI KMO? Taking a Closer Look

Key management requirements have historically been distributed across multiple PCI standards and programs. PCI PIN and PCI P2PE have each carried their own key management sections, and organizations running both programs have had to satisfy overlapping requirements for the same underlying keys. That fragmentation is not just an audit inconvenience. A poorly managed key, whether it is exposed during conveyance, reused past its intended lifespan, or destroyed without a verifiable record, is one of the more direct paths to a PIN or cardholder data compromise, which is exactly why the industry has pushed for a unified approach.

On September 14, 2026, the PCI Security Standards Council published PCI Key Management and Operations (PCI KMO), a new standard designed to bring those requirements under one common framework. Here is what governance leaders and security teams need to know about it.

What Is PCI KMO?

PCI KMO, short for Key Management and Operations, is a standard published by the PCI Security Standards Council (PCI SSC) for the secure management and operation of systems that use cryptographic keys. Version 1.0, released September 14, 2026, covers the cryptographic key lifecycle from generation through destruction, with its initial focus on key management requirements for PIN and P2PE data.

PCI KMO creates a common framework for key management requirements rather than replacing the programs that reference it. PCI SSC describes it as intended to address the generic key management requirements shared across other PCI standards and programs, consolidating, aligning, and updating what PIN and P2PE previously specified separately. In its v1.0 announcement, PCI SSC states that future revisions of PCI KMO may address additional data types, such as those covered by the PCI Card Production standards, though no timeline for that expansion has been published.

What Does PCI KMO Cover?

PCI KMO covers the entire cryptographic key lifecycle, along with the security of the procedures, systems, and equipment used to manage and operate keys throughout that lifecycle. The scope includes keys used to secure PINs, account data, and other sensitive assets, along with keys that exist to protect other keys, such as storage, transport, and derivation keys.

This lifecycle view gives security teams a single map of every stage where a key could be exposed, mishandled, or improperly destroyed, instead of tracking that map separately for PIN and for P2PE.

Who Is PCI KMO Intended For?

PCI KMO is intended for entities involved in the operation and management of systems that use cryptographic keys tied to PIN or P2PE data. Potentially relevant entities include processors, acquirers, PCI PIN-scoped key injection facilities, and providers operating key management or HSM services, depending on the specific functions they perform and the applicable PCI program requirements. Key injection facilities and remote key injection environments may therefore be relevant to KMO scope where they perform applicable key management functions. The specific controls a KIF or RKI environment must demonstrate should be confirmed against the KMO Requirements and Test Procedures rather than assumed. Organizations that do not perform relevant PIN or P2PE key management functions may have limited or no direct KMO applicability, depending on their role and the requirements of the applicable PCI program.

Whether an entity is required to comply with or validate against PCI KMO is decided by the organization that manages the relevant compliance program, such as a payment brand or acquirer, not by PCI SSC directly. Organizations already validating against PCI PIN or PCI P2PE should evaluate how PCI KMO v1.0 affects their future assessment strategy rather than assume an immediate change in obligation. PCI SSC has not yet published detailed transition or grandfathering guidance for existing PIN and P2PE key management validations. Organizations should confirm the treatment of their existing validations with the applicable payment brand, acquirer, or other entity responsible for their compliance program, rather than assume a default outcome, and monitor PCI SSC announcements as the KMO assessor ecosystem matures.

How Does PCI KMO Relate to PCI PIN, PCI P2PE, and PCI PTS HSM?

PCI KMO does not replace PCI DSS, PCI PIN, PCI P2PE, or PCI PTS HSM. It is a standalone standard that those programs can reference for key management requirements, while each program continues to govern its own broader scope.

PCI KMO is built to support what PCI SSC calls an assess-once, use-many approach. A single KMO assessment is intended to validate key management controls that support both PIN and P2PE key types, and the resulting KMO listing can be referenced by a PCI P2PE implementation where appropriate. The model is designed to reduce duplicated assessment effort where the same key management controls currently support more than one PCI program, which may reduce evidence-management burden where the same controls support multiple PCI programs. This is worth tracking for risk and third-party management teams, since it could change how often the same evidence needs to be produced for different reviewers.

Assessment scope, duration, and cost will depend on the organization’s applicable KMO scope, key types, environments, service providers, and assessment requirements.

How Does PCI KMO Address Cloud and Remote HSMs?

PCI KMO explicitly addresses cloud-based and remote hardware security module deployments, including HSM-as-a-Service models. It was developed in alignment with the PCI PIN Transaction Security (PTS) Hardware Security Module (HSM) Modular Security Requirements v5.0, commonly shortened to PCI HSM v5.0, which PCI SSC published on May 18, 2026, and which added cloud, multi-tenant, and remote-administration modules to HSM device requirements.

The distinction matters. PCI PTS HSM v5.0 evaluates the security of the HSM device and its deployment model. PCI KMO addresses the operational management and lifecycle of cryptographic keys, including when those operations involve on-premises, cloud-based, or remote HSM environments. In a cloud or remote HSM deployment, responsibility for the physical HSM, infrastructure, key ceremonies, custodians, access controls, and lifecycle operations may be distributed between the provider and customer. Organizations should document that responsibility explicitly and verify it against the provider’s contract, attestation documentation, and applicable PCI requirements, rather than assume a default split. Teams evaluating their broader cloud security posture should treat this as part of the same conversation, since key custody is often the least understood part of a multi-cloud payment environment.

What Are the Core Concepts Inside PCI KMO v1.0?

PCI KMO organizes its requirements around the operational controls that apply at each stage of a key’s life. Based on PCI SSC’s own description of the standard’s scope, this includes controls over key generation, secure conveyance and loading, restrictions on what a key can be used for, scheduled rotation and retirement, and verifiable destruction at end of life. It also includes data specific requirements where a particular key type, such as a PIN key or a P2PE key, needs additional controls beyond the generic baseline.

A few terms are worth defining before reading the standard itself, since they come up throughout PCI key management generally:

• Dual control: requires at least two authorized individuals to jointly perform a sensitive key management action, so no single person can complete it alone.
• Split knowledge: divides a cryptographic key or key component so that no single person holds complete knowledge of the key value.
• Key custodian: refers to the individual formally assigned responsibility for a key component, with clear separation of duties from other custodians of the same key.
• HSM-as-a-Service: describes a model where an organization consumes hardware security module capacity from a provider rather than owning the physical device.
• Key block: such as those specified by ANSI X9.24 / TR-31 or its formal successor, ANSI X9.143, is a mechanism used in payment key management to bind a key to its permitted usage. Organizations should confirm the applicability of any specific key block standard against PCI KMO’s actual requirements and their own implementation.

This article describes these as general key management concepts reflected in PCI SSC’s published scope, not as a clause by clause breakdown of the requirements document. Organizations should confirm specific control language against the published PCI KMO Requirements and Test Procedures before building an assessment plan, since inferred detail should never carry the same weight as a cited control number.

Lifecycle-based key management controls, of the kind PCI KMO organizes its requirements around, are generally understood in the industry to address a recognizable set of threats: substitution of an authorized key with an attacker-controlled one, misuse of a key for a function it was not intended for, single-person compromise of a key management process, and exposure of key material through poorly controlled handling or storage. This framing is offered as general context for why lifecycle controls matter, not as a description of specific attack scenarios PCI KMO documents or tests against, since that level of detail sits in the requirements document itself.

PCI KMO also sits alongside, rather than replaces, several non-PCI key management references that many payment organizations already use, including NIST SP 800-57 (Recommendation for Key Management), ISO/IEC 11568 (Financial services key management), and ANSI X9.24 / TR-31 (the key block standard underlying key-usage restrictions). Organizations with existing key management programs based on these references can use their existing lifecycle practices as a starting point for reviewing the KMO requirements, but should validate the specific mapping against the KMO Requirements and Test Procedures. Mapping PCI KMO’s specific lifecycle stages to control numbers in frameworks such as ISO 27001 or NIST SP 800-53 is possible in principle, but should be done against the primary KMO requirements text directly rather than assumed, since PCI SSC has not published that crosswalk itself.

What Evidence Should Organizations Prepare for PCI KMO?

Organizations preparing for a future PCI KMO assessment should expect to produce documentation across the full key lifecycle, not just point-in-time configuration snapshots. Based on the lifecycle scope PCI SSC has published, useful evidence to have on hand includes:

• Key inventory covering every PIN, P2PE, and supporting key type.
• Key lifecycle documentation and policies.
• Key generation records.
• Key ceremony records.
• Key custodian assignments and separation-of-duties documentation.
• Access control records for systems and personnel with key access.
• HSM configuration evidence, including cloud or remote HSM setups.
• Rotation and retirement records.
• Key destruction evidence.
• Third-party and service provider documentation, including HSM-as-a-Service agreements.
• Written key management policies and procedures.

This list reflects the general categories of evidence common to key management assessments rather than a confirmed KMO evidentiary checklist. Organizations should verify exact evidence expectations once the KMO Requirements and Test Procedures document is reviewed directly, or once a Qualified KMO Assessor engagement begins.

How Should CISOs Prepare for PCI KMO?

CISOs can start preparing before the assessor ecosystem is fully in place:

1. Confirm applicability: Check with your payment brand or acquirer to determine whether PCI KMO applies to your organization and identify your current key custodians and documented key management policies.
2. Build a complete key inventory: Catalog every PIN key, P2PE key, key encryption key, derivation key, and HSM or cloud/remote HSM service involved in your environment.
3. Map controls against the lifecycle: Compare existing controls to each KMO lifecycle stage: generation, conveyance, loading, use, archive, retirement, and destruction. Pay particular attention to rotation, retirement, and destruction records, since these lifecycle stages should be supported by demonstrable evidence.
4. Review third-party and vendor agreements: Confirm shared responsibility documentation with every HSM provider, cloud provider, key injection provider, and P2PE provider involved in your key operations, and consider adding KMO readiness as a criterion in future HSM or key management RFPs.
5. Confirm evidence readiness: Make sure you can produce key ceremony records, inventory logs, rotation and destruction records, access logs, and HSM configuration evidence on request.

Governance leaders who need a structured way to run this exercise often bring in dedicated advisory support, such as vCISO guidance, to translate the new standard into a prioritized plan rather than treating it as another audit checkbox.

About Ampcus Cyber’s PCI Practice: Ampcus Cyber’s PCI Qualified Security Assessors and PIN specialists support processors, acquirers, and key management providers through PCI DSS, PCI PIN, PCI P2PE, and emerging standards like PCI KMO, from initial gap assessment through certification.

People Also Ask

Enjoyed reading this blog? Stay updated with our latest exclusive content by following us on Twitter and LinkedIn.