Rackspace kept running old Exchange for clients, and kept its old risks

The week

On Friday, December 2, 2022, email stopped working for thousands of small and mid-sized organizations. Messages would not send, inboxes would not load, and phones showed spinning wheels. Staff restarted their laptops, called IT, and waited.

The problem was not in their offices. That day, Rackspace’s Hosted Exchange service began failing for customers. Exchange is Microsoft’s email and calendar server software, the engine behind the inbox for a great many businesses. Hosted Exchange meant that Rackspace, a managed services company, ran that engine on its own computers on the customers’ behalf. The service was used mainly by small and mid-sized organizations that had chosen a managed version of Exchange instead of Microsoft’s own cloud service, Microsoft 365.

The company’s own timeline shows how the picture changed over the first days. On December 2 it noticed a problem, shut down the Hosted Exchange environment and described the issue as connectivity and login trouble. By December 3 it had concluded that it was dealing with a security incident. The word ransomware did not appear until December 6.

On December 6 the company confirmed a ransomware incident. Ransomware is malicious software that criminals use to lock up an organization’s systems and data, usually demanding payment to unlock them. Within days Rackspace was moving affected customers to Microsoft 365. Many were without normal email for days, and some waited much longer for historical mailbox data.

Rackspace’s filings with the SEC put the business in proportion. Its December 6 filing said Hosted Exchange generated about $30 million of annual revenue and that the incident might cost it some of that revenue. Three days later it described the business as about 1% of total revenue, serving mainly small and medium businesses that used only that product. Its other services, including a separate email product, were described as unaffected.

The migration offer was concrete. Rackspace provided Microsoft Exchange Plan 1 licenses at no cost until further notice, added support staff and brought in Microsoft’s FastTrack team. But customers’ own administrators had to set up users and update their DNS records themselves. Rackspace also said Hosted Exchange had already been slated for migration to Microsoft 365 before the attack.

Rackspace later attributed the attack to the Play ransomware group. After an investigation by CrowdStrike, a cybersecurity firm, it said the attackers got in through a then-unknown exploit tied to CVE-2022-41080. A CVE is a catalog number for a publicly known software flaw. An exploit is the technique an attacker uses to take advantage of it.

CrowdStrike had described the technique, which it called OWASSRF, as a way around Microsoft’s published mitigations for the ProxyNotShell flaws. A mitigation is a temporary workaround that blocks known attack routes until a proper fix, a patch, is installed. OWASSRF found a side door the workaround did not cover.

The technical history explains how that could happen. The ProxyNotShell flaws were disclosed in late September 2022, and for weeks Microsoft offered only mitigations, chiefly a web server rule that blocked requests matching a known attack pattern. Patches arrived on November 8, 2022. CrowdStrike found that the OWASSRF chain reached Exchange through the Outlook Web Access endpoint instead of the endpoint the rule watched, so the rule never fired. Systems with the November patches applied were not vulnerable to it.

Rackspace added a detail that matters for anyone who triages patches. Microsoft had classified CVE-2022-41080 as a privilege escalation flaw, with no mention that it could form part of a remote code execution chain. A flaw labeled that way tends to sit lower in a patch queue than one labeled as a way in from the internet.

In early January 2023 Rackspace said the hosted Exchange environment would not be rebuilt. It reported that the attackers had accessed stored mailbox files of 27 customers.

That figure was out of nearly 30,000 Hosted Exchange customers, and Rackspace said the investigation found no evidence that the attacker viewed or misused those files. It said it was supporting an FBI investigation. Its forensic work had found no attacker activity after December 2 and no movement beyond the Hosted Exchange environment.

The customers had done what many sensible small organizations do: paid an expert to run something complicated so they would not have to. The week showed what that bargain does, and does not, include.

Rackspace’s customers did not run their own Exchange servers. They paid a provider so that someone else would patch, monitor and recover the platform. The incident exposed a gap in that bargain, and the gap applies to any hosted service: hosting changes who does the work, but the software and its attack history stay the same.

