PCI DSS V4.0.1: A PRACTICAL GUIDE TO CRYPTOGRAPHIC KEY GOVERNANCE

Protect key lifecycles, strengthen audit evidence and reduce operational complexity

For security leaders, payment technology owners, compliance teams and cryptography specialists.

EXECUTIVE SUMMARY

Encryption works only when its keys are governed

PCI DSS v4.0.1 does not add or remove requirements from v4.0. It is a limited revision that corrects errors and clarifies intent. The operational challenge remains demanding: where cryptography protects stored account data, organisations must secure the relevant keys, run defined lifecycle processes and show that those controls operate as intended.

That is harder in hybrid payment environments. Keys may support databases, payment applications, HSMs, cloud key stores, tokenisation services and partner connections. Ownership often crosses security, infrastructure, application, operations and compliance teams. A secure component can still sit inside a fragmented operating model.

The practical response is not to pull every cryptographic asset into PCI scope. It is to begin with account-data flows and applicable systems, identify the keys and certificates on which those controls depend, then govern those assets through clear ownership, policy, workflow and evidence.

This guide maps the relevant PCI DSS requirements, provides a key-lifecycle model and a self-assessment, and explains how CrystalKey 360 can contribute central policy, automation, visibility and audit evidence across supported cryptographic environments.

The central point

Technology can support and evidence a control. It cannot define PCI DSS scope, approve policy, assign accountable owners, validate implementation or certify compliance on the organisation's behalf.

Inside this guide

Start with PCI DSS scope and cryptographic dependencies.
Map Requirements 3.5, 3.6, 3.7 and 4.2.1.1 accurately.
Follow one key from creation to destruction and test the evidence chain.
Build a people, process and technology operating model.
Position CrystalKey 360 as a governance enabler, not a compliance shortcut.

Important: This guide is general information, not legal, audit or assessment advice. Applicability and compliance depend on scope, implementation, operating effectiveness, documentation and validation through the appropriate PCI DSS process.

SCOPE COMES FIRST

Govern the cryptography that supports the control

Key governance starts with the PCI DSS scope and the function of each system, not with an unrestricted list of enterprise cryptography. PCI DSS requirements apply to relevant system components unless a requirement is verified as not applicable for a particular system. PCI SSC specifically notes that Requirements 3.5 to 3.7 may be not applicable to systems that do not store or manage stored cardholder data and have no access to that data, the keys, or the encryption and decryption mechanisms.

PCI DSS v4.0.1 in one line

The June 2024 release is a limited revision to v4.0. It clarifies language and intent, and contains no added or deleted requirements.

Begin with six scope questions

Where is PAN stored, and which applications, databases, files, backups or services handle it?
Which approved methods make stored PAN unreadable, such as encryption, tokenisation, truncation or keyed cryptographic hashing?
Which keys, key-encrypting keys, HSMs, cloud key stores and cryptographic services support those methods?
Which people and system components can access the data, key material, or encryption and decryption mechanisms?
Which connections transmit PAN over open, public networks, and which trusted keys and certificates protect those connections?
What documented evidence supports each applicability and scoping decision, including any system treated as not applicable?

Keep the account-data rules distinct

PAN is the defining element of cardholder data. Requirement 3.5 addresses making stored PAN unreadable, while Requirements 3.6 and 3.7 focus on the keys used to protect stored account data. Sensitive authentication data must not be stored after authorisation, even if encrypted. Strong key management does not make prohibited retention acceptable.

A useful scoping principle

Start with the data flow and applicable systems. Follow their cryptographic dependencies outward. Record why each key, certificate, device and administrator is in scope.

REQUIREMENT MAP

The PCI DSS requirements that matter most

The following section summarises the control intent. It is not a substitute for the standard, its guidance, or assessor judgement. The important discipline is to connect each requirement to the relevant stored account data, cryptographic dependency, owner, process and evidence source.

3.5 and 3.5.1

Control intent: PAN is rendered unreadable wherever it is stored. Strong cryptography with associated key-management processes and procedures is one permitted approach.

Key-governance implication: Link each relevant key to the PAN store or protection mechanism it supports. Record purpose, algorithm, owner, location and dependency. Where keyed cryptographic hashing is used for stored PAN, govern the associated keys in line with 3.6 and 3.7.
3.6
3.7 and 3.7.1 to 3.7.8
3.7.9 - Service providers only
4.2.1 and 4.2.1.1

Control intent: Strong cryptography and secure protocols protect PAN during transmission over open, public networks. An inventory of trusted keys and certificates used for this protection is maintained.

Key-governance implication: Connect the key and certificate inventory to endpoints, owners, validity, revocation, renewal, trust and technical dependencies. Requirement 4.2.1.1 is now fully effective following the 31 March 2025 future-dated requirement deadline.
Supporting control areas

GOVERN THE LIFECYCLE

