Who is accountable when privileged access remains in place after a role change or merger?

Why This Matters for Security Teams

Privileged access that survives a role change or merger is not just messy administration. It is a control failure that leaves the organisation unable to prove who still has authority, why it remains, or whether it has been revoked. The risk increases when accounts, service identities, and inherited entitlements are carried across HR moves, shared platforms, or acquisition clean-up.

That is why identity governance must treat privileged access as a lifecycle obligation, not a one-time approval. The OWASP Non-Human Identity Top 10 reflects the broader pattern: access that is not continuously validated tends to outlive the business condition that justified it. NHIMG research on Ultimate Guide to NHIs shows how fragmented identity ownership creates gaps in review and revocation, especially when many teams assume someone else will clean up residual access. In practice, many security teams discover stale privileged access only after an audit finding, a post-merger clean-up, or an incident exposes that the old role was never fully removed.

How It Works in Practice

Accountability should be assigned before the access change happens, and it should remain traceable after the move, transfer, or merger. The entitlement owner is responsible for the access itself, the approving manager confirms business need, and the identity governance function verifies that the entitlement was reviewed, updated, or removed. In merger scenarios, this often extends to a temporary integration owner who is accountable for inherited admin rights until the target-state model is complete.

Operationally, teams need evidence, not assumptions. That means:

• documenting the new role and comparing it against the prior privileged entitlements
• running time-bound access reviews for admin, break-glass, and delegated rights
• removing access automatically when the business justification no longer matches the current role
• capturing approvals, revocations, and exceptions in the identity governance record

Current guidance from OWASP Non-Human Identity Top 10 and 52 NHI Breaches Analysis reinforces a practical lesson: lingering privileges are most dangerous when they are treated as a records problem rather than an access problem. A role change without timely entitlement removal also creates audit ambiguity, because no one can clearly show who authorised the continuation of elevated access.

For merger activity, the cleanest model is to treat inherited access as temporary and re-certify it against the post-close operating model. These controls tend to break down when multiple HR systems, directory domains, or acquired business units each believe another team owns the final revocation step.

Common Variations and Edge Cases

Tighter entitlement control often increases operational overhead, requiring organisations to balance fast business continuity against the need to revoke access that no longer fits the current role. That tradeoff is real during mergers, reorganisations, and emergency replacements, where some privileges may need to stay live briefly to avoid service disruption.

Best practice is evolving, but current guidance suggests using time-boxed exceptions with explicit expiry dates, named owners, and post-change review checkpoints. For highly privileged or production access, there is no universal standard for how long an exception may remain open, but the principle is consistent: the longer the entitlement persists after a role change, the stronger the justification and the tighter the evidence requirement must be.

Edge cases often include shared admin groups, inherited contractor access, and break-glass accounts. Those should not be handled as ordinary role membership because the accountability chain is different. A shared group may need a service owner, a merger cutover may need a temporary control owner, and break-glass access may require separate logging and daily review. NHIMG’s The State of Secrets in AppSec highlights how fragmented control environments weaken central oversight, which is why a single owner for review and removal matters even more during organisational change.

Related resources from NHI Mgmt Group

• Who should be accountable for role-based privileged access governance?
• Who is accountable when access is left active after a role change or departure?
• Who is accountable when access remains in place after it should have been removed?
• What is the difference between role-based access and API key governance for NHI security?