Every hosted platform needs three paths that the customer can see and test: a patch path, an exit path and a recovery path. Here, all three turned out to sit with the provider. First, though, consider what customers were actually buying.

What “hosted” really means

There are, broadly, three ways an organization can get email. It can run the software itself, on its own servers in its own building, which is called on-premises. It can buy a cloud service from the software maker, such as Microsoft 365, where Microsoft writes the software and runs it on infrastructure built for that purpose. Or it can hire a third party to run the on-premises software for it, in the third party’s data center. That third model is hosting, and it is what Rackspace offered.

Hosted Exchange is like paying a garage to keep an older car running and drive you around in it. The garage may be excellent. But the car is still the older model, with all its known weaknesses, and the garage did not design it.

Hosting has real advantages. It removes the need for in-house specialists, it can cost less than doing it yourself, and it often lets an organization keep familiar software and settings. For a small credit union, a clinic network or a county office, that is an attractive deal.

The hidden assumption is that the provider’s scale and expertise also absorb the security risk. They absorb some of it. But some software was built to sit inside one company’s network and has since become one of the most attacked products in the world. It does not become safer because a capable company is running many copies of it. In some ways the target becomes larger: a single breach can reach many customers at once.

Who does what, written down

The clearest way to see the bargain is a responsibility matrix. In an on-premises deployment the customer patches the operating system and the application, manages identity, runs backups and owns the configuration. In a software-as-a-service product such as Microsoft 365, the maker patches everything below the customer’s settings, while the customer still owns identity, configuration, retention settings and any independent copies.

Hosting falls between the two, and the line moves with every contract. Usually the provider patches the servers and the application, and runs backups designed to restore its own platform. The customer often keeps its domain, its identity decisions and its records obligations, whether or not anyone has told it so. Most hosted customers had never seen that matrix written down for their own service.

Shared infrastructure adds a second dimension. Rackspace ran Exchange for nearly 30,000 customers. Every one of them inherited the same patch decisions, the same mitigations and the same exposure. A misjudgment that would hurt one company running its own server hurt all of them at once.

A product in managed decline

The economics of an old hosted product shape how it is run. Rackspace described Hosted Exchange as about 1% of its revenue, serving mostly small customers, and said it was already planned for migration to Microsoft 365. A provider in that position has little reason to invest in deep engineering for a platform it intends to retire.

That does not make the provider negligent. It makes the platform a sunset product, and sunset products carry predictable risk: fewer engineers who know them well, less appetite for disruptive changes, and customers who stay because moving is inconvenient. A customer can learn this by asking the provider directly about its roadmap for the service. A plan to retire the product is a signal to set the customer’s own exit date, not to wait for the provider’s.

The way a ransomware attack typically unfolds explains why the three paths below matter. Attackers first find a way in, often through a flaw in software that faces the internet, such as an email server. Once inside, they explore, looking for administrator passwords and for the backups. Only then do they encrypt, scrambling data so it cannot be read without a key they hold. Many groups also copy data out before encrypting it, so they can threaten to publish it. Each stage is an opportunity: a timely patch can stop the first, separate credentials can limit the second, and an independent backup can blunt the third. A customer who controls none of those stages is relying entirely on someone else’s defenses.

The patch path

On-premises Exchange was among the most targeted enterprise products of 2021 and 2022. ProxyLogon, ProxyShell and, in autumn 2022, ProxyNotShell each produced waves of exploitation. These were families of flaws, each given a memorable name by researchers, that let attackers break into Exchange servers exposed to the internet.

Microsoft revised its ProxyNotShell mitigation guidance several times as researchers found ways around it. The OWASSRF chain used against Rackspace reached the same vulnerable component through a different route, so a server could be correctly mitigated on paper and still exposed.

Why a mitigation is not a patch

The details of the ProxyNotShell mitigation show the problem in miniature. Microsoft’s interim fix was a rewrite rule on the web server in front of Exchange. It examined incoming addresses and dropped requests that contained both “autodiscover” and “powershell”. That blocked the published attack.

