When should organisations prioritise recertification over authentication improvements?

Why This Matters for Security Teams

Recertification becomes the priority when the problem is not whether an identity can prove itself, but whether it should still have the access it already has. Authentication improvements harden the login event, yet they do not address accumulated entitlements, stale service accounts, or access granted for a project that ended months ago. That is why governance problems often persist even after MFA, stronger tokens, or better login monitoring are in place.

This distinction is especially important for NHIs because their access is usually broad, persistent, and rarely reviewed with the same discipline as human accounts. NHI Management Group notes that Ultimate Guide to NHIs — What are Non-Human Identities reports 97% of NHIs carry excessive privileges, which makes recertification a direct risk-reduction control rather than a paperwork exercise. The same pattern shows up in audit findings and breach reviews: access is technically valid, but no longer business-justified. That is a governance failure, not an authentication failure.

For teams aligning with NIST Cybersecurity Framework 2.0, recertification supports ongoing authorization and access assurance, while authentication improvements support stronger entry controls. In practice, many security teams encounter excessive access only after an audit, incident review, or failed offboarding process has already exposed it, rather than through intentional access lifecycle governance.

How It Works in Practice

The practical test is simple: if the risk is “who should still have access,” recertification should come first. If the risk is “how can an attacker get in,” authentication improvements belong in the roadmap, but they do not solve entitlement sprawl. Effective recertification reviews focus on role ownership, business justification, last use, system criticality, and whether the access is still tied to an active workflow or service dependency.

For NHIs, this usually means reviewing secrets, API keys, certificates, OAuth clients, service accounts, and machine-to-machine permissions against the current environment. A mature recertification workflow typically includes:

• Owner attestation for each NHI and the systems it touches.
• Validation that the access scope still matches the workload’s current purpose.
• Removal of dormant, duplicate, or inherited permissions.
• Rotation or revocation of credentials when ownership cannot be confirmed.
• Exception handling for systems that cannot yet support short-lived credentials.

That governance loop complements guidance from the Sisense breach case context, where exposure risk is not limited to initial authentication. It also aligns with broader identity hygiene in the NIST Cybersecurity Framework 2.0, which treats access review and continuous governance as ongoing security work, not one-time onboarding activity. If an organisation has weak inventory, no reliable owner mapping, or no way to distinguish active from abandoned access, recertification will be noisy but still necessary. These controls tend to break down when cloud sprawl, shadow IT, and unmanaged service accounts make ownership impossible to verify quickly.

Common Variations and Edge Cases

Tighter recertification often increases operational overhead, requiring organisations to balance entitlement hygiene against review fatigue and business disruption. That tradeoff is especially visible when access is deeply embedded in production systems, where owners may hesitate to remove anything that could affect uptime. In those environments, current guidance suggests starting with the highest-risk identities first: privileged NHIs, internet-facing services, third-party integrations, and credentials that have not been used recently.

There is no universal standard for recertification frequency yet. Best practice is evolving toward risk-based review cycles rather than a single calendar rule. High-change systems may need more frequent certification than stable infrastructure, while low-risk internal services can sometimes be reviewed less often if logging, ownership, and rotation are strong. Authentication improvements still matter in these cases, but they are secondary if the main exposure is over-entitlement.

One important edge case is when organisations are moving toward short-lived credentials and stronger workload identity. In that model, authentication improvements and recertification work together: the former reduces credential misuse, while the latter removes unnecessary standing access. If a system still relies on long-lived secrets stored in code or config, recertification should take priority because the access problem is already embedded in the environment. NHI Management Group’s Ultimate Guide to NHIs — What are Non-Human Identities is explicit that most organisations still struggle with these lifecycle controls, so governance usually delivers faster risk reduction than a front-door redesign alone.

Related resources from NHI Mgmt Group

• When should organisations prioritise access governance over software spend optimisation?
• When should organisations prioritise lifecycle governance over new access features?
• When should organisations prioritise renewal governance over retrospective spend reporting?
• When should organisations prioritise IGA modernization over more review cycles?