What should teams do first when an acquired hospital is added to an identity programme?

Start with inventory before expansion

The first move is to find out what the acquired hospital actually brought into scope. That means every application, directory, entitlement source, service account, API key, token and certificate, plus who owns each one and where it is used. Without that baseline, teams tend to widen access before they understand blast radius, which creates avoidable identity sprawl.

The practical goal is not just discovery, it is to separate what can be trusted from what must be re-validated. In an acquisition, inherited access often includes duplicates, stale accounts, hidden integrations and credentials that were created for local convenience rather than enterprise governance.

Why ownership and trust have to be established next

Once the inventory exists, the next question is ownership. Each identity source and credential-bearing system needs a responsible owner, a known authentication path, and a decision on whether it belongs in the target environment. That is the point at which teams decide which identities should be consolidated, which need new credentials or trust relationships, and which should be retired before broader access is granted.

This step matters because access is only safe when the source of authority is understood. If a directory, application or service account is inherited but not attributable, it is hard to prove whether its entitlements are current, whether its authentication is still valid, or whether it should remain a live path into clinical or administrative systems.

For a broader programme view, this is the same discipline that an Identity Security Programme Guide applies to any identity programme: establish scope, ownership and governance before you scale controls.

How to sequence consolidation without disrupting care

After discovery and ownership mapping, teams should sort identities into three groups: consolidate, reissue, or retire. Consolidate when two sources represent the same function and one can become authoritative; reissue when the hospital’s local credential or token should be replaced under central control; retire when an identity, key or certificate no longer has a justified business purpose. The sequence should be driven by dependency and patient-service risk, not by whichever system is easiest to migrate first.

That sequencing is especially important for service accounts and machine credentials, because they often sit behind clinical workflows, interface engines, imaging platforms and background integrations. A rushed cutover can break automation, but leaving inherited credentials untouched extends the period in which unknown access paths remain active.

Teams that need a structured migration path can use the Identity Programme Roadmap Template to phase the work, and the Ultimate Guide to NHIs to distinguish service accounts, API keys, tokens and certificates from human user access.

Risk and Threat Considerations

Acquired environments often arrive with overlapping directories, shared secrets and undocumented integrations. That creates a high-risk transition period where an old credential, stale service account or duplicate entitlement source can still authenticate while the new owner assumes it has already been rationalised.

Failure mechanism: inherited identities remain active longer than intended, so attackers or internal users can exploit unknown trust paths, excessive privilege or unmanaged secrets before consolidation is complete.

Impact: widened access can expose clinical systems, administrative records and connected services, and it can make compromise harder to detect because ownership and authority are unclear.

Practitioner Guidance

What to prioritise: Start with systems that can authenticate directly into production workflows, then work outward to lower-risk applications. If a credential, token or certificate can reach a live clinical or administrative service, treat it as a migration priority before any enterprise-wide access expansion.

What to verify: Confirm that every identity source has an owner, a current purpose and a documented decision, either keep, consolidate, reissue or retire. If you cannot name the owner or explain the trust path, the identity should not be allowed to persist by default.

Practitioner takeaway: In a hospital acquisition, speed comes from disciplined inventory and ownership mapping first, not from turning on broad federation or provisioning before you know which identities are safe to inherit.

Related resources from NHI Mgmt Group

• What breaks when identity security is added late in a CMMC programme?
• Who should get stronger authentication first in an identity programme?
• Who should require passkeys first in an identity programme?
• What happens when identity security monitoring is added on top of existing IAM controls without fixing the underlying gaps first?