OWASSRF sent its request to the Outlook Web Access path instead. The rule looked for one road into the vulnerable component, and the attackers took another. A patch fixes the component itself, whichever road leads to it. A mitigation guards the roads someone has already mapped.

CrowdStrike’s advice to organizations that could not patch at once was to disable Outlook Web Access entirely. That is a real compensating control, but it removes webmail for every user. A customer running its own server can make that trade for itself. A hosted customer cannot. It depends on the provider making a choice for thousands of tenants, most of whom want webmail to keep working.

Why providers patch slowly

Providers have legitimate reasons for caution. A patch applied across a shared platform can break service for every tenant at once, so they test longer than a single organization would. Severity labels also drive their queues. A flaw labeled as privilege escalation, like CVE-2022-41080, can wait behind flaws labeled as remote code execution.

Customers should not demand reckless patching. What they need is to know which state the service is in: fully patched, mitigated or awaiting a fix. They also need to agree in advance on the maximum time the service may stay mitigated before the provider either patches or shuts off the exposed feature. That single disclosure would have told Rackspace’s customers, in November 2022, how much they were relying on a workaround.

Hosted customers had no view of any of this. A typical agreement promised availability and support response times. It did not say how quickly critical patches would be applied, or what the provider would do when only a mitigation existed. Nor did it say whether customers would be told when the service was running mitigated rather than patched. For a product with that record, those are the questions that matter.

A customer can ask for them in contract terms. Examples include:

• A maximum time to apply critical security updates.
• Notice when the provider is relying on a temporary mitigation instead of a full patch.
• The right to see the provider’s vulnerability management reports, or an independent assessment such as a SOC 2 Type 2 report that covers patching. A SOC 2 Type 2 report is an independent auditor’s review of how well a service provider’s controls actually worked over a period of months, as well as how they were designed.

The customer also needs someone internal who reads those reports. A report nobody reads is decoration. A small credit union or clinic network can assign that to its security lead as a quarterly task without hiring anyone.

Reading the evidence a provider offers

A SOC 2 Type 2 report is useful only if someone reads its fine print. It covers a defined period, often six or twelve months, and the report may be several months old by the time a customer sees it. A bridge letter from the provider covers the gap, but it is the provider’s own statement, not the auditor’s.

The most useful section for a customer is often the list of complementary user entity controls. These are the controls the provider assumes its customers operate, such as managing their own user accounts or reviewing access. Reading that list tells a customer, in the provider’s own words, which parts of the bargain were always its responsibility. Exceptions noted by the auditor, especially in change management and vulnerability management, deserve a written follow-up question.

The exit path

When Rackspace moved customers to Microsoft 365 instead of restoring the old service, each customer had to buy licenses, verify domains, configure identity, update DNS records and reconfigure every phone and laptop, all under pressure.

A few of those terms need defining. A domain is your organization’s name on the internet, such as the part of an email address after the “@”. DNS, the domain name system, is the internet’s address book: it tells the world which servers handle your email and website. The registrar is the company where you registered your domain, and whoever controls that account controls where your mail goes. Identity is the system that decides who can sign in to what, often the same username and password used across many services.

Organizations that kept their own record of DNS, identity and device settings moved in days. Those that had relied on the provider for everything found that the knowledge of their own configuration sat with the provider too.

Exit planning is usually treated as a contract clause about returning data at the end of the term. A working exit plan answers operational questions instead. Who holds administrator credentials for the domain registrar and DNS. Which identity system controls sign-in, and whether it could point at a different service tomorrow. Where the authoritative copy of the data lives, in what format, and how long a bulk export would take. And which applications send mail through the service, such as scanners, line-of-business systems and alerting tools.

Those answers are cheap to write down in advance and very expensive to reconstruct during an outage, when the provider’s own staff are overwhelmed and every customer is calling at once.

