The time-of-check to time-of-use gap is the security window between when software is inspected and when it is later executed. In supply-chain security, a package may appear safe during build validation but become malicious, be reclassified, or behave differently once running in production.
Expanded Definition
Time-of-check to time-of-use gap describes a trust gap between inspection and execution. The check may occur during code review, package scanning, signature verification, sandboxing, or policy evaluation, while the use happens later in a different runtime state. The security problem is not the check itself, but the assumption that what was checked remains unchanged.
In practice, the gap matters when software, dependencies, identities, or permissions are mutable between validation and execution. A package can be benign when assessed and still become risky if its content, metadata, resolution target, or execution context changes afterward. That is why the term is often discussed in supply-chain security, runtime authorization, and systems that make decisions based on stale state.
There is a useful boundary here: this is not the same as a simple scanning failure. The scan may be correct and still insufficient because the system later acts on a different object, different version, or different trust condition. For readers working with machine access and secrets, the same pattern appears when a credential is validated, then reused after its scope or lifecycle has changed. The OWASP Non-Human Identity Top 10 OWASP Non-Human Identity Top 10 is a useful adjacent reference where this trust-gap pattern intersects with service identities and secret handling.
Examples and Use Cases
- CI pipelines verify a dependency at build time, but the referenced artifact is swapped or retagged before deployment.
- A policy engine checks file permissions before launch, yet the file path is redirected after validation and before execution.
- A service account token is confirmed as valid during approval, but its privileges change before the workload actually uses it.
- A package registry entry is scanned as clean, then the publisher changes the content or publishing metadata later in the lifecycle.
- An agentic workflow authorizes a tool call using current context, but the execution step occurs after the context has drifted.
The common implementation tradeoff is speed versus assurance. Narrowing the gap usually means adding binding controls, stronger provenance, or repeated validation closer to execution, but that can increase pipeline complexity and runtime overhead.
For security teams, the practical challenge is that evidence of safety can age quickly. A result that was accurate during intake may no longer describe the object that actually runs.
Security Implications
When this gap is misunderstood, defenders may overtrust earlier validation and undercontrol the later execution path. The result is a false sense of safety: the system believes it approved one thing, while production consumes another. That mismatch can expose build systems, release pipelines, runtime environments, and downstream users to malicious or altered code.
The main failure mechanism is state drift between verification and use. Attackers and other hostile actors may exploit mutable references, delayed execution, dependency replacement, or context changes to turn a validated object into an unsafe one after checks have passed. In identity-heavy systems, the same mechanism can lead to stale authorization decisions, overbroad token reuse, or unexpected privilege at execution time.
Observable symptoms include benign scan results followed by unexpected runtime behaviour, inconsistent artifact hashes, approval records that do not match deployed content, and access decisions that no longer match current scope. The operational consequence is that incident teams may trust the wrong checkpoint and miss the real point of compromise.
Domain and Governance Relevance
In supply-chain security, the term is a governance issue as much as a technical one. It pushes organisations to ask what exactly is being checked, what remains bound to the result, and which later step is still permitted to change. A check that does not constrain the subsequent use may satisfy a process requirement while leaving the actual risk untouched.
In identity and NHI environments, the concept becomes more material because non-human actors often operate at machine speed and with long-lived credentials or tokens. That makes stale validation especially dangerous when a workload, agent, or service can continue acting after its trust state has changed. For this reason, the gap is relevant wherever execution depends on secrets, delegated authority, or externalised policy decisions.
Governance should therefore focus on trust continuity, not just one-time approval. The key question is whether the control still holds at the moment of use, not only at the moment of inspection.
Risk and Threat Considerations
This concept creates material exposure when organisations treat an earlier check as proof that later execution is safe. The risk is highest where artifacts, identities, or policies can change between verification and use, especially in automated pipelines and runtime-dependent authorization flows.
Failure mechanism: An attacker or hostile change exploits the interval after validation by altering the artifact, retargeting the reference, or waiting for the environment to drift so the checked object is no longer the used object.
Impact: A trusted approval can be bypassed without breaking the original check, leading to malicious code execution, stale privilege, unauthorized access, or deployment of an object that no longer matches the verified state.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 2 — Inventory and Control of Software Assets | Tracks approved software state so execution matches validated inventory. |
| 16 — Application Software Security | Addresses build and release controls that must preserve software integrity through deployment. | |
| Recommendation — Inventory software assets continuously and block execution of unapproved or altered artifacts. Apply application security controls that keep verified code and deployed code aligned. | ||
| MITRE ATT&CK | T1036 — Masquerading | Covers attacker use of altered or disguised artifacts after initial trust is established. |
| Recommendation — Map suspicious post-check changes to T1036 and investigate disguise or replacement activity. | ||
| NIST CSF 2.0 | PR.DS — Data Security | Supports integrity protections for artifacts whose state must remain stable between check and use. |
| Recommendation — Protect artifact integrity so verified objects remain unchanged until execution. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Applies when the gap affects machine identities, secrets, or delegated access used later at runtime. |
| Recommendation — Bind machine credentials to current state and revoke stale access before execution. | ||
Practitioner Guidance
What to watch for: Treat a long or loosely bound interval between validation and execution as a control weakness, not a process detail. The most common mistake is assuming that a successful check remains valid across asynchronous build, deploy, or authorization steps.
Governance implication: Assign ownership for the trust boundary between check and use, especially where build systems, package repositories, and non-human identities are involved. If the control cannot bind the approved state to the executed state, it should not be treated as a final assurance point.
Practitioner takeaway: The closer the assurance step is to execution, and the more tightly the checked object is bound to the used object, the less room exists for state drift to become a security failure.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
