How do you stand up an out-of-band incident bridge in a SaaS-first company with no on-premises fallback?

## The situation Everything the company runs on is somebody else's platform: chat, mail, documents, the identity provider, the on-call rota, the HR directory. You have concluded that at least one identity in that tenant is adversary-controlled and you cannot yet bound the compromise. There is no server room to retreat to. You need a place to plan, and you need it inside the hour. ## Work the four dependencies in order **1. Identity.** The bridge must not authenticate through the suspect identity provider. That rules out most of the obvious options, because the fastest thing to reach for is another product in the same tenant. It also rules out procuring a new tool by clicking "sign up with corporate SSO", which quietly re-creates the dependency you were escaping. Practical answers: a conference bridge from an unrelated provider joined by dial-in, a secure messenger on personal devices with identities that are personal, or - if the company was farsighted - a small standing tenant with independent accounts and its own multi-factor credentials. **2. Membership and the roster problem.** You need contact details for responders, and the address book is in the compromised suite. This is the step teams have not rehearsed. Options: personal numbers held by the responders themselves, an offline copy of the call tree if one was ever printed or exported, or an HR contact retrieved by a person walking to a desk rather than by a query against the suspect directory. Never post the bridge details in the in-band channel, which is the single most common way an out-of-band bridge is compromised in its first ten minutes. **3. Verification of who joins.** An unknown number on a bridge is not a colleague until you have established that it is. Verify live: a voice the convener recognises, or a challenge that turns on shared prior knowledge - something the two of you did together that is not written down anywhere in the estate. Do not verify by sending a code to a corporate mailbox or chat account, and be aware that a familiar-sounding voice alone is weaker than it used to be. Admission is by name, one person at a time, and someone keeps the list. **4. Devices and content.** If endpoints are in scope, the laptop is not a trusted display. Phones, or a small number of machines you have reason to believe are clean, carry the sensitive part. The artefacts that matter - the working hypothesis, the list of hosts and accounts you believe are involved, the planned timing of any action - live off the estate's document store, because a document that is merely restricted in a compromised tenant is not restricted. ## The decisions that come with it **Keep the room small, and say why.** Every extra member is exposure and slower decisions. Name who is on it: incident lead, the investigators, someone from legal, an executive sponsor, and the platform owner you cannot act without. Everybody else gets what they need through a named person. **Decide what stays in-band deliberately.** Ordinary business should continue to look ordinary. A company where every channel goes silent at 03:00 has announced something, and the sudden absence of the usual chatter is itself a signal to someone watching. The rule is that the *sensitive* conversation moves; the routine one does not have to. **Keep a record.** The out-of-band channel still produces the incident record. Decisions, times and who approved what have to be captured somewhere durable and later folded into the case file, because an investigation held on people's personal phones is one that cannot be reconstructed and is awkward to produce if lawyers, auditors or an insurer ask. This is a real argument for an independent company-run tenant over personal apps where you have the option. **Plan the exit.** Out-of-band operation is expensive in speed and context. State the conditions for going home: adversary access removed, session and token revocation confirmed, monitoring in place that would show re-entry, and no live hypothesis that depends on the estate being untrusted. ## Failure modes worth naming out loud - The new tool is procured with the compromised SSO, or its administrators are the same administrators. - The bridge number is posted in the in-band channel by someone trying to be helpful. - The multi-factor prompt for the new tool is delivered to the corporate mailbox or an authenticator managed by the suspect identity provider. - The on-call rota that tells you who to invite lives in the suite you are avoiding. - The bridge has no host controls, so anyone with the number is in the room and nobody notices. - Nobody wrote anything down, and three days later there is no record of who decided what and when. ## What good looks like The strongest answers acknowledge that the real work happened *before* the incident: an independent tenant already exists, an offline roster is kept current, and the team has dialled the bridge once in a rehearsal. Building all of it at 03:00 is survivable, but you will make dependency mistakes under pressure, and knowing which ones is what the interviewer is listening for.