Skip to main content
Commerce Security Authority
Category: Cryptography Fundamentals

Keyed Cryptographic Hash

Also known as: Keyed Hash, Keyed Hash Algorithm, Hash Message Authentication Code (HMAC)
Simply put

A keyed cryptographic hash is a way of scrambling data into a fixed-size fingerprint using both the data itself and a secret key. Because the key is required, someone who only knows the data cannot reproduce or reverse the result without also knowing the key. In payment security, it is one method used to protect a card number (PAN) when the PAN needs to be rendered unreadable.

Formal definition

A keyed cryptographic hash is an algorithm that produces a fixed-size output from a message combined with a secret key shared or held by the relevant endpoints, most commonly implemented as a message authentication code such as HMAC. Unlike an unkeyed hash, incorporating a secret key defends against precomputation and brute-force attacks that exploit the small input space of a PAN, since an attacker cannot enumerate candidate values and match the digest without also possessing the key. In PCI DSS, keyed cryptographic hashing of the entire PAN is one of the defined methods for rendering PAN unreadable where stored; note that a hash is not reversible like encryption and does not by itself constitute tokenization, truncation, or masking, and its acceptability and any associated key-management and version-specific requirements should be confirmed against the current published PCI DSS standard rather than an assumed requirement number.

Why it matters

A primary account number (PAN) occupies a comparatively small and well-structured input space: the leading digits identify issuers, a check digit constrains the final digit, and much of the remaining range is predictable. This means an unkeyed hash of a PAN is vulnerable to precomputation and brute-force attacks, where an attacker enumerates candidate PANs, hashes each one, and matches the result against stored digests. A keyed cryptographic hash addresses this weakness by incorporating a secret key into the computation, so that an attacker who obtains only the stored digests cannot reproduce or reverse them without also possessing the key.

In the context of PCI DSS, keyed cryptographic hashing of the entire PAN is one of the defined methods for rendering PAN unreadable where it is stored. This matters for organizations that need to retain a consistent, non-reversible representation of a PAN—for example to match or deduplicate records—without keeping the PAN itself in readable form. Because the security of this approach depends entirely on protecting the secret key, key-management controls become central; a compromised key can undermine the protection the hash was intended to provide.

It is important not to overstate what a keyed hash accomplishes. A hash is not reversible in the way encryption is, and it does not by itself constitute tokenization, truncation, or masking—these are distinct techniques with different properties and different effects on scope. Whether keyed hashing is acceptable for a given use, and what key-management and version-specific obligations apply, should be confirmed against the current published PCI DSS standard rather than an assumed requirement number, since numbering and wording differ between versions.

Who it's relevant to

Security engineers and application developers
Teams building systems that must retain a non-reversible representation of a PAN need to understand that keyed hashing is one of the defined methods for rendering PAN unreadable where stored, and that it differs from encryption, tokenization, truncation, and masking. They must implement it as a keyed construction such as HMAC over the entire PAN, and design robust protection and management for the secret key, since the security of the approach rests on the key remaining confidential.
Compliance officers and QSAs
Those validating how stored PAN is protected should confirm that keyed cryptographic hashing is applied to the entire PAN and that associated key-management requirements are met. They should verify acceptability and any version-specific obligations against the current published PCI DSS standard rather than an assumed requirement number, and should not treat a hash as equivalent to tokenization, truncation, or masking based on the label alone.
Cryptography and key-management teams
Because the protection a keyed hash offers depends on the secrecy of the key, teams responsible for key generation, storage, rotation, and access control are central to its effectiveness. A compromised key can undermine the intended defense against precomputation and brute-force attacks that exploit the small input space of a PAN.

Inside Keyed Cryptographic Hash

Cryptographic Hash Function
The underlying one-way function (for example a member of the SHA-2 or SHA-3 families) that produces a fixed-length output from arbitrary input. A keyed cryptographic hash builds on this by incorporating a secret key into the computation.
Secret Key
A confidential value combined with the input so that only parties possessing the key can compute or verify the resulting value. Its confidentiality is what distinguishes a keyed hash from a plain, unkeyed hash that anyone can reproduce.
HMAC Construction
A common standardized method for producing a keyed hash by combining a secret key with a hash function in a defined manner, intended to provide message integrity and authentication.
Message Authentication Code (MAC) Output
The resulting value used to verify that data has not been altered and originated from a party holding the key. It supports integrity and authenticity rather than confidentiality.
Key Management Context
The processes for generating, distributing, storing, rotating, and retiring the secret key. The security properties of a keyed hash depend on protecting this key, which is governed by cryptographic key management controls.

