Sometime around 1 PM ET yesterday, Microsoft services supporting Outlook, Teams, and many other services went offline. Attempts to apply patches or revert to a prior state didn’t immediately work because servers were quickly overwhelmed by a backlog of traffic as they came online. Microsoft had to shed load and throttle downstream traffic, likely explaining why some regions and services had only partial availability. This scenario isn’t uncommon. Recovery from this kind of saturation can create a “thundering herd” on recovering servers, further extending the incident yet again. Google had this happen last year.

As of early Friday morning ET, services are starting to resume after a nearly 18-hour outage. Assuming recovery continues, tech and business leaders should now ask how they can better prepare for and reduce the risk of similar disruptions.

Concentration Risk Strikes Again – It’s Time To Address Hyper Consolidation

The outage affected nearly every Microsoft service from Outlook to Copilot to core security services like Defender. For a variety of reasons from price bundling to customer service, integration, and knowledge sharing, companies have been consolidating their employee productivity and collaboration apps as well as their business apps, general computing workloads, and security solutions to handful of tech giants and hyperscalers.

  • Consider diversifying or having alternatives for key productivity apps. It’s unrealistic to diversify application by application – there’s integration overhead to too much diversity and CIOs need to be careful not to over invest for a problem that is generally rare. However, for some industries where doc management and communication is critical (i.e. law firms), it’s not unreasonable to have backup options like Google Workplace (closest 1:1) and even Zoom (which also has an email solution).
  • Ensure you have multiple communication options in place. Most enterprises should have a mass communication service in place like EverBridge and/or employee communication tools independent of email (e.g. FirstUp and StaffBase). Whether its extreme weather or a catastrophic IT outage, you can trigger these solutions to send critical communications to customers, employees, and partners using multiple modes of communication from SMS to voice alerts. Additional messaging systems like Slack, Element, Wire, or Threema can be used to serve as a secure bidirectional chat across organizations. Critical industries (e.g. energy, government) should have additional redundancy through satellite and radio systems. All companies should offer continuous communication through their own websites, status, and social media updates.
  • Re-architect for workload portability and vendor diversification. Use upcoming enterprise contract renewal cycles to critically assess vendor concentration risk. Consolidating productivity suites, identity management, security agents, and cloud infrastructure under one vendor creates systemic fragility. Design your long-term cloud strategy around containerization, multi-cloud or hybrid portability, and independent third-party backup solutions to ensure a single vendor’s service disruption never halts your core business operations.
  • Diversify your security tech stack. The move to platformatization, deployment ease, and license bundling drove enterprises to adopt a single vendor approach to security. Security leaders have long been reluctant to put all their eggs in a single vendor basket for reasons like the preference for multiple security approaches at different layers. With more security solutions being delivered from the cloud as a service, those tools are susceptible to outages. Security leaders should evaluate where it makes sense to diversify vendors in areas like data, endpoint, email and collaboration, and network security.

Design For Failure But Engineer For Recovery

Technology leaders need to engineer resilience into the identity, security, authentication, and recovery services that allow the business to maintain control when a critical provider becomes unavailable.

  • Stabilize identity services during outages (Immediate). Instruct your help desk to halt all mass password-reset advisories. During cloud identity provider outages (such as Microsoft Entra ID), automated or user-initiated resets cause cascading multi-factor authentication (MFA) loops and widespread account lockouts the moment services begin to recover. These loops can not only impact business users’ daily actions but also privileged users’ access to on-prem, cloud infrastructure and SaaS applications.
  • Capture telemetry and document SLA Impact (Immediate). Task your site reliability engineering (SRE) and operations teams with aggregating system logs, error rates, and degraded service windows. Under Microsoft’s Financial-backed Service Level Agreements (SLAs), you have strict reporting windows to file claims for service credits. Detailed timestamp logs and quantified business-unit productivity losses are also essential for your executive post-mortem and board reporting.
  • File your SLA claim ASAP (Immediate). Microsoft will not apply SLA credits automatically to your bill – you must submit a claim within one month after the end of the outage month to receive credits. Have your Microsoft administrator document the services that suffered from outages, the number of seat holders that were impacted, and the duration of the outages, then submit an SLA credit request through M365 billing support. Note that credits are only awarded for the specific service impacted; if that service was bundled with other services that were not impacted, the credit will be prorated for just the impacted service. For services purchased through CSP partners, submit the claim through the CSP partner.
  • Audit single points of authentication and infrastructure (Medium-term). Evaluate where your enterprise has tightly coupled its operational dependencies to a single cloud ecosystem. Review your identity federation architecture to determine if secondary, independent identity providers or localized authentication failover mechanisms can be introduced. Ensure critical operational runbooks and emergency documentation are mirrored to local or offline storage repositories that do not require an active cloud session to .
  • Re-assess usage of email OTP for authentication (Medium/Long-term). Organizations should reduce reliance on email-delivered OTP for authentication and recovery, particularly when the email service and identity ecosystem share common infrastructure dependencies that can fail together. Prioritize phishing-resistant methods such as passkeys, while maintaining pre-enrolled, independently dependent fallback methods for continuity; simply replacing email OTP with SMS OTP reduces one dependency, but does not provide the security or resilience of stronger authentication methods. Minimally for the duration of the outage, ensure that transitioning to other MFA factors or changing email addresses on users’ accounts is possible without the user having access to their old email account.
  • Transition from static documentation to dynamic disaster recovery drills (Medium-term). Traditional Business Continuity Plans (BCPs) stored inside cloud-based document repositories become useless when those repositories go offline. Shift your resilience strategy toward automated chaos engineering and regular, unannounced tabletop exercises. Test your actual Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) under simulated multi-region cloud outages and endpoint failure scenarios to build operational muscle memory.

Use This Outage To Jumpstart Sovereign Alternatives 

The Microsoft outage is a quasi-natural experiment for stress-testing an organization’s, or even an entire continent’s digital sovereignty. While not strictly a sovereignty issue, it shows what could happen if an interruption of services and tools availability was the direct consequence of a deliberate order from the foreign government whose jurisdiction a vendor depends on. Sovereign alternatives are not always available equivalent, or sufficient. For instance, sovereign communication tools exist, but the real problem is the communication protocol which allows the communication exchanges. While full sovereignty is rarely achievable, minimum viable sovereignty is what you need. Here is how to proceed:

  • Map the dependencies on foreign vendors that really matter. Sovereignty is not just about where your data resides, but who controls the technologies your business depends on. Identify critical dependencies across cloud infrastructure, identity, communications, AI, network, and software. For example, a sovereign cloud deployment may still depend on a foreign provider’s authentication services. Prioritize the dependencies whose disruption would threaten essential operations, rather than pursuing sovereignty everywhere.
  • Build alternatives where they deliver real independence. Replacing a foreign technology provider with a domestic one does not automatically guarantee sovereignty or resilience. Alternatives must also be interoperable, operationally viable, and sufficiently independent. For example, adopting a sovereign collaboration platform offers limited protection if users cannot communicate with external partners or if it relies on the same underlying services. Diversify selectively and prioritize open standards, interoperability, and substitutability over provider nationality.
  • Stress-test your ability to operate without your foreign provider. Sovereignty is ultimately about retaining control when external dependencies become unavailable, whether accidentally or deliberately. For example, simulate a prolonged loss of access to your primary cloud or collaboration platform and assess whether essential operations can continue. Establish recovery thresholds, test alternative communication channels, and validate your ability to operate, recover, or switch providers before a disruption occurs.

Schedule a guidance session or inquiry call with us to discuss your strategy on how to improve your resilience discipline and jumpstart your minimum viable sovereignty.

Share