Break-Glass Access Nobody Tested

A Conditional Access policy is edited on a Tuesday morning to require compliant devices. The scope stays at All users, because that is the default, and the exclusion list is empty. Twenty minutes later sign-ins begin failing across the company. Among the accounts that can no longer authenticate are the two administrators who could turn the policy off.

That is not a prediction about your business. It is a description of a mechanism, and the mechanism exists in every organization running a modern identity platform. No adversary is required. No zero-day. One checkbox and a quiet afternoon will do it.

The lockout you cause yourself is the likelier one

Break-glass accounts entered the IT vocabulary when identity was a convenience layer. Email had its own password. The file server had its own password. Losing access to one system was an inconvenience rather than an event.

Consolidation changed the shape of that risk. Single sign-on is now the front door to mail, documents, finance, the CRM, the VPN, the ticketing system, the security console, and often the phone system. That is genuinely good for IT security — one place to enforce MFA, one place to cut off a departing employee, one audit trail. It also means the blast radius of an identity failure is the whole company rather than one application.

Judgment, not statistics: the most probable cause of that failure is internal. Policy scope applied too broadly. A rule that assumes a device state the emergency account can never satisfy. A federation certificate that expired because the calendar reminder belonged to someone who left. A license change that silently removed the sign-in method an admin account depended on. None of these are attacks. They are configuration, and configuration is what most organizations change most often.

Passwordless removed a fallback nobody wrote down

For years the unstated recovery plan in most businesses was a password. Not a documented plan — an assumption. Somewhere there was a long string on a card in a drawer, and if everything else failed, someone would type it.

Passkeys and hardware-backed authentication are the right direction. Moving away from shared secrets is one of the few security shifts that improves protection and user experience at once. It also dismantles that assumption. A device-bound credential cannot be escrowed in a drawer. If the enrollment service is the unavailable thing, there is no path to register a new factor. If the phone holding the authenticator is the phone that was lost, the fallback and the primary share a failure mode.

The design rule that follows is an engineering judgment rather than a standard: emergency access should be built so that no two recovery paths share a dependency. In practice that tends to mean more than one break-glass identity, each surviving a different kind of failure. One protected by a physical security key held offline under two-person control. Another cloud-only account deliberately excluded from the policies most likely to be misconfigured, with alerting on every sign-in attempt. Exclusion makes security teams uncomfortable, as it should. The alternative is an emergency account that is perfectly secured and completely unusable.

Outage and takeover look identical at 3 a.m.

Executives hear "break-glass" and picture an outage. The provider has a bad day, service degrades, everyone waits. Annoying, expensive in lost hours, largely survivable with communication discipline and an out-of-band way to reach staff.

Contested control is the harder case, and the reasoning is structural rather than sourced from any incident report. In a consolidated tenant, identity is the most valuable thing an intruder can hold, because holding it makes every other control negotiable — authentication methods can be added, sessions for legitimate administrators can be revoked, trust relationships can be altered. The identity platform is perfectly healthy in that scenario. It is simply working for someone else.

Both emergencies sound the same on the first phone call. They demand opposite responses. One calls for patience. The other calls for immediate isolation, and the credentials needed for isolation are worthless if they live in a password vault that authenticates through the platform now under someone else's control. Emergency credentials belong outside the system they recover — physically, ideally split between two people, with the tamper seal serving as the audit record.

One newer wrinkle deserves naming. The practical break-glass path in most companies has always been "call IT and get a reset." Synthetic voice and video are now commodity capabilities, which means recognition is no longer proof of anything. If your emergency procedure depends on someone knowing a voice, or on a video call as identity evidence, the procedure has a hole in it. Deciding in advance who may authorize emergency access, and what counts as proof when a face and a voice no longer do, is part of the design.

The runbook lives behind the door you are trying to open

Draw the dependency map once and it is difficult to unsee. Where does the incident runbook live? If the answer is SharePoint, and SharePoint authenticates through the platform that is down, the runbook does not exist during the one hour it matters. Ask the same question of the backup console, the endpoint detection portal, the documentation wiki, the vendor contact list, and the chat tool you would use to coordinate. Plenty of organizations have rehearsed disaster recovery for servers and data and have never once run the exercise for identity, which is now the more probable failure.

Then there is rot. A credential nobody has used does not work. Expiration policies quietly invalidate it. Tenant changes made since it was created were never applied to it. The safe combination is known by someone who left two years ago. An untested emergency account is not a control; it is a belief. Exercising it on a schedule, with two people present and the result written down, converts belief into fact — and the exercise almost always surfaces something broken, which is the point.

This is also the moment to settle an ownership question that matters more than it sounds. If an outside provider administers your Microsoft 365 tenant, whose break-glass credentials are they? An arrangement where the only emergency access belongs to a vendor is a single point of failure with a contract wrapped around it. The healthier structure is explicit: the client holds sovereign access to its own identity platform, the provider holds operational access, and both are documented.

Three questions before the next configuration change

Break-glass access is not an IT hygiene item. It is the technology equivalent of check-signing authority — a decision about who can unilaterally take control of the company, under what conditions, and with which witnesses. That belongs on the officer agenda, not buried in a configuration ticket.

• Which recovery tools depend on the system they are meant to recover?
• When was emergency access last used successfully, by whom, and who watched?
• If someone called tonight claiming to be a locked-out executive, what would prove it?

The third question is why the human path matters as much as the technical one. Pro Link Systems has supported Los Angeles businesses from Woodland Hills since 1999, and our help desk is in-house, US-based, staffed around the clock, and answered live — no phone tree, no hold queue. Knowing exactly who picks up, and what they will ask you to prove, is itself part of the control. If you want a second set of eyes on your identity failure modes before a configuration change finds them first, start with our managed IT services team.