Time-Of-Check To Time-Of-Use Gap

Expanded Definition

The time-of-check to time-of-use gap describes a security weakness where software is validated at one point in time, then relied on later under different conditions. In NHI and software supply-chain security, that delay matters because an artifact can be inspected as benign during build, approval, or scanning, then altered, repackaged, or activated with different behavior before production execution.

Definitions vary across vendors, but the core issue is consistent: trust is being granted based on a stale assessment. The gap is especially important for packages, containers, scripts, signed artifacts, and automation jobs that move through CI/CD pipelines with multiple handoffs. NIST’s NIST Cybersecurity Framework 2.0 reinforces the broader need to maintain integrity across the full lifecycle, not just at a single checkpoint.

The most common misapplication is treating a successful pre-deployment scan as proof of runtime safety, which occurs when teams ignore post-check behavior, dependency drift, or pipeline tampering.

Examples and Use Cases

Implementing time-of-check to time-of-use controls rigorously often introduces pipeline friction, requiring organisations to weigh faster delivery against stronger integrity verification at the point of execution.

• A build artifact passes signature verification in CI, but the deployment job pulls a newer mutable tag, creating a mismatch between what was checked and what actually runs.
• A dependency is scanned during compilation, yet the package registry is compromised before deployment, so the runtime package differs from the validated version.
• A container image is approved in staging, but the orchestrator allows an init script or sidecar to fetch unreviewed code after the approval step.
• A service account token is valid during inspection, then remains usable long enough for an attacker to swap the referenced binary or configuration before execution.
• An NHI-controlled automation task is reviewed against policy, but permissions expand before the task runs, making the original check obsolete.

In supply-chain analysis, the Ultimate Guide to NHIs is useful for understanding how exposed identities, secrets, and third-party connections increase the blast radius when the checked object is not the same object that later executes.

Why It Matters in NHI Security

Time-of-check to time-of-use gaps matter because NHI environments depend on automation, delegated authority, and machine-speed trust decisions. If the checked artifact can change after approval, then secrets, service accounts, API keys, and deployment credentials may be used to execute code that was never truly trusted. This is why the issue shows up alongside secret sprawl, privilege abuse, and pipeline compromise. NHI Mgmt Group notes that 96% of organisations store secrets outside of secrets managers in vulnerable locations, and 79% have experienced secrets leaks, which amplifies the risk when validation is separated from execution. The broader governance lesson appears in the Ultimate Guide to NHIs, where lifecycle control and visibility are treated as essential rather than optional. Strong handling also aligns with the integrity and least-privilege intent of NIST Cybersecurity Framework 2.0.

Organisations typically encounter the consequence only after a trusted pipeline, package, or automation step is abused, at which point the time-of-check to time-of-use gap becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Time-Of-Check/Time-Of-Use Flaw
• Time-of-Check, Time-of-Use race on origin
• Time-of-check/time-of-use (TOCTOU)
• Should identity teams use just-in-time access for NHIs?