Notifications
Clear all
Topic starter
06/06/2026 2:03 am
TL;DR: Mergers and acquisitions create a high-risk identity integration problem because service accounts, API keys, tokens, and certificates are often inherited across mismatched environments with unclear ownership, inconsistent scoping, and hidden secrets, according to Oasis Security. The security issue is not just sprawl, but the collapse of governance assumptions that make merged identity estates auditable and controllable.
NHIMG editorial — based on content published by Oasis Security: How to manage Non-Human Identities during M&A
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps , 38% have no or low visibility, and a further 47% have only partial visibility.
Questions worth separating out
Q: How should security teams manage non-human identities during M&A?
A: Security teams should start with discovery, then classify every inherited service account, key, token, and certificate by owner, privilege, and lifespan.
Q: Why do non-human identities become riskier after a merger?
A: They become riskier because two organisations often merge identity systems that were built on different assumptions about trust, naming, ownership, and credential lifetime.
Q: What breaks when NHI ownership is unclear after integration?
A: When ownership is unclear, no one can confidently revoke, rotate, or recertify the identity when the system changes.
Practitioner guidance
- Run a pre-close NHI inventory sweep Scan cloud accounts, SaaS tenants, repositories, container registries, and on-prem systems for service accounts, service principals, managed identities, PATs, certificates, and embedded secrets before integration work begins.
- Freeze new long-lived credentials during integration Block creation of persistent credentials until the merged governance baseline is defined, then require short-lived access where the business process can support it.
- Assign ownership to every inherited identity Record a named owner, business purpose, privilege scope, and retirement date for each NHI so orphaned accounts can be removed instead of left to drift.
What's in the full article
Oasis Security's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step discovery workflow for service accounts, secrets, certificates, and workload identities across merged environments
- A tactical five-step M&A playbook that sequences due diligence, remediation, governance baseline, merge strategy, and monitoring
- Operational metrics for tracking privileged roles, credential lifespan, stale identities, and anomalous machine-to-machine traffic
- Implementation guidance for lift-and-shift versus federation decisions in post-merger identity integration
👉 Read Oasis Security's guide on managing non-human identities during M&A →
Non-human identities during M&A: what IAM teams need to fix?
Explore further
06/06/2026 3:30 am
Merger-time identity governance is a lifecycle problem, not a systems integration problem. The article shows that post-merger risk begins with discovery, but the real issue is whether every inherited non-human identity has an owner, a scope, and a retirement path. That maps directly to OWASP-NHI and the lifecycle discipline described in the NHI Lifecycle Management Guide. Practitioners should treat M&A as a governance reset, not a migration exercise.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, which shows how slowly remediation can trail exposure.
A question worth separating out:
Q: Who should be accountable for inherited NHI risk in M&A?
A: Accountability should sit with the team that owns the merged identity programme, not with whichever side originated the account. That team needs authority to approve scope changes, remove dormant identities, and enforce the lifecycle baseline across both estates. If accountability is split, orphaned access tends to survive the integration window.
👉 Read our full editorial: Managing non-human identities during M&A requires a new baseline
