Frequently Asked Question

How can hashing be used to protect Primary Account Numbers (PAN) and in what circumstances can hashed PANs be considered out of scope for PCI DSS?
One-way hashing is a method that can be used to render PAN unreadable in storage. The hashing process and results, as well as the system(s) that perform the hashing, are in scope for a PCI DSS assessment to assure that the process meets applicable PCI DSS requirements.
If the hashing result is transferred and stored within a separate environment, the hashed PAN in that separate environment would no longer be considered cardholder data and would be out of scope for additional PCI DSS requirements. However, if the hashed PAN is stored on the same system that performed the hashing, that system is considered to be storing cardholder data and remains within PCI DSS scope.
PCI DSS requires that hashing be of the entire PAN and be based on strong cryptography. This means that collisions would not occur frequently, and the hash cannot be recovered or easily determined during an attack. For PCI DSS v3.2.1, it is recommended, but not required, that an input variable, or salt, be used. Additionally, PCI DSS v4.0 introduces a new requirement for processes that hash PAN to use keyed cryptographic hashing. This new requirement is a best practice in PCI DSS v4.0 until 31 March 2025.
Since hashing is used when there is no need to recover the PAN, a recommended practice is to remove the PAN rather than allowing the possibility of a compromise cracking the hash and revealing the original PAN. If the entity intends to recover and use the PAN, then hashing is not an option and an alternative method for rendering the PAN unreadable should be considered.
Related
-
How should PCI DSS v4.x requirements noted as superseded by another requirement be reported after 31 March 2025?
-
Are providers of third-party scripts for e-commerce environments considered third-party service providers for PCI DSS Requirements 12.8 and 12.9?
-
Why do requirements 8.3.9 and 8.3.10.1 focus on passwords/passphrases used for single-factor authentication, when multi-factor authentication is required for all access into the CDE?
Featured FAQ Articles
Featured
-
Do PCI DSS requirements for keyed cryptographic hashing apply to previously hashed PANs?
-
Is the PCI DSS Attestation of Compliance intended to be shared?
-
How does an entity report the results of a PCI DSS assessment for new requirements that are noted in PCI DSS as best practices until a future date?
-
Where do I direct questions about complying with PCI standards?
-
Can SAQ eligibility criteria be used for determining applicability of PCI DSS requirements for assessments documented in a Report on Compliance?
Most Popular
-
How should PCI DSS v4.x requirements noted as superseded by another requirement be reported after 31 March 2025?
-
Are providers of third-party scripts for e-commerce environments considered third-party service providers for PCI DSS Requirements 12.8 and 12.9?
-
Why do requirements 8.3.9 and 8.3.10.1 focus on passwords/passphrases used for single-factor authentication, when multi-factor authentication is required for all access into the CDE?
-
Do PCI DSS Requirements 8.3.9 and 8.3.10.1 apply to all system components?
-
Is the cardholder in scope for PCI DSS?
Most Recently Updated
-
How should PCI DSS v4.x requirements noted as superseded by another requirement be reported after 31 March 2025?
-
Are providers of third-party scripts for e-commerce environments considered third-party service providers for PCI DSS Requirements 12.8 and 12.9?
-
Why do requirements 8.3.9 and 8.3.10.1 focus on passwords/passphrases used for single-factor authentication, when multi-factor authentication is required for all access into the CDE?
-
Do PCI DSS Requirements 8.3.9 and 8.3.10.1 apply to all system components?
-
Is the cardholder in scope for PCI DSS?