Why do dormant accounts and orphaned service accounts become more dangerous during M&A?

They become more dangerous because merger timelines create pressure to keep systems working while governance lags behind. Dormant accounts and orphaned service accounts often retain valid credentials or trust relationships, so they can provide quiet access long after their business purpose has ended. In a combined environment, that old access is harder to see and easier to abuse.

Why dormant and orphaned access becomes riskier during M&A

In a merger or acquisition, the problem is not just that old accounts still exist. It is that integration work often prioritises continuity, so access cleanup is deferred while environments, directories, and ownership models are being reconciled. A dormant human account or orphaned service account can therefore outlive the controls that once constrained it and remain reachable through trust paths the combined business has not yet normalised.

That makes the old account materially more dangerous than it looked pre-deal. A valid login, token, key, or delegated trust relationship can bypass new approval workflows, especially when teams have not yet completed identity and access governance across both sides of the transaction. In practice, the account is dangerous because it is still accepted by systems that matter, not because it is active every day.

M&A also increases the chance that nobody can quickly prove who owns the account, which system depends on it, or whether its access should have been removed already. That ownership gap is what makes orphaned service account especially attractive: they often survive because they are embedded in application dependencies, batch jobs, integrations, and legacy automation. When those dependencies are discovered late, teams are forced to keep them alive temporarily, extending the window of exposure.

How attackers benefit from stale trust and hidden dependencies

Dormant access is valuable to an attacker because it tends to attract less attention than a privileged interactive account. If the credential still works, it can be used quietly for persistence, lateral movement, data access, or staged abuse while security teams focus on directory consolidation and application migration. The longer the transition lasts, the more likely the account blends into normal operational noise.

Orphaned service accounts create a different but related problem: the access is often machine-to-machine, so it may not be monitored with the same scrutiny as a human login. If the account still has broad rights, the attacker does not need to compromise a current employee or exploit a fresh vulnerability. They only need a credential or trust path that the business forgot to retire. NHIMG’s Service Account Security Guide and the NHI Ownership and Accountability Guide both point to the same operational truth: access that lacks clear ownership is hard to govern and easy to overlook.

The risk grows further when duplicated identities from both organisations collide. During integration, the same person, app, or integration may have multiple accounts, multiple roles, or multiple authentication paths. That duplication increases the chance that one path remains active after the intended replacement is in place, creating a hidden fallback route into production systems.

What should security teams do before the account sprawl settles

The most useful move is to treat M&A as a short-lived period of elevated identity risk, not a normal steady state. Start by identifying which dormant human accounts and service accounts still have reachable trust, then determine whether those accounts are tied to critical systems, privileged workflows, or cross-domain integrations. Identity posture management is useful here because it helps teams prioritise stale access, standing privileges, and ownership gaps before they are lost in migration work.

Where the account supports a business-critical process, the right response is usually not immediate deletion without validation. The better sequence is verify dependency, assign a named owner, reduce privilege, and then rotate or retire the credential as soon as the dependency is removed. For service accounts, that means confirming whether the process can move to a managed identity, federated trust, or another controlled pattern rather than preserving the old secret indefinitely. The Guide to NHI Rotation Challenges is directly relevant because rotation pressure rises sharply when many systems depend on the same account.

The biggest mistake is to assume that “unused” means “safe to leave alone” during the integration window. In an M&A context, unused often means “not yet discovered, not yet mapped, or not yet assigned to the new operating model.” The safer rule is to treat every unexplained valid credential or trust relationship as live until ownership, dependency, and removal criteria have been confirmed.

Risk and Threat Considerations

Dormant and orphaned accounts are dangerous in M&A because integration delays create a wider gap between technical reality and governance reality. That gap lets old access persist after the business has moved on, which increases the chance of unnoticed abuse, accidental overreach, or persistence by an intruder who finds a credential that should have been retired.

Failure mechanism: M&A projects often postpone access cleanup while directories, applications, and ownership structures are merged, so stale credentials and trust paths remain valid longer than intended.

Impact: Attackers or insiders can exploit the leftover access for quiet persistence, lateral movement, or data access, while defenders face a harder attribution and revocation problem because ownership is unclear.

Practitioner Guidance

What to prioritise: Focus first on accounts that combine three traits: valid authentication material, unclear ownership, and access to production or cross-environment systems. Those are the accounts most likely to become hidden bridge points during integration.

What to verify: Before trusting a dormant or orphaned service account, confirm who owns it, what system depends on it, when it was last used, and whether its credential can be rotated without breaking a live process. If any of those answers are missing, treat the account as a transition risk, not a low-priority cleanup item.

Decision rule: If the account still authenticates to a critical system, reduce privilege and rotate it before you spend time debating whether it has already been abused. If it cannot be fully justified, remove or isolate it with an expiry plan rather than allowing it to survive by default.

Practitioner takeaway: In M&A, stale access is dangerous because integration pressure turns “temporary retention” into long-lived exposure, so ownership and credential validation must move faster than system consolidation.

Related resources from NHI Mgmt Group

• Why do dormant and orphaned accounts become more dangerous during holiday periods?
• When do service accounts become a higher risk than ordinary user accounts?
• What problem does ownership attribution solve for service accounts and API keys?
• How should security teams govern Active Directory service accounts?