Customer IDs and privacy: what not to put in an ID
Customer IDs leak. They appear in URLs, in log files, in support chat transcripts, in analytics dashboards, and in screenshots users post publicly. Designing an ID as if it stays inside your database is the original sin of identifier design — because it never does. The fix is simple: put nothing personal in the ID itself.
Why personal data in IDs is dangerous
An ID like CUST-jdoe-1985 broadcasts a name fragment and a birth year to everyone who sees it. That is personal data traveling in the least protected channel you have. The risks compound: IDs are rarely treated as sensitive (they get logged, cached, and shared freely), they are hard to change (everything references them), and they persist for the lifetime of the customer relationship. A password can be rotated; an ID baked into a thousand records cannot. Our formats guide covers the structural options — this guide covers what must never go inside them.
What counts as "personal" in an ID
| Never embed | Why it is risky | Use instead |
|---|---|---|
| Names or initials | Identifies the person directly | Random or sequential opaque ID |
| Birth dates / years | Enables identity fraud | Store DOB in a protected profile field |
| Email or phone fragments | Contactable identifier | Opaque ID; link to contact record internally |
| Government ID numbers | Regulated, high-value for fraud | Never in an ID; encrypted vault storage |
| Location codes (zip, city) | Narrows identity, goes stale on move | Opaque ID; location as separate attribute |
| Gender or demographic flags | Sensitive attribute, changes over time | Separate consented profile fields |
The opacity principle
The safest customer ID is opaque: a random or sequential value that reveals nothing about the person — CUS-8X4K2Q rather than CUST-jdoe-1985. All the meaningful attributes (name, email, segment, region) live in the customer record, linked by the ID, protected by access controls. The ID is just the key. This separation is also what privacy regulations expect: identifiers that minimize personal data by design are easier to defend in any compliance review. See why businesses use customer IDs for the legitimate jobs IDs do — none of which require personal data inside them.
Sequential IDs and enumeration
Opaque does not automatically mean safe. Sequential IDs (1001, 1002) reveal business metrics and are trivially enumerable — an attacker can walk the whole customer list by incrementing. If IDs appear in URLs or APIs, prefer random or prefixed-random formats and enforce authorization on every lookup: the ID being unguessable is defense in depth, not a substitute for access control. Never rely on ID obscurity as your only protection — that is security by obscurity, and it fails the moment someone shares a link.
Migrating away from personal IDs
Already have meaningful IDs in production? Migration is painful but possible: issue new opaque IDs, keep a mapping table, update references in phases (new code writes both, reads prefer the new), and retire the old IDs from customer-visible surfaces first — URLs, emails, and support tools — since those are the exposure points. Do not try to "scrub" meaning out of existing IDs in place; the history is already out there. Our ID best practices guide covers the mechanics of running the new scheme.
Key takeaway: customer IDs are public-facing by accident. Make them opaque, keep personal data in protected records behind access control, and treat unguessability as a bonus — never the plan. The same numbering discipline applies to other document identifiers — see our contract numbering policy guide.
IDs in URLs, logs, and tickets
Assume the ID will appear in all three — because it will. In URLs, prefer opaque IDs and always enforce authorization; never let the ID be the only access control. In logs, weigh redaction: full IDs in debug logs are useful until the logs ship to a third-party aggregator, at which point they become a data-sharing question. In support tickets, opaque IDs are safe to quote freely, which is precisely why support teams love them — no PII handling overhead on every conversation. Design the ID for its most exposed context, not its most sheltered one.
FAQ
Is a sequential numeric ID a privacy problem?
It reveals count and is enumerable, but it does not directly expose personal data. The bigger issues are business intelligence leakage and insecure direct object references — fix with authorization checks and, for exposed IDs, random formats.
Can I include the signup year in the ID?
Avoid it. It is low-value information that complicates the ID and can aid social engineering. Store signup date as a proper attribute instead.
What about initials plus numbers, like JD-4821?
Still personal data, and it breaks on name changes and collisions. Opaque IDs avoid all of it.
Do privacy laws actually regulate customer IDs?
IDs that contain or are linkable to personal data fall under data-protection rules wherever you operate. Opaque IDs minimize your exposure surface — which is the entire point.
Should customers ever see their own ID?
Often they must (support, account pages). That is fine — an opaque ID shown to its owner is harmless. The danger is personal data in an ID that travels beyond the owner.