8 Questions on Crisis Platforms for M365 Outages

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.

1. Why does an M365 outage break most "crisis communication" setups?

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.

2. What does "Microsoft 365-independent" actually mean in a crisis platform?

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:

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."

3. Why does app-free reach matter more than a good mobile app?

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:

• Frontline and non-desk staff who may not have a corporate app on personal devices
• New starters and contractors who haven't been onboarded to every internal tool
• The exact moment of an M365 outage, when Teams push notifications may not be delivering anyway

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.

4. What does "secure alerting" require beyond encryption in transit?

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:

1. Message integrity and authentication - can recipients trust that an alert genuinely came from the platform, not a spoofed source, particularly during the chaos of an active incident when phishing attempts spike?
2. Data residency and sovereignty - where is contact and incident data actually stored, and does that satisfy sector-specific regulatory requirements (this matters disproportionately for UK crisis communications, covered in Question 7)?
3. Access control independent of the compromised system - if the outage is security-related (not just an availability incident), can administrators still trigger alerts if the org's primary identity provider is the thing under investigation?
4. Audit trail and delivery confirmation - can the platform prove, after the fact, who was sent what, when, and whether they acknowledged it? This is increasingly an operational resilience and compliance requirement, not just a nice-to-have.

Vendor certifications worth asking for directly include ISO 27001 : 2022, and — for UK/EU organisations - confirmation of GDPR-compliant data handling and hosting location.

5. Why is SSO through Microsoft 365 a hidden vulnerability, not just a convenience?

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.

What to require from vendors

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:

• Does not rely on Microsoft 365 or Entra ID
• Cannot be compromised simply by compromising an employee's Microsoft 365 credentials
• Remains available during an M365 or Entra ID outage
• Provides tightly controlled administrator access
• Supports strong authentication and appropriate security controls independently of your primary identity provider

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.

6. Why can deep Microsoft 365 integration work against your resilience goals, even when it's sold as a strength?

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:

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.

7. What's different about UK crisis communications requirements specifically?

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:

• Article 11 requires ICT business continuity policies with crisis communication plans built in;
• Article 14 requires maintained communication policies for internal and external stakeholders during ICT-related incidents;
• Article 19 requires timely reporting of major ICT incidents to clients, including what mitigation steps were taken. A platform that goes down with the M365 outage it's meant to report on doesn't satisfy any of the three.

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.

8. What does a practical evaluation checklist look like?

Bring this list into vendor demos and ask each question directly — vague answers are themselves informative.

• [   ] Hosting: Confirm the platform does not run on Microsoft Azure in a way that shares fate with Microsoft 365, or get written confirmation of separation if it does.
• [   ] Login fallback: Get a live demonstration of an administrator logging in and sending an alert without Entra ID/Azure AD available.
• [   ] Delivery channels: Confirm SMS and voice delivery work independently of Outlook/Exchange and Teams — ask for a live test, not a feature list.
• [   ] Integration dependency map: List every Microsoft 365 integration point the vendor demos (Teams bot, Outlook add-in, SharePoint-hosted plans, Power Automate workflows) and get a stated fallback for each.
• [   ] App-free reach: Confirm 100% of a test distribution list can receive and acknowledge an alert without opening an app.
• [   ] Data residency: Get written confirmation of where contact and incident data is hosted and processed.
• [   ] Certifications: Confirm ISO 27001 and/or SOC 2 status, and GDPR compliance documentation for UK/EU deployments.
• [   ] Activation speed: Time how long it takes from incident declaration to first alert sent, end to end.
• [   ] Audit trail: Confirm delivery and acknowledgement logs are generated automatically, not manually compiled after the fact.

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.