How should organisations design identity access so users can still authenticate during a cloud outage?

Design for authentication continuity, not a single cloud dependency

The core design choice is to treat authentication as a service that must survive cloud disruption, not as a feature that is assumed to be available whenever the primary identity platform is reachable. That means planning an alternate path for sign-in, validating what happens when the primary path is unavailable, and making sure the fallback preserves security properties such as strong authentication, policy enforcement, and auditability.

For many organisations, the most practical pattern is a local or independently hosted failover path for the critical identity services that users depend on during an outage. The exact architecture may vary, but the important test is simple: if the cloud identity service is unavailable, can users still prove who they are without bypassing the control model? If the answer is no, the outage has become an access outage.

That is why the design has to include both the NIST Cybersecurity Framework 2.0 recover function and the access-control disciplines captured in CIS Controls v8. One focuses attention on continuity and restoration, while the other reinforces that account management and access control still need to hold during degraded operations.

What the fallback must preserve during a cloud outage

A working fallback is not just a backup login page. It needs to preserve the actual trust decisions that make authentication useful: who is allowed to authenticate, how assurance is established, which factors are required, and what logging is retained for later review. If the backup path is simpler than the primary path without a deliberate risk decision, it can quietly become the weakest control in the environment.

In practice, organisations should expect trade-offs. A fallback that is too permissive can restore availability but weaken assurance. A fallback that is too strict can preserve control but fail the business continuity goal. The right balance depends on which systems are truly mission critical and whether the outage scenario is loss of the cloud service, loss of connectivity to the cloud, or loss of the organisation’s own identity dependencies.

This is where ISO/IEC 27001:2022 Information Security Management and the NIST Cybersecurity Framework 2.0 both help: the former pushes organisations to define security requirements and control ownership, while the latter keeps the discussion anchored in protect and recover outcomes rather than in a single product implementation.

For cloud-centric identity stacks, the most useful architectural question is whether your authentication design has an independent control plane, an independent network path, or an independently reachable directory or federation component. If all three depend on the same cloud failure domain, the fallback is probably only theoretical.

Practitioner guidance for building and testing outage-safe authentication

What to prioritise: protect the highest-value authentication journeys first, such as workforce access to core operations, admin access for recovery, and any account paths that would block the business if unavailable. Do not start with full feature parity; start with the sign-ins that preserve operational continuity.

What to verify: test the exact outage modes that matter, including identity provider unavailability, DNS failure, network isolation, and expired or revoked credentials. The control is only real if users can complete authentication under the same assumptions the outage will break.

Common mistake: treating failover as an availability exercise only. A fallback path that ignores assurance level, role-based restrictions, or logging can restore access while creating a harder problem later, because the organisation may not know who authenticated, under what conditions, or with what privileges.

Decision rule: if the backup path cannot enforce the minimum assurance needed for the system, limit it to recovery roles and tightly scoped emergency access rather than normal production access. That keeps continuity without turning resilience into an open door.

Practitioner takeaway: design the outage path as a governed authentication mode, not an emergency bypass, and prove it works under real failure conditions before you rely on it in production.

Related resources from NHI Mgmt Group

• How should security teams design access controls that still work during a cloud outage?
• How should organisations govern access to SAP workloads in RISE with SAP S/4HANA Cloud without weakening identity controls during migration?
• How should organisations secure cloud platform access when users authenticate with eIDs across multiple services?
• Who is accountable for identity continuity when access fails during an outage?