Skip to main content

Pseudonymization

Replace direct identity with a controlled reference while treating the mapping, stable links, attributes, and auxiliary data as remaining privacy risks.

Controlled replacement of identity

Pseudonymization replaces a direct identifier with a token or reference so ordinary processing does not need the person's identity. A separate mapping or other information can restore the association. Pseudonymized data remains personal and often remains linkable.

Design choices

Choose random tokens for stored mappings or keyed derivation with explicit domain separation when deterministic linkage is required. Scope by tenant, audience, purpose, and time. Protect mapping keys and tables with narrow identities, operations, access evidence, backup, rotation, and deletion.

Do not use an unkeyed hash of an email, phone number, or small identifier space. An observer can enumerate likely inputs. A global deterministic token creates correlation across every recipient.

Separation and resolution

Keep the resolver outside ordinary analytics and application paths. Define who can resolve a pseudonym, for which investigation or support purpose, under what approval, and with what notification and evidence. Return only the minimum identity attributes needed.

Retire tokens and mappings according to retention. Consider whether backups, exports, and recipients can keep the association after central deletion.

Failure and residual risk

Unique behavior, attributes, location, time, and external data can identify a record without the mapping. Stable pseudonyms reveal history. A mapping service is a high-value target and availability dependency. Key rotation can break continuity or preserve old links through dual mapping.

Pseudonymization reduces exposure. It does not make public release safe or remove re-identification risk.

Pomerium boundary

Pomerium needs stable subject information for authentication, policy, and evidence in configured contexts. Operators can minimize claims and use scoped application identifiers where the identity provider and upstream design support them. Hashing Pomerium log identities does not by itself anonymize access histories.

Evaluation checklist

  • Is the pseudonym random or keyed, and is it scoped by tenant, audience, purpose, and time?
  • Can an observer enumerate the input or link the same token across unrelated datasets?
  • Who can access the mapping or resolution operation, and what approval and evidence apply?
  • Which quasi-identifiers or behavioral patterns can identify the person without the mapping?
  • Do retention, rotation, backup, export, and deletion remove both mapping and unwanted links?

Sources and further reading

Keep learning

Privacy EngineeringCryptography and Data Protection

Personal Data and Metadata

Treat identifiers, device facts, access events, relationships, timing, locations, and derived attributes as personal when context can link them to people.

Learn this term

Get a Personalized Demo

Schedule a Call with a Pomerium Engineer

Get a Demo