Why do IAM policies that pass simulation still create access risk?

Why a Passing Simulation Does Not Eliminate IAM Access Risk

A simulation checks one policy statement against the inputs you supplied. It does not prove the live identity has no other route to the same resource, no standing entitlement that bypasses the tested path, or no session that can outlast the task. The risk is not the simulator’s answer, but the remaining real-world access shape around it.

What the Simulation Actually Verifies, and What It Does Not

Policy simulation is a narrow correctness check. It tells you whether a specific action, resource, and context would be allowed or denied under the tested logic, which is useful for catching obvious policy mistakes. It does not inspect every effective permission, conditional path, delegated grant, inherited role, token scope, or downstream session state that can still matter in production.

That means a passing result can coexist with excessive access. A policy may be written correctly while the identity still carries broader permissions from another role, group, federation claim, or temporary grant. It may also hide the difference between “this request is denied” and “this identity still has enough privilege to do harm through a different action.”

For that reason, simulation is a policy validation tool, not a complete access-risk control. It helps answer whether the rule is internally consistent, but not whether the overall access model is bounded to least privilege. That distinction is why governance should treat simulation as one signal, not the final control outcome.

Why Live Access Risk Persists After a Pass

Access risk persists when the tested policy is correct but the surrounding entitlement environment is not. A user, service, or workload can still retain standing access, stale membership, inherited privilege, or overbroad session scope even when the simulated request is denied or tightly limited. The same gap appears when the tested action is safe, but adjacent actions remain open.

Identity and access reviews need to look beyond a single policy document and examine effective permissions, duration, inheritance, and revocation behavior. IAM and IGA Basics is a useful reference point for that broader entitlement view, because the control question is not only “does this rule pass?” but “what access remains in force?”

For non-human actors, the same problem often appears through credentials, tokens, role assumptions, and workload permissions. A policy can simulate cleanly while the credential that runs the task can still be reused, shared, or left active after the job ends. Cloud Workload Identity Guide and Lifecycle Processes for Managing NHIs both reinforce that access risk is also a lifecycle problem, not just a policy-expression problem.

What Practitioners Should Check Before Trusting a Passing Simulation

A passing simulation should trigger a second question: what else can this identity still do? The most useful verification is to compare the simulated permission with the identity’s actual effective access, session lifetime, inherited roles, and revocation status. If those do not line up, the simulation may be correct and still operationally misleading.

What to verify:

• Whether the identity has any other role, group, or delegated path to the same data or function.
• Whether the access is time-bound, revocable, and actually rotated or expired when the task ends.
• Whether the tested policy covers the full resource set, not only one endpoint or one action.
• Whether standing privilege remains even after the simulated request is denied.

What good looks like: the simulated outcome matches the live effective permissions, unused access is removed, and the identity cannot retain more privilege than the task requires. That is the point where policy correctness and access governance start to converge instead of diverge.

Common mistake: treating a passing simulation as evidence of least privilege. It only proves the evaluated statement behaved as expected, not that the broader entitlement model has been reduced to the minimum needed for safe operation.

Risk and Threat Considerations

A passing simulation can create false confidence when the real danger is residual access, not incorrect policy syntax. If attackers or insiders reach the identity through a separate path, they may still benefit from stale roles, unused permissions, or long-lived credentials that the simulation never tested.

Failure mechanism: the policy engine evaluates one request path, while effective access persists through other entitlements, inherited permissions, or active sessions that were never part of the simulation.

Impact: the organisation can believe access is constrained when in practice the identity still has enough privilege to exfiltrate data, change configuration, or move laterally.

Practitioner Guidance

Decision rule: If a simulation passes but the identity still has standing privilege, treat the result as a policy check only and continue with entitlement review, session review, and revocation verification. If those checks are not available, do not treat the simulation as proof of acceptable access.

What to prioritise: focus first on identities with broad or persistent access, because those are the cases where a correct policy test is least likely to reflect true blast radius. The question is not whether the policy is valid in isolation, but whether the live access model is bounded in practice.

Practitioner takeaway: Simulation validates a rule, not the whole access posture, so the real control objective is to align tested policy with effective permissions, time limits, and revocation.

Related resources from NHI Mgmt Group

• Why do ephemeral credentials still leave risk in machine access models?
• Why does unused IAM access still create risk even when no one appears to be using it?
• Why does ephemeral access still create risk for NHI programmes?
• Why do AI agents create new IAM risk in access review workflows?