A Day Key is a secret value generated for a single day and used to create the transient identifiers that other devices receive. When a user reports an infection, selected day keys can be published so other phones can check for matches locally. The key itself is not meant to reveal whereabouts or identity.
What Day Keys Do in Exposure Notification Systems
Day keys are short-lived secret values that sit at the boundary between privacy and matching. They are not the broadcast identifiers themselves, but the source material that lets devices derive those identifiers for a specific day without exposing a person’s routine or direct identity.
The design goal is to keep the matching system useful while limiting what any published or observed value can reveal. That makes the day key a control point for both identifier generation and privacy protection, because its scope is intentionally narrow and time-bound.
In practical terms, the day key is part of a larger ephemeral identifier scheme. It supports local comparison on user devices, so the system can detect possible exposure without centralizing a full movement history or turning the key into a tracking token.
How Day Keys Relate to Transient Identifiers
The key’s main function is derivation. A device uses it to create the rolling or transient identifiers that other devices receive over time, usually changing frequently enough that passive observers cannot treat one identifier as a stable label.
This separation between the secret and the broadcast identifier is important. The identifier can be shared widely, but the day key is the more sensitive input because it can be used to reproduce that day’s identifier set. The security model depends on keeping the two roles distinct.
When a user later reports an infection, selected day keys can be published so other phones can compare locally against what they observed. That publication pattern is designed to support exposure checking without exposing the full secret history needed to recreate every prior day.
Privacy Properties and Trust Boundaries
Day keys are meant to reduce the value of intercepted broadcasts, because the observed identifier is not supposed to directly reveal whereabouts, identity, or a long-lived account link. The privacy promise comes from rotation, locality, and the limited meaning of any single day’s material.
That said, the trust boundary is narrow. If a day key were exposed too broadly, the derived identifiers for that period could become more useful to an observer, especially if combined with timing, proximity, or external context. The scheme depends on short retention, minimal publication, and local-only comparison.
The design therefore trades centralized visibility for distributed verification. Devices do the matching themselves, which improves privacy posture, but also makes correct implementation of key generation, publication, and retention essential to the whole model.
Where Day Keys Fit in the Exposure Checking Workflow
Day keys are only one step in the workflow, but they are the step that connects private generation to public checking. They help create the identifiers a handset advertises, then later help other handsets decide whether any observed identifier belongs to a reported exposure window.
Because the process is time-scoped, operational mistakes matter. If key windows are misaligned, retained too long, or reused beyond their intended period, the system can weaken privacy or reduce the quality of matching. If keys are published too early or too broadly, they can reveal more than the design intends.
For readers, the important point is that a day key is not a user identity, not a tracker, and not the exposure event itself. It is a transient secret used to support local comparison in a privacy-preserving workflow.
Risk and Threat Considerations
Day keys carry a real privacy risk because they are secret inputs to a broadcast identifier scheme. If they are leaked, reused, or handled outside their intended time window, an observer may gain more ability to correlate observations or reconstruct a person’s daily identifier set.
Failure mechanism: Weak key handling, overlong retention, or premature publication can turn a short-lived secret into a broader correlation primitive, especially when combined with location, timing, or repeated observation.
Impact: The main consequence is degraded privacy, with a larger chance of tracking, linkage, or unwanted inference about exposure or movement patterns.
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 provides the primary governance reference for this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Day keys are time-bounded secret material that must be generated, protected, rotated, and retired correctly. |
| SC-12 — Cryptographic Key Establishment and Management | Day keys are secret values used to derive transient identifiers and depend on controlled cryptographic handling. | |
| AC-6 — Least Privilege | Only narrowly necessary processes should access or publish day keys because broader access increases privacy risk. | |
| Recommendation — Manage day-key lifecycle tightly, including rotation, storage, and retirement, to reduce exposure from secret reuse. Apply controlled key-management practices so derived identifiers remain ephemeral and resistant to exposure. Restrict access to day keys and their publication paths to the smallest set of authorized processes. | ||
Practitioner Guidance
Why practitioners should care: The practical challenge is not just generating a key, but ensuring its lifetime, publication rules, and derivation behavior preserve the privacy model the system relies on. If those controls drift, the scheme can still function technically while losing its intended confidentiality benefits.
Common misunderstanding: A short-lived secret is not automatically safe just because it rotates daily. Its safety depends on whether the daily boundary is enforced consistently and whether published material remains limited to what local checking actually requires.
Practitioner takeaway: Treat the day key as a sensitive, time-bounded secret whose handling should be designed around minimal disclosure and minimal reuse.
Related resources from NHI Mgmt Group
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
