Not Using Complete Mediation

What It Means When Access Is Checked Only Once

Not using complete mediation is a control failure, not just a coding shortcut. The system trusts a prior decision instead of revalidating authority at the point of use, so permission can drift away from the actual state of the resource, session, or user context.

This weakens the core security assumption that access decisions remain valid over time. Once the original check becomes stale, any later change in ownership, role, session state, or object state can leave a dangerous gap between what the application believes and what should be allowed.

Why Stale Decisions Become Dangerous

The main risk is that attackers can exploit timing gaps, cached authorisation, or repeated use of an old decision to reach something they should no longer be able to access. That is why this weakness is often associated with race conditions and time-of-check, time-of-use style failures.

In practice, the danger grows when the protected operation is sensitive, high value, or hard to monitor. If a system reuses a previous allow decision, the attacker only needs one moment of weakness, then can act before the defender's assumptions are refreshed. The CWE Top 25 Guide is useful background because it groups not using complete mediation with other high-impact software weaknesses, including race-condition and authorisation flaws.

Where It Usually Shows Up

This flaw appears wherever an application separates the permission check from the actual sensitive action. Common examples include cached session decisions, reused object handles, stale role information, client-assisted state, and workflows that trust an earlier validation step for too long.

It is especially problematic when the resource state can change quickly, such as after revocation, reassignment, approval, expiry, or concurrent update. Any design that assumes "checked once means safe forever" creates a brittle trust boundary that attackers can target.

How Defenders Reduce the Exposure

Defensive design should bind authorisation to the exact sensitive operation, not to an earlier moment in the workflow. Recheck permissions when the resource is accessed, invalidate cached assumptions when context changes, and treat revocation, ownership changes, and workflow transitions as events that can invalidate prior trust.

Operationally, this means reviewers should look for reused decisions, stale state, and concurrency windows in code paths that expose sensitive data or actions. The CISA Known Exploited Vulnerabilities Catalog is also relevant as a reminder that widely exploited weaknesses often persist because the underlying exposure is not fully removed, only partially patched.

For control design, NIST Cybersecurity Framework 2.0 supports this kind of discipline through governance, protection, detection, and response expectations that favour continuous validation over one-time trust.

Related resources from NHI Mgmt Group

• What do teams get wrong about using pen tests as a complete security validation?
• What breaks when private keys are protected with fragmented controls instead of complete mediation?
• Why does storing credit card data for future transactions create higher compliance and security risk than using it only to complete the current purchase?
• Complete Mediation