A useful test is a tabletop exercise, a structured discussion in which leaders and staff walk through a realistic scenario around a table, in which the provider disappears for two weeks. Gaps surface within an hour. Typical findings include a registrar account tied to a former employee’s personal email, mail-flow records nobody has copied, and licensing that only the provider can change.

What the forced migration involved

Rackspace’s own instructions show the work that fell to customers. Administrators had to create users in the new service by hand and update DNS records, with changes taking up to a day to spread across the internet. Customers with a hybrid setup had to move every mailbox. A temporary forwarding option applied only to mail sent after it was configured, not to anything earlier.

Behind “update DNS” sit several distinct records, each with its own failure mode. The MX record tells other mail servers where to deliver mail. The Autodiscover record tells Outlook and phones where to find the mailbox. SPF, DKIM and DMARC records tell receiving servers which systems may send mail for the domain and how to check that a message is genuine.

Get MX wrong and inbound mail bounces or disappears. Get SPF or DKIM wrong and outbound mail lands in recipients’ spam folders or is rejected outright, including invoices and patient reminders. An organization changing all of these under pressure, for the first time, will usually get at least one wrong.

An exit runbook

1. Credentials. Registrar and DNS administrator accounts in the organization’s name, with multifactor authentication and at least two named holders.
2. Records. A current export of every DNS record, kept outside the provider, with notes on which ones relate to mail.
3. Senders. A list of every system and device that sends mail, with how each authenticates.
4. Target. A named alternative service, with an understanding of how licenses would be bought quickly.
5. Data. A tested method and an estimated time for exporting all mailboxes in bulk.

These items need no new system. Each needs an owner and a review date.

The contract can carry part of the load. Useful exit terms include a transition assistance period after termination, export of all data in standard formats at no cost or a capped cost, and a duty to cooperate with the successor provider. That duty should apply even when the contract ends because of the provider’s own failure. Those terms will not make a forced move painless, but they turn a favor into an obligation.

The recovery path

For many customers the hardest part was not the days without new email. It was the uncertainty over old mailboxes.

In regulated organizations email is often a record: correspondence with members and patients, approvals, notices and complaints. Losing access touches retention schedules, the rules on how long records must be kept; litigation holds, the legal duty to preserve material relevant to a lawsuit; and supervisory expectations. Broker-dealers have specific electronic recordkeeping requirements under SEC Rule 17a-4. Health systems and public agencies have their own retention schedules and public records obligations. “Our email provider was hacked” does not suspend any of them.

Some customers had an independent archive. It might be a journaling service, which automatically copies every message to a separate store as it is sent or received, or a separate backup tenant. Those customers could keep meeting those obligations while Rackspace worked through recovery.

Customers who treated the provider’s resilience as their backup learned a hard distinction. A provider’s disaster recovery is designed to restore the provider’s service, not necessarily to give each customer its own data in a usable form. Those are different promises.

What recovery looked like

Rackspace began handing customers their historical mailboxes as PST files around December 21 and 22. A PST is a single-user Outlook data file. By January 5, 2023, it said more than half of affected customers had some or all of their data available for download. Fewer than 5% of those customers had actually downloaded it. Public folder data was excluded, and files were available through the customer portal for a limited window.

Those numbers say something about customers as well as the provider. Many small organizations had no one with the time, tools or storage to take back their own data, even when it was offered. A PST file per user is also a long way from a searchable, retention-managed archive. Producing a year of correspondence for an examiner from a folder of PST files is slow and error-prone work.

Recovery obligations differ by sector

A broker-dealer must keep business communications in a form that meets SEC Rule 17a-4. The SEC amended that rule in October 2022, allowing an audit-trail approach as an alternative to write-once storage. Either way, the firm must be able to produce the records promptly. A provider’s outage does not pause that duty.

A health system or clinic network that uses a hosted email service for patient information needs a business associate agreement with the provider. HIPAA’s Security Rule also requires a contingency plan with data backup, disaster recovery and emergency mode operation components. The contingency plan is the health system’s own, and a provider’s backup can support it but does not replace it.

