Guide Cybersecurity Compliance

Reducing Microsoft dependency: the case for change and a practical roadmap

Microsoft controls more of the enterprise IT stack than any other single vendor. The consequences of that concentration are documented: state-actor breaches of Microsoft's own signing infrastructure, a government report concluding the attacks were preventable, and a 2025 admission from Microsoft that it cannot guarantee data sovereignty to European customers. This piece sets out what the risks are and what a realistic reduction in dependency looks like in practice.

Ryland Deakin
Ryland Deakin
Lead Consultant, Cyvra
12 August 2026
15 min read
Key takeaways
  • The US Cyber Safety Review Board found the Storm-0558 breach "preventable." Attackers forged tokens giving access to any Exchange Online account globally. Microsoft did not detect the intrusion; a customer reported it.
  • In June 2025, Microsoft acknowledged to the French Senate that it cannot guarantee data sovereignty to European customers.
  • The US CLOUD Act requires Microsoft to produce data from its servers regardless of where those servers are physically located.
  • Full Microsoft exit is rare. Reducing concentration through identity decoupling and infrastructure diversification is the practical path for most organisations.

The security incidents

The US Cyber Safety Review Board (CSRB) published its report on the Storm-0558 breach in April 2024. The board's conclusion: the attack was "preventable and should never have occurred." The CSRB described Microsoft's security culture as inadequate and called for fundamental change in how the company prioritises security over new feature development.

Storm-0558 is a Chinese state-sponsored group that obtained a Microsoft signing key and used it to forge authentication tokens. Forged tokens authenticate as legitimate without requiring passwords. Storm-0558 used them to access email accounts across US government agencies, including the Commerce Secretary's inbox. The tokens worked across Exchange Online, SharePoint, Teams, and Azure because Microsoft's authentication layer is shared. One key reached every service. Microsoft's own monitoring missed it. A customer reported the breach.

CSRB finding, April 2024

The breach hit 22 organisations and more than 500 individuals globally, including senior US government officials. The CSRB found "numerous avoidable errors" in Microsoft's response and noted that Microsoft made incorrect public statements about how the incident occurred and took too long to correct them.

Midnight Blizzard (tracked by some vendors as NOBELIUM) gained entry to Microsoft's corporate environment through a legacy test account with no MFA. Attackers read executive emails, browsed source code repositories, and collected credentials customers had shared with Microsoft's support teams. They left knowing how Microsoft's security team operated and what Microsoft was telling its customers.

The attack surface extends beyond your tenant. When Microsoft's signing infrastructure is compromised, attackers reach customer data without touching the customer environment. No amount of tenant hardening stops that.

Data sovereignty and the CLOUD Act

The US CLOUD Act (2018) requires US law enforcement agencies to compel US-headquartered companies to hand over data from their servers regardless of where those servers sit. Microsoft's servers in Ireland or the Netherlands face the same legal obligation as servers in Virginia. Where data is physically stored is irrelevant to that obligation.

Microsoft's EU Data Boundary programme commits to keeping most commercial data within the EU. Telemetry, diagnostic data, service improvement data, and account metadata still route to US infrastructure under default settings. The boundary covers productive data. It does not cover everything that leaves an endpoint.

On the record, June 2025

Microsoft's president told the French Senate that the company cannot guarantee data sovereignty to French customers. The structural problem: US law already requires Microsoft to comply with law enforcement requests regardless of where its servers sit, and no contractual commitment overrides that.

European regulators have taken this seriously. The Dutch data protection authority recommended in 2023 that government bodies run a CLOUD Act risk assessment before relying on Microsoft cloud services. German federal cybersecurity authorities flagged Windows telemetry as a source of uncontrolled cross-border data transfer. The EU Data Act, in force from September 2025, adds mandatory portability and switching rights.

For UK organisations the conflict is the same. UK GDPR imposes obligations around international transfers, and US extraterritorial law does not stop at the Channel.

The blast radius of a single-vendor estate

In most enterprise environments, Microsoft controls the operating system, local identity (Active Directory), cloud identity (Entra ID), email (Exchange Online), productivity applications (Microsoft 365), and cloud infrastructure (Azure). A single compromised signing key cascades through all of it.

Storm-0558 demonstrated this. Forged tokens worked across email, SharePoint, Teams, and Azure because Microsoft's authentication layer is shared. One key reached multiple agencies through a single channel.

Vendor monoculture means a single provider's security failures become yours. Consolidation and concentration risk are not separate choices. You buy them as a pair.

Windows Recall, announced in 2024, shows the trajectory of OS-level data collection: the feature takes frequent screenshots of your screen and runs OCR on them to build a searchable AI history of your activity. After researchers exposed a plain-text database storing that history and keylogging vulnerabilities, Microsoft made it opt-in. It is off by default. The intent was clear.

Service outages and operational resilience

On 22-23 January 2026, Outlook, Exchange Online, Teams, SharePoint, OneDrive, and Microsoft Defender went down together. The event lasted eight to nine hours; full recovery took more than 21. A Copilot disruption on 15 January and an Azure Front Door DNS failure on 26 January took down Xbox Live and Microsoft portal access within the same month. On 16 March 2026, an Exchange Online failure broke calendar synchronisation, sign-ins, and Outlook access for users across every region.

