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.
