What breaks when application access is never recertified?

Why Recertification Is the Control That Keeps Access Honest

Application access recertification is the mechanism that proves an entitlement is still needed, still approved, and still tied to a current business purpose. Without it, access decisions age out of context: project-based access stays alive after the project ends, shared exceptions become normal, and nobody can reliably show why a person or service still has access. A recertification process also creates the evidence trail auditors expect when they ask who accepted the risk and when it was last reviewed. As NHI Management Group notes, only 5.7% of organisations have full visibility into their service accounts, which is a useful reminder that review failure is often a visibility failure first. In practice, teams usually discover the problem only after dormant access has already blended into the baseline rather than through deliberate review.

For broader identity governance context, the OWASP Non-Human Identity Top 10 is useful because it frames why stale access becomes dangerous when it is never revisited.

How Access Decay Happens in Practice

When recertification does not happen, access accumulates through a few predictable patterns. Managers approve access once and never see it again. Application owners assume the original requester still needs the same roles. Helpdesk or workflow exceptions are granted for speed and then left in place. Over time, the organisation no longer has a current answer to basic questions such as who should have access, which entitlements are still necessary, and whether the application still supports the original use case.

This creates operational drag and control failure at the same time. Excess entitlements make it harder to separate legitimate activity from misuse, especially in applications with broad role groups or indirect inheritance. It also weakens least privilege because no one removes access unless something visibly breaks. NHI Management Group’s research points to the scale of the problem: 97% of NHIs carry excessive privileges, which shows how quickly unchecked access broadens the attack surface when review is absent. The same pattern applies to application access more generally, even when the identity is human.

• Inactive users keep entitlements because nothing triggers removal.
• Role drift appears when job changes are not matched by access changes.
• Audit evidence degrades because approval history no longer matches current access.
• Security teams inherit false confidence when the access request exists but the entitlement is never revalidated.

For a governance lens on why this matters, NIST’s Security and Privacy Controls provide the control family that underpins periodic review, while the Ultimate Guide to NHIs gives practitioner context on why stale access is rarely an isolated issue. These controls tend to break down when applications lack clean ownership or when entitlement structures are so nested that reviewers cannot tell what they are actually certifying.

Common Edge Cases and Where the Rule Gets Sloppy

Tighter recertification often increases administrative overhead, so organisations have to balance review depth against review fatigue. That tradeoff matters because a process that is too heavy gets rubber-stamped, while a process that is too light becomes a formality with no real security value.

Best practice is evolving in environments with application roles, inherited entitlements, and machine-supported access paths. A quarterly human review may be sufficient for low-risk business tools, but high-privilege or sensitive systems usually need a stronger cadence and more precise ownership. Current guidance also suggests treating temporary access differently from standing access: time-bound approvals should expire automatically, while recurring approvals should be re-earned with evidence. That distinction becomes especially important when access is shared across teams, delegated through intermediaries, or tied to service accounts that no one actively “uses” in the human sense.

The hardest edge case is not the obvious leaver scenario. It is the entitlement that remains technically valid, lightly used, and therefore easy to ignore. Those permissions often survive because nobody owns the cleanup, nobody questions the exception, and nothing external forces a decision until audit, incident response, or a privilege review exposes the gap.

Risk and Threat Considerations

Never-recertified access creates privilege persistence, audit defensibility risk, and a wider blast radius if an account is compromised or repurposed. The exposure is not only that too many people can reach an application, but that the organisation loses assurance that access still maps to an approved need.

Failure mechanism: Access review controls fail when entitlement records are not revalidated against current role, purpose, or ownership. Stale approvals then accumulate, inherited permissions remain hidden inside groups or roles, and attackers or insiders can exploit dormant but still-valid access paths that defenders no longer watch closely.

Impact: Excess access becomes normalised, separation of duties erodes, and investigations become harder because the organisation cannot prove whether the entitlement was intentionally retained, accidentally forgotten, or maliciously abused.

Practitioner Guidance

What to prioritise: Start with high-impact applications, privileged roles, and any access path that can reach sensitive data or administrative functions. If review capacity is limited, focus on entitlements whose misuse would create the largest recovery or disclosure problem, not on low-risk convenience access.

What to verify: A useful recertification process should verify current business need, current owner approval, and whether the access is still the least-privilege option. If reviewers cannot explain why an entitlement exists in one sentence, treat that as a sign the control is already too weak to trust.

What practitioners underestimate: The biggest failure is often review fatigue, not review absence. When every certification looks the same, approvers learn to click through, so the organisation gets paperwork instead of governance. The practical test is whether access decisions change when the context changes, because if they do not, recertification is not functioning as a control.

Practitioner takeaway: Recertification is valuable only when it forces a real decision about current necessity; once it becomes routine sign-off, stale access survives indefinitely and the control turns into audit theatre.

Related resources from NHI Mgmt Group

• What breaks when application owners need direct privileged access to the Azure portal?
• What breaks when access revocation is slow after an employee leaves or an account is compromised?
• What breaks when access is only checked once at login?
• What breaks when organisations keep multiple VPNs and inconsistent access rules?