An example of a linkage attack is correlating supposedly separate records by combining shared attributes such as postcode, age range, device details, or behaviour patterns until a person can be re-identified. Defenders reduce the risk by minimising exposed attributes, applying privacy-preserving aggregation, and testing whether released data can be joined back to individuals.
How linkage attacks work in practice
A linkage attack starts with data that looks harmless in isolation, then joins it across sources until the combined profile points back to one person. The practical danger is not a single obvious identifier, but the cumulative effect of quasi-identifiers that become distinctive when matched together.
In real deployments, the attacker does not need every field to be unique. A postcode, age band, device fingerprint, purchase pattern, or repeated behavioural signal may be enough once records are compared against other datasets, especially when the same person appears across multiple systems or time periods.
This is why privacy engineering focuses on reducing linkability, not just hiding names. Techniques such as tokenisation, masking, k-anonymity-style grouping, differential privacy, synthetic data, and clean rooms all aim to make re-identification harder by weakening the joins an adversary can make. NHIMG’s Privacy-Enhancing Technologies Guide is a useful reference point for those controls.
What a real-world linkage attack looks like
A common example is a published or shared dataset that removes direct identifiers but keeps enough structure for correlation. An analyst, competitor, or attacker may combine it with public records, marketing data, device telemetry, or other internal datasets, then narrow the population until one record set maps back to a named individual.
Linkage attacks are especially effective when organisations release several “safe” datasets over time. One extract may contain age and location, another may contain device or usage details, and a third may contain event timing. Each release can be modest on its own, but the combined set can become highly identifying.
The same pattern appears when teams over-share attributes for analytics or troubleshooting. If the data can still be joined back to an employee, customer, patient, or user, the release has not really been de-identified in a practical sense. For that reason, the test is not whether a record feels anonymous, but whether it resists realistic re-linking.
Why defenders treat linkage as a privacy and security problem
Linkage attacks matter because they turn ordinary data sharing into re-identification risk. Once a person is recoverable from the dataset, downstream harms can include privacy loss, targeting, unwanted profiling, policy breach, and in some cases exposure of regulated or sensitive attributes that were never meant to be disclosed.
The defensive question is whether the published or shared dataset still supports joins that a motivated party could make. Minimising attributes, generalising values, segregating datasets by purpose, and testing linkability before release are all more reliable than assuming that removing names alone is enough.
Current privacy practice also recognises that utility and privacy trade off against each other. The more precise the data, the easier it is to match; the more aggressively it is transformed, the less operational value it may retain. That tension is why privacy-preserving aggregation and disclosure review need to happen before publication, not after.
Risk and Threat Considerations
Linkage attacks are risky because they exploit the fact that “anonymous enough” for one team is not necessarily anonymous enough against a broader data environment. Once multiple releases or sources can be correlated, the residual risk shifts from theoretical anonymity loss to practical re-identification and profile reconstruction.
Failure mechanism: Shared attributes, repeated patterns, and stable quasi-identifiers let an adversary join records across datasets until one subject can be singled out, even when direct identifiers were removed.
Impact: Individuals can be re-identified, sensitive context can be inferred, and data that was expected to be low risk may become personal, regulated, or operationally sensitive again.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while GDPR defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | PT-2 — Pseudonymization | Supports reducing re-identification risk in shared data |
| DM-2 — Data Retention and Disposal | Limits unnecessary retention of datasets that can later be linked or recombined | |
| AC-6 — Least Privilege | Restricts who can access rich datasets used for linkage and re-identification | |
| Recommendation — Apply PT-2-style pseudonymization to reduce direct linkability before data release. Dispose of unnecessary datasets to shrink the pool available for linkage attacks. Restrict access to high-resolution datasets to the smallest needed set of users. | ||
| GDPR | Art.25 — Data Protection by Design and by Default | Requires privacy controls that limit re-identification risk in data publishing |
| Recommendation — Build privacy-preserving aggregation and minimisation into the release process. | ||
Practitioner Guidance
What to verify: Treat any dataset as linkable until you have tested it against realistic external and internal joins. Verify whether combinations such as location, timing, device detail, and behaviour still leave unique or near-unique records.
Decision rule: If the dataset supports individual-level joins after basic masking or removal of names, escalate to stronger transformation, tighter access, or narrower release scope rather than relying on a de-identification label.
What good looks like: The released data supports the intended analysis, but no plausible secondary dataset can recover a specific person with high confidence from the published attributes alone.
Practitioner takeaway: The practical test is not whether data looks anonymous in one table, but whether it stays non-linkable when an informed party combines it with everything else they can realistically access.
Related resources from NHI Mgmt Group
- What is an example of Camera Hijack Attack on Facial Recognition System in practice?
- What is an example of Morris II Worm: RAG-Based Attack in practice?
- What is an example of Web-Scale Data Poisoning: Split-View Attack in practice?
- What is an example of Rules File Backdoor: Supply Chain Attack on AI Coding Assistants in practice?