When should teams prioritise access recertification over adding more access request automation?

When recertification should come before more request automation

Recertification should win when the access problem is already in the estate, not in the approval queue. If teams are carrying stale entitlements, inherited roles, dormant accounts, or unclear ownership, faster requests only increases the rate of new access while leaving existing exposure untouched. The practical question is whether the bigger governance gap is “too slow to grant” or “too much access already exists.”

That distinction matters because request automation optimises throughput, while recertification reduces accumulated privilege. When access is already overprovisioned, the highest-value control is the one that can remove unnecessary access, confirm business ownership, and force a decision on access that has drifted beyond its original justification. In that situation, automation is useful later, after the access baseline is cleaner.

Teams should also treat recertification as the better first move when access knowledge is unreliable. If approvers do not know why an entitlement exists, who owns it, or whether it is still used, then automating more requests simply scales a weak control model. Recertification rebuilds the decision record, and that record is what makes downstream access automation safer and more credible.

Why faster access requests do not solve excess access

Access request automation shortens the path from “need” to “grant.” It helps when the bottleneck is manual routing, repetitive approvals, or inconsistent fulfilment. But it does not answer whether the entitlement should exist at all, and it does not clean up the long tail of access that accumulates through role drift, project changes, exceptions, and leavers who kept more access than they still need.

That is why recertification is the more strategic control when the organisation has already reached a point of privilege creep. A mature review cycle can identify entitlements that are no longer tied to a current job function, access that was granted as a temporary exception, and privileges that no one can confidently defend. If the environment has many dormant or high-risk entitlements, removing them usually has more governance value than making the next request faster.

Automation becomes the priority only when the current access model is already reasonably clean and the main pain is operational friction. In that case, speeding up legitimate requests can improve user experience without materially increasing exposure. But where the access estate itself is suspect, the better investment is validation, cleanup, and ownership, not more intake speed.

What good prioritisation looks like in practice

The best ordering is usually cleanup first, automation second. Start by identifying where entitlement reviews will change the most risk, for example orphaned accounts, long-lived exceptions, privileged roles with weak ownership, and access that has not been meaningfully touched in a long time. Once those conditions are brought under control, request automation can be added to streamline the stable path for new access.

That sequencing also helps avoid the common failure mode where teams digitise a broken process. If the request workflow is automated before the entitlement catalogue, role model, and ownership data are trustworthy, the organisation may become faster at granting access that should have been removed. Recertification forces the underlying access model to be examined before it is scaled.

For teams trying to decide where to begin, a simple rule works well: if the hardest question is “who should get access next?”, automation is probably the right lever; if the hardest question is “why does this access still exist?”, recertification is the right lever. The second question is the more urgent one whenever auditors, managers, or platform owners cannot clearly justify the current state.

Risk and Threat Considerations

When recertification is deferred in favour of faster requests, excess access can compound quietly. Stale entitlements, dormant accounts, and overprivileged roles increase the blast radius of compromise and make it harder to distinguish legitimate use from abuse. Faster approvals can even disguise the problem by making entitlement growth look like process improvement.

Failure mechanism: The control failure is entitlement accumulation without periodic challenge, so access that no longer has business value remains active and may be exploitable through misuse, lateral movement, or simple operational error.

Impact: Organisations carry avoidable exposure for longer, retain unclear ownership, and make every later incident, audit, or access exception harder to investigate and justify.

Practitioner Guidance

What to prioritise: Prioritise recertification first when you can already see evidence of access bloat, weak ownership, or high-risk entitlements. If the review will remove or downgrade meaningful access, it is usually a better investment than another workflow tweak.

Decision rule: If the current control question is “should this access still exist?”, pause request automation work and focus on certification, removal, and ownership cleanup. If the access baseline is healthy and the bottleneck is fulfilment speed, automate the request path.

What to verify: Before adding more automation, verify that reviewers can name the business purpose, owner, and expiry condition for the entitlement set you are about to streamline. If they cannot, the process is not ready to be scaled.

Practitioner takeaway: Automate the granting of access only after you have made the existing access inventory defensible; otherwise you are accelerating entitlement drift instead of reducing it.

Related resources from NHI Mgmt Group

• When should security teams prioritise lifecycle automation over ad hoc access requests for external users?
• When should teams prioritise data rights automation over manual request handling?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams run access reviews for non-human identities?