Who is accountable when temporary access becomes permanent after a merger?

Why This Matters for Security Teams

Merger-driven access often starts as a temporary exception, but exceptions become liabilities when no one owns the review date. In practice, the real risk is not just that access was granted, but that it outlives the business condition that justified it. NHI Management Group has documented how weak lifecycle discipline turns into exposure at scale, including the Ultimate Guide to NHIs finding that only 20% of organisations have formal offboarding and revocation processes. That is exactly the kind of gap merger teams create when integration schedules outrun identity governance. Current guidance from the OWASP Non-Human Identity Top 10 treats stale access and poor lifecycle control as core failure modes, not edge cases.

The accountability question matters because permanent access after a merger usually reflects a control failure shared across business owners, security approvers, and integration teams. The approval itself may have been valid, but the obligation to revalidate was not optional. In practice, many security teams encounter lingering merger access only after an audit, an incident, or a post-close control review rather than through intentional cleanup.

How It Works in Practice

The cleanest way to assign accountability is to map it to the access lifecycle. Business owners define why the temporary access exists. Security owners define the guardrails, such as approval duration, logging, and revocation criteria. Integration teams execute the merger work and must trigger revalidation when the temporary need ends or when the target operating model changes. If no one is designated to close the loop, temporary access becomes de facto permanent.

Practitioners usually need three controls working together:

• Time-bound approvals with a mandatory expiry date, not open-ended exceptions.
• Periodic recertification tied to merger milestones, system cutover, and data migration completion.
• Automated revocation workflows so expired access is removed without waiting for manual follow-up.

The underlying principle is consistent with governance expectations in 52 NHI Breaches Analysis, where stale credentials and weak ownership repeatedly amplify blast radius. For implementation, current guidance from the OWASP Non-Human Identity Top 10 and NIST Cybersecurity Framework 2.0 both support continuous governance rather than one-time approval. In a merger, that means the control owner should be explicit in the ticket, the risk acceptance should carry an end date, and the integration program should report overdue access as a delivery defect, not as an administrative reminder.

These controls tend to break down when merger integration spans multiple IAM domains, because each side assumes the other party owns recertification and revocation.

Common Variations and Edge Cases

Tighter expiry and recertification controls often increase coordination overhead, requiring organisations to balance speed of integration against the risk of inherited access lingering too long. That tradeoff is real during large mergers, especially when legal hold, transition services, or outsourced operations justify short-term exceptions.

Best practice is evolving for hybrid and cross-entity environments. For example, if a service account or API key must survive a carve-out period, the accountable owner should still be named, the reason should be documented, and the review cadence should be shorter than the merger program itself. Where secrets are involved, long-lived access should be treated as an exception requiring senior approval, because prolonged validity makes cleanup easier to postpone and harder to prove.

There is also a practical distinction between business accountability and technical accountability. Business leaders own the risk decision, but platform, IAM, and integration teams own enforcement. NHI Management Group’s Ultimate Guide to NHIs — Key Challenges and Risks shows how poor visibility and excessive privilege often coexist, which means organisations need named owners, not just approval chains. Where identities are federated across environments, the guidance breaks down when revocation depends on manual handoffs between acquired and acquiring companies, because accountability becomes ambiguous exactly when speed pressure is highest.

Related resources from NHI Mgmt Group

• Who is accountable for access cleanup after ransomware recovery?
• Who is accountable when a third party retains access after offboarding?
• Who is accountable when access governance gaps appear during digital transformation?
• Who is accountable when access is over-provisioned across cloud and on-premises systems?