Should teams prioritise runtime identity evidence over more policy reviews?

Why runtime evidence should outrank another policy review

Policy reviews answer a governance question: was access approved, documented, and periodically recertified? Runtime identity evidence answers a different and more urgent question: did the identity behave as expected during actual use, or did it cross an intended boundary after approval? That distinction matters because many attacks succeed after legitimate access is granted, not by bypassing the approval process.

Runtime evidence becomes more valuable when access is dynamic, delegated, or short-lived, because the risk is no longer just who was allowed in, but what the identity did with that access. Review cadences are necessary for accountability, but they are backward-looking. Runtime telemetry is the only way to observe privilege use, unusual tool invocation, abnormal session patterns, and boundary violations while they are happening.

A practical way to think about the split is that policy review validates the entitlement decision, while runtime evidence validates the operating behaviour. Teams that treat those as interchangeable tend to miss the gap between formal approval and actual misuse, especially where secrets, service accounts, or delegated automation can operate faster than human review cycles.

What runtime evidence tells you that reviews cannot

Runtime identity evidence is strongest when it shows the relationship between granted access and real behaviour. That includes authentication context, session duration, command or API activity, privilege elevation, lateral movement signals, and whether the identity stayed within the expected workload, environment, or application boundary. When this evidence is present, teams can judge whether the access model is merely approved on paper or actually operating safely in production.

This is why runtime visibility is often the better control signal for identity security programmes and for NHI lifecycle management. Lifecycle approval can tell you an identity exists for a reason; runtime evidence tells you whether it is still behaving like the reason it was granted. That is especially important when the access path is a service account, workload identity, API token, or similar credential-bearing actor.

Runtime evidence also sharpens remediation. If a review finds an out-of-date approval, the next step is administrative cleanup. If runtime evidence shows privilege use outside the expected boundary, the next step is containment, credential rotation, and blast-radius assessment. Those are different operational decisions, so the signal source matters.

For identity-heavy environments, the runtime question is often stronger than the review question because it captures the control that is actually exercised, not just the control that was intended.

When policy reviews still matter, and where they fall short

Policy reviews remain important for ownership, recertification, and auditability. They are the right control for establishing who is responsible for an identity, which access should exist, and whether dormant or overbroad permissions should be removed. They also help when you need evidence that governance exists at all, especially in regulated environments.

But reviews have structural limits. They are point-in-time, they depend on the reviewer’s context, and they often miss drift between review cycles. An approval can be correct on Monday and unsafe on Friday if the identity’s usage changes, a downstream integration is added, or credentials are copied into a new environment. In practice, the biggest failure is assuming that an approval means the identity is still operating within policy.

That is why runtime evidence should not replace governance, but it should usually outrank it when the question is whether the identity is behaving safely now. Teams get the best result when they use reviews to define intended access and runtime signals to confirm that the intent still holds.

Risk and Threat Considerations

Policy-only control creates a blind spot for post-approval misuse, including credential abuse, privilege drift, and lateral movement that happens after a legitimate entitlement is granted. Runtime evidence reduces that blind spot because it shows whether access is being used in ways that approvals would not reveal until much later.

Failure mechanism: An identity receives valid access, then an attacker, excessive automation, or a misconfigured workflow uses that access outside its expected boundary. A review may still look clean, but runtime evidence can expose the abnormal use pattern, escalation, or unusual reach that indicates compromise or overprivilege.

Impact: Faster detection of misuse, better containment decisions, and lower blast radius when the problem is an approved identity behaving badly rather than an unapproved identity entering the environment.

Practitioner Guidance

What to prioritise: Use policy review to confirm entitlement intent, but prioritise runtime evidence when the main concern is misuse after access has already been granted. If the two signals disagree, treat the runtime signal as the stronger indicator of current risk.

What to verify: Check whether the evidence actually covers session behaviour, privilege use, and boundary violations, not just login success or token issuance. A control that only proves authentication happened is not enough to judge safe use.

Decision rule: If the identity can reach production systems, customer data, or privileged tooling, require runtime visibility before accepting a review-only control as sufficient.

Practitioner takeaway: Reviews establish whether access was allowed, but runtime evidence establishes whether that access is being used safely, and that is usually the more decisive question once an identity is active.

Related resources from NHI Mgmt Group

• When should organisations prioritise continuous identity evidence over quarterly access reviews?
• When should teams prioritise machine evidence over access policy language?
• When should teams prioritise evidence collection over policy writing in ISO 27001?
• How should security teams prioritise NHI remediation in cloud environments?