What breaks when organisations fail to remove dormant SaaS accounts after an acquisition?

Dormant accounts often retain access to sensitive systems long after the business need has ended. In an acquisition, those accounts can become an easy entry point for attackers, especially if ownership is unclear or monitoring is weak. If teams do not purge them quickly, they inherit hidden access, increase breach exposure, and complicate later audit and offboarding work.

Why This Matters for Security Teams

After an acquisition, dormant SaaS accounts are not just housekeeping debt. They are inherited access paths that may still point into finance, support, CRM, collaboration, and admin consoles long after the original business purpose has ended. When ownership is unclear, these accounts often escape normal joiner-mover-leaver workflows and sit outside active monitoring, which means the buyer inherits exposure without inheriting the context needed to manage it.

That matters because dormant accounts undermine least privilege, complicate incident response, and weaken auditability. NIST’s control baseline for account management and access enforcement, including NIST SP 800-53 Rev 5 Security and Privacy Controls, assumes organisations can identify and govern who has access. Acquisition scenarios often break that assumption. NHIMG’s analysis of the Salesloft OAuth token breach shows how hidden third-party access paths can persist long enough to be abused, even when the business believes the access should have been retired.

In practice, many security teams discover dormant access only after a post-close review, when the real business and legal exposure has already been inherited.

How It Works in Practice

Dormant SaaS accounts break the security model in three places at once: identity governance, access review, and monitoring. An acquired company may have hundreds or thousands of user, admin, service, and contractor accounts tied to old domains, legacy IdPs, or unmerged tenant structures. Some are inactive by login history but still retain API permissions, delegated admin rights, mailbox access, or shared workspace membership. Others are “silent active” accounts that no one uses regularly but that still authenticate successfully.

The practical fix is not a single delete action. Teams need an acquisition-specific deprovisioning workflow that maps identities from the target environment to an accountable owner in the acquiring organisation, then validates whether each account is still required. That workflow should include:

• tenant inventory across SaaS, IdP, and shadow admin surfaces
• ownership assignment for every retained account
• risk-based review of privileged, federated, and service-linked identities
• session revocation, token invalidation, and MFA reset where supported
• log review for recent use before removal or quarantine

Current guidance suggests treating dormant access as a trust problem, not just a cleanup task. If an account cannot be tied to a live business function, it should be removed or tightly constrained until proven necessary. In high-impact environments, teams also need to align with control families in The State of Secrets in AppSec because stale SaaS accounts often coexist with exposed secrets, reused credentials, and weak rotation discipline. These controls tend to break down when the acquired tenant has no reliable identity inventory and the original admin group is already gone.

Common Variations and Edge Cases

Tighter deprovisioning often increases operational friction, requiring organisations to balance faster account removal against the risk of disrupting business-critical workflows. That tradeoff is especially visible in acquisitions where finance close, customer support, or regulatory retention teams claim they still need access.

There is no universal standard for this yet, but best practice is evolving toward staged removal: first quarantine, then confirm usage, then delete. That approach is safer than immediate mass deletion when the acquired environment has poor documentation or overlapping admin roles. Some accounts also require special handling. Service accounts may look dormant while still supporting background integrations. Shared accounts may hide multiple users behind one credential set. Federated accounts can survive even after local password resets if the upstream trust remains active.

NHIMG research on the BeyondTrust API key breach and Snowflake breach reinforces the same lesson: long-lived access, especially when poorly inventoried, becomes a durable attack path. The edge case to watch is a post-merger environment where identity data is split across multiple directories and no one can confidently prove whether an account is truly inactive or merely unobserved.

Related resources from NHI Mgmt Group

• What breaks when organisations do not track copied and derived data after consent is withdrawn?
• What breaks when organisations leave stale service accounts enabled?
• What breaks when organisations do not offboard unused SaaS integrations?
• What breaks when organisations do not revoke verifiable credentials after termination or device loss?