They should manage CIS1 and CIS2 as a controlled coexistence period with clear exception ownership, readiness checks, and access-path testing. The goal is to reduce reliance on CIS1 before the final removal date without forcing clinicians into unusable access patterns.
How trusts should run CIS1 and CIS2 together during withdrawal
Trusts should treat the period as a controlled coexistence, not a permanent dual-run. CIS1 needs an explicit sunset plan, while CIS2 should be introduced in a way that preserves clinical access, operational continuity, and traceability. The practical question is not whether both can exist briefly, but whether each access path is safe, owned, tested, and time-boxed.
The coexistence model matters because a rushed cutover can create unsafe workarounds, while an open-ended overlap can leave duplicate access routes in place longer than necessary. That usually shows up as unclear ownership, stale exceptions, and clinicians falling back to the path that “still works” rather than the one that is being migrated.
A good transition plan separates the business need for continuity from the technical goal of removal. If CIS2 is not yet ready for every use case, the trust should define which functions remain on CIS1, which can move now, and what evidence is required before any remaining CIS1 dependency is retired.
What readiness checks should exist before CIS1 is removed
Readiness is more than functional sign-off. The trust should confirm that CIS2 supports the real clinical workflows, that access pathways are documented, and that fallback behaviour is understood if a user cannot complete a task in CIS2. If the new path is technically live but operationally awkward, adoption will fail at the point of care.
Testing should include access-path validation, not just application testing. That means verifying who can reach the system, how they authenticate, what happens when roles or permissions differ, and whether the path works under realistic clinical pressures. For a healthcare environment, this is where access control becomes a patient-safety issue as much as a security issue.
The trust should also require exception review before go-live. If any team still needs CIS1 for a justified reason, that exception should have an owner, an expiry date, and a migration milestone. Without those elements, temporary access becomes de facto permanent access.
How to avoid unsafe workarounds during the migration
Workarounds usually appear when the replacement system is available in theory but not in practice. The highest-risk pattern is when users are forced to choose between compliance and getting their job done. If CIS2 is slower, harder to use, or missing a key access path, local teams will often preserve CIS1 usage informally.
That is why access-path testing should be done from the user journey outward, not just from the platform inward. The test is whether a clinician can complete the necessary task through the intended route without a hidden dependency on the withdrawn path, an informal bypass, or a shared credential pattern that weakens control.
Where there is uncertainty, trusts should prefer short, controlled exceptions over broad continued availability. A tightly governed exception is easier to audit, measure, and remove than an assumed business dependency that is never revisited.
Risk and Threat Considerations
The main risk is that a withdrawal timetable outpaces operational readiness, leaving users dependent on a legacy path after support has already weakened. That creates exposure from missed cutover dates, inconsistent access control, and unowned exceptions that are difficult to trace or remove.
Failure mechanism: CIS1 remains in use because CIS2 does not yet support every workflow, but the organisation lacks a disciplined exception and testing process. Users then route around the intended migration path, which can preserve access but weaken governance and increase the chance of unmanaged access exposure.
Impact: The trust can end up with duplicated access routes, unclear accountability, and delayed removal of a system that was supposed to be retired. In a clinical setting, that can also create service disruption if the legacy path is removed before the replacement path is genuinely usable.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication and Access Control | Controls access during CIS1 to CIS2 coexistence. |
| Recommendation — Test and enforce access paths so only approved users can reach each system. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Governs who retains access while legacy and replacement systems overlap. |
| Recommendation — Review and time-box accounts that still need CIS1 during migration. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Requires defined access control rules during transitional system use. |
| Recommendation — Define and enforce access rules for both CIS1 and CIS2 during coexistence. | ||
Practitioner Guidance
What to prioritise: Start with the few CIS1-dependent workflows that would cause the most disruption if removed too early, then prove CIS2 can handle those first. That sequence reduces the chance of forcing clinicians into temporary manual processes or shadow access routes.
What to verify: Confirm that every remaining CIS1 use case has an owner, a reason, a review date, and a tested CIS2 alternative. If any of those are missing, the issue is not just migration progress, it is governance debt.
Practitioner takeaway: The safest withdrawal is one that removes CIS1 only after CIS2 has been tested against real access patterns, because usability failures in migration are what usually turn a planned transition into a long-lived exception.
Related resources from NHI Mgmt Group
- How should healthcare organisations manage CIS1 to CIS2 migration without disrupting clinical access?
- How should organisations prepare for agent-ready desktops and MCP support?
- What does a data security platform need to support in an AI-ready enterprise?
- Why does HSTS increase the risk of lockout when certificates or subdomains are not fully ready?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org