How do you know if post-merger access governance is actually working?

Why This Matters for Security Teams

Post-merger access governance is only real when the acquirer can prove who owns each retained account, why access was approved, and whether that access still matches current business need. Without that evidence, organisations inherit duplicated entitlements, orphaned service accounts, and privileged paths that nobody can confidently defend. The practical test is not whether a policy exists, but whether the merged environment can answer audit and incident questions quickly and consistently.

That is especially important because identity sprawl tends to accelerate after a merger. One useful benchmark from the 2024 ESG Report: Managing Non-Human Identities is that 72% of organisations have experienced or suspect a breach of non-human identities, which reinforces how often governance gaps turn into exposure. Current guidance from the NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10 both point toward provable asset visibility, accountability, and access review as the baseline. In practice, many security teams discover governance failure only after an inherited account is used in an incident, rather than through deliberate validation.

How It Works in Practice

Working post-merger governance starts by turning the inherited identity inventory into a decision set, not a spreadsheet. Every account, API key, certificate, admin role, and integration should be classified by owner, business purpose, system dependency, privilege level, and renewal path. That classification is what makes review meaningful. The strongest programmes connect each entitlement to an approver, a ticket or case record, and a current service owner, so that access can be revalidated without guessing.

The operational sequence usually looks like this:

• Consolidate identity sources from both organisations and deduplicate accounts tied to the same person, workload, or vendor.
• Map privileged access to explicit business justification and a current owner who can accept or remove it.
• Validate that logs cover the full path of access use, including authentication, approval, change, and revocation events.
• Sample retained access and attempt to reconstruct a real incident timeline from evidence alone.

The Ultimate Guide to NHIs — Regulatory and Audit Perspectives is useful here because it frames governance as evidence-backed control, not policy aspiration. The 52 NHI Breaches Analysis also shows why log quality and ownership clarity matter when post-incident reconstruction is needed. For implementation detail, NIST Cybersecurity Framework 2.0 supports the expectations around asset management, access control, and logging, while OWASP’s NHI guidance helps teams spot where inherited credentials and over-privileged access persist after integration.

Evidence of success is simple: the team can trace any retained account from owner to approval to usage to revocation without relying on tribal knowledge. These controls tend to break down when merger integration leaves one directory partially authoritative, because conflicting ownership records make revocation and review unreliable.

Common Variations and Edge Cases

Tighter governance often increases integration overhead, requiring organisations to balance speed of consolidation against the need for defensible evidence. That tradeoff is most visible when a merger includes regulated entities, outsourced operations, or a large population of service accounts, because each category has different retention and review requirements. Best practice is evolving, but there is no universal standard for how quickly every inherited entitlement must be remediated.

Two edge cases deserve special attention. First, some access may be intentionally retained during a transition period, but it still needs a named owner, a time limit, and an explicit review date. Second, delegated or third-party access often survives longer than expected because neither side of the merger believes it owns the approval record. The safest approach is to treat every exception as temporary and time-bound, with a documented business reason.

The Top 10 NHI Issues and Ultimate Guide to NHIs — Key Challenges and Risks both reinforce a practical point: governance fails fastest where ownership is ambiguous and credentials outlive the reason they were issued. In high-churn environments, the real test is whether revocation and re-approval are faster than new exceptions being created.

Related resources from NHI Mgmt Group

• How do you know if recertification is actually working for data access?
• How do you know if Oracle access governance is actually working?
• How do you know if privileged access governance is actually working?
• How do you know whether privileged access governance is actually working?