Masking, truncation and hashing: what you can show, and where

Three treatments for a card number that are routinely used as synonyms. The PCI SSC defines them separately, and the difference decides whether a control does what you think.

Ask three people how the card numbers in a system are protected and you will get masking, truncation and hashing used interchangeably. The PCI SSC glossary defines them as three different things, and the differences are not cosmetic. Two of them protect stored data. One of them does not.

What each one is

The single most useful thing on that table is the right-hand column. Masking is defined against display and print. Truncation is defined against data that is stored, processed or transmitted.

Why that distinction breaks systems

Requirement 3.5.1.1 addresses the related trap directly: where hashed and truncated versions of the same PAN, or different truncation formats of the same PAN, are present in an environment, additional controls are required so the different versions cannot be correlated to reconstruct the original PAN.

A masked PAN on screen tells you nothing about what is in the database behind it. Masking conceals a segment when it is shown. The full number can be sitting in the record, in the log the query wrote, and in the backup taken that night.

This is a common and expensive misunderstanding. A team shows an assessor a screen displaying only part of the number and treats the storage question as answered. It is not the same question. Truncation removes the digits. Masking hides them.

If the full number can be recovered, it was masked, not truncated. The test is whether the removed digits still exist somewhere reachable.

Where hashing gets tricky

A one-way hash produces a fixed-length digest that cannot be reversed to the input. That property is what makes it useful for storage.

The complication is that a card number is a short value from a constrained set, so a hash of a PAN is vulnerable to being reconstructed by working forwards: generate candidate numbers, hash them, compare. That is why 3.5.1 asks for one-way hashes based on strong cryptography of the entire PAN rather than any hash function.

In PCI DSS v4.0.1 the two live in different requirements. Requirement 3.4.1 governs display: PAN is masked when displayed, and it states that the BIN and last four digits are the maximum number of digits to be displayed, with anything more restricted to personnel who have a documented, legitimate business need. Requirement 3.5.1 governs storage: PAN is rendered unreadable anywhere it is stored, by one-way hashes based on strong cryptography of the entire PAN, truncation, index tokens, or strong cryptography with associated key-management processes.

The practical checks

1. 1For every screen showing a partial PAN, find out what the underlying record holds. The screen is not evidence about storage.
2. 2Check the logs. Applications that mask on display frequently log the unmasked value on the way through.
3. 3Check exports and reports. A masked interface with an unmasked CSV export is a common pattern.
4. 4If you hash, confirm the method and that hashed and truncated forms of the same PAN are not sitting side by side.

How EmberHound fits

Those four checks all reduce to one question: where is a full card number actually present. EmberHound scans enrolled company devices and reports stored card data with the file and device attached, which covers the exports, logs and local copies that sit outside the application you designed.

The detection itself follows the same principle as the standard. Matching happens on the endpoint, and what leaves the machine is a masked preview and a salted fingerprint rather than the number.

This article is general information, not assessment advice. Your acquirer and your QSA determine what applies to you.