Decentralised models reduce risk because they avoid building a central database of where people went and who they met. If a system can verify exposure using published day keys and device-side checks, the authority does not need to store a rich movement log. That narrows the attack surface, limits secondary use, and makes misuse of collected data much harder.
Decentralised exposure notification reduces privacy risk by shifting exposure checks onto the device instead of concentrating contact histories in a central repository. That architecture limits how much location-adjacent or social-graph data any operator can see, store, or repurpose, and it also shrinks the damage if a component is compromised. The privacy gain comes from data minimisation, not from making the system invisible.
What changes when exposure matching happens on the device
In a centralised tracing design, the operator receives or can reconstruct a richer picture of who was near whom, when, and sometimes where. That creates a single high-value dataset with obvious retention, access, and misuse concerns. In a decentralised design, the authority publishes the information needed for verification, while phones perform the comparison locally, so the platform does not need a central movement log to determine exposure.
This matters because the privacy risk is not just about outsiders stealing data. It is also about ordinary operational use: retention creep, secondary analytics, insider access, and cross-purpose reuse all become harder when the system never aggregates the raw relationship data in the first place. The device becomes the place where the most sensitive inference happens, and the server role is narrower.
That is the same logic behind stronger data protection by design: collect less, centralise less, and reduce the number of parties that can observe the sensitive relationship. The decentralised model does not eliminate risk, but it substantially reduces the concentration of exposure that makes tracing data so attractive to misuse.
Why centralisation increases the privacy attack surface
A central tracing architecture creates a custody problem. The more complete the repository, the more attractive it becomes to attackers, data brokers, curious administrators, and future use cases that were never part of the original public-health purpose. Even if access is controlled, the mere existence of a central graph of encounters raises the stakes for breach, subpoena, and policy drift.
Decentralised exposure notification reduces that concentration effect. If verification can be done with published day keys and on-device checks, the system does not need to store the full network of encounters to deliver the service. That reduces the number of systems that must be protected, the number of identities that can query the data, and the number of ways the data can be repurposed later.
For practitioners, the key distinction is between a system that can answer “was I exposed?” and a system that can also answer “who met whom, where, and how often?” The second capability is what drives most of the privacy concern. When it is absent by design, the security and governance burden is materially lower.
What privacy risk remains in a decentralised model
Decentralisation is a risk reduction strategy, not a guarantee. Metadata can still leak through app telemetry, notification timing, key management mistakes, or poor implementation of the local matching logic. If the device-side workflow is weak, a server that stores less can still be undermined by a client that stores too much or exposes too much.
That is why the privacy review should focus on what the server can infer, what the device retains, and whether the published keys are limited to the minimum necessary for exposure checking. The design goal is not zero data, but reduced sensitivity, reduced central custody, and reduced reuse potential.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 sets the technical controls, while GDPR and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| GDPR | A.5.15 — Data protection by design and default | Exposure notification design is a privacy-by-design problem. |
| A.5.12 — Classification of information | Encounter data and keys need handling based on sensitivity and inferability. | |
| Recommendation — Minimise centrally collected encounter data and default to device-side matching. Classify exposure data as sensitive and restrict downstream use accordingly. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-rest is protected | Centralised tracing stores sensitive encounter data that must be protected if retained. |
| PR.AA-04 — Identity credentials are managed, verified, revoked, and audited | Access to tracing back-end data and operational tooling must be tightly governed. | |
| Recommendation — Protect any retained exposure data with strong storage controls and minimisation. Restrict and audit who can access any exposure-notification back-end data. | ||
| ISO/IEC 27001:2022 | A.5.12 — Classification of information | Tracing data sensitivity depends on the inferable relationship data it contains. |
| Recommendation — Classify encounter data conservatively and limit access to it. | ||
Practitioner Guidance
What to verify: Confirm that the server only receives what it genuinely needs to support exposure matching, and that it cannot reconstruct a durable contact graph from operational logs, analytics, or support tooling. If the back end can still infer who met whom, the privacy benefit has been eroded.
Decision rule: If a proposed feature requires central storage of encounter history, treat it as a material privacy expansion and re-review the data model before launch. Features built on aggregated encounter data should be assumed higher risk until proven otherwise.
What good looks like: The operator can publish keys, maintain availability, and support integrity checks without holding a rich behavioural record. The system should be able to demonstrate minimal custody, limited retention, and a narrow purpose boundary.
Practitioner takeaway: The privacy advantage of decentralised exposure notification comes from preventing sensitive relationship data from becoming a central asset in the first place; once that data is centralised, the risk profile changes fundamentally.
Related resources from NHI Mgmt Group
- When does secret exposure become a broader identity risk?
- How should teams reduce the risk from overprivileged NHIs?
- How should security teams reduce identity risk from everyday online privacy exposure?
- Why can decentralised identity approaches reduce the risk created by centralised identity databases?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
