Keyed Cryptographic Hashes for PAN

“Keyed cryptographic hashes for PAN” is a narrow but high-impact requirement because it governs a pattern teams often adopt for analytics, deduplication, customer search, chargeback correlation, and token linking: storing a derived value of PAN instead of the PAN itself. PCI DSS allows hashing as a method to render PAN unreadable, but only if the hash is keyed and computed over the full PAN, and only if the key is managed under defined key-management controls. (PCI DSS v4.0.1 Requirement 3.5.1.1)

For a Compliance Officer, CCO, or GRC lead, the operational goal is simple: make sure any system claiming “we don’t store PAN, we store a hash” can prove (1) the hash is keyed, (2) it covers the entire PAN, (3) the key is protected and lifecycle-managed, and (4) implementation is consistent everywhere PAN is handled. Failures here usually come from engineering convenience (plain SHA-256, truncation, hard-coded keys) rather than malicious intent.

This page gives you requirement-level implementation guidance you can hand to engineering and audit prep teams: what to build, how to govern it, and what evidence to retain for assessment.

Regulatory text

Requirement statement (verbatim): “Hashes used to render PAN unreadable ¹ are keyed cryptographic hashes of the entire PAN, with associated key-management processes and procedures in accordance with Requirements 3.6 and 3.7.” (PCI DSS v4.0.1 Requirement 3.5.1.1)

Operator interpretation (what you must do):

1. If you’re using a hash as your PAN “protection” method, the hash must be keyed (think HMAC or equivalent keyed hash construction).
2. The hash must be computed over the entire PAN, not a subset, not a truncated form, and not “PAN + something else” while omitting digits.
3. You must treat the key as a managed cryptographic key with documented processes aligned to PCI key-management requirements referenced by the standard. (PCI DSS v4.0.1 Requirement 3.5.1.1)

Plain-English requirement (what it means in practice)

If a system stores something derived from PAN, and you’re relying on that derived value to say “PAN is unreadable,” you need two things:

• A secret key is involved in the hash, so the output can’t be reproduced without that key.
• The process is repeatable and controlled across the estate, with key custody, access control, rotation/lifecycle, and change management.

A plain hash (example: SHA-256(PAN)) is not enough under this requirement because it is unkeyed; anyone who guesses the PAN can hash it and compare, and attackers can run mass guessing. A keyed hash changes that risk profile because the key becomes the control point you protect and manage.

Who it applies to (entity and operational context)

Entity types: Merchants, service providers, payment processors that store, process, or transmit cardholder data and choose hashing as a mechanism to render PAN unreadable. (PCI DSS v4.0.1 Requirement 3.5.1.1)

Operational contexts where this shows up:

• Data warehouses and analytics platforms storing “PAN hash” for joins, deduplication, or customer-level metrics.
• Fraud, chargeback, and reconciliation systems correlating transactions across channels.
• Customer service workflows searching by card (often via “last 4 + hash” patterns).
• Logging, observability, and event pipelines where developers create “safe identifiers.”
• Third parties who receive PAN and store a hashed derivative (you still need to validate their approach in due diligence).

What you actually need to do (step-by-step)

1) Inventory every place PAN is handled, then find “PAN-derived” fields

Deliverable outcome: a list of systems, tables, topics, logs, and files where:

• PAN exists in cleartext at any point, or
• a “PAN hash / fingerprint / token / surrogate key” exists.

Practical move: run a structured data discovery effort (DB schemas, data catalog, DLP findings, log sampling). Don’t forget:

• dead-letter queues,
• debug logs,
• exports to object storage,
• replicas and backups.

2) Decide whether hashing is the right approach for your use case

Hashing is usually chosen for deterministic matching (“same PAN produces same identifier”). If you actually need reversible retrieval of PAN, hashing is the wrong tool; encryption or a tokenization service may be required. Keep the decision documented.

Decision checkpoint (what auditors look for):

• If a system stores a “hash” and teams claim it makes PAN unreadable, then it must meet this keyed-hash requirement. (PCI DSS v4.0.1 Requirement 3.5.1.1)

3) Implement a keyed cryptographic hash of the entire PAN

Control intent: determinism plus secrecy.

Implementation expectations to set with engineering:

• Use a keyed hashing scheme (commonly HMAC with an approved hash function).
• Hash input must be the full PAN exactly as captured/normalized (define normalization rules explicitly: remove spaces, handle hyphens, define encoding).
• Standardize the output format (hex/base64) and length to prevent ad hoc truncation.

