How do identity teams decide which access should be recertified versus redesigned?

They should recertify access that is truly long-lived and tied to a stable identity, but redesign access that exists only because a process repeats. For NHIs and agents, repeated use often signals that the privilege model, not the certification cadence, is the real issue.

When to recertify instead of redesigning access

Recertify when the access is genuinely durable, the identity is stable, and the privilege is still aligned to a continuing business need. That is the right test for entitlements that should exist across cycles, not just during one workflow. Redesign when the access exists only because the same task repeats, because repeated approvals are usually a signal that the access model is carrying process friction rather than expressing a real entitlement.

For identity teams, the practical distinction is whether the access is an enduring permission or a recurring workaround. If the answer changes only because the event repeats, recertification can become a rubber stamp. If the access should disappear between runs, the control problem is not review cadence, it is entitlement design.

A useful anchor is whether the permission can be justified without referencing the next manual request. Stable users, stable roles, and stable business responsibilities are candidates for recertification when the access remains proportionate. Repeated use by a foundational IAM and IGA model should be evaluated as a governance decision about standing access, not merely as an approval event.

Why recurring use often points to a redesign problem

Access that is reapproved every time a workflow runs often indicates that the permission has no clean lifecycle boundary. That is common with temporary project access, shared operational accounts, or agent-like access patterns where the same privilege is invoked repeatedly but should have a tighter scope, shorter duration, or a different control path.

When that happens, the certification process starts absorbing design flaws: reviewers see the same access again and again, the justification becomes formulaic, and the control slowly loses meaning. In that situation, redesign usually means moving the access to a role, a delegated approval flow, a time-bound entitlement, or a service-specific control model so the recurring need is represented correctly.

The stronger signal is repetition. If the same access reappears because a process repeats, the team should ask whether it belongs in a lifecycle that can be owned and reviewed once, rather than in a recurring certification queue. A good starting point is the Access Reviews and Certification Guide, which frames certification as a way to remove unnecessary access, not preserve repetitive exceptions.

For non-human accounts, this distinction is even sharper. Repeated operational use often means the privilege is being treated like a persistent capability even when the work is episodic. That is why a NHI lifecycle management approach is often a better fit than repeated recertification alone.

How to make the decision in practice

Teams usually get the decision right by asking three questions: is the identity stable, is the business need continuous, and is the permission bounded enough to survive another review cycle without becoming excessive? If all three are yes, recertification is usually appropriate. If the access only exists because the work repeats, redesign is usually the better control.

Recertify access that is tied to a known owner, a stable role, and a clear ongoing need.
Redesign access that keeps coming back because the process was never converted into a proper role, workflow, or time-bound entitlement.
Escalate repeated approvals for the same access when reviewers are forced to approve the same exception every cycle.

For machine, workload, and agent access, the same logic should drive role simplification and entitlement cleanup. If repeated reapproval is the norm, the team should inspect whether the access can be expressed as a narrower service permission, a shorter-lived token pattern, or a cleaner ownership model. The Role Mining and Role Design Guide is useful here because it treats repeated access as a role-design signal, not just a review outcome.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while CSA Cloud Controls Matrix and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CSA Cloud Controls Matrix	IAM — Identity and Access Management	Recertification versus redesign is an IAM governance decision about entitlement lifecycle and access ownership.
Recommendation — Review IAM entitlements for recurring exceptions and redesign access paths that keep reappearing.
NIST SP 800-53 Rev 5	AC-2 — Account Management	Deciding whether access should persist or be reworked maps to account lifecycle and review controls.
	AC-6 — Least Privilege	Redesign is needed when repeated approvals reveal permissions broader than the ongoing need.
	IA-9 — Service Authentication	Non-human and agent access in this question depends on how services authenticate and carry recurring privilege.
Recommendation — Use AC-2 to review recurring access and remove accounts or entitlements that only exist for repeated processes. Apply AC-6 to narrow standing access when repeated certification shows the privilege is too broad. Apply IA-9 to validate and tighten recurring service and workload access instead of recertifying it unchanged.
OWASP Non-Human Identity Top 10	NHI-07 — Long-Lived Secrets	Recurring NHI use often indicates persistent credentials or tokens that should be redesigned, not repeatedly recertified.
Recommendation — Replace long-lived NHI secrets with shorter-lived access patterns when recurring use is the norm.

Practitioner Guidance

What to prioritise: Start with the access that creates the most review fatigue and the least business value. Repeated approvals for the same entitlement are often the fastest path to finding redesign candidates.

What to verify: Confirm whether the reviewer can explain the business need without referencing the next event, ticket, or campaign. If not, the access is probably compensating for a missing lifecycle pattern.

Common mistake: Treating successful recertification as proof that the access model is healthy. A clean review may still be masking an entitlement that should have been redesigned into a role, a bounded workflow, or a time-limited capability.

Practitioner takeaway: Recertification is for access that should endure; redesign is for access that only exists because the work repeats. If the justification sounds temporary, even when it recurs often, the entitlement model is usually the thing that needs fixing.