Treat every key as a controlled asset

A defensible lifecycle combines policy, technical enforcement and evidence. The stages below are a practical operating model for keys that protect stored account data. Local procedures may use different names, but each control outcome should be clear and testable.

01 Generate

Relevant requirements: 3.7.1.

Use approved algorithms, strengths and trusted generation methods. Assign a unique identifier, owner, purpose and policy at creation.

02 Distribute

Relevant requirements: 3.7.2.

Use approved channels and protected formats. Authenticate recipients and retain evidence that the correct key reached the intended destination.

03 Store & Protect

Relevant requirements: 3.6 & 3.7.3.

Protect secret and private keys in permitted forms, minimise copies and locations, and separate or otherwise secure key-encrypting keys as required.

04 Use & Administer

Relevant requirements: 3.6, 7 & 8.

Restrict use and administration by business need. Separate request, approval and execution where appropriate, and monitor privileged activity.

05 Change or Rotate

Relevant requirements: 3.7.4.

Define a crypto-period for each key type. Rotate at its end and on relevant events, with dependency checks, continuity planning and clear evidence.

06 Retire or Replace

Relevant requirements: 3.7.5.

Remove keys from active use when they expire, are compromised or may be weakened. Control any retained or archived material and prevent further use.

07 Control Manual Operations

Relevant requirements: 3.7.6 to 3.7.8.

Apply split knowledge and dual control to manual cleartext operations, prevent unauthorised substitution, and record custodian acknowledgement.

08 Destroy & Retain Evidence

Relevant requirements: 3.7.5, 10 and 12.

Destroy key material when it is no longer required and retain the approvals, timing, result, review and exception records needed for assurance.

SELF-ASSESSMENT

Follow one key from request to retirement

Choose one high-value key that protects stored account data. Trace its latest complete lifecycle event using actual records, not only the documented procedure. If the answers sit across several teams and tools, note each hand-off and evidence source.

What stored account data or protection mechanism does the key support, and why is it in PCI DSS scope?
Who is accountable for the key, who are its custodians, and which applications or services depend on it?
Are the algorithm, effective strength, intended use and cryptoperiod defined and approved?
Where and how was the key generated, and what proves that strong generation controls were used?
Where is the key stored, in which forms and copies, and how are secret or private keys and key-encrypting keys protected?
Who can request, approve, administer and use it? When were access and role assignments last reviewed?
How is it distributed, imported or exported? Does any cleartext operation occur, and if so, how are split knowledge and dual control applied?
When was it last changed or rotated? Can you connect the approval, technical event, affected dependencies and result?
What happens after compromise, suspected weakness, expiry or retirement? How is further use prevented and destruction evidenced?
Can an independent reviewer move from policy to approved workflow, technical log, review record and exception without relying on undocumented knowledge?

Red flags

No named owner; no defined crypto-period; several unexplained copies; a key or certificate that cannot be linked to a business service; evidence held by one person; rotation records without the associated approval or result; expired exceptions; or an inventory that records objects but not purpose and dependency.

A defensible evidence chain

Approved policy and scope -> authorised workflow -> technical event -> recorded result -> review or exception. Each link should identify the asset, owner, time and outcome.

FAILURE PATTERNS

Where cryptographic governance breaks down

Most weaknesses are operational rather than mathematical. Each platform may use strong cryptography, yet the estate becomes difficult to govern as payment services, HSMs, cloud platforms and teams multiply.

INVENTORY WITHOUT CONTEXT

The organisation can count keys but cannot connect them to PAN stores, applications, owners, policies or business-critical dependencies.

POLICY WITHOUT EXECUTION

The standard says how keys should be managed, but local teams use different request, approval, rotation and retirement processes.

TOOL BOUNDARIES BECOME CONTROL BOUNDARIES

HSM, cloud, PKI and application logs are secure individually, but there is no consistent view of lifecycle activity across them.

OWNERSHIP IS SPLIT BUT NOT EXPLICIT

Security defines policy, infrastructure operates devices, applications consume keys, and compliance gathers evidence. Gaps form between responsibilities.

EVIDENCE IS ASSEMBLED TOO LATE

Teams reconstruct decisions from tickets, spreadsheets, consoles and individual knowledge shortly before an assessment or incident review.

How fragmentation compounds

Fragmented ownership -> Manual coordination -> Inconsistent execution -> Scattered evidence -> Audit friction and slower change

Centralisation is useful when it creates a common control model for ownership, policy, workflow and evidence. It does not require every application, HSM or cloud service to be replaced or made identical.

OPERATING MODEL

Combine people, process and technology

No single layer is sufficient. People own decisions, processes make those decisions repeatable, and technology enforces or records them. A mature model makes the relationship between the three visible.

People

Control question: Who is accountable? Who may request, approve, administer, use and review? Where do service-provider duties begin and end?

