What happens when exposure notification relies on centralised risk scoring instead of device-side checks?

When risk scoring moves to a central server, the system has to receive more contact details and processing inputs than a device-side approach would need. That increases trust requirements, expands the amount of sensitive data handled in one place, and makes the backend a more attractive target. The result is a larger privacy burden even if the system still aims to be useful.

Why centralised scoring changes the privacy and trust model

Device-side exposure notification keeps more of the decision-making local, so the server can stay comparatively blind to who met whom and when. Once risk scoring moves centrally, the backend needs additional encounter data, inferred risk inputs, or processing signals to compute a result. That changes the trust boundary, because the service operator now becomes part of the scoring decision rather than only a transport or coordination layer.

That shift matters even if the public-health goal stays the same. The central service now has a larger concentration of sensitive data, a clearer ability to correlate records, and a stronger incentive for attackers or insiders to target the scoring pipeline rather than many phones.

It also changes the privacy posture of the programme itself. A design that can be safe on-device may become harder to justify centrally if the same utility can be achieved with less data exposure and less server-side processing.

What central scoring changes operationally

Centralised risk scoring usually means the backend must ingest more context, retain it long enough to score it, and protect the resulting decision state. That creates a larger administrative surface for access control, logging, retention, and abuse monitoring. It also increases the number of places where a mistake can expose encounter history or enable re-identification through linkage.

The operational trade-off is straightforward: central scoring can make policy updates, model changes, and consistency easier to manage, but those gains come at the cost of a more sensitive backend and a broader blast radius if the service is compromised or over-privileged.

For practitioners, the key question is whether the central score genuinely needs raw encounter detail or whether it can work from less revealing inputs, shorter-lived state, or a split design that keeps most checks on device.

Why device-side checks are usually the more privacy-preserving default

Device-side checks reduce the amount of contact data that must leave the handset, which limits central visibility and lowers the consequences of server compromise. The design is not privacy-free, but it narrows the set of parties that can observe or reconstruct encounter patterns.

That said, device-side scoring can be harder to govern uniformly, especially if local devices differ in update speed, policy enforcement, or operating-system support. The practical goal is not decentralisation for its own sake, but to place the most sensitive processing where it creates the least unnecessary data exposure.

When evaluating a centralised design, the useful comparison is not only performance or convenience. It is whether the server really needs to see enough information to justify the added trust burden, or whether a local or hybrid approach can preserve the same outcome with less central concentration.

Risk and Threat Considerations

Centralised risk scoring increases the value of the backend as a target because one compromise can expose many encounters, scoring decisions, or linked identifiers at once. It also creates a stronger privacy risk if the service accumulates more data than it strictly needs, because re-identification and correlation become easier as the dataset grows.

Failure mechanism: More contact details and scoring inputs are collected into one backend, expanding the number of users, services, and operators that can access or misuse the data, and increasing the impact of a server breach, insider abuse, or weak retention controls.

Impact: The system can lose the privacy advantage that exposure notification was meant to preserve, and any compromise can affect a much larger set of people than a device-side design would expose.

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 and NIST Zero Trust (SP 800-207) set the technical controls, while ISO/IEC 27001:2022 and GDPR define the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Central scoring concentrates sensitive encounter data and backend access.
	AU-2 — Event Logging	A central backend needs stronger traceability over access to sensitive scoring data.
Recommendation — Limit backend access to the minimum users and services needed to score notifications. Log access to scoring inputs, decisions, and administrative actions on the backend.
ISO/IEC 27001:2022	A.8.3 — Information access restriction	Centralised scoring increases the need to restrict access to contact and risk data.
Recommendation — Restrict access to scoring inputs and outputs to only authorised personnel and services.
GDPR	Art. 5 — Principles relating to processing of personal data	Central scoring raises data minimisation and purpose-limitation concerns.
Recommendation — Minimise collected encounter data and keep processing limited to the stated notification purpose.
NIST Zero Trust (SP 800-207)	AC-4 — Information Flow Enforcement	A central scoring service becomes a trust boundary that should tightly control data flow.
Recommendation — Enforce strict flow controls between mobile clients, scoring services, and data stores.

Practitioner Guidance

What to prioritise: Minimise the data needed for scoring before you optimise the scoring logic itself. If the same policy outcome can be achieved with local checks, short-lived tokens, or aggregated inputs, that should be preferred over central collection of encounter detail.

What to verify: Confirm who can access raw encounter data, what is retained, and whether the scoring service can operate without making the backend a long-term repository of sensitive proximity history. If the trust model depends on broad backend access, treat that as a design risk rather than an implementation detail.

Practitioner takeaway: The main decision is not central versus local in the abstract, it is whether central scoring adds enough value to justify expanding the trust boundary and concentrating sensitive data in one place.