The pattern through 2025 was the same. On 9-10 July, Exchange Online and Outlook.com went offline globally for 19 hours, leaving millions unable to access their mailboxes. On 29 October, a faulty configuration change in Azure Front Door's control plane broke routing for Microsoft 365, Teams, Outlook, Xbox Live, and external systems including regional airline reservation platforms. On 9 October, packet loss through Azure Front Door disrupted Microsoft 365 and Teams for users across EMEA and Asia. Through March, Outlook.com and Exchange Online dropped repeatedly across several weeks.

This is the normal pattern, not an exception. A shared cloud platform carrying millions of organisations' productivity workloads will go down periodically, and when it does, every customer on that service goes down with it. There is no routing around the failure.

This risk sits outside the standard security threat model. When your estate runs Azure for compute, Exchange Online for email, Teams for communications, and SharePoint for documents, any Microsoft platform outage is your outage. There is no architectural fallback. Diversified infrastructure is the only way to keep critical functions running when a provider goes down.

Licensing costs and structural lock-in

Microsoft distributes security capabilities across licence tiers to push organisations toward higher-cost plans. Extended audit log retention, advanced threat hunting, privileged identity management, and some Conditional Access features require E5 or E5 Security add-ons. Organisations that need those controls for compliance pay the full E5 per-seat cost regardless of whether they use the rest of the suite.

Running Microsoft workloads on competing cloud infrastructure is structurally harder. Azure-to-AWS or Azure-to-GCP migrations hit licensing restrictions and capability gaps that disappear when workloads stay on Azure. The economics push organisations toward full Azure consolidation.

Microsoft's bundled security incentives push in the same direction. The fastest route to a better security posture score is buying more Microsoft products. That tightens the lock-in while appearing to fix the risk.

How organisations are responding

The most visible responses have been governmental. France's digital interministerial department is migrating millions of civil service workstations to Linux. Germany's state of Schleswig-Holstein is replacing Windows and Office with Linux and LibreOffice across 30,000 workstations. Both programmes span years.

Enterprises mostly take an architectural approach rather than a full exit. The dependency runs deep, and migration projects carry real operational risk. The practical pattern is selective decoupling: replacing Microsoft where risk or cost is highest, keeping it where the switching cost outweighs the gain.

Full exits happen. They work best for organisations with strict sovereignty requirements, open-source mandates, or estates small enough that migration costs stay manageable. Most commercial enterprises with established Microsoft infrastructure will reduce their dependency, not eliminate it.

Reducing dependency in practice

Start with identity

When Entra ID is your sole authentication layer, every Microsoft credential controls access to everything. Adding a third-party identity provider (Okta, JumpCloud, Ping Identity) as the primary layer lets Microsoft 365 stay accessible while authentication runs through a non-Microsoft chain. Entra ID becomes one source among several rather than the root of trust for your entire estate. A Microsoft identity compromise then affects only what Entra ID touches, not your whole environment. This change requires no replacement of Microsoft productivity applications.

Separate infrastructure from productivity

Moving existing Azure workloads carries real risk and cost. A simpler starting point: stop new workloads from landing on Azure. OVHcloud and Hetzner operate outside US legal jurisdiction and cover most infrastructure needs. Set a non-Azure build standard for new workloads and concentration falls incrementally, without touching existing systems.

Email and calendar

Email is what organisations replace first. Google Workspace covers email, calendar, and video conferencing for most setups. Migration complexity scales with mailbox count and Exchange-specific configuration depth. Standard setups move cleanly. Complex transport rules, public folder dependencies, or deep Outlook integration add planning time but are not blockers. Proton Business suits organisations with strict privacy requirements and provides end-to-end encryption at rest.

Productivity applications

Productivity applications take the most preparation. Google Workspace covers documents, spreadsheets, and presentations for most organisations. Excel workbooks with heavy macro or VBA dependencies need assessment before you migrate. LibreOffice works for organisations that cannot use cloud tools or run primarily on Linux. OnlyOffice has better Microsoft format fidelity than LibreOffice and suits teams that share files with partners still on Office.

Endpoints

Endpoint migration takes years for most organisations. Developer and technical teams can move to Linux within months; the tooling fits how they work and most stay productive. General staff workstations need application compatibility testing and a structured rollout. macOS is the practical non-Windows option for organisations that want a managed endpoint without deploying Linux to general staff.

File storage and collaboration

Nextcloud, on European-operated infrastructure, replaces OneDrive and SharePoint for file storage and collaboration. Slack or Mattermost replaces Teams messaging. Google Meet or Zoom replaces Teams video. These replacements run in the same workstream as the productivity migration.

What most organisations actually end up with

  • A third-party identity provider as the primary authentication layer, with Entra ID demoted to one of several credential sources
  • Non-Microsoft cloud infrastructure for all new workloads
  • Microsoft 365 retained where migration cost exceeds benefit, but hardened with Conditional Access, third-party SIEM integration, and explicit telemetry controls
  • A written incident response plan that covers scenarios where Microsoft cloud services are unavailable or compromised at the infrastructure level

For most organisations, reducing dependency starts with identity: running a third-party IdP alongside Entra ID, enforcing MFA across all accounts, and applying Zero Trust access controls so Microsoft platform availability is no longer the single condition for accessing critical systems.

Risk assessment

Understand where Microsoft sits in your risk profile

We map your Microsoft dependency, identify your highest-risk exposure points, and help you build a realistic reduction plan.

Ryland Deakin
About the author
Lead Consultant, Cyvra · CISM · CompTIA Security+ · MCP

Ryland has delivered cybersecurity, compliance, and IT management programmes for regulated organisations across the UK and the Netherlands for over 20 years, including senior roles at Microsoft, ING, IPsoft, PPHE and more. View full profile