Who is accountable for securing CIS2 access during the transition period?

Why This Matters for Security Teams

During the CIS2 transition period, accountability is not limited to one team because the access path touches identity proofing, privileged workflows, endpoint posture, and application behaviour at the same time. When access is still being migrated, any gap in one control plane can create a service outage or an unauthorised path into clinical systems. That is why the practical answer is shared accountability across identity, infrastructure, and clinical application owners.

For NHI-driven access paths, the risk is often invisible until secrets or service accounts are already in play. NHI Mgmt Group notes in the Ultimate Guide to NHIs that 97% of NHIs carry excessive privileges, which is a useful warning for any transition where temporary exceptions become permanent. The problem is not just permission scope. It is also ownership clarity, rotation discipline, and whether the access remains governable while systems are being changed. OWASP’s Non-Human Identity Top 10 frames this as an identity and lifecycle issue, not merely an IAM configuration task. In practice, many security teams encounter broken accountability only after a failed login, a delayed patient workflow, or an emergency rollback has already occurred, rather than through intentional transition control design.

How It Works in Practice

Effective CIS2 transition governance treats accountability as an operating model, not a ticket assignment. Identity teams usually own the authentication fabric, credential policy, federation, and access telemetry. Infrastructure teams own network reachability, platform hardening, certificate and secret handling, and uptime of the path itself. Clinical application owners own the workflow logic, role mapping, and whether the access model still supports safe care delivery. Current guidance suggests that all three must sign off on the transition state, because no single owner can validate the full chain end to end.

A practical pattern is to create a named transition control owner, then require three controls before cutover:

• Identity controls: MFA, federation, break-glass rules, and privileged account review.
• Infrastructure controls: segmentation, logging, certificate validity, and secret rotation.
• Application controls: role mapping, session timeout, and safe fallback workflow.

Where service accounts or API keys support the access path, the same discipline applies. NHI Mgmt Group’s Key Challenges and Risks research shows how often secrets are mismanaged, and that matters because a transition window is exactly when temporary credentials proliferate. For implementation, teams can use the OWASP Non-Human Identity Top 10 to check for overprivileged accounts, stale secrets, and missing ownership. These controls tend to break down when legacy clinical systems require shared accounts and cannot support traceable per-user or per-service identity.

Common Variations and Edge Cases

Tighter transition governance often increases coordination overhead, requiring organisations to balance safer access against urgent clinical continuity. That tradeoff is real, especially when a hospital must maintain 24/7 operations while migrating authentication or access policies. Best practice is evolving here, and there is no universal standard for who signs the final approval in every environment. Some organisations place final authority with the CISO, while others use a joint clinical-technical change board, but the operational principle is the same: the owner of the risk must be explicit.

Edge cases usually appear when:

• Emergency or downtime access must bypass normal approval flows.
• Third-party vendors still hold live credentials during migration.
• Multiple clinical applications depend on the same identity source.
• Shared service accounts prevent clean attribution and revoke-on-completion handling.

In those cases, accountability should shift from “who approves access” to “who can prove the path is secure right now.” That is why transition evidence should include ownership registers, exception expiry dates, and revocation testing, not just project plans. For organisations trying to reduce residual risk, the 52 NHI Breaches Analysis is a useful reminder that unmanaged credentials become incident material quickly when controls are deferred.

Related resources from NHI Mgmt Group

• Who is accountable when access governance gaps appear during digital transformation?
• Who is accountable for access risk during an SAP IDM migration?
• How should manufacturing teams automate access governance during seasonal hiring spikes?
• Who is accountable when access is over-provisioned across cloud and on-premises systems?