Top Key Management Failures We See in PCI Assessments

If you walk through the control objectives of PCI PIN and PCI P2PE cryptographic key management looks straightforward. The principles of Key Management are clear and well defined: split knowledge, dual control, secure key management using SCDs, approved key forms and key strengths, none of this is new. In fact, most of these concepts have been around for decades and, as we’ve shared on our blog about the Evolution of Cryptographic Key Management originated during the rapid expansion of electronic banking and payment networks in the 1970s and 1980s.

In theory everything seems to be clear, but when you step into the real environments, things start to look very different. In this post we will analyse common mistakes and key management failures found based on our assessment observations and provide practical recommendations on how organisations can strengthen their key management practices to avoid those issues.

Where Things Start to Break

First of all, no one is intentionally ignoring the key management practices. At the beginning, organisations design the processes correctly and do the right things following PCI guidelines. But over time, small gaps start to appear. A shortcut here, an exception there and a process that worked well slowly become not aligned with the Standards. What’s interesting is that this usually isn’t a knowledge problem. Most organisations we work with perfectly understand what split knowledge and dual control is supposed to look like and of course they are familiar with proper key ceremonies structures, or key lifecycle requirements.

Here we come to our first main observation. The real reason of the most key management issues is not a lack of understanding the secure principles or requirements, it is making those principles work consistently in a complex and constantly changing environments. Let’s review common key management failures we are seeing during PCI assessments and what organisations should do to avoid those issues.

Failure 1: No Clear Ownership of Cryptographic Keys

Core Risk:

If no one clearly owns the key lifecycle process, key management becomes inconsistent and critical actions, like key rotation or revocation may never happen. Many times, we’ve seen when different teams within the organisation have fragmented key management ownership and have the responsibility in only a specific part of the key lifecycle. One team generates keys, another is responsible to load those keys into the payment application or device, a third operates the HSM, but no one oversees the full keys lifecycle. In practice, this often leads to situations where:

• Keys are never rotated because each team assumes someone else is responsible
• Expired or deprecated keys remain active in production systems for a long time
• During incidents, no one can quickly identify who owns or can revoke a compromised key.

What to Do Instead:

• Define clear ownership for the key management in the organisation at both operational and governance levels
• Assign an accountable role for the full lifecycle. For example, a Cryptographic Key Manager that is accountable for all phases and requirements related to keys generation, usage, rotation, and destruction, and ensures responsibilities are formally documented and understood across teams that use those keys.

Failure 2: Incomplete or Non-Existent Key Inventory

Core Risk:

You cannot protect what you don’t know exists. Missing key inventory leads to unmanaged keys, unknown exposure, and inability to enforce cryptoperiods or respond to incidents. Many organisations cannot provide and do not handle a complete list of their owned cryptographic keys. Keys exist in the environment in different forms and systems but not managed as an inventory. Keys in legacy payment applications, keys as backups, clear-text key materials of a transport key shared with the third-party service provider and forgotten. Those are the most common scenarios when organisations surprisingly found that they have cryptographic materials.

What to Do Instead:

• Maintain a centralized and continuously updated Key Inventory
• Include all key types across all environments
• Link keys to owners, systems, and key lifecycle states so they can be properly governed and easily assessed.

Failure 3: Keys That Never Rotate

Core Risk:

Long-lived keys increase the impact of compromise and often indicate a lack of lifecycle governance and cryptoperiod enforcement. Keys that remain in use for years and years are always easier to compromise, even if properly managed and owned. Such keys indicate weak lifecycle governance and lack of key rotation enforcement.

What to Do Instead:

• Define and enforce cryptoperiods for all key types
• Automate key rotation where possible
• Regularly review key age and key usage and align it with NIST recommendations.

Failure 4: No Clear Scope and Architecture for Key Management

Core Risk:

Without a defined cryptographic architecture and scope, key management becomes unmanageable. Different systems designed, using different cryptographic controls. Over time, this leads to an environment where cryptographic key management principles are applied differently and not aligned to a standardized architecture. As a result, architectural inconsistency, gaps, and assessment failures. For example:

• One system uses HSM-protected keys, the other stores keys in application memory
• Cloud services use managed keys, while on-prem systems rely on manual key management processes
• Different teams follow different rotation or handling procedures.

What to Do Instead:

• Establish a documented key management architecture across the organisation
• Define scope, key hierarchies, system boundaries, and cryptographic controls upfront
• Treat key management as a designed capability, not something that grows by default.

Failure 5: Cleartext Key Materials Handling in the Improper Environment

Core Risk:

