The Front Door That Locked Itself: Testing Identity Fallbacks Before an SSO Outage

Single sign-on has become so ordinary that staff rarely think about it until it stops working. As of November 2026, many UK SMEs rely on an identity provider to authenticate people into email, finance systems, file storage and a long tail of SaaS tools. When that service is unavailable, or when administrators lock themselves out of it, the effect is not a single failed login. It is a loss of access to the working day.

Most organisations have a disaster recovery plan for servers and a continuity plan for broadband. Fewer have rehearsed what happens when the identity layer itself is the problem. A tabletop drill is a proportionate way to find the gaps before they appear at 08:45 on a Monday.

Why an identity outage feels like everything at once

SSO is not merely a convenience. It is a dependency chain. If the identity provider cannot issue tokens, federated applications may reject every user, even when those applications are healthy. Email may be affected, file shares may be unreachable and finance approvals may stall. A misconfiguration, an expired certificate, a vendor-side outage or an aggressive conditional access rule can all produce the same outward symptom: the login screen says no.

That creates a specific risk for small teams. The people who would normally fix the problem may be unable to sign in to the tools they need to fix it. The drill should therefore test not only technical recovery, but also decision-making, communications and access to emergency credentials.

Set the scene for a one-hour drill

Choose a facilitator and a small group: an IT manager, a finance lead, an operations representative, someone who can speak for HR or internal communications, and a senior sponsor. The scenario should be plain and plausible: at 09:15 on a normal working day, the primary identity provider begins returning errors. The admin console is inaccessible. There is no confirmed estimated time to recovery.

Make the rules clear. No real changes are made during the tabletop. Decisions are recorded with timestamps. The group has one hour. The facilitator should introduce complications only where they are realistic, such as a key administrator being on leave or a remote worker unable to reach the office network.

First ten minutes: confirm the incident and name an owner

The group should decide who declares an identity incident and who leads it. That person confirms whether the problem is widespread rather than a single user's password issue. Checking the vendor status page is useful, but so is a quick internal test from more than one location. The incident lead should also prevent everyone from contacting the vendor separately.

A simple incident log is enough: time, symptom, systems affected, decisions taken and who owns each action. This record matters later, both for learning and for any audit or insurance question.

Minutes ten to twenty-five: break-glass access and critical applications

Break-glass accounts are the centre of the drill. These are emergency credentials intended for use when normal authentication fails. The group should confirm where they are stored, who can retrieve them and whether they still work. If the credentials sit in a password manager that itself depends on SSO, the fallback is not a fallback.

At least two emergency accounts should exist for critical platforms, owned by roles rather than individuals. Their use should be logged and alerted. They should not be shared across the helpdesk or used for routine administration. During the drill, walk through retrieval without actually signing in, then schedule a separate technical test.

The group should also list the five most important line-of-business applications and note how each authenticates. Some may support local accounts as an emergency route. Others may be SSO-only, in which case the practical fallback may be a vendor support process or a manual workaround. That distinction should be written down, not discovered during an outage.

Minutes twenty-five to forty: vendor updates and degraded operations

One person should own vendor communications. That means checking the status page at sensible intervals, raising a support case where needed, and recording case numbers and timestamps. Flooding a vendor with duplicate tickets from multiple staff rarely improves recovery.

For each critical system, the group should agree what degraded operations look like. Can finance process payments manually? Can payroll be run from a local file? Can staff access documents through an alternative route? If the answer is no, the organisation should say so clearly and decide who communicates that limitation. Acceptance of an outage is a valid decision, provided it is made deliberately.

Minutes forty to fifty-five: staff communications

The communications channel is often the weakest point. Sending an email to say that email is down is not a plan. The group should identify an out-of-band route: SMS, a phone tree, a notice on the intranet if it remains reachable, or a message on the main phone line. For remote staff, a mobile number list kept offline may be necessary.

Draft messages should be short and consistent. They should say what is affected, what staff should not do, where to get updates and how to contact the service desk. Staff should be told not to repeatedly attempt password resets, which can create further lockouts. A single source of truth prevents rumour.

Minutes fifty-five to sixty: debrief and actions

Finish with a short debrief. Record gaps such as missing credentials, unclear ownership, stale contact lists or applications with no fallback. Assign an owner and a date to each action. A tabletop is not a substitute for a technical test, but it is an efficient way to decide what must be tested next.

Keeping the fallback route patched and auditable

The emergency route needs maintenance. A quarterly check should confirm that break-glass accounts remain enabled, credentials are valid and the second factor is independent of the primary identity provider. Sign-in logs for those accounts should be reviewed. Emergency access exclusions should be documented so that they do not quietly become permanent loopholes.

Review the application inventory at the same time. New SaaS tools are often added without anyone asking how they authenticate. Update the runbook, the contact list and the communications templates. If a break-glass account is used, rotate its credentials afterwards and record the reason. Leavers should not retain emergency access, and the account should not sit in a shared spreadsheet.

A short drill checklist helps: confirm the incident owner, locate emergency credentials, identify the top five dependent applications, test the out-of-band communication route, record vendor contact details and set review dates. None of this is exotic. The point is to make the first fifteen minutes deliberate rather than improvised.

An identity provider outage is not the most likely event a UK SME will face, but it is one of the most disruptive relative to its duration. The login screen is now the front door. It is worth checking that the side entrance opens, that someone holds the key and that the alarm still works.