Design detail that prevents audit pain: publish a single internal “PAN hashing spec” that defines:

• the algorithm family,
• input normalization,
• output encoding,
• versioning strategy (so you can rotate keys without breaking join logic).

4) Put the hashing key under formal key management

The requirement explicitly ties keyed hashes to key-management processes and procedures. (PCI DSS v4.0.1 Requirement 3.5.1.1)

Operationally, treat the HMAC key like any other sensitive cryptographic key:

• Generate and store the key in a controlled key-management system (KMS/HSM patterns are common).
• Restrict access based on job role (apps may use it; developers generally should not).
• Prevent key material from being embedded in code, configs, CI variables, images, or tickets.
• Define key lifecycle steps: creation, activation, rotation, retirement, and destruction.
• Log and monitor key access and administrative actions.

Control mapping note: the requirement references key-management alignment to PCI Requirements 3.6 and 3.7; build your procedure set to be explicitly auditable against those internal key-management controls. (PCI DSS v4.0.1 Requirement 3.5.1.1)

5) Control where hashing happens (and stop PAN from spreading)

If the hash is your stored identifier, the safest pattern is:

• PAN is captured in a controlled ingestion boundary,
• keyed hashing happens immediately,
• only the keyed hash flows downstream to analytics and non-payment systems.

Where teams get in trouble: hashing happens “later” in the pipeline, after PAN has already landed in multiple systems. That turns a narrow control into a broad scope problem.

6) Build testing and monitoring that proves the implementation stays correct

Add automated checks:

• Unit tests: same PAN + same key yields stable output; different PAN yields different output; normalization rules behave as documented.
• Static checks: detect forbidden functions/patterns (e.g., unkeyed SHA-256 on PAN fields).
• Data validation: confirm no table stores both PAN and “hash” unless explicitly approved and protected.
• Change monitoring: alerts on key-policy changes and unexpected key access.

7) Third-party and SDLC governance

If a third party receives PAN and returns a “hash,” you need to confirm:

• it is keyed,
• it covers the entire PAN,
• key management is in place, and
• you can evidence it during due diligence and assessment.

This is a common gap: contracts and SOC reports talk about “hashing,” but do not specify keyed hashing over full PAN.

Where Daydream fits naturally: use Daydream to track which third parties touch PAN, collect targeted evidence (hashing design + key-management controls), and keep the assessor-ready package tied to the exact PCI requirement language.

Required evidence and artifacts to retain

Keep evidence at two levels: design proof and operational proof.

Design and governance artifacts

• PAN hashing standard (algorithm, full-PAN requirement, normalization, output format, versioning).
• Data flow diagrams showing where PAN is captured, where hashing occurs, and where hashed PAN is stored.
• Key-management procedure documents aligned to referenced PCI key-management requirements. (PCI DSS v4.0.1 Requirement 3.5.1.1)
• Access control policy for cryptographic key administration and application use.

Technical evidence

• KMS/HSM configuration screenshots/exports: key policies, role bindings, separation of duties.
• Application configuration evidence showing keys are retrieved at runtime (not hard-coded).
• Sample code snippets or approved library documentation showing keyed hashing is used on full PAN.
• Logging/monitoring evidence for key access and administrative events.
• Data discovery results showing absence of clear PAN in systems meant to store only hashes.

Assessment-ready “one pager”

• System list: where hashed PAN is stored and purpose.
• Key ownership: who owns the key, who can administer it.
• Rotation and change process summary, including how old hashes are handled when keys change.

Common exam/audit questions and hangups

Expect assessors to press on these points:

