A decision guide for enterprise resilience, security, and business continuity teams evaluating crisis communication platforms.
Microsoft 365 outages are no longer rare events. When Exchange Online, Teams, or Entra ID goes down, the first casualty is often the very tool teams planned to use to tell people about it. If your crisis communication platform sends alerts through Outlook, authenticates through Entra ID, or expects staff to open Teams to see an incident notice, you don't have a crisis communication plan - you have a single point of failure with a different name.
This guide answers the eight questions enterprise resilience and security teams most need answered before selecting or re-evaluating a crisis communication platform, with a specific focus on Microsoft 365-independent platforms, secure alerting, and app-free staff alerts.
Because most organisations route incident alerting through the same Microsoft 365 stack that just failed.
Distribution lists live in Exchange, alert bots live in Teams, and login for the alerting tool itself often runs through Entra ID (Azure AD) single sign-on. When Microsoft 365 has an availability incident - authentication failures, Exchange Online mail delays, Teams outages - all three dependencies routinely go down together, because they share the same underlying identity infrastructure.
This isn't hypothetical. In October 2025, a Microsoft 365 outage left users unable to authenticate into Teams or Exchange Online at the same time that Entra ID single sign-on and multi-factor authentication messages were failing - meaning the alerting tool, the login path, and the MFA fallback all degraded together. Microsoft later attributed it to imbalanced directory operations infrastructure during a traffic spike.
A similar pattern recurred in January 2026, when an authentication and routing disruption (tracked internally as MO1221364) took down Outlook, Exchange Online, Teams, and the admin portals within the same window, and again in June 2026, when an Exchange Online mail-routing fault (EX1331830) disrupted delivery across North America, Asia-Pacific, and Europe for over an hour.
The practical test: ask whether your current alerting tool would still work if Entra ID authentication and Exchange Online were both unavailable at the same time. Recent history says that's not an edge case — it's the specific failure mode M365-dependent alerting tools keep running into. If the honest answer is "no," independence from M365 isn't a nice-to-have feature — it's the core requirement.
It means the platform's infrastructure, identity, and delivery paths run separately from Microsoft's cloud, so a Microsoft outage doesn't take your alerting down with it. Three components need to be checked independently - vendors will often satisfy one and imply the other two:
| Component | What "independent" looks like | What to watch for |
|---|---|---|
| Hosting infrastructure | Runs on its own cloud environment or a non-Microsoft cloud (AWS, GCP, private data centre) | Platform quietly hosted on Azure, inheriting Microsoft's own outage risk |
| Identity and authentication | Has a working login path that doesn't require Entra ID/Azure AD, even if SSO is offered as an option | SSO-only login with no fallback — covered in Question 5 |
| Delivery channels | Sends via SMS, voice, push notification through its own gateways — not solely through Outlook/Exchange or Teams | "Multi-channel" that quietly means "email plus Teams" |
A genuinely independent platform should be able to activate an incident and reach every recipient with zero functioning Microsoft 365 services. That's the bar - not "mostly independent," not "independent except for login."
Because during a real incident, you cannot assume staff have the app installed, updated, logged in, and connected — and you don't have time to find out.
App-based alerting is the single most common gap discovered in post-incident reviews: the alert "went out," but a meaningful share of staff never saw it because they hadn't opened the app in weeks, hadn't accepted push notifications, or had it removed after a phone upgrade.
App-free staff alerts - delivered via SMS, voice call, or standard email that doesn't require an app to open - solve this by using channels every device supports without setup. This matters most for:
The right posture isn't "app or no app" - it's app-optional. A well-designed platform should reach 100% of a distribution list through app-free channels and treat an app (if offered) as a convenience layer for two-way response, not the primary delivery mechanism.
Encryption in transit is table stakes; it doesn't tell you much on its own. For enterprise security and business continuity teams, secure alerting during an M365 outage should be evaluated against four specific criteria:
Vendor certifications worth asking for directly include ISO 27001 : 2022, and — for UK/EU organisations - confirmation of GDPR-compliant data handling and hosting location.
Don't activate SSO on your crisis communications platform -if it's an option.
SSO is often presented as a security improvement: fewer passwords, easier access and simpler administration. But for a crisis communications platform, those benefits come with a serious trade-off.
You are connecting your crisis platform directly to the identity system most likely to be targeted during a cyberattack.
If an attacker compromises a Microsoft 365 account with access to your crisis platform, they may be able to use those credentials to authenticate directly into the platform. The very mechanism designed to make access easier can therefore create another route into a system that exists to coordinate your response to an attack.
There is also a resilience problem. If Microsoft 365 or Entra ID is unavailable, degraded or compromised, SSO can prevent legitimate administrators from accessing the crisis platform altogether — even when the crisis platform itself is fully operational.
For ordinary business applications, that dependency may be an acceptable trade-off. For crisis communications, it isn't.
Your emergency communications platform should be deliberately separated from your primary identity infrastructure. It needs its own authentication controls, independent credentials and a secure access route that remains available if Microsoft 365 is compromised or unavailable.
Don't ask whether the platform supports SSO. Ask whether you can keep it switched off.
Your crisis communications platform should provide an independent authentication mechanism that:
SSO makes everyday access easier. In a crisis communications platform, that convenience can come at the cost of security and resilience. Keep it switched off.
Because every integration point marketed as convenience is also a dependency, and vendors rarely draw that distinction for you.
SSO (Question 5) is the most obvious example, but it's rarely the only one. Platforms increasingly compete on how tightly they plug into Microsoft 365 - a native Teams bot for alert delivery, an Outlook add-in for triggering an incident, incident plans and contact directories hosted in SharePoint, escalation workflows built on Power Automate.
Each of these is a genuine convenience during normal operations. Each one is also a thread tying the crisis platform's functionality back to the exact stack it needs to survive an outage of.
The distinction that matters is integration as a convenience layer versus integration as a dependency:
| Integration point | Convenience layer (fine) | Dependency (a problem) |
|---|---|---|
| Teams alert delivery | One of several channels; SMS/voice/email work if Teams is down | The primary or only channel staff are told to watch |
| Outlook add-in for triggering alerts | A shortcut for admins already logged in | The only way to activate an incident |
| SharePoint-hosted incident plans | A convenient reference copy | The only copy, with no offline or independently-hosted fallback |
| Power Automate/Power Platform workflows | Automates routine, non-critical steps | Drives the escalation logic itself, with no manual override |
None of these integrations are wrong to use. The problem is treating them as free - every one quietly narrows the set of conditions under which the platform actually works, and that narrowing is invisible until the exact moment M365 goes down.
The question to put to any vendor, for each integration they demo: "If this specific Microsoft 365 service is unavailable, what breaks, and what's the fallback?" A vendor who can answer that cleanly for every integration point has designed for resilience. A vendor who can only answer it for login (because that's the question everyone now knows to ask) may have solved Question 5 while leaving three quieter dependencies in place.
UK organisations are working against three overlapping pieces of legislation right now, each at a different stage - and all three push in the same direction: toward crisis communication capability that doesn't depend on the systems it may need to report on.
DORA (Digital Operational Resilience Act) has been in force in the EU since 17 January 2025. It isn't UK law, but it applies directly to UK financial entities that operate in the EU or serve EU clients, and it sets a benchmark UK regulators increasingly expect firms to match.
Three articles matter most for this evaluation:
Martyn's Law (the Terrorism (Protection of Premises) Act 2025) received Royal Assent on 3 April 2025 and, per the Home Office, is expected to come into force in spring 2027 after its required implementation period.
It applies to premises and events with a capacity of 200 or more people, with additional requirements above 800 - venues, retail, hospitality, education, and similar. It doesn't target M365 outages specifically, but it does require in-scope organisations to have preparedness and response procedures ready before an incident, including the ability to alert and coordinate staff quickly - which makes app-free, infrastructure-independent alerting directly relevant to compliance planning now, well ahead of the enforcement date.
The Cyber Security and Resilience (Network and Information Systems) Bill is the most directly relevant of the three and is still moving through Parliament: introduced 12 November 2025, it cleared the Commons and entered the House of Lords in June 2026, with Royal Assent expected in late 2026 and phased implementation running through to 2028.
It substantially expands the UK's NIS Regulations 2018, bringing managed service providers and data centres into scope for the first time and introducing a 24-hour early-warning and 72-hour full-report duty to sector regulators and the NCSC following a qualifying incident. For any organisation that will fall in scope, an out-of-band communication channel — one that doesn't rely on the same infrastructure a cyber incident may have compromised — moves from good practice to a practical necessity for meeting the reporting clock.
Taken together, none of these three require a specific vendor or product — but all three make a documented case for why UK crisis communications planning should treat M365 independence as a compliance-relevant capability, not just an operational nice-to-have, and why that case gets stronger, not weaker, over the next 18 months.
Bring this list into vendor demos and ask each question directly — vague answers are themselves informative.
A platform that can answer all eight of these without hedging is one built for the outage it needs to survive — not just the demo it needs to pass.
This guide focuses on evaluation criteria rather than vendor rankings. Platform capabilities, pricing, and legislative timelines all change - confirm current specifications with vendors and current status of DORA, Martyn's Law, and the Cyber Security and Resilience Bill directly with official sources (gov.uk, legislation.gov.uk, or your legal/compliance team) before making a procurement or compliance decision. This is not legal advice.