Key-Custodian Separation
also called Token Vault Separation, Split-Custody Pseudonymisation
Keeping the mapping or key that re-identifies pseudonymised data in a system with a different access path from the data itself - so a breach of the analytical store yields behaviour without people.
A warehouse leaks. Whether that is an incident or a catastrophe depends on one property: can the identifiers in it be recovered using only what leaked? Hashing an email fails this test, because the space of plausible addresses is small enough to enumerate against commodity hardware running billions of hash evaluations a second. Encrypting a column with a key stored beside it fails for the obvious reason.
Key-custodian separation is the discipline of making re-identification depend on a second system, with a second access path, second credentials and its own audit trail.
Why it matters
Pseudonymisation does not remove data from the scope of data protection law. What it changes is the consequence of a breach and the reach of internal access. A separated custodian converts a warehouse compromise from a disclosure of customers into a disclosure of behaviour, which is the difference between a notifiable breach involving people and an embarrassing one involving rows.
It also makes internal access defensible: analysts get tokens, and the small number of processes that genuinely need identity call the custodian and are logged doing it.
Implementation patterns
- Random token plus mapping table. The token carries no information about the subject, so the only path back is the mapping. Rotation and revocation become possible because the mapping is data rather than a function of the input.
- HMAC with a separately held key as the cheap variant, correct when you never need to reverse the mapping. Its weakness is rotation: a new key breaks every historical join, so it suits short-lived data and not multi-year analysis.
- Batch tokenisation at ingest, so a per-event call to the custodian never lands on a hot path. A 10k-events-per-second stream calling a vault per event has made the vault a tier-1 dependency of ingestion.
- Re-identification as an audited service call, never as a table join. The audit trail is the control that makes the design defensible internally.
- Separate infrastructure ownership: different account, different network path, different on-call, so a compromise of the analytics platform does not carry the custodian with it.
Industry example
Payment tokenisation is the mature form of this pattern: merchants hold a token that is useless outside the acquirer's context, while the card number sits with the party that must hold it. The scope reduction that PCI DSS assessments recognise for tokenised environments — carried through into version 4.0 of the standard in 2022 — comes from exactly this separation, and it is the reason a commerce platform that stops storing card numbers shrinks its assessment boundary rather than merely encrypting more.
Failure scenarios
- The hash that was called anonymisation, reversed by enumeration within hours of the leak.
- The vault that became a join. Someone materialises the mapping into the warehouse for convenience and the separation is gone with no alert.
- Key rotation that breaks two years of history, discovered when a cohort analysis returns nonsense rather than an error.
- The custodian as a single point of failure, taking ingestion down with it because tokenisation was synchronous and unbuffered.
- Linkage attacks across releases, where tokens are stable and two published extracts intersect to re-identify people even though neither contains an identifier.
Trade-offs
| Choose | Gains | Pays |
|---|---|---|
| Random tokens with a vault | Revocation and rotation without breaking joins | A tier-1 dependency and a concentrated target |
| HMAC with a held key | No vault to operate, no lookup latency | Rotation breaks historical joins |
| Dropping the identifier | Nothing to protect | No longitudinal analysis at all |
When not to use it
If nobody can articulate a question that requires per-person linkage, delete the identifier instead. That is cheaper, faster and strictly safer than any custody scheme, and the requirement for two-year user-level analysis frequently evaporates when someone is asked to name the decision it supports. Equally, for data that will be published outside the company, token separation is the wrong control: stable tokens still permit linkage across releases, so aggregation thresholds or formal privacy guarantees are what that job needs.
Interview question
Q: An analytics team wants two years of user-level event history in the warehouse. Design the identifier strategy, and tell me what a breach of the warehouse would then disclose.
What a strong answer covers: rejecting plain hashing with the enumeration argument · the vault or HMAC choice driven by whether reversal is needed and how joins survive rotation · batch tokenisation to keep the custodian off the hot path · the audit trail on re-identification · that pseudonymised data remains personal data · and the counter-question of whether per-user history is needed at all.
Quick check
Quiz: Why is SHA-256 of an email address not adequate pseudonymisation? The identifier space is small enough to enumerate, so the hash is recomputable from a guess and the column is equivalent to the addresses.
Flashcard: What does a token vault buy that a keyed hash does not? — Rotation and revocation without breaking historical joins, because the mapping is stored data rather than a function of the input.