Time of Check is the moment a system verifies an identity, permission, condition, or resource state before allowing an action. In security, the gap between this check and the actual use creates a race condition, where access can change after verification but before execution.
What Time of Check Means in Security
Time of check is the verification moment, when a system evaluates identity, permission, condition, or resource state before proceeding. Its security importance comes from the fact that verification alone does not lock the state in place.
That distinction matters because the system may approve an action based on a state that is no longer true by the time execution begins. In practice, this is the root shape of a time-of-check to time-of-use flaw, often abbreviated TOCTOU.
Why the Check-to-Use Gap Is Dangerous
The danger is the gap itself. If an attacker or competing process can alter a file, permission, session, token, link target, or other resource after the check but before the use, the final action can run against a different reality than the one that was verified.
This creates a race condition rather than a simple validation bug. The weakness is often subtle because each individual step can look correct when reviewed in isolation, yet the sequence as a whole is unsafe.
Common Security Patterns Behind TOCTOU
TOCTOU appears in file access, privilege checks, symbolic links, temporary files, object ownership, and workflow decisions that are split across multiple operations. The same pattern also shows up when systems trust a condition that can change asynchronously, such as account status, group membership, or resource existence.
- Checks on a path or object before opening or acting on it.
- Permission decisions made before the final resource bind.
- State assumptions that are not revalidated at the moment of use.
- Concurrency bugs where another actor can intervene between steps.
Designs that reduce the number of separate steps, bind the check and the action atomically, or hold a lock across the relevant operation are less exposed to this class of flaw.
Why Practitioners Care About Time of Check
For defenders, time of check is not just a code-review detail. It is a signal that the system may be making security decisions on stale state, which can undermine authorization, integrity, and isolation even when the original validation logic is correct.
When you see this pattern, treat the question as whether the security decision is still valid at the exact moment of execution, not merely whether it was valid earlier in the flow.
Risk and Threat Considerations
TOCTOU flaws can let an attacker exploit a trusted check by changing the target or state before use. That can turn a legitimate verification step into a path for unauthorized access, privilege escalation, file substitution, or workflow manipulation.
Failure mechanism: A system verifies state, then performs the action later without an atomic guarantee that the state has not changed. An attacker or competing process wins the race and swaps the checked object, permission, or condition before the use step.
Impact: The system acts on an untrusted or unintended state, which can defeat authorization checks, break integrity controls, and expose data, files, or privileged operations to abuse.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5, OWASP ASVS and OWASP SAMM set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | TOCTOU flaws often exploit weak state-handling and insecure temporary resource patterns. |
| Recommendation — Harden file, path, and workflow handling so checks and use occur within controlled, consistent configurations. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Time-of-check decisions directly affect whether access enforcement still holds at use time. |
| Recommendation — Enforce authorization at the moment of action and avoid split-step access decisions. | ||
| OWASP ASVS | V8 — Authorization | TOCTOU can bypass intended authorization when the checked state changes before use. |
| Recommendation — Verify that authorization remains valid at execution time, not only during preliminary checks. | ||
| MITRE ATT&CK | T1222 — File and Directory Permissions Modification | Attackers commonly change permissions or replace objects between check and use to abuse race windows. |
| Recommendation — Hunt for permission-changing activity and object replacement that occurs around sensitive file operations. | ||
| OWASP SAMM | SFD — Secure by Design | Time-of-check weaknesses are design-time concurrency and validation flaws that SAMM addresses. |
| Recommendation — Build atomic validation and state-consistency requirements into design and architecture reviews. | ||
Practitioner Guidance
Why practitioners should care: The safest fix is usually architectural, not cosmetic. If the security decision depends on state that can change, the design should reduce or eliminate the window between validation and execution.
What to watch for: Separate existence checks, permission checks, or ownership checks that are followed by a later use of the same object are classic warning signs. Review any flow where the resource can be replaced, re-pointed, or reclassified between those steps.
Practitioner takeaway: Prefer atomic operations, binding, locking, or single-step authorization paths wherever the state itself is part of the security decision.