1. “Show me it’s keyed.” They will ask for code, configs, or library references proving a secret key is part of the hash. (PCI DSS v4.0.1 Requirement 3.5.1.1)
2. “Is it the entire PAN?” They will look for truncation, partial PAN hashing, or “last 4 only” practices. (PCI DSS v4.0.1 Requirement 3.5.1.1)
3. “Where is the key stored and who can access it?” They will map this to key-management processes. (PCI DSS v4.0.1 Requirement 3.5.1.1)
4. “Do logs or analytics still contain PAN?” They will test whether PAN leaks before hashing.
5. “What happens on key rotation?” If you rotate keys, do you version hashes, re-hash, or maintain old keys for verification? Document the approach.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	How to avoid
Unkeyed hash (e.g., SHA-256(PAN))	Not a keyed cryptographic hash	Standardize on HMAC or equivalent keyed construction and ban unkeyed hashing for PAN. (PCI DSS v4.0.1 Requirement 3.5.1.1)
Hashing only part of the PAN	Not “entire PAN”	Centralize hashing in a shared library that only accepts full PAN input and enforces validation. (PCI DSS v4.0.1 Requirement 3.5.1.1)
Hard-coded key in code/config	Key becomes broadly exposed and unmanaged	Require KMS/HSM-backed runtime key retrieval; block secrets in repos and CI.
Multiple teams implement their own hashing	Inconsistent behavior; hard to evidence	Provide one approved library and spec; require architecture review for exceptions.
Hash + clear PAN stored together “temporarily”	Temporary becomes permanent; scope expands	Put explicit retention controls, TTLs, and monitoring on any exception storage.

Risk implications (why assessors care)

A PAN hash is often treated as “safe,” then copied into analytics, customer support tooling, and event streams. If the hash is unkeyed or the key is poorly managed, the derived identifier can become a pivot point for correlation or recovery attempts, and it increases the blast radius of any data exposure. The requirement forces you to make the hash dependent on a protected secret and forces disciplined key governance. (PCI DSS v4.0.1 Requirement 3.5.1.1)

Practical 30/60/90-day execution plan

First 30 days (Immediate)

• Identify every location where “PAN hash/fingerprint” is stored and who owns each system.
• Confirm whether each hash is keyed and computed over full PAN; flag exceptions.
• Freeze new implementations: require security review for any new PAN-derived identifiers.
• Draft the PAN hashing standard and key ownership model. (PCI DSS v4.0.1 Requirement 3.5.1.1)

Days 31–60 (Near-term)

• Implement or standardize a single approved keyed-hash library/service for PAN.
• Move keys into managed infrastructure (KMS/HSM pattern) and restrict access.
• Update data flows so hashing happens at ingestion and downstream systems only see hashes where possible.
• Create assessor-ready evidence packs per system: diagrams, configs, code references, and procedures. (PCI DSS v4.0.1 Requirement 3.5.1.1)

Days 61–90 (Operationalize)

• Add automated detection for unkeyed hashing patterns and PAN leakage in logs/streams.
• Implement key lifecycle procedures (rotation/versioning plan, approvals, monitoring) and run a tabletop key-rotation exercise.
• Formalize third-party due diligence questions and evidence requests for any third party handling PAN-derived data.
• Centralize tracking of controls, evidence, and third-party attestations in Daydream so audits don’t devolve into screenshots and Slack threads.

Frequently Asked Questions

Does hashing PAN automatically remove the system from PCI scope?

Not by itself. This requirement only states what qualifies when hashes are used to render PAN unreadable; scoping depends on the full environment and data flows. (PCI DSS v4.0.1 Requirement 3.5.1.1)

Is SHA-256(PAN) acceptable if we salt it?

The requirement calls for a keyed cryptographic hash, which implies a managed secret key as part of the construction. Document and implement a true keyed scheme and manage that key under formal key-management procedures. (PCI DSS v4.0.1 Requirement 3.5.1.1)

Can we hash only the last 4 digits since we never store the full PAN?

No if you are claiming hashing is your method to render PAN unreadable; the requirement specifies keyed cryptographic hashes of the entire PAN. If you only store last four, that’s a different design and needs separate validation for business need and data handling. (PCI DSS v4.0.1 Requirement 3.5.1.1)

Where should the HMAC key live?

Put it in controlled key-management infrastructure with restricted administrative access, strong logging, and documented lifecycle processes. The requirement explicitly ties keyed hashing to key-management processes. (PCI DSS v4.0.1 Requirement 3.5.1.1)

How do we handle key rotation without breaking deterministic matching?

Use a versioned hashing approach: store the hash version alongside the hash value, keep verification logic aware of active versions, and document the process. Make rotation a governed change with evidence retained for assessment.

What evidence will an assessor ask for to prove compliance?

Expect requests for the hashing design/spec, code or configuration showing keyed hashing over full PAN, key-management procedures, and proof of restricted access and monitoring around the key. (PCI DSS v4.0.1 Requirement 3.5.1.1)

Footnotes

1. the first bullet of Requirement 3.5.1