WithPCI Logo
WithPCI.com

3.5.1.1 Hashes used to render PAN unreadable

Original requirement from PCI DSS v4.0.1

Defined Approach Requirements

3.5.1.1 Hashes used to render PAN unreadable (per the first bullet of Requirement 3.5.1) are keyed cryptographic hashes of the entire PAN, with associated key-management processes and procedures in accordance with Requirements 3.6 and 3.7.

Customized Approach Objective

Cleartext PAN cannot be determined from hashes of the PAN.

Applicability Notes

All Applicability Notes for Requirement 3.5.1 also apply to this requirement.

Key-management processes and procedures (Requirements 3.6 and 3.7) do not apply to system components used to generate individual keyed hashes of a PAN for comparison to another system if:

  • The system components only have access to one hash value at a time (hash values are not stored on the system)

AND

  • There is no other account data stored on the same system as the hashes.

This requirement is considered a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. This requirement will replace the bullet in Requirement 3.5.1 for one-way hashes once its effective date is reached.

Defined Approach Testing Procedures

3.5.1.1.a Examine documentation about the hashing method used to render PAN unreadable, including the vendor, type of system/process, and the encryption algorithms (as applicable) to verify that the hashing method results in keyed cryptographic hashes of the entire PAN, with associated key management processes and procedures.

3.5.1.1.b Examine documentation about the key management procedures and processes associated with the keyed cryptographic hashes to verify keys are managed in accordance with Requirements 3.6 and 3.7.

3.5.1.1.c Examine data repositories to verify the PAN is rendered unreadable.

3.5.1.1.d Examine audit logs, including payment application logs, to verify the PAN is rendered unreadable.

Purpose

Rendering stored PAN unreadable is a defense in depth control designed to protect the data if an unauthorized individual gains access to stored data by taking advantage of a vulnerability or misconfiguration of an entity's primary access control.

A hashing function that incorporates a randomly generated secret key provides brute force attack resistance and authentication integrity.

Definitions

Refer to Appendix G for the definition of "keyed cryptographic hash" and information about appropriate keyed cryptographic hashing algorithms and additional resources.

Examples

Systems which only have access to one hash value at a time and which store no other account data on the same system as the hash, are not required to meet key-management processes and procedures (Requirements 3.6 and 3.7). Examples of such systems include transaction-originating devices that generate a hash of the PAN for use in a backend system, such as pay-at-gate transit turnstiles. However, in such an implementation, the backend system will have access to more than one hash value at a time, and therefore is required to meet key-management processes and procedures at Requirements 3.6 and 3.7.

purpose

Document and implement key management policies and procedures.

compliance strategies

  • Centralized key management
  • Annual review

typical policies

  • Key Management Policy

common pitfalls

  • Outdated key management documentation

type

Documentation/Process Control

difficulty

High

key risks

  • Weak or inconsistent key management

recommendations

  • Use dedicated key management systems

Eligible SAQ

  • SAQ-D MERCHANT
  • SAQ-D SERVICE PROVIDER

Your perspective on this PCI DSS requirement matters! Share your implementation experiences, challenges, or questions below. Your insights help other organizations improve their compliance journey and build a stronger security community.Comment Policy