Account Recertification

What Account Recertification Actually Does

Account recertification is an access-governance control, not a one-time setup step. It forces a fresh business decision on whether a user or non-human account still needs access, based on current role, ownership, and duty requirements rather than historical assignment.

The value of the process is that access tends to accumulate over time. Without periodic review, dormant permissions, old project access, inherited admin rights, and forgotten service account can remain active long after the original justification has changed.

Why It Matters for IAM Governance

Recertification is one of the practical ways organisations keep identity data aligned with reality. It helps validate whether the account still has a defined owner, whether the access matches the person or system's current function, and whether the privilege level is still appropriate.

For human accounts, the review often follows organisational change, such as a move, promotion, or team transfer. For non-human accounts, the review is just as important because application accounts, service principals, API credentials, and automation identities can outlive the workload they were created for.

That makes account recertification closely related to identity governance and access review discipline. A strong program does not treat certification as paperwork, but as a control that preserves least privilege and reduces entitlement drift across cloud, SaaS, and infrastructure.

What Good Recertification Looks Like

Effective recertification starts with accurate inventory. Reviewers need to know which accounts exist, who owns them, what system they belong to, and which privileges they actually hold. If the inventory is incomplete, the review will miss risky access or rubber-stamp stale records.

The review itself should be context-aware. A manager or system owner should be able to answer whether the access is still needed, whether it is excessive for the role, and whether the account should be kept, reduced, moved to a different owner, or removed entirely.

The best programs also include remediation follow-through. A certification decision only matters when rejected or reduced access is actually enforced, because closed-loop action is what turns the review into a real control rather than a reporting exercise.

How Recertification Supports Cleaner Access Decisions

Account recertification works best when it is connected to the broader lifecycle of provisioning, change, and deprovisioning. If access is granted quickly but never revalidated, organisations build privilege creep into everyday operations.

It also supports better ownership discipline. Accounts with no clear reviewer, sponsor, or system owner are much harder to govern, which is why recertification often exposes orphaned account, shared accounts, and stale entitlements that other processes have missed.

When applied consistently, recertification improves confidence in access decisions across applications, cloud platforms, and infrastructure layers. It gives organisations a repeatable way to justify retained access and remove what no longer fits the current business need.

Risk and Threat Considerations

Accounts that are never recertified tend to become attack surface. Excessive access, orphaned identities, and stale service credentials can create easy paths for privilege abuse, lateral movement, or unauthorized access long after the original business use has ended.

Failure mechanism: Access that should have been removed stays active because the organisation lacks timely review, clear ownership, or enforcement after approval decisions.

Impact: Attackers or insiders can exploit unnecessary permissions, while routine operational change slowly turns the access model into a weaker and less trustworthy version of the intended design.

Practitioner Guidance

What to watch for: Recertification loses value when reviewers do not understand the account's purpose, when ownership is vague, or when too many approvals are accepted by default. Those are signals that the campaign is measuring compliance activity rather than actual access validity.

Governance implication: The control should be owned jointly by identity governance and the business or system owner who can genuinely attest to need. That keeps the decision tied to current operational reality, not to who happened to be assigned the account in the past.

Related resources from NHI Mgmt Group

• Service Account Governance
• What happens when a human uses an NHI account?
• What happened in the demo account left active in production scenario and what does it reveal?
• What makes a super NHI different from an ordinary service account?