2. Identity and access survival

The Shock happened four hours ago - and nothing works. Not because systems are down, but because access is gone. Nearly everything sits behind the company’s single sign-on. The corporate email is unreachable. The internal messaging system does not open. Desktop phones across the office are silent - because they authenticate through the same identity layer. 

A few people managed to get in. They are the ones who never enabled SSO. At the time, it was considered sloppy. Non-compliant. Something that would be fixed later. Now, those accounts are the only ones that still work. Even then, most of these attempts fail at the second step. The two-factor authentication app does not unlock. Only a handful succeeded. They are the ones who can still find their recovery codes. 

Administrators are in the server room. They can see the racks. They can hear the fans. They can physically touch the servers. But they cannot log in. Consoles demand credentials, as a “modern” cloud-based Key Management System was put in place. Trust was outsourced,  and trust is now unreachable.

Modern companies are structurally vulnerable to identity and access failures for several reasons.

• They are heavily automated. Infrastructure changes, deployments, and even recovery procedures often require authenticated API access. When identity fails, automation becomes unusable.
• Access is frequently centralized. A small number of individuals hold administrative privileges, billing authority, or root access. This is efficient during normal operations but creates brittle dependencies during a crisis.
• Identity systems are often externalized. Single sign-on providers, cloud-native IAM, and managed authentication services reduce friction day-to-day, but they also create a tight coupling between identity availability and operational control. 

When these layers fail together, the company may be unable to even assess the situation, let alone fix it. Compute, storage, networking, and even backups may still exist and be technically intact, but without access to the control plane, they are unreachable and unmanageable. From the company’s perspective, they may as well not exist. 

Losing identity or administrative access is often worse than losing infrastructure itself.

Failure mode

When your SSO becomes unavailable, what can you still access ?

In traditional failure models, outages were associated with servers, disks, or networks. In cloud-native environments, the control plane (the systems that authenticate users, authorize actions, and allow changes to be made) becomes a fragile component: 

This control plane typically includes:

• cloud-dependant password managers (eg. Google’s built-in password manager in Chrome)
• cloud-dependant 2FA applications (eg. Google Authenticator)
• cloud IAM system (eg. Amazon IAM)
• cloud identity providers / SSO (eg. Okta)
• and policy enforcement layers that sit outside the company’s direct control.

If these systems are unavailable or inaccessible, access to numerous peripheral tools becomes impossible - let alone recovery: this is the “locked out” scenario. The company cannot access their own data and systems anymore - and grinds to a halt. It might undergo cyber attacks that remain unnoticed. 

This is not hypothetical. Reddit and HackerNews are filled with horror stories of companies losing access to their account due to automated account suspensions, expired payment methods, compromised credentials triggering protective lockouts, or identity provider outages that cascaded into cloud access loss.

Objectives

You cannot fix what you cannot access. Your identity management architecture should enable you to:

• Enable SSO-independant, offline access to critical systems, especially backups.
• Avoid total lockout from your own systems.

Solutions: Designing for identity failure

Resilient password management and 2FA

In many companies, identity itself is fully cloud-dependent: single sign-on is often provided by a third-party SaaS. Password managers synchronize through cloud backends. Two-factor authentication relies on mobile apps that require account recovery flows, push notifications, or device enrollment services hosted elsewhere. Even when credentials are technically “yours,” the systems that make them usable frequently are not.

This creates a layered dependency stack where access to your cloud infrastructure depends on an identity provider, then a password manager service, then a second-factor delivery mechanism, then a second-factor application, and on top of that the availability of the public internet itself. When any of these systems is unavailable, the result is not degraded security. It is complete loss of control. Security mechanisms designed to protect the company become obstacles to recovery.

Designing for identity failure does not mean abandoning SSO, password managers, or strong authentication. It means accepting that these tools may be temporarily unreachable, and that access paths must exist outside their normal operating assumptions.

This requires deliberate separation. Administrative access to infrastructure should not rely exclusively on the same SSO provider used for daily employee access. Emergency credentials should not live solely inside a cloud-synced password manager. Second-factor mechanisms must have offline-capable.

Password managers

Most mainstream cloud password managers are headquartered in the US (Bitwarden, Lastpass, Keeper) 1Password is based in Canada, and Dashlane is now headquartered in the US.

Want to add more or to report an inaccuracy ? Contact me. 

2FA Apps

The mainstream 2FA apps are mostly headquartered in the US as well (Google Authenticator, Microsoft Authenticator, Authy (by Twilio), BitWarden…

Want to add more or to report an inaccuracy ? Contact me. 

Break-glass access is not optional

In normal conditions, access feels ubiquitous. Engineers authenticate through single sign-on. Credentials are retrieved from password managers. Second factors arrive automatically on personal devices. Because these systems work every day, they are rarely questioned. During a widespread outage, however, they may all fail at once. Break-glass access exists to challenge that assumption.

Break-Glass Access (BGA) is the explicit verification that, even if cloud-based SSO systems are unavailable, even if password managers cannot sync, and even if normal authentication paths are broken, the company can still reach and control its most critical systems. 

This is typically achieved through backup access codes, sometimes called recovery codes, emergency codes, or one-time recovery codes. They are single-use credentials that allow a user to regain access to an account when normal authentication methods are unavailable. 

They are generated at account creation or when setting up 2FA devices. Research from Google, Microsoft and academia consistently shows that backup recovery mechanisms are a major point of failure in modern authentication systems. More than 50% of users cannot successfully recover accounts when primary authentication fails, even when recovery mechanisms exist. Users either do not save recovery codes during enrollment, store them in inaccessible locations, or are unable to retrieve them months later. 

Prepared companies treat backup access codes as critical recovery assets: 

• they are generated intentionally,
• stored offline or in systems with independent access paths,
• access is limited to a very small set of trusted individuals,
• ownership and responsibility are clearly defined,
• usage triggers an immediate regeneration process.

Prepared companies deliberately identify business critical systems and verify that these systems remain accessible without relying on the primary SSO provider. This starts with :

• The primary cloud provider account, including the ability to view resources, stop or start services, and manage access.
• The DNS provider, since DNS control determines whether traffic can be redirected, paused, or restored.
• The domain registrar, which ultimately governs ownership of the company’s domains.
• Billing and account ownership portals.
• Critical third-party infrastructure providers, such as CDN, email delivery, or monitoring services.
• Backup access paths to credentials, stored in a way that does not rely on cloud-only password managers or live synchronization.

The goal is not to avoid modern identity systems. The goal is to ensure that these foundational control points do not all disappear behind the same authentication failure.

Deliverables

Verification matters more than design

Many organizations believe Break-Glass Access exists, but it has never been exercised. Or the credentials technically exist, but no one has confirmed they still work independently of the identity provider. Or access depends on a single individual, device, or location that may not be available during an incident.

This verification is not theoretical. It is tested in controlled conditions, before a crisis forces improvisation. 

Conclusion

In cloud-native environments, identity is the real root of control. A company that is prepared for identity failures can answer the following questions confidently:

• If all administrators are locked out today, what is the recovery path?
• Who can prove ownership of the cloud account and how?
• How can credentials be rotated if the identity provider is down?
• How long can systems run safely without administrative access?

If these questions cannot be answered clearly, identity is a critical unmitigated risk.

Digital preparedness means accepting that identity and control planes can fail - and designing explicit, tested paths to recover access when they do. This is not about mistrust or paranoia. It is about ensuring that, even under extreme conditions, the company retains the ability to act.