How should organisations govern service accounts after an acquisition?

Why This Matters for Security Teams

After an acquisition, service account become one of the fastest ways for unknown access paths to survive the deal close. They are often spread across legacy systems, scripts, integrations, and CI/CD tooling, which means no single team can immediately answer who owns them, what they do, or whether they still need to exist. NHI Management Group’s Ultimate Guide to NHIs — What are Non-Human Identities shows why these identities are fundamentally different from human users: they are machine-held, often overprivileged, and easy to overlook during integration work. NIST’s NIST Cybersecurity Framework 2.0 reinforces the same operational expectation: identity assets must be governed continuously, not only at onboarding. NHIMG’s research also notes that only 5.7% of organisations have full visibility into their service accounts, which is exactly why acquisition programs inherit more access than they can readily justify. In practice, many security teams discover the real service account inventory only after authentication failures, application outages, or a post-merger incident investigation.

How It Works in Practice

Effective governance starts with a separate inventory stream for service accounts, API keys, and other non-human identities, rather than folding them into human IAM reports. That inventory should capture owner, system, business purpose, authentication method, last-used date, secret location, privilege scope, and dependencies. The most reliable way to clean up acquired environments is to validate each account against an application map, then retire anything that lacks a clear business function or accountable owner. The practical sequence is usually:

• discover service accounts across endpoints, cloud tenants, directories, vaults, pipelines, and embedded configs;
• classify them by criticality, blast radius, and whether they are interactive, scheduled, or machine-to-machine;
• tie each account to a named owner and a supported application or integration;
• rotate secrets before and after cutover where there is any doubt about exposure;
• remove dormant accounts, then monitor for failed authentications that reveal hidden dependencies.

Current guidance suggests that service account governance should align with lifecycle discipline in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs, especially around rotation, offboarding, and periodic review. That matters because acquisition projects frequently inherit secrets stored in code, config files, and pipelines, which increases the chance that legacy access persists long after the business case disappears. A good control plane also uses NIST CSF’s asset and access governance logic to keep inventories current and reviewable, not just documented once. These controls tend to break down when the acquired environment includes hard-coded credentials inside unmanaged scripts, because changing them can break batch jobs, integrations, or vendor connectors that nobody documented.

Common Variations and Edge Cases

Tighter service account control often increases migration friction, requiring organisations to balance security gain against application stability and deal timelines. That tradeoff is especially visible in carved-out environments, where domain trusts, shared vaults, and cross-tenant integrations make it hard to distinguish a truly orphaned account from one that still supports revenue-critical processing. Best practice is evolving here, but there is no universal standard for how much temporary exception handling is acceptable during post-acquisition separation. Two edge cases matter most. First, dormant accounts may still be required for quarterly jobs or disaster recovery paths, so “unused” cannot be the only deletion criterion. Second, service accounts with shared ownership across the seller and buyer should be short-lived bridge accounts, not permanent exceptions. NHIMG’s Top 10 NHI Issues highlights how excessive privileges and weak lifecycle discipline are common failure patterns, and the 52 NHI Breaches Analysis shows why inherited non-human identities often become the path of least resistance after a transaction closes. The safest posture is to treat every retained account as temporary until its owner, purpose, rotation method, and retirement plan are confirmed in writing.

Related resources from NHI Mgmt Group

• How should security teams govern Active Directory service accounts?
• How should organisations evaluate SoD for service accounts and automation identities?
• How should organisations govern password resets for privileged accounts?
• How should security teams govern non-human identities alongside human accounts?