When your primary systems fail under attack, improvised emergency access is better than nothing. But it isn't a strategy. Here's what separates a break-glass capability from a purpose-built out-of-band resilience platform.
Imagine it's 3am. Your IT team has just confirmed a ransomware attack is spreading across your network. Email is compromised. Microsoft Teams has been taken offline as a precaution. Your CISO can't reach the board. The CEO has no way to tell the incident response team what decisions have been made. Your comms infrastructure - the very thing you need to manage the crisis - is itself part of the incident.
This is the scenario that separates organisations that have thought seriously about resilience from those that haven't. And it's where the distinction between a break glass capability and a proper out-of-band (OOB) communications platform becomes critical.
The term comes from the old emergency fire alarm boxes - the ones behind a pane of glass with the instruction "In case of emergency break glass".
In technology and security, a break-glass capability refers to an emergency mechanism that exists outside normal operating procedures, held in reserve for when everything else has failed.
(The term may appear as break glass, break-glass or breakglass - they are interchangeable)
In practice, break glass approaches in the communications context typically include things like:
What these have in common is that they are survivable by design - they exist separately from your primary infrastructure. If your main environment is compromised, the break glass option should still function.
"A break glass capability is a lifeline. But a lifeline is not the same as a lifeboat."
The analogy is apt. A lifeline - a rope thrown from the shore - might save one person in an emergency. A lifeboat is a structured, equipped vessel capable of keeping an entire crew safe and coordinated over an extended period. When a major cyber incident strikes an organisation of any significant size or complexity, what you need is the lifeboat.
Breakglass solutions solve one problem elegantly: survivability. But they introduce new ones - or fail to address the full scope of what crisis communications actually requires.
|
WHAT BREAKGLASS DOES WELL |
WHERE BREAKGLASS FALLS SHORT |
|
|
Consider what actually happens in a major incident.
The first few minutes might indeed be served by a breakglass contact list - the CISO calls the CTO on a mobile number.
But within the hour, you need structured situation reports going to the right people.
You need to document decisions made under legal privilege.
You need your incident response team coordinating across time zones, your PR team aligned with your legal counsel, and your board receiving a coherent briefing — all without any of that communication touching the compromised environment.
A WhatsApp group, however well-intentioned, cannot do that work.
YUDU Sentinel is purpose-built as an out-of-band resilience platform. That means it operates on entirely separate infrastructure from your primary IT environment - separate networks, separate cloud hosting, separate authentication.
If your Microsoft 365 tenant is encrypted, Sentinel is unaffected. If your on-premises servers are offline, Sentinel is still running.
In that narrow sense - survivability - Sentinel shares the same foundational purpose as a break-glass capability. Both are designed to still work when your primary environment doesn't. But Sentinel goes considerably further.
|
CAPABILITY |
BREAK GLASS |
YUDU SENTINEL |
|
Survives network compromise |
Yes |
Yes |
|
Secure messaging between groups |
Partial |
Yes |
|
Structured incident command workflow |
No |
Yes |
|
Auditable communication log |
No |
Yes |
|
Secure file and document sharing |
No |
Yes |
|
Broadcast alerting to staff |
Limited |
Yes |
|
Role-based access and permissions |
No |
Yes |
|
Legal privilege-compatible comms |
No |
Yes |
|
Scales across large organisations |
No |
Yes |
|
Regular testing and exercising |
Rarely |
Built-in |
|
Single-tenant data isolation |
No |
Yes |
|
Zero cost to set up |
Yes |
No |
One dimension that is almost universally overlooked in break-glass planning is the legal and regulatory importance of a contemporaneous record. After a significant cyber incident, your organisation will face scrutiny - from the ICO, from regulators, from insurers, possibly from litigation.
A WhatsApp thread that was hurriedly deleted the morning after the incident, or that exists on someone's personal device, is not an adequate answer.
YUDU Sentinel maintains a verifiable, time-stamped record of communications that occurred during the incident - one that can support post-incident review, demonstrate regulatory compliance, and if necessary be produced as evidence of responsible crisis management.
That capability simply does not exist in any informal break glass approach.
There is a quiet irony in how most organisations approach break-glass capabilities: they are set up, documented in a procedure somewhere, and then never tested.
The mobile number list is three years out of date. The Signal group still contains someone who left the business eighteen months ago. The laptop with the emergency credentials is in a storage room and nobody knows the password.
"An untested break glass capability is indistinguishable from no capability at all — until the moment you need it."
YUDU Sentinel is designed to be exercised regularly. Crisis simulations, tabletop exercises, and live drills can all be run through the platform — which means that when a real incident occurs, your team is already familiar with how to navigate it. Muscle memory matters. The 3am moment is not the time to read the instructions.
The honest answer is: complementary, if the break-glass capability is genuinely necessary for your organisation's context - and Sentinel is your structured resilience layer.
For very small teams or specific edge cases (a single executive travelling internationally without network access, for example), a personal device-based backup contact method makes sense as a last resort. But it should be exactly that: a last resort, not a strategy. Sentinel handles the operational reality of incident communications - the sustained, structured, governed coordination that a real response requires.
Think of it this way. A break glass capability answers the question: can we reach each other at all? YUDU Sentinel answers the question: can we manage this crisis effectively, compliantly, and with a complete record of what happened?
Both questions matter. Only one of them is sufficient.
Organisations with mature crisis communication resilience tend to have three things in place.
First, a verified contact method that sits entirely outside their corporate environment - this is the legitimate core of a break glass capability, properly maintained and tested.
Second, a purpose-built OOB platform like YUDU Sentinel as the primary coordination environment for any incident of material significance.
Third, a programme of regular exercising that covers both — so that when an incident occurs, nobody is working out how to use the tool for the first time under pressure.
The Colt Technology cyberattack, the NHS ransomware incidents (WannaCry and Synnovis), the attacks on critical national infrastructure providers across Europe - all of them have reinforced the same lesson. The organisations that managed these events well had invested in their resilience infrastructure before the incident, not during it.
The glass was already in its frame. They just never needed to break it.