When should organisations prioritise attack-path analysis over periodic access recertification?

Why attack-path analysis should come first in modern identity estates

Attack-path analysis should take priority when approvals are only part of the story and the real question is what those approvals unlock. In SaaS, cloud, and hybrid environments, a single role, token, or service account can chain into broader access across systems, so recertification can confirm legitimacy while still missing the exposure that matters most.

That shift matters because modern access is often compositional. An identity may be approved for one system, but inherited trust, federated access, delegated permissions, and cross-platform integrations can turn that approval into a path to sensitive data, admin functions, or downstream identities. The practical unit of risk is no longer just the account.

Where periodic recertification still helps, and where it stops short

Periodic recertification remains useful for entitlement hygiene, owner accountability, and catching obvious drift such as stale access, forgotten accounts, and missing business justification. It is especially valuable where regulators or auditors expect evidence that access was reviewed on a schedule and ownership is documented.

Its weakness is that it is retrospective and local. A reviewer can approve access that appears reasonable in isolation, yet the same access may combine with another entitlement, an inherited trust path, or a standing privilege elsewhere to create a much larger attack surface. That is why organisations often pair access reviews and certification with path-based analysis rather than treating them as substitutes.

In practice, recertification is best at answering whether access should continue. Attack-path analysis is best at answering whether that access can be turned into something more dangerous. Those are related questions, but they produce different operational priorities.

When the attack path is the real control point

Attack-path analysis becomes the stronger control when trust can move across boundaries, especially through SaaS integrations, cloud roles, service accounts, API credentials, or federated identity relationships. In those environments, identity posture findings are most useful when they show how one exposed entitlement connects to another rather than when they only report the entitlement itself.

It is also the better lens when organisations have many non-human or machine-mediated access paths. Service accounts, workload identities, automation, and integration tokens often outlive the business process that created them, and their risk is not just whether they are approved, but whether they can be abused to pivot, escalate, or persist. Lifecycle management for non-human identities matters here because stale access is often only the starting point.

For mature teams, the right trigger is not “review everything more often”, but “review the identities most likely to create a chain of compromise.” That usually includes privileged cloud roles, cross-tenant integrations, long-lived secrets, shared service accounts, and any identity that can inherit authority from a platform control plane.

Practitioner Guidance

What to prioritise: Start with identities and permissions that can fan out across systems, not with the largest list of low-risk entitlements. If an identity can reach production data, automate actions, or assume other roles, it deserves path analysis before the next scheduled certification cycle.

What to verify: Confirm whether the review process looks only at approval status or also at reachable privilege. A good test is whether the team can show the shortest paths from a given identity to sensitive assets, administrative roles, or cross-system trust edges.

What good looks like: Recertification trims obvious excess, while attack-path analysis drives remediation of the few identities that create disproportionate blast radius. In that model, review cycles become a hygiene control and path analysis becomes the prioritisation engine.

Common mistake: Treating “approved” as equivalent to “safe enough”. Approved access can still be the first step in a compromise chain, especially where cloud roles, SaaS connectors, and machine identities inherit more privilege than their owners realise.

Practitioner takeaway: Use recertification to validate ownership and necessity, but use attack-path analysis to decide where risk actually concentrates. When the two disagree, the path analysis usually tells you where to spend your limited remediation effort first.

Related resources from NHI Mgmt Group

• When should organisations prioritise attack-path analysis over score-based triage?
• Should organisations prioritise attack-path reduction over finding counts?
• Should organisations prioritise live access visibility over periodic spreadsheet reviews?
• Should organisations prioritise lifecycle-triggered de-provisioning over periodic recertification?