Keyed Pseudonym
also called HMAC Pseudonymisation, Secret-Keyed Identifier
Replacing a person's identifier with an HMAC or random mapping that only the data controller can compute, so downstream parties can join a user's events but cannot recover or match the identity.
An analytics vendor receives events keyed by SHA-256 of the user's email. The vendor, or anyone with an email list, hashes candidate addresses and matches them in seconds, because the input is guessable and the hash is fast. A keyed pseudonym uses a secret key (HMAC-SHA-256) or a random lookup table held only by the controller, so the identifier has no relationship to the email that an outsider can compute.
Why it matters
Hashing an enumerable identifier is not anonymisation, and regulators say so: pseudonymised data remains personal data under GDPR, and only a design in which re-identification needs information held separately counts as a real safeguard. The difference between an unsalted hash and a keyed pseudonym is the difference between a safeguard and a label.
Implementation patterns
- HMAC-SHA-256 with a secret key held in a key management service, the key never shared with processors.
- Random surrogate IDs with a mapping table in a restricted store; no derivation exists to attack, at the price of storing the table.
- Purpose-specific pseudonyms: derive a different pseudonym per vendor or purpose (HMAC over identifier plus purpose string), so datasets cannot be joined across them.
- Key versioning: include a key version in the output so rotation does not silently reset history; keep old versions for the retention period.
- Separation of duties: the mapping or key is held by a different team from the analysts, with access logged.
- Deletion path: to honour an erasure request, delete or break the mapping (for a table) and submit deletions to processors.
Industry example
This is an archetype from consumer platforms: a music or video service sending behavioural events to analytics and advertising partners. Public reporting and regulator guidance, including the European Data Protection Board's guidelines on pseudonymisation (draft, January 2025), describe the key point that a pseudonym remains personal data when the controller can reverse it, which is why designs separate the key from the data and use per-recipient identifiers. No specific company's implementation is cited here.
Failure scenarios
- Unkeyed hash of an email or phone number: reversed by dictionary; phone numbers fall in minutes because the space is small.
- One global pseudonym shared across vendors, enabling joins that defeat the separation.
- Key leak with the dataset (the key stored beside the data), giving the attacker both halves.
- Rotation without versioning, which breaks longitudinal analysis and tempts teams to freeze the key forever.
Trade-offs
| Choose | Gains | Pays |
|---|---|---|
| HMAC with secret key | Stateless, deterministic, no table | Key custody and rotation complexity |
| Random mapping table | No derivable relationship | Table storage and lookup latency |
| Plain hash | Easy | Trivially reversible for guessable inputs |
When not to use it
For aggregates published publicly, aim for anonymisation with minimum group sizes instead; pseudonyms still identify individuals' trajectories. If the downstream party does not need to follow individuals, send no identifier at all.
Interview question
Q: A vendor needs a stable user identifier for analytics but must not be able to identify users. Design it.
What a strong answer covers: why hashing emails fails; HMAC with a controller-held key or a random mapping; per-vendor derivation; key versioning and rotation; deletion and subject access handling; GDPR status of pseudonymised data; and minimising which attributes accompany the identifier.
Quick check
Quiz: Why is SHA-256 of an email a weak pseudonym? The input space is enumerable and the hash is fast, so a list of emails reverses it.
Flashcard: What makes a pseudonym 'keyed'? — A secret held only by the controller is needed to compute or reverse it.