A public agency answers to its state’s records retention schedules and public records law. A request for correspondence does not lapse because the mailbox is offline. Agencies that hold criminal justice information in email have additional security requirements to meet in any replacement service.

A backup inside the same administrative domain as the system it protects can be lost in the same incident. An administrative domain is the set of systems controlled by the same administrators and passwords. If an attacker gains those keys, they can often reach the backups too, which is exactly what ransomware groups try to do. The independent copy should use separate credentials, a separate provider account and a restore procedure that someone has actually run. A backup that has never been restored is a hope, not a plan.

Journaling, backup and export are different tools

Three tools are often confused. Journaling captures a copy of each message as it passes through the mail system and stores it in a separate archive. It serves records retention, supervision and legal discovery, because it captures mail even if a user later deletes it. Backup takes periodic copies of mailboxes so they can be restored to working order. Export produces a portable copy, such as PST files, usually for a move.

An organization with records obligations usually needs journaling into an archive it controls, and backup for operational recovery. Export alone serves neither well. Whatever the tool, the copy should live under separate administrative credentials, ideally with settings that prevent deletion for a defined period, so an attacker who takes over the mail platform cannot erase it as well.

Two firms, one outage

Consider two hypothetical organizations on the same hosted email service when it fails.

The first, a regional insurance brokerage, has done little beyond signing the hosting contract. Its domain is registered under the account of an IT contractor who left years ago. Nobody has a list of the systems that send email. Its only copy of old mail is inside the failed service. When the provider recommends moving to a new platform, the brokerage spends its first several days just proving it owns its own domain. Its compliance officer cannot tell regulators when historical correspondence will be available.

The second, a community health clinic network, did a tabletop exercise the year before. It holds its own registrar and DNS credentials. It has a short document listing every system that sends mail. It journals all email to a separate archive with separate passwords. When the outage hits, it buys new licenses, points its DNS at the new service and reconfigures devices, with staff using the archive to find old messages in the meantime. The disruption is real and unpleasant, but it is measured in days, and the clinic can answer every regulator and patient question about its records.

Neither organization chose a worse provider. One simply kept the three paths in its own hands.

The difference between them cost very little. The clinic’s preparation was a half-day exercise, a list of senders, a registrar account in its own name and an archive subscription. The brokerage would have spent less on all of that than on its first week of emergency consultants.

Beyond email: the same pattern everywhere

The pattern is not specific to email. Consider hosted core banking, the central system that keeps a bank’s accounts and ledgers, and hosted EHR instances, the electronic health records that hold patient charts. Add hosted case management and hosted file transfer. All involve a provider running software it did not write for customers who cannot see how it is run.

Core banking shows the exit problem most sharply. Banks and credit unions that use a hosted core typically face deconversion work and fees when they leave, and their data is held in the processor’s formats. An exit plan for a core system is measured in months, not days. That makes the recovery path, including an independent copy of account and ledger data that the institution can read, more important while the relationship lasts.

The architectural question is whether the software is still being actively engineered for current threats, and whether the customer keeps enough control to patch around, leave or recover from the provider. Software that is still being designed and improved by its maker tends to get stronger over time. Software in its later years tends to accumulate known weaknesses faster than it sheds them, however good the people running it.

Reading the end-of-life signals

The signals are usually public. Software makers publish lifecycle dates, and the gap between the end of mainstream support and the end of extended support is the period when a product gets security fixes but few improvements. Exchange Server 2019, for example, left mainstream support in January 2024 and extended support in October 2025.

Other signals come from the provider. A provider that steers new customers to a different product, offers migration discounts or stops adding features is telling its existing customers where the service is headed. A customer that records these signals for each hosted platform has its own early warning, instead of learning the roadmap from an incident notice.

The case for staying put, and its limits

There are good reasons organizations choose hosted older software. It can be cheaper. It preserves integrations, add-ons and workflows that a modern cloud service may not support. Some organizations have contractual or data-location requirements that a mass-market service did not meet at the time. And a move to a major cloud provider concentrates risk in a different place.

