Digital identity linkability is the degree to which separate records, sessions or transactions can be recognized as belonging to the same person. If two websites can tell that the same individual visited both, or one service can connect today’s login with last year’s purchase, those events are linkable.
Linkability is not always harmful, since some services need continuity to work. The problem arises when links form without a person’s knowledge or need. This article explains what makes identity data linkable, where links form in identity systems, how to measure them and which designs keep unnecessary links from forming.
When Two Records Point to the Same Person
Every identity interaction leaves traces: an account number in one database, a login event in another, a credential check in a third. On their own, each trace reveals a limited slice of someone’s life. Linked together, they form a timeline of behavior, relationships and locations.
Picture a hypothetical user who signs into a pharmacy app, a fitness tracker and a job board with the same identity provider account. If each service receives the same user identifier, anyone holding all three datasets can join them instantly. No name is needed; the shared identifier does the work.
Linkability is therefore a property of how identity systems are built, not only of what data they contain. Two systems holding similar data can differ enormously in privacy depending on whether their identifiers, signatures and metadata allow records to be matched across contexts.
Linkability, Identifiability and Traceability
Three related terms are often used interchangeably, but they describe different risks. Linkability means two items can be connected as relating to the same subject. Identifiability means an item can be tied to a specific real person, such as a named individual.
Records can be linkable without being identifiable. Two anonymous browsing sessions may share a device fingerprint, revealing that one unknown person performed both. Once any single linked record contains a name or email address, though, the entire linked set becomes identifiable at once.
Traceability usually refers to following an identity or transaction back to its origin, such as connecting a credential presentation to the moment it was issued. Privacy frameworks, including published privacy engineering guidance, treat reducing linkability as a core protection goal because it limits how far a single disclosure can spread.
The Handles That Make Records Linkable
Links form through handles, meaning any value or pattern that repeats across contexts. Identifying these handles is the first step toward deciding which links are necessary and which should be designed away.
Direct Identifiers
Email addresses, phone numbers, government ID numbers and global user IDs are the most obvious handles. They are designed to be unique and stable, which makes them perfect for matching.
A single email address reused across dozens of services acts as a master key that joins all of those accounts together, whether or not the person intended that connection.
Cryptographic Artifacts
Identity systems also produce cryptographic values that can serve as handles. A credential’s signature, a certificate’s serial number or a public key reused across services all repeat each time they appear.
Even when attributes are hidden, these repeated values let verifiers recognize the same credential. Designs that generate fresh proofs or per-service keys remove this kind of handle from presentations.
Metadata and Behavior
Some handles are not identity data at all. IP addresses, browser characteristics, typing patterns, location history and activity timing can link sessions together.
Behavioral patterns are probabilistic rather than exact, but combined with other clues they can be highly distinctive, which is why removing direct identifiers alone rarely produces genuine unlinkability.
Deterministic and Probabilistic Linking
Linking methods fall into two broad categories. Deterministic linking matches records using an exact shared value, such as the same email address or account number. It is precise and simple, and it is the reason stable identifiers are so powerful.
Probabilistic linking estimates the likelihood that two records belong to the same person by comparing several imperfect signals, such as similar names, overlapping locations and matching device traits. Each signal is weak on its own, but together they can produce confident matches across systems that share no common identifier.
This distinction matters for defense. Removing exact identifiers stops deterministic linking but may leave probabilistic linking intact. Effective protection considers both, reducing stable identifiers while also limiting the quasi-identifiers and metadata that let statistical matching succeed.
Linking Points Across the Credential Lifecycle
Identity credentials pass through several stages, and each stage can create links. At issuance, the issuer learns who received a credential and may record identifiers embedded in it. Those identifiers can later connect every use back to the issuance record.
At presentation, the verifier sees whatever handles the credential carries. If the same signature or holder key appears each time, different verifiers can compare notes, and the same verifier can recognize repeat visits even when no name is shown.
Validity checks introduce another link. If verifying a credential requires contacting the issuer, the issuer can learn where and when each credential is used. Designs that publish status in shared lists, or let holders prove validity without contacting the issuer, avoid creating this observation point.
Federation and Single Sign-On as Linking Hubs
Federated identity, where one identity provider authenticates users for many services, is convenient and often more secure than separate passwords. It also concentrates linkability. The identity provider sees every service a user signs into, creating a detailed log of online activity in one place.
Relying parties can also link users if the provider sends the same identifier to each of them. OpenID Connect addresses this with pairwise subject identifiers, which give each relying party a different stable identifier for the same person, preventing simple matching between services.
Pairwise identifiers do not help when the provider also shares an email address or phone number, which links accounts directly. Organizations operating federation should combine pairwise identifiers with careful attribute release, so that convenient single sign-on does not silently become a cross-service tracking system.
When Linkability Serves a Purpose
Some links are necessary and beneficial. A bank must recognize returning customers, a fraud team must connect suspicious transactions, and an account recovery process must link a new device to an existing account. Removing all linkability would break these legitimate functions.
The goal is scoped linkability: links that exist within a defined context for a defined purpose, without spreading further. A bank linking a customer’s transactions internally is expected; sharing a stable customer identifier with advertising partners extends that link beyond its purpose.
Making links visible helps users and auditors. Services can explain which activities are connected, why and for how long. When the purpose ends, such as when an account closes, the identifiers enabling those links should be deleted or rotated so old records cannot be rejoined later.
Design Techniques That Limit Unwanted Links
Engineers have a well-established toolkit for reducing linkability. Most techniques replace global, stable handles with local or short-lived ones, so that each context sees only what it needs to function.
- Pairwise and per-context identifiers so different services cannot match users by ID.
- Per-site authentication keys, as used by passkeys based on FIDO2 and WebAuthn.
- Unlinkable credential proofs that look different on every presentation.
- Batch-issued credentials with distinct salts and keys, used once each.
- Privacy-friendly status checks that avoid contacting the issuer per use.
- Metadata reduction, such as truncating IP addresses and minimizing logged device details.
These techniques complement each other. A system using per-site keys but logging full IP addresses and device fingerprints still leaves strong probabilistic links, so reviews should cover protocol design and operational logging together.
Testing a System for Linkability
Linkability is easiest to understand through deliberate testing. Teams can simulate how an observer, or several colluding observers, might connect records, and then adjust designs to break the links that serve no purpose.
- List every observer, including issuers, providers, verifiers, analytics tools and network operators.
- Record what each observer sees in a typical transaction, including identifiers, signatures and metadata.
- Compare views across observers to find values that repeat between contexts.
- Rank each link by necessity, sensitivity and how widely it spreads.
- Redesign or document each unnecessary link, then retest after changes.
Repeating this exercise when features change keeps linkability from creeping back in through new integrations, logging changes or third-party scripts added after the original review.
How Everyday Choices Create or Break Links
Individuals create many links without noticing. Signing up for every service with one email address, using the same phone number for two-factor codes everywhere and choosing one social login for all apps each build a shared handle that ties otherwise separate parts of life together.
Breaking unnecessary links does not require technical expertise. Grouping accounts into categories, such as finance, health, work and leisure, and giving each category its own email address limits how far a single identifier spreads. Email alias features can extend this to individual services where the provider supports them.
Browser habits matter as well. Separate browser profiles for different activities keep cookies and saved logins apart, and reviewing app permissions limits location and contact data that can link accounts. These steps will not stop every form of tracking, but they remove the easiest and most reliable handles.
Making Unlinkability a Default Requirement
For organizations, the most effective step is to write unlinkability into design requirements. New features should state which identifiers they use, which contexts can see them and how long they persist. Reviewers can then challenge any global identifier that lacks a documented purpose.
For individuals, the next practical step is a short audit: list the email addresses and phone numbers tied to major accounts, note which services share a single sign-in, and separate the most sensitive categories first, such as health and finance.
As credential formats with unlinkable proofs and per-context identifiers mature, the technical barriers to private identity will continue to fall. The lasting challenge will be organizational discipline: choosing not to link records simply because the data makes it possible.