Overview
Between November 24 and January 9, the PCI Security Standards Council opened its second request for comments on the PCI Key Management Operations v1.0 Standard. This draft consolidates cryptographic key management requirements across multiple PCI standards, specifically targeting operations that secure PINs, account data, and the keys themselves.
This isn't a new standard from nowhere. It's the second iteration. The Council incorporated feedback from the first RFC, restructuring the requirements, rewriting environmental security sections, and revising the relationship between requirements and guidance.
The scope is broader than you might expect: any cryptographic key used to protect account data, including Data Encryption Keys, Key Encryption Keys, and derivation keys used in PCI PIN and PCI P2PE Domain 5 environments.
Timeline
First RFC: Initial draft released; stakeholders identified gaps in requirement verifiability and questioned whether environmental security controls were detailed enough.
Post-first RFC: Council restructured requirement organization and rewrote environmental security sections based on stakeholder input.
November 24: Second RFC period opens via PCI SSC Portal. Eligible stakeholders receive email instructions and must accept an NDA to download the draft.
January 9: RFC period closes. Only comments submitted through the Portal within this window will be considered.
Post-RFC: Council will incorporate feedback and move toward final publication (timeline not specified).
Identifying Gaps in Key Management
This isn't a breach analysis but a look at process failures revealing structural gaps in cryptographic operations management.
Fragmented key management requirements. Before PCI KMO, key management controls were scattered across PCI PIN, PCI P2PE, and PCI DSS. Each standard addressed keys within its own context, but none provided a unified framework. If you managed a Hardware Security Module (HSM) cluster supporting both P2PE merchant environments and PIN processing for ATM networks, you were implementing requirements from multiple documents that didn't align on testing procedures or environmental controls.
Lack of a standard-agnostic key lifecycle framework. PCI DSS Requirement 3.6 mandates cryptographic key management processes, but it's aimed at general cardholder data protection, not specialized key operations like those in PCI PIN or P2PE Domain 5. Teams managing dedicated key infrastructure had no single operational standard to follow.
Unclear boundaries between key types. The industry uses Data Encryption Keys to encrypt account data, Key Encryption Keys to protect those DEKs, and derivation keys to generate session keys. But operational requirements for each weren't consistently defined across standards. PCI KMO explicitly includes "keys used to secure PINs, account data, and other sensitive assets."
Insufficient environmental security detail. The Council's restructuring between the first and second RFC indicates stakeholders found the original environmental security requirements vague or narrow. The revised draft addresses this, but the need for a full rewrite signals that the first version didn't adequately cover physical and logical controls for key management facilities.
What the Standards Require
PCI DSS 4.0 Requirement 3.6 establishes baseline cryptographic key management: documented procedures for key generation, distribution, storage, destruction, and periodic key changes. It requires split knowledge and dual control for manual clear-text key operations, and mandates that keys exist in no more than one form at a time.
PCI PIN Security Requirements govern PIN encryption keys, including key loading, key custodian procedures, and HSM operational controls. These requirements assume a PIN-specific context.
PCI P2PE Domain 5 (Key Management) defines how encryption keys are managed within Point-to-Point Encryption solutions, including key injection, key custodian responsibilities, and cryptographic device management.
FIPS 140-3 sets cryptographic module validation requirements that underpin all these standards. Any HSM or cryptographic device used must meet FIPS 140-3 Level 2 or 3, depending on the use case.
PCI KMO consolidates these into a single operational framework. Instead of cross-referencing three standards to manage a KEK that protects both P2PE merchant keys and PIN encryption keys, you'll have one set of security and test requirements.
Action Items for Your Team
Map your current key management operations. Before PCI KMO v1.0 publishes, document which keys you manage, which standards govern them, and where operational gaps exist. If you're running HSMs that support both PCI PIN and PCI P2PE workloads, you're already managing keys across multiple requirement sets. Identify where those requirements conflict or leave questions unanswered.
Review your environmental security controls. The Council rewrote this section because stakeholders found it insufficient. Examine your key management facility's physical and logical access controls and monitoring. Do you have RBAC implemented for HSM administrative functions? Are key custodian activities logged and reviewed? Can you demonstrate least privilege for personnel interacting with KEKs?
Assess your key lifecycle documentation. PCI KMO will demand verifiable key management processes. Your current documentation might satisfy PCI DSS 3.6, but can a QSA verify your key generation entropy sources, key destruction procedures, and key rotation schedules across all key types? If your documentation is standard-specific rather than operation-specific, consolidate it.
Test your split knowledge and dual control implementations. If you're using manual key loading procedures, verify that you're enforcing split knowledge, no single custodian can reconstruct a clear-text key. Test your dual control procedures: are two authorized individuals required for all sensitive key operations, and is that requirement technically enforced?
Prepare for requirement verifiability questions. The Council is asking whether requirements are "sufficiently verifiable." QSAs will need clear evidence, not interpretive documentation. If your current key management procedures rely on narrative descriptions rather than technical logs, audit trails, and system-enforced controls, start building that evidence base now.
Participate in the RFC if eligible. If you're a PCI SSC stakeholder, download the draft and submit specific feedback. The Council restructured the standard once based on input, your operational experience can shape the final version. Focus your comments on verifiability gaps and operational feasibility.
The PCI KMO v1.0 Standard won't create new key management obligations, you're already managing these keys under existing standards. But it will create a unified operational framework and eliminate gaps when managing keys across multiple PCI contexts. The question isn't whether you'll comply; it's whether you'll use this RFC period to influence how those requirements are structured.