Minimum practice: Named owners and custodians; least privilege; separation of duties; dual control where required; formal custodian acknowledgement; periodic access review.

Typical evidence: Role assignments, approval records, access recertification, custodian acknowledgement and third-party responsibility records.

Process

Control question: How are inventory, generation, distribution, change, compromise, retirement, destruction and exceptions managed?

Minimum practice: Defined crypto-periods and triggers; approved runbooks; controlled changes; tested compromise response; time-bound exceptions with owners.

Typical evidence: Policies, procedures, workflow records, ceremony records, change tickets, exception decisions and test results.

Technology

Control question: Where are controls enforced, and how are events linked across HSMs, key stores, applications, PKI and monitoring?

Minimum practice: Protected key material; enforced roles and approvals; standard integrations; reliable identifiers; logging, alerting and evidence retention.

Typical evidence: Configuration records, key and certificate inventories, system logs, workflow reports, monitoring alerts and review evidence.

Three maturity tests

Can an owner see every in-scope key and certificate for a service, including dependencies across supported environments?
Can routine lifecycle work follow the same authorised pattern without relying on one specialist's memory?
Can a reviewer trace a sample from policy and scope to technical execution, outcome and review?

Design for the operating year, not only the audit window

The strongest evidence is produced by normal operations. If a record exists only because an assessment is approaching, the process is likely too manual.

CRYSTALKEY 360

How the platform can contribute

CrystalKey 360 is designed as a control and orchestration layer for governed cryptographic operations across supported hybrid environments. It can centralise policy, ownership, approvals, lifecycle automation, visibility and evidence without requiring wholesale replacement of existing HSMs, cloud key stores or payment infrastructure.

Its key-management capabilities cover generation, import, export, rotation, renewal, backup, revocation, versioning and destruction. API-based integration and governed workflows can make recurring work more consistent and give security, operations and compliance teams a shared evidence source.

CONTROL AREA	CRYSTALKEY 360 CONTRIBUTION	ORGANISATIONS REMAIN RESPONSIBLE FOR
Visibility	Provides a common view across supported HSMs, cloud platforms, key stores and cryptographic services.	Defines the authoritative PCI DSS scope; verify completeness; document unsupported or out-of-band activity.
Lifecycle Control	Standardises and automate approved key lifecycle work through policies, workflows and APIs.	Approves algorithms, cryptoperiods, triggers and procedures; test integrations and continuity; govern exceptions.
Roles & Approvals	Supports policy ownership, approval paths and traceable administrative action.	Assigns accountable owners; enforce least privilege and separation of duties; review access and custodianship.
Logging & Evidence	Records lifecycle and administrative activity across supported integrations to improve auditability.	Sets retention and review requirements; integrate monitoring; investigate anomalies; confirm that evidence meets assessment needs.
Hybrid Adoption	Centralises governance while retaining fit-for-purpose HSM, cloud and application infrastructure.	Secures the underlying platforms, administrative identities and trust anchors; maintain vendor and service provider responsibilities.

Technology supports the control

CrystalKey 360 supports defined control outcomes and contributes operational evidence. Compliance still depends on the entity's scope, design, configuration, procedures, ongoing operation and assessor validation.

BUILD THE BASELINE

FIVE STEPS TO A GOVERNED OPERATING MODEL

No single layer is sufficient. People own decisions, processes make those decisions repeatable, and technology enforces orrecords them.A mature model makes the relationship between the three visible.

BEYOND PCI DSS

Extend the foundations to cloud and PQC

Cloud governance

Cloud key services add strong native capabilities, but they do not remove the organisation's responsibility for scope, ownership, access, policy and evidence. A common governance layer can connect approved cloud key use to payment applications and enterprise controls while preserving the cloud service that fits each workload.

Post-quantum readiness

PCI DSS v4.0.1 does not create a general post-quantum migration requirement. The preparation is still relevant: an organisation cannot change algorithms safely if it does not know where cryptography is used, which services depend on it, who owns the change and how new key or certificate lifecycles will be controlled. Inventory, ownership and repeatable lifecycle work are the foundations of crypto-agility.

CONCLUSION

PCI DSS does not ask organisations merely to deploy encryption. Where cryptography protects stored account data, it expects the relevant keys to be secured and managed through defined, operating lifecycle controls. Where PAN is protected in transit, trusted keys and certificates need disciplined inventory and lifecycle management.

The strongest programme begins with scope, connects every relevant key and certificate to its purpose and owner, and produces evidence as part of normal operations. That reduces audit friction, limits hidden dependencies and gives the organisation a safer basis for cloud growth and future cryptographic change.

A PRACTICAL NEXT CONVERSATION

Speak with Cryptomathic to discuss how key governance is operated today, where lifecycle activity is fragmented, and where CrystalKey 360 could add control, automation and evidence across supported environments.

Explore CrystalKey 360