How should security teams handle shadow SaaS and dormant accounts during M&A integration?

Security teams should start with rapid discovery of every application, account, and integration path in both environments. Prioritise dormant accounts, unsanctioned apps, and third-party tools used during the deal. Then standardise access policies, revoke unnecessary permissions, and centralise identity controls so hidden access does not survive the merger. The key is to shrink the attack surface before systems are fully connected.

Why Shadow SaaS and Dormant Accounts Become M&A Risk Multipliers

M&A integration exposes access that was never designed to be merged cleanly. Shadow SaaS, legacy collaboration tools, contractor accounts, and stale service identities often sit outside central governance, so they survive diligence and then blend into the combined environment. That creates a window where hidden OAuth grants, orphaned admin roles, and dormant accounts can be reactivated or abused before standard controls are applied. NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts, which is exactly why merger activity is so dangerous.

Security teams should treat this as an identity consolidation problem, not just an application inventory exercise. The same logic seen in incidents like the Salesloft OAuth token breach and the BeyondTrust API key breach applies during integration: if old access paths remain valid, an attacker does not need to compromise the new perimeter. Current guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls supports aggressive account review and least privilege, but merger timelines often compress those steps. In practice, many security teams discover dormant access only after the first cross-domain sync has already expanded the blast radius.

How to Discover and Contain Hidden Access During Integration

The first priority is to build a merged access map before systems are interconnected. That means discovering all SaaS tenants, OAuth consents, API keys, service accounts, delegated admin roles, and the business owners who can still approve them. Teams should correlate procurement records, CASB data, SSO logs, directory exports, and finance approvals because no single source usually shows the full picture. For dormant accounts, the key question is not whether the account exists, but whether it still has a valid path back into a production system.

In practice, the safest sequence is:

• Freeze new third-party app approvals and new privileged grants until the inventory is complete.
• Classify accounts by business criticality, last use, and privilege level, then isolate unknowns first.
• Revoke unused OAuth grants, stale API keys, and duplicate admin entitlements before directory merge.
• Require reattestation from system owners for accounts that have been inactive beyond the defined threshold.
• Move surviving identities into central controls with logging, conditional access, and periodic review.

This is where Zero Trust thinking matters: the point is to validate every identity and every connection at runtime, not to trust legacy approvals simply because they predate the merger. The attack patterns described in the Snowflake breach and the GitHub Repo Breach — Heroku and Travis CI OAuth Tokens show why dormant tokens and forgotten integrations are so valuable to attackers. These controls tend to break down when identity data is fragmented across business units and SaaS tenants because no team can prove which dormant account is still linked to production.

Where the Standard Answer Breaks Down in Real M&A Programs

Tighter account cleanup often increases integration friction, requiring organisations to balance speed of merger execution against the risk of removing a still-needed hidden dependency. That tradeoff is real, especially when a business unit relies on unsanctioned SaaS to keep customer operations running during a transition. Best practice is evolving, but there is no universal standard for how much temporary access should be tolerated while integration teams sort out ownership.

The main edge case is shadow SaaS that has become operationally critical without ever being formally approved. In those cases, immediate shutdown can create outage risk, so teams may need a short exception window with monitored access, explicit owners, and a retirement date. Another common problem is dormant accounts tied to departed executives, contractors, or acquired-company admins who still have access to shared workspaces. NHI Mgmt Group’s guidance on the Ultimate Guide to Non-Human Identities is especially relevant here because NHI governance often reveals stale machine access that human-centric reviews miss. Current guidance suggests pairing access reviews with continuous monitoring, not one-time cleanup, because post-close activity often reactivates accounts that looked safe during diligence. The strongest programs also align with The State of Non-Human Identity Security to expose third-party connections that are invisible in standard IAM reports.

Related resources from NHI Mgmt Group

• How should security teams reduce risk from dormant SaaS integration credentials in third-party ecosystems?
• How should security teams reduce risk from shadow SaaS and unmanaged accounts in cloud environments?
• How should security teams automate SaaS user offboarding at scale across shadow apps and dormant accounts?
• What breaks when orphaned accounts and shadow IT are left in place during integration?