What breaks when orphaned accounts and shadow IT are left in place during integration?

Orphaned accounts and shadow IT create blind spots that often survive the early stages of integration. They can preserve hidden access after role changes, bypass normal review processes, and undermine segregation of duties. The result is a higher chance of unauthorised activity, audit findings, and remediation work after the deal closes.

Why This Matters for Security Teams

During integration, orphaned accounts and shadow IT rarely look dangerous on day one. They look like old exceptions, temporary connectors, or business-critical tools nobody wants to interrupt. That is exactly why they persist. Once the merger, acquisition, or platform consolidation begins, those hidden identities can keep authenticating, preserve stale entitlements, and bypass the normal review path that should catch privilege drift. Current guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls makes clear that access governance depends on maintaining accurate inventories, but integration work often moves faster than identity clean-up.

The practical risk is not just excess access. Shadow IT can introduce unmanaged SaaS tenants, unaudited OAuth grants, and unknown service accounts that never enter the formal control plane. NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, and that blind spot makes integration risk harder to contain. When those identities are connected to live business processes, they can become durable backdoors rather than temporary leftovers. In practice, many security teams discover the problem only after audit failures, failed offboarding, or the first suspicious transaction rather than through planned integration testing.

How It Works in Practice

The breakage usually starts with incomplete identity discovery. During integration, teams map humans first and systems second, which leaves service accounts, API keys, unmanaged app-to-app connections, and locally created admin users outside the migration plan. Those identities continue to function because the source systems still trust them, even if the owning team has changed, the application has moved, or the original business case no longer exists.

Orphaned accounts are especially risky because they often retain previous entitlements, embedded trust relationships, or direct database and cloud access. Shadow IT compounds that problem by introducing tools the central IAM or PAM stack does not control. That can create parallel approval paths, duplicate tokens, and inconsistent logging. For example, a sanctioned integration may be documented in one system while a forgotten OAuth grant or local account still has production access in another. NHIMG incident research such as Klue OAuth Supply Chain Breach and GitHub Repo Breach — Heroku and Travis CI OAuth Tokens shows how third-party trust and unmanaged tokens can turn one overlooked integration into broader exposure.

• Inventory every account type, including service accounts, bots, API keys, and local admin credentials.
• Identify ownership, business purpose, and last-used date before deciding whether to retain or revoke.
• Reconcile shadow IT against sanctioned tooling, especially SaaS apps with delegated OAuth access.
• Move retained access into explicit approval, logging, and review workflows.
• Revoke anything that cannot be linked to a current owner and business function.

These controls tend to break down when integration spans multiple cloud tenants and unmanaged SaaS platforms because no single team has complete visibility into credential issuance, reuse, and revocation.

Common Variations and Edge Cases

Tighter identity clean-up often increases project friction, requiring organisations to balance speed of integration against the risk of preserving hidden access. That tradeoff matters because not every orphaned account is immediately malicious, and not every shadow IT tool is unauthorized by intent. Some are embedded in finance close, customer support, or manufacturing workflows, which means abrupt removal can disrupt operations. Current guidance suggests risk-based prioritisation rather than blanket deletion, but there is no universal standard for this yet.

The most difficult edge case is shared ownership. If a legacy app has no current owner, no documented approver, and no reliable log source, the account may remain active simply because nobody can prove it is safe to remove. Another common exception is delegated access created by a business user through a sanctioned platform that later became unsanctioned through drift. In those cases, the technical control failure is often a governance failure first. NHIMG’s guide on Ultimate Guide to NHIs is useful here because it frames visibility, lifecycle control, and offboarding as one problem rather than separate tasks. NIST’s broader identity and access guidance on access control and account management supports that same approach.

Where teams go wrong is assuming integration completion means access normalisation is finished. It is usually the opposite: integration is when old trust relationships become hardest to see and easiest to exploit.

Related resources from NHI Mgmt Group

• What breaks when unused tokens and app connections are left in place?
• What breaks when orphaned machine identities are left in place?
• What breaks when stale Snowflake service accounts are left in place?
• What breaks when over-privileged SaaS accounts are left in place?