Who should own duplicate identity cleanup and access recertification?

Why This Matters for Security Teams

Duplicate identity cleanup is not just an account hygiene task. When the same person, workload, or service is represented by multiple identities, recertification becomes unreliable because reviewers cannot see the full access footprint. That creates hidden privilege, orphaned access, and gaps between what managers approve and what systems actually enforce. Current guidance from the OWASP Non-Human Identity Top 10 and NHI Management Group’s Ultimate Guide to NHIs points to the same operational truth: identity governance fails when the inventory is fragmented.

The ownership question matters because cleanup has two different decision types. Security and identity teams can correlate duplicates, normalize identifiers, and surface overexposure. Business owners and managers must decide whether merged access still matches job function, process need, or contract scope. That separation is what keeps recertification from becoming a rubber stamp. It also aligns with the control intent in NIST SP 800-53 Rev. 5 Security and Privacy Controls, where access review is only meaningful when the reviewer has the right context.

NHI Management Group notes that only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them. In practice, many security teams discover duplicate identities only after a failed audit, an access review dispute, or a credential incident has already exposed the gap.

How It Works in Practice

Effective ownership usually follows a split model. Identity governance owns the process, the control evidence, and the recertification workflow. Business managers and application owners own the approval decision for the merged account set. Security owns detection, correlation, and risk escalation. That division prevents cleanup from turning into an IT-only data exercise while still keeping the business accountable for access need.

In practical terms, the workflow should start with identity matching across directories, applications, SaaS platforms, and privileged tools. Security or IAM analysts resolve likely duplicates using shared attributes, activity history, and account-to-owner mapping. Once duplicates are confirmed, the identity governance team consolidates the records and presents the combined entitlement set for review. Managers then verify whether the access is still required, while application owners confirm whether any technical dependencies would break if access were removed. This is consistent with the control logic in Top 10 NHI Issues and the broader governance guidance in the Ultimate Guide to NHIs — Key Challenges and Risks.

• Security identifies and correlates duplicates across systems.
• Identity governance validates the master record and remediation ticket.
• Managers and application owners recertify the merged access footprint.
• Privileged access teams remove excess rights and verify revocation.
• Audit retains evidence of who approved the cleanup and why.

Where this works best, the organisation has a clean owner model, reliable joiner-mover-leaver data, and a central access review platform. These controls tend to break down when identities are split across business units, when shadow IT owns its own directory, or when application owners cannot explain inherited entitlements because the underlying account lineage is undocumented.

Common Variations and Edge Cases

Tighter recertification often increases operational overhead, so organisations have to balance review depth against the speed needed to remove risk. That tradeoff becomes sharper when duplicate identities span contractors, shared service accounts, or merged acquisitions, because ownership can be ambiguous even when the security issue is obvious.

There is no universal standard for this yet, but current guidance suggests a few practical exceptions. Shared accounts should not be handled like personal identities; they need explicit service ownership and compensating controls. In mergers and post-acquisition cleanups, a temporary remediation owner may be assigned while the target operating model is still being built. For high-risk privileges, such as admin or break-glass access, recertification should be more frequent and include explicit approval from both the system owner and the business sponsor. The 52 NHI Breaches Analysis shows why this matters: duplicate or poorly governed identities often persist long enough to become incident pathways.

Best practice is evolving toward lifecycle ownership rather than one-time cleanup. That means the same parties that validate recertification should also own the ongoing trigger events that create duplicates in the first place, including role changes, app provisioning, and access inheritance. When no one is accountable for the source of the duplicate, remediation turns into a recurring backlog instead of a control.

Related resources from NHI Mgmt Group

• When do NHI access reviews create more value than a one-time cleanup?
• Who should own mixed physical and digital access governance?
• Who should own audit evidence for human and non-human access?
• Who should own identity posture management in an enterprise?