How should healthcare organisations manage CIS1 to CIS2 migration without disrupting clinical access?

They should treat the migration as an identity governance programme, not a one-time technical swap. That means mapping every CIS1 dependency, validating CIS2-ready authentication on shared devices, and coordinating provisioning and offboarding across local and national systems so clinicians keep uninterrupted, auditable access during the transition.

Why This Matters for Security Teams

CIS1 to CIS2 migration is rarely just an authentication upgrade. In healthcare, the real risk is breaking access paths that clinicians rely on across shared workstations, mobile carts, wards, and cross-system workflows. A migration that ignores identity dependencies can create downtime, shadow access, or rushed exceptions that outlive the project. Guidance from the NIST Cybersecurity Framework 2.0 and the Ultimate Guide to NHIs both point to the same operational reality: identity changes must be governed, measured, and reversible.

For healthcare organisations, the migration also intersects with non-human identities that support clinical systems, integration engines, and scheduling or medication workflows. Those accounts often have broader privileges than expected, which means a CIS1 to CIS2 change can expose hidden dependencies if credentials, tokens, or service accounts are not mapped first. NHI Management Group has noted that only 5.7% of organisations have full visibility into their service accounts, which is why migration planning must extend beyond user sign-in flows. In practice, many security teams discover failed access only after clinicians are already blocked at the point of care, rather than through intentional testing.

How It Works in Practice

The safest approach is to treat the move as an identity governance programme with staged cutover, not a big-bang replacement. Start by inventorying every CIS1 dependency, including clinical apps, federation links, shared-device logins, and back-end NHI integrations. Then classify each path by risk: human clinician access, machine-to-machine access, and emergency access. That distinction matters because an account used by a nurse on a shared terminal behaves very differently from a service account used by an interface engine.

Current best practice is to validate CIS2-ready authentication in parallel before decommissioning CIS1. That usually means testing on shared devices, confirming session persistence rules, and verifying that offboarding and provisioning work across both local and national systems. Where possible, use step-up controls for sensitive actions, short-lived access for temporary roles, and explicit break-glass procedures for outage scenarios. The Top 10 NHI Issues and OWASP Non-Human Identity Top 10 are useful references for spotting where service account sprawl, over-privilege, and weak rotation can undermine migration safety.

• Map every CIS1 login flow and dependency before changing policy.
• Test CIS2 on shared clinical endpoints with real workflows, not lab-only samples.
• Coordinate identity lifecycle events so joiner, mover, and leaver actions stay synchronized.
• Keep audit trails intact across both systems during the transition window.
• Revoke or rotate stale service credentials as dependencies are retired.

Where this guidance breaks down is in highly federated hospital networks with inconsistent local device management, because authentication success can vary by site, terminal state, and legacy integration timing.

Common Variations and Edge Cases

Tighter migration control often increases operational overhead, requiring organisations to balance reduced access risk against clinical continuity and support burden. That tradeoff becomes sharp in emergency departments, theatres, and remote clinics, where even brief access friction can affect care delivery. There is no universal standard for every CIS1 to CIS2 rollout, so current guidance suggests prioritising the highest-risk workflows first and deferring low-risk paths only with explicit exception tracking.

Edge cases usually involve break-glass accounts, third-party access, and embedded NHI credentials inside clinical applications or interfaces. These should not be migrated by assumption. Instead, validate whether the credential is human, machine, or application-scoped, then apply the least disruptive control that still preserves accountability. The Regulatory and Audit Perspectives section of the Ultimate Guide to NHIs is especially relevant when migration evidence must satisfy auditors and clinical governance teams at the same time. In practice, the hardest failures come from legacy clinical systems that cannot support modern session controls, forcing a phased coexistence model longer than security teams originally planned.

Related resources from NHI Mgmt Group

• How should NHS security teams reduce privileged access risk without disrupting clinical operations?
• How should organisations phase in passwordless authentication without disrupting access?
• How should healthcare teams reduce password reset tickets without disrupting clinical workflows?
• How should organisations manage SaaS access without creating entitlement drift?