Common questions

Answers to the questions practitioners most commonly ask about Keyed Cryptographic Hash.

Does a keyed cryptographic hash count as encryption of cardholder data?
No. A keyed cryptographic hash is a one-way function that produces a fixed-length output and is not designed to be reversed to recover the original PAN, whereas encryption is intended to be reversible with the appropriate key. They are distinct data-transformation methods, and PCI DSS treats them as different approaches to rendering data unreadable. Confirm the specific requirement wording and acceptable methods against the current published standard, since numbering and language differ between versions.
Is any hash of a PAN automatically out of scope for PCI DSS?
No. Whether a hashed value affects scope depends on implementation and validation, not on the label alone. An unkeyed or weakly implemented hash of a PAN can be vulnerable to brute-force or lookup attacks because the PAN space is limited and structured. A keyed cryptographic hash intended to render the PAN unreadable must be implemented and managed so the key is protected, and its scope effect should be assessed against the current standard rather than assumed.
How does keyed hashing differ from a plain hash when rendering a PAN unreadable?
A keyed cryptographic hash incorporates a secret key into the computation, so an attacker without the key cannot precompute or reproduce the output for candidate PAN values. A plain, unkeyed hash of a structured and limited value such as a PAN can be susceptible to precomputation, lookup tables, or brute-force enumeration. The security of the keyed approach depends on protecting the key with appropriate key-management controls.
Where should the key used for a keyed cryptographic hash be stored?
The key should be managed under key-management controls that keep it separate from and inaccessible to anyone who could combine it with the hashed data to attempt reconstruction. Storing the key alongside the hashed values in the same accessible location can undermine the protection the keyed hash is intended to provide. Consult the current PCI DSS key-management requirements and, where relevant, PCI PIN for keys in that context, confirming exact wording against the published standard.
Can a keyed cryptographic hash of a PAN be used to correlate records across systems?
A keyed hash can produce a consistent, deterministic value for the same PAN under the same key, which can support matching or de-duplication without retaining a readable PAN. However, that same determinism means the output is a stable identifier, so its handling, access, and scope implications should be evaluated. Correlation use cases should be assessed against the current standard and your data-handling policies rather than assumed to be out of scope.
How does keyed hashing relate to truncation, masking, and tokenization when protecting a PAN?
These are distinct methods that transform data differently: truncation permanently removes digits, masking hides digits in display without necessarily altering storage, tokenization substitutes a surrogate value typically via a separate mapping process, and a keyed cryptographic hash produces a one-way keyed output. Their effect on PCI DSS scope depends on how each is implemented and validated, not on the label. Verify acceptable methods and their conditions against the current published standard.

Common misconceptions

A keyed cryptographic hash provides confidentiality for the data it protects, similar to encryption.
A keyed hash is intended to support integrity and authenticity, not confidentiality. It does not conceal the underlying data in the way encryption is designed to, and it is not reversible to recover the original input. Encryption, tokenization, truncation, and hashing transform data differently, and their effect on PCI DSS scope depends on implementation and validation rather than the label alone.
Hashing a Primary Account Number, keyed or not, automatically removes it from PCI DSS scope.
Whether a hash reduces scope depends on the implementation and validation, not on the fact that a hash was applied. Where hashed and truncated versions of the same PAN could be correlated, additional controls may be needed. Practitioners should confirm the applicable requirements against the current published PCI DSS rather than assuming a fixed outcome or requirement number.
A keyed hash can be used to store sensitive authentication data safely after authorization.
Sensitive authentication data such as full track data, CAV2/CVC2/CVV2/CID, and PINs or PIN blocks must not be stored after authorization, even when transformed or encrypted. Applying a keyed hash does not create an exception to this prohibition.

Best practices

Use standardized keyed-hash constructions such as HMAC with a current, well-regarded hash function rather than ad hoc or homegrown methods.
Protect the secret key with documented key management processes covering generation, secure storage, distribution, rotation, and retirement, since the security of the keyed hash depends on key confidentiality.
Do not rely on a keyed hash to provide confidentiality; select encryption or other appropriate controls where concealing data is the objective.
Never use a keyed hash to justify storing sensitive authentication data after authorization, and confirm that only permitted cardholder data is retained under defined controls.
When hashing a PAN, evaluate the full implementation, including whether hashed and truncated forms could be correlated, and validate scope impact against the current published PCI DSS rather than assuming a fixed requirement number.
Document the intended security property (integrity and authenticity) and its limitations so that reviewers and auditors understand what the control does and does not address.