Handling key material in plaintext outside properly controlled physical and logical environments creates immediate exposure risk, especially in shared and insufficiently secured rooms. Very often organisations generate cleartext keys in a proper secure environment following applicable PCI controls, but when it comes to a loading of those keys – it happens in lower-security environments. Also, an environment, where cleartext key materials are managed not dedicated to only key management purposes, containing equipment or systems that is used for another purpose. As a result, people that shouldn’t have access to the secure key management premise may access it and misuse it or become a source of compromise.

What to Do Instead:

• Restrict cleartext key materials handling to strictly controlled environments only, and only when absolutely necessary
• Reduce cleartext key materials usage as much as possible
• Use secure cryptographic devices and approved key forms wherever possible to eliminate cleartext key materials exposure.

Failure 6: “We Have an HSM, So We’re Secure” Mindset

Core Risk:

HSMs protect keys physically, but weak role separation, poor configuration, or improper device usage can still expose keys or allow misuse. An HSM provides strong technical protection, but it does not replace cryptographic key governance. Weak access control, poor role separation, or misconfiguration of the HSM can still lead to key misuse and keys compromise. Common issues we’ve seen:

• Overly broad admin access to the HSM
• Lack of separation between HSM operational roles
• Keys are securely generated within the HSM but exported or handled outside the HSM boundary insecurely
• HSM is not configured in PCI mode and critical security features are disabled.

What to Do Instead:

• Treat the HSM as one component of a broader key management system
• Harden HSM using vendor Security Policy and Security Configuration Guidelines
• Enforce HSM strict role-based access
• Monitor HSM usage and align HSM operations with defined governance processes.

Failure 7: Confusing FIPS Validation with PCI Requirements for HSM

Core Risk:

Relying on Federal Information Processing Standards (FIPS) validation alone with your HSM can lead to gaps in PCI controls. PCI HSM requirements include operational and procedural expectations not covered by the FIPS. FIPS validation focuses on the security of the cryptographic module itself, not on how it is operated and implemented. Common issues we’ve seen:

• Relying on FIPS alone can leave gaps in areas such as improper key wrapping for an externally stored key
• Cleartext keys are exposed in areas of the HSM which were not considered in the validation of the HSM
• HSM does not always operate in a fully tamper-responsive mode
• HSM is not always configured to check it manages PIN operations securely
• HSM validated under FIPS does not fully consider HSM virtualisations and requires additional implemented controls.

What to Do Instead:

• Understand the difference between FIPS and PCI HSM validation methods of defined HSM models
• Use PCI HSM validated devices where possible.

Failure 8: Outsourcing Key Management Without Understanding Responsibility Boundaries

Core Risk:

When using cloud HSMs or external HSM service providers, unclear shared responsibility models can result in critical controls being assumed but not actually implemented by either party. With cloud HSMs and managed services, organisations often assume that the provider is responsible for key management. In reality, responsibility is shared and often results in missing key management controls. Common issues we’ve seen:

• Organisation assuming the HSM cloud provider handles key rotation, but it is not. HSM service providers require clear key rotation requests from the Organisation to be able to proceed with key replacement
• Unclear responsibility for logging and monitoring of specific key management activities
• No ownership of incident response for key potential compromise
• No defined SLAs between the parties in case of incident handling and urgent key rotation
• Missing PCI controls because each party assumes the other is responsible.

What to Do Instead:

• Clearly define the shared responsibility model for your Cloud HSM service provider
• Understand which controls are handled by the provider and which remain with your organisation
• Validate that all responsibilities are actively implemented and no missing key management scenarios present.

Failure 9: Inconsistent Key Ceremony Logging

Core Risk:

Without proper logging of each key management step and visibility into key usage, organisations cannot detect misuse, respond to incidents, or demonstrate compliance during the assessments. Common issues we’ve seen:

• Lack of logs for key lifecycle stages and inability to define which from appointed key custodians’ teams were participating in the specific key ceremony
• Key Management logs are not reviewed, so errors are not noticed until it is too late
• Incomplete audit trails for ceremonies or key operations.

What to Do Instead:

• Implement comprehensive logging for all key management activities
• Use electronic logs in addition to paper-based logs to easily track and manage keys usage
• Regularly review logs and monitor for anomalies
• Ensure audit trails are complete and accessible for the assessment purpose and potential incident response.

The Pattern Behind the Key Management Failures

If you look at these failures individually, most of them don’t feel dramatic. It is mainly a lack of consistency and clear accountability on the implemented key management principles. However, those failures become more critical, when environments transform into hybrids and rely on cloud service provider key management roles. Organisations start expanding scenarios, where cryptographic key management processes and systems should assure that more sensitive data types are protected using the same principles. In the next post, we’ll focus on how this shift is changing key management in practice and why traditional key management approaches require improvements nowadays.

How We Help

Our PCI Assessor team provides the technical guidance needed to secure your environment while minimizing your compliance overhead.

Learn more about our PCI Crypto Practice and get support from the most trusted team.