That last point is fair. Large cloud services have had serious incidents of their own. In 2023 a China-based group used a stolen Microsoft signing key to reach the email of government agencies, and a federal review board sharply criticized Microsoft’s security culture in 2024. Moving to a modern service does not end the need for the three paths. It changes the patch path, since the maker patches continuously, while the exit and recovery paths stay with the customer. The argument therefore holds for every hosted platform, old or new. Old software simply makes the patch path the first to fail.

For each hosted platform, someone inside the organization should be able to answer all three from documents the organization controls. Where nobody can, that platform belongs at the top of the risk register, the formal list of risks a board reviews.

An outage that stops the business

For most organizations, an email outage is closer to a business stoppage than an IT inconvenience. Email is how quotes go out, how invoices arrive, how patients confirm appointments, how regulators send notices and how staff reset their passwords for other systems. When it stops, much else stops with it.

Email is part of the identity system

Email also carries the keys to other systems. Password resets, sign-in codes, vendor portal notices and alerts from monitoring tools often arrive by email. During an outage, staff may be unable to reset a password for an unrelated system, and security teams may miss alerts that were routed to the dead inbox.

The usual workaround, staff switching to personal accounts, creates its own problems: business records outside retention, and phishing that is harder to spot. A short out-of-band plan helps. It names an alternative channel for staff and an offline list of key contacts at regulators, vendors and partners. It also sets out a way to send customers or patients a notice that does not depend on the failed service.

The costs show up in several places at once. There is lost productivity while staff improvise with personal accounts and phone calls, which itself creates records and security problems. There is the direct cost of an emergency migration: new licenses, outside help, overtime. There is regulatory exposure if records cannot be produced or retained as required. And there is reputational cost when customers notice that messages go unanswered, or learn that a provider holding their correspondence was breached.

A subtler governance issue sits underneath. Many boards accept “we outsourced it” as a complete answer to a question about technology risk. It is an answer about who does the work. It is not an answer about whether the organization can cope when the work fails. Regulators in banking, healthcare and government increasingly say the same thing in their own language: you can delegate the task, but you remain accountable for the outcome.

Accountability, by regulator

The federal banking agencies made that explicit in June 2023 with joint guidance on third-party relationships. It expects banks to plan, conduct due diligence, negotiate contracts, monitor and plan for termination, in proportion to the criticality of each relationship. Credit unions follow their own regulator’s third-party expectations, which run along similar lines.

For health systems, the HIPAA Security Rule makes the covered entity responsible for its contingency plan whatever its business associates do. For public agencies, accountability runs through state records law, audit offices and, for federal systems, CISA’s directives. The vocabulary differs, and the expectation is the same: the organization must be able to show it understood and managed the dependency.

A modest standard for any hosted platform

The standard for any hosted platform is surprisingly modest. The contract states patch timelines and requires notice when the provider is running on temporary workarounds. Someone inside reads the provider’s security reports and raises concerns. The organization holds its own registrar, DNS and identity credentials, and keeps a short, current document describing its configuration. An independent copy of important data sits outside the provider’s reach, and someone has restored from it within the past year. Leaders have rehearsed a provider failure at least once. And there is a dated plan for moving off any platform whose software is reaching the end of its life.

A short scorecard keeps the standard honest. For each critical hosted platform, record four dates. The last provider security report reviewed. The last restore test from the independent copy. The last exit exercise. And the support end date of the underlying software. Any date more than a year old, or any support end date within two years without a migration plan, is a finding for the risk committee.

Proportion matters. A three-person office cannot run quarterly exercises and read audit reports on every vendor. Its minimum is smaller and still meaningful: registrar and DNS credentials in its own name, an independent archive of email, and one page describing how it would move. Those three items cover most of the damage a provider failure can do.

Most failures start as assumptions:

• Assuming the provider’s backups are your backups.
• Assuming a capable provider can make aging software safe indefinitely.
• Letting the provider, or a former contractor, hold the keys to your domain.
• Reading the service-level agreement for uptime promises and never asking about patching.
• Writing an exit clause about returning data, and never working out how you would actually leave.
• Waiting for the provider to announce a migration, rather than choosing your own timing.

Each of these is cheap to fix on an ordinary Tuesday and expensive to fix in the middle of an outage.

Three paths for every hosted system

• Which of our critical systems are run for us by a hosting or managed service provider, and how old is the underlying software?
• Do our contracts say how quickly critical security patches are applied, and whether we are told when the provider is relying on a temporary workaround?
• Who holds the administrator passwords for our domain registrar, DNS and sign-in system, and are they written down somewhere the provider does not control?
• If our main provider vanished for two weeks, what would we do on day one, and have we ever rehearsed it?
• Where is our independent copy of email and other records, does it use separate credentials, and when did someone last restore from it?

With hindsight

Rackspace did not bring hosted Exchange back. The move to Microsoft 365 that began as an emergency measure became the permanent answer.

Rackspace closed its forensic investigation in early January 2023 and stopped posting updates, while support for affected customers continued. For most customers the practical outcome was a mailbox in Microsoft 365 and, for those who retrieved it, a set of PST files holding the history.

Play kept working. In December 2023 the FBI and CISA issued a joint advisory on the group. It described initial access through known flaws in internet-facing systems, including the ProxyNotShell Exchange vulnerabilities, and the double-extortion pattern of stealing data before encrypting it.

Microsoft, meanwhile, kept retiring on-premises Exchange. Exchange 2013 reached end of support in April 2023, meaning Microsoft stopped issuing security fixes for it. Exchange 2016 and 2019 followed on October 14, 2025, leaving a subscription edition as the supported on-premises option. For any organization still running older versions, directly or through a provider, the patch path had simply ended.

The subscription edition arrived in July 2025. For organizations still on Exchange 2016 or 2019 after October, the choice was to upgrade, move to the cloud or run unsupported software. That choice faced hosted providers and their customers just as it faced organizations running their own servers.

Exchange stayed a target. In August 2025 CISA, the federal Cybersecurity and Infrastructure Security Agency, issued Emergency Directive 25-02, giving federal civilian agencies a few days to mitigate a hybrid Exchange flaw. That flaw could let an attacker with on-premises administrator access escalate into the connected Microsoft 365 environment. “Hybrid” describes an organization that runs some email on its own servers and some in Microsoft’s cloud, linked together. The directive showed that older on-premises software can become a bridge into newer cloud systems, as well as a risk in its own right.

The directive also showed what had not changed. Federal agencies still ran enough on-premises Exchange in 2025 for CISA to need an emergency order about it, nearly three years after the Rackspace incident.

The directive’s instructions were telling. Agencies had to run Microsoft’s health checker script to inventory every Exchange server, and to disconnect any server not eligible for the April 2025 hotfix updates, including end-of-life servers. CISA also strongly recommended disconnecting the last Exchange server left behind after a move to the cloud. Federal agencies were being told, in effect, that an unpatchable server should not be on the network at all.

The regulatory frame tightened around the same ideas. The federal banking agencies’ June 2023 third-party guidance put termination and exit planning into the expected lifecycle of every critical relationship. In Europe, the Digital Operational Resilience Act applied from January 2025 and required financial entities to have exit strategies for critical technology providers. The SEC’s 2023 cybersecurity disclosure rules required listed companies to report material incidents within four business days of determining materiality. A provider’s incident can quickly become its customers’ disclosure question.

The recovery argument has aged best. Email remains a record for broker-dealers, health systems and agencies whatever happens to the platform. An archive outside the provider’s administrative domain is the one control that held up in every version of this incident. It covered the outage, the decision not to rebuild, and the questions about who could see stored mailboxes.

Outsourcing changes who carries out the work, while the duty of oversight stays with you. A board does not need to understand how an exploit chain works. It does need to know, for each critical hosted system, whether the organization could patch around it, leave it or recover from it using documents and credentials it controls. Those three answers are as useful today as they were the week the email stopped.