Summary
- Confirmed exploitation and data theft preceded public disclosure, so the initial patch race began after some customer environments had already been entered; patching was essential, but it could not by itself determine what had already been taken.
- Accountability is distributed but not vague: Progress controlled product security, cloud response, patches and advisories; operators controlled exposure, local evidence and retention; service providers controlled customer escalation; and data-owning organizations retained duties to know where their information traveled and to notify affected people.
- The most consequential control was often outside the vulnerable code path. Internet inventory, durable logs, short file-retention windows and mapped supplier relationships determined whether an organization could limit theft, prove its scope and notify people without months of reconstruction.
A transfer service became a temporary vault
MOVEit Transfer sat at an unusually consequential boundary. Organizations used it to exchange payroll files, pension records, student reports, health information, government data and other material that was too sensitive or too operationally important for ordinary email. A managed file-transfer system is supposed to improve control: authenticate senders and recipients, encrypt transport, automate recurring exchanges and record activity. Yet those same functions concentrate valuable data and place a web-accessible application between internal workflows and outside parties. The security promise and the aggregation risk are two sides of the same design.
That distinction matters because the 2023 event is often compressed into a simple story: Progress Software had a vulnerability; a criminal group exploited it; thousands of organizations were breached. Every clause contains truth, but the compression hides the decisions that changed the scale of harm. The vulnerability was the common entry point. It did not decide which servers were exposed, how long files remained available, whether reliable logs survived, how quickly suppliers alerted customers, or whether a data owner knew that its records had passed through a fourth party. Those decisions were spread across a service chain.
Progress itself described two materially different operating models. MOVEit Transfer was installed in customers' own environments, while MOVEit Cloud was operated in public and customer-dedicated cloud instances. In its July 2023 quarterly filing, Progress said the on-premise product provided it with no continuing telemetry about a customer's deployed version, file-transfer activity, stored data, or patch status. That is not a minor implementation detail. It marks the boundary between the vendor's ability to issue a fix and an operator's ability to deploy it, investigate its own instance and report what happened.
Cloud language can blur this boundary. MOVEit Cloud was a service Progress could take down, patch and restore. An on-premise MOVEit Transfer server was a supplier product under customer operation, even if business teams experienced it as a managed or cloud-like dependency. A contractor might operate that server for another organization; the contractor might in turn handle data for many customers. The person whose Social Security number or medical information was inside a transferred file might have no relationship with Progress, the operator, or the intermediary that actually held the vulnerable instance.
The campaign therefore exposed two forms of concentration. There was technical concentration in a product deployed on internet-facing servers. There was also contractual concentration in service providers that used one MOVEit environment to exchange files for many customers. A single compromised installation could trigger dozens or hundreds of downstream reviews. The later public record did not expand only because attackers continued acting. It expanded because organizations gradually learned what their suppliers had held, matched files to clients, identified individuals and met different legal notification duties.
This is why the incident should be read as a trust-boundary failure rather than only a patch-management failure. Code quality at Progress was central. So were the conditions under which customers placed sensitive information at that boundary and the evidence they retained to reconstruct access. Responsibility follows control: who could prevent the flaw, who could reduce exposure, who could limit the available data, who could preserve proof, and who could warn the people facing the residual risk.
May 27-30: exploitation before a public defense existed
The earliest public evidence does not establish the first-ever exploitation attempt. It establishes a lower bound. Mandiant reported that, across its incident-response engagements, the earliest evidence it had observed was May 27, 2023, with web-shell deployment and data theft. Rapid7 separately said its teams confirmed indicators of compromise and exfiltration dating to May 27 and May 28. These findings support exploitation before disclosure, but neither proves that every victim was accessed on those dates or that no earlier testing occurred.
The observed chain used an SQL injection weakness later designated CVE-2023-34362. The NVD entry describes an unauthenticated attacker reaching the MOVEit database through HTTP or HTTPS, with the ability to infer data and execute statements that alter or delete database elements. Incident responders observed a purpose-built web shell, commonly called LEMURLOOT, placed under filenames resembling a legitimate MOVEit component. It could enumerate files, retrieve configuration information, establish or remove a privileged-looking account and retrieve selected files. Mandiant saw cases in which theft followed web-shell deployment within minutes.
This observed behavior is narrower than the maximum technical effect researchers later reproduced. Huntress reported that it had recreated a full exploitation chain capable of administrative access, file theft and arbitrary code execution. That laboratory result showed what the flaw could enable; it is not evidence that the 2023 campaign deployed ransomware or took control of every host in that manner. Public victim reports generally described data theft from the MOVEit environment, often with no lateral movement into the wider network. Good forensic writing must keep capability, observed conduct and victim-specific findings separate.
Progress's own clock began with a customer signal. Its filing says the MOVEit technical-support team received an initial call on the evening of May 28 Eastern Time about unusual activity in a customer's instance. An investigative team mobilized, and on May 30 it identified a zero-day affecting both Transfer and Cloud. This sequence is important for accountability because it shows the vendor did not enter the event with advance public warning and a neglected patch. The first confirmed defense window opened only after customer evidence surfaced.
That fact does not eliminate product-security questions. A zero-day is a description of defender knowledge at exploitation, not a conclusion that the underlying defect was unavoidable or that prior secure-development controls were adequate. SQL injection is a long-established vulnerability class. The public record does not reveal the exact code history, review coverage, test cases or internal design decisions that allowed this path to persist. It therefore supports a firm conclusion that the product contained a critical, exploitable defect, but not a detailed claim about which developer or management decision caused it.
The pre-disclosure interval also reframes customer patch performance. Organizations breached on May 27-30 could not have installed a patch that did not yet exist. Their relevant pre-event controls were exposure management, web-application defenses, segmentation, anomaly detection, logging and data minimization. Those controls were not guaranteed to stop a novel chain, but they could reduce the reachable population, detect unexpected activity, constrain consequences or make later proof possible. Calling every early victim “unpatched” would substitute hindsight for chronology.
May 31: disclosure, containment and the first patch race
On May 31, Progress disclosed the critical issue, made fixes available for supported Transfer releases and patched its cloud environments. The company's later customer patch FAQ identifies CVE-2023-34362 as the first of three vulnerabilities communicated between May 31 and June 15. Its release notes show security hotfix versions across maintained branches, including MOVEit Transfer 2023.0.1 on May 31.
The immediate guidance was not merely “install an update when convenient.” Organizations were told to block HTTP and HTTPS access to MOVEit until they could patch, inspect for indicators and investigate unauthorized access. That step traded availability for containment. Because the vulnerable surface was the web application, removing web access interrupted ordinary workflows as well as the attack path. Operators had to decide how to move urgent files, which business processes could wait and when evidence was sufficient to restore service.
Progress controlled that tradeoff directly for MOVEit Cloud. It took web access down, investigated, applied the fix and restored service. In a June 5 response update, the company said those actions occurred within 48 hours and that an outside forensic firm had tested the patch against a controlled unpatched instance. Progress also urged cloud customers to inspect audit logs for unusual downloads and to review access, system and protection-software logs.
For on-premise Transfer, the vendor could publish and communicate; it could not reach into every installation. Its filing says it notified all then-known current and former customers. But without ongoing product telemetry, Progress could not confirm who still had an exposed instance, which version was running or whether an operator applied the fix. Customer records and direct notices were useful, but they were not a real-time asset census.
The word “known” matters. Enterprise software can outlive the team that procured it. A business unit may operate a server under a contractor. A former customer may retain an old installation. A service provider may expose an application for clients that never see its name in their own inventory. Internet scan data can help identify visible services, but it cannot resolve every ownership and deployment relationship. The patch race therefore depended on three inventories aligning under pressure: Progress's customer contacts, each operator's technical assets, and each data owner's supplier map.
The May 31 patch also did not answer the first forensic question: had exploitation already occurred? Removing the vulnerable path prevented new use of that path, but it did not erase a web shell, undo theft or prove the absence of earlier access. An operator that patched and immediately restored service without preserving the filesystem, IIS logs, database evidence and application audit records might improve current security while weakening its ability to scope the incident.
That distinction appeared in real response timelines. The Government of Nova Scotia's public incident report says its team identified the advisory on June 1, took MOVEit offline, patched and returned it to service. On June 2, after the Canadian Centre for Cyber Security recommended checking suspicious IP addresses, it took the system down again. Investigators then found suspicious activity and later confirmed that files had been stolen on May 30 and 31, before the patch. The patch was successful as containment; the first restoration was not yet a completed investigation.
June 1-7: public evidence made the campaign visible
Technical reporting moved quickly after disclosure. Rapid7 published observations from multiple customer environments. Mandiant documented LEMURLOOT behavior and data theft. Huntress shared host and log artifacts, then demonstrated the exploit chain. CISA placed CVE-2023-34362 in its Known Exploited Vulnerabilities catalog on June 2, giving US federal civilian agencies a June 23 remediation deadline. On June 7, the FBI and CISA issued a joint advisory with indicators, detection material and defensive measures.
This collective disclosure changed the evidence available to operators. A generic alert about unauthorized access became a hunt for particular web-shell names, application requests, account artifacts, source addresses and unusual downloads. Defenders could compare their IIS and application records with patterns observed elsewhere. But indicators were clues, not a binary verdict. Filenames could vary. Infrastructure could change. A missing known indicator could mean no compromise, a different artifact, expired retention or inadequate collection.
The public network view offered another kind of evidence. Censys reported more than 3,000 internet-exposed MOVEit hosts around the disclosure period and observed the count fall to roughly 2,600 over the following week. That was meaningful exposure intelligence: thousands of services could be identified from outside, and some operators appeared to be taking systems offline. It was not a victim count. Censys explicitly cautioned in its later industry analysis that an internet scanner could identify services but could not determine from that fact alone whether a device was vulnerable or compromised.
This distinction is essential under the topic of network-resource evidence. An exposed hostname, IP address, autonomous-system association or service fingerprint can establish that a service was publicly reachable at a particular observation time. It may help a company find an unknown asset, identify a hosting provider or prioritize outreach. It cannot establish who controlled the application, which software build ran behind every response, whether a compensating control blocked the exploit, or whether data left the server. Treating scan results as breach proof would overstate the evidence; ignoring them would discard an important independent inventory signal.
Mandiant's infrastructure findings sit at a different layer. It observed much of the scanning and initial exploitation from a particular netblock while later web-shell interaction and theft came from other systems. It also found overlaps in internet providers, address ranges, certificates and historical infrastructure. Those observations supported its threat-cluster assessment. They did not make every request from a listed address malicious, nor did they prove that only listed infrastructure was used. Defenders needed to correlate network records with application behavior and local artifacts.
Attribution developed over these same days. Progress said Microsoft associated the activity with Lace Tempest, which overlapped with FIN11 and TA505, while Progress noted on June 5 that it had not independently confirmed the assessment. Mandiant initially tracked the activity as UNC4857 and then merged it into FIN11 based on targeting, infrastructure, certificate and leak-site overlaps. A post on the CL0P leak site claimed responsibility and threatened publication if victims did not engage.
The most defensible phrasing is therefore layered: incident responders attributed the campaign to clusters associated with CL0P/Clop operations; the operators of the CL0P leak site claimed responsibility; and government advisories used the CL0P and TA505 labels. The criminal claim is corroborating context, not a trustworthy promise about the full victim set or what happened to any organization's data. Claims that government data would be deleted, for example, could not substitute for incident evidence or a risk assessment.
The campaign also differed from a conventional ransomware event. Public evidence centered on rapid theft and later extortion, not widespread encryption inside victim networks. Huntress proved the vulnerability could support broader execution, but CISA and victim reports described the observed campaign around web-shell access and exfiltration. Precision matters because response priorities differ: restoring encrypted systems is not the same task as identifying which transient files were copied and which people they described.
June 9-July 6: one emergency update became a patch sequence
The first fix did not end the product-security work. During additional code review, Huntress and Progress identified distinct SQL injection paths. Progress released a new patch on June 9 for CVE-2023-35036 and deployed it to MOVEit Cloud. In a June 13 security update, Progress said it had not seen evidence that this newly found vulnerability had been exploited. On June 15, it disclosed and patched CVE-2023-35708. The July FAQ likewise said the company had seen no indication that the June 9 or June 15 flaws were exploited.
That qualification prevents a common timeline error. CVE-2023-35036 and CVE-2023-35708 increased the operator's remediation workload and showed that the original review had uncovered more risk. They should not automatically be described as entry points used in the May campaign. CVE-2023-34362 is the vulnerability tied by public incident evidence to the mass theft. The later findings are part of the response and exposure-management story unless victim-specific evidence proves otherwise.
Operators now faced repeated emergency change. A team that had blocked web access, preserved evidence, upgraded and restored on May 31 or June 1 had to return on June 9. Less than a week later it had to act again. Nova Scotia's later regulatory record provides a rare operational chronology: staff monitoring vendor and industry sources flagged the June 9 advisory, patched and upgraded; on June 15 they declared another major incident, blocked user access, patched on June 16 and restored service. Investigators found no additional theft during those later events.
On July 5, Progress issued a service pack and formalized a more predictable service-pack program. Rapid7's timeline records three more CVEs disclosed around July 6: CVE-2023-36934, a critical unauthenticated SQL injection; CVE-2023-36932, an authenticated SQL injection; and CVE-2023-36933, an exception-handling issue capable of crashing the application. Again, the public record did not tie these additional flaws to the original campaign before fixes became available.
The sequence creates accountability on both sides of the supplier line. Progress was responsible for broadening review, producing validated fixes for maintained versions, updating Cloud and communicating clearly which patches superseded earlier ones. Customers were responsible for maintaining an emergency-change path that could absorb multiple releases without losing asset coverage or evidence. A patch process designed for monthly maintenance was poorly matched to a product under active scrutiny.
Frequent fixes also complicate assurance. “Patched” became a time-dependent statement. A system current on June 1 was not current on June 10. A questionnaire asking whether MOVEit was patched, with no version and observation time, could produce a comforting but meaningless answer. Customers needed deployed-version evidence for every instance, a record of when web access was blocked and restored, and checks that an upgrade had not missed a node in a web farm or a dedicated environment.
The service-pack response was constructive, but it also acknowledged a lifecycle problem: operators needed a simpler, predictable path for security fixes. Progress said it expected service packs approximately every two months. Predictability helps routine adoption. During an active exploitation crisis, however, emergency notices, tested hotfixes and version-specific instructions remain necessary. A regular cadence cannot delay a fix for a known critical path.
The notification cascade was a second incident
By early June, the technical campaign had largely established its pattern. The public consequences were just beginning. Every stolen file had to be mapped from an application to a business process, from a business process to a client, and from a client to individuals and legal duties. This was not clerical cleanup. It was a second incident that consumed forensic, privacy, legal, customer-service and communications capacity for months.
Some organizations operated MOVEit directly. New York City's Department of Education says it learned of the vulnerability June 1, patched within hours and later determined that about 19,000 files had been copied on May 28. The files included student evaluations, service-progress reports, Medicaid material and employee leave records. The department said no other part of its network was accessed. That statement scopes the incident to the transfer environment; it does not make the contained data less sensitive.
Nova Scotia similarly operated a government MOVEit service. Its public timeline progressed from a June 1 patch to a June 2 renewed shutdown, June 3 confirmation of theft and phased notifications beginning June 16. The province's MOVEit breach page recorded batches of letters to health employees, public servants, pension recipients, students and community-service clients. The later privacy commissioner report says approximately 168,000 letters went out between late June and September.
Other organizations encountered the incident through a supplier. CalPERS announced on June 21 that PBI Research Services, used to identify member deaths and prevent overpayments, had been affected. Its public notice demonstrates a chain in which pension data moved to a service provider, the service provider used MOVEit, and the pension system then had to warn members. The vulnerable server was not necessarily inside the data owner's own network, but the consequences returned to the data owner and its beneficiaries.
The Centers for Medicare & Medicaid Services described another chain. Maximus used MOVEit in work supporting Medicare appeals. According to the CMS notice, Maximus detected unusual activity on May 30, stopped using the application early May 31 and notified CMS on June 2. CMS and Maximus began notifying an estimated 612,000 current beneficiaries in late July, offering credit monitoring and replacement Medicare numbers where relevant. CMS emphasized that its own systems were not compromised. That was an important network-scope fact, but the affected information was still CMS-related data held by its contractor.
Maximus's SEC filings show the scale extending beyond one government customer. Its September 2023 quarterly report said it used MOVEit for internal and external sharing, including government-program data, and notified people whose files could contain Social Security numbers, health information and other personal data. One operator's repository could therefore generate multiple customer notices, each on a different clock and under a different public name.
Ofcom's disclosure illustrates both containment and data-owner responsibility. On June 12, the UK communications regulator said personal data of 412 employees and some confidential company information had been downloaded. It stopped further use of the service, applied the recommended measures and alerted affected regulated companies. Ofcom also said its own systems were not compromised. The stolen information still required action because service boundaries do not erase data responsibility.
Maine shows why public counts continued rising long after the exploit window. The state said on November 9 that it had completed enough review to begin broad notification. Its official incident statement described a cross-agency analysis and different remedies depending on the data involved. A filing in the Maine attorney general's breach portal listed 1,324,118 affected people, including 534,194 Maine residents, with breach dates of May 28-29 and discovery on May 31. The interval to notification reflects the difficulty of identifying people across a large file set; it also represents months in which affected people lacked individualized information.
The UK National Cyber Security Centre explicitly described the supply-chain pattern in its MOVEit guidance: organizations whose supply chains used the application suffered breaches involving customer or employee data. That wording is more useful than calling every case a direct Progress customer breach. It captures subcontractors, payroll processors, benefits administrators, technology providers and government contractors that connected many data owners to one vulnerable system.
Independent tallies reveal the broad order of magnitude but require caveats. Emsisoft's June 2024 compilation listed 2,773 organizations and 95,788,491 individuals, drawing from breach notices, SEC filings, other public disclosures and the CL0P site. It warned that individual counts overlap and that service providers can represent multiple downstream organizations. The organization total is therefore a research tally, not a regulator-certified count of unique direct compromises. It supports “thousands affected”; it does not prove thousands of separately exploited MOVEit servers.
This cascade changes how loss should be measured. Server restoration may take days. File review, legal analysis and notification may take months. Identity risks can persist for years. A vendor's lost revenue or legal expense captures only one slice. Contractors fund investigations and call centers; data owners fund notices and remediation; individuals spend time replacing identifiers, monitoring accounts and deciding whether a letter is genuine. The cost follows the data far beyond the original application.
Data minimization was an incident-response control
The cleanest evidence about preventable blast radius came after the emergency. In February 2025, Nova Scotia's information and privacy commissioner issued a detailed investigation report. It found that the government had frequently used MOVEit as a repository rather than a transfer mechanism, had not completed a privacy impact assessment and had not established retention and disposition schedules for the system.
The report states that MOVEit had a default 14-day retention period, yet users sometimes kept material much longer based on individual choice. It concluded that this practice significantly compounded the breach. Files removed after receipt would not have been available when attackers entered. That is a direct causal finding about harm, not a generic best-practice slogan.
Data minimization is sometimes framed as a privacy principle separate from cybersecurity. MOVEit shows why that division is false. Deletion changes the attacker's available inventory. A repository containing two weeks of transfers presents a different opportunity from one containing years of payroll, health or pension files. Encryption at rest may protect lost disks, but an application-level attacker with authorized-equivalent access may retrieve files through the system's own functions. Reducing the stored corpus remains effective even when access controls fail.
Retention also changes the notification workload. Each unnecessary file can create another client, data category or person to identify. Old files may contain stale addresses, deceased individuals and records whose business owners have changed. Nova Scotia's commissioner found that outdated contact information meant thousands of people did not receive notices and that vague letters caused further anxiety. Excess retention therefore enlarged both the data theft and the difficulty of responding accurately.
The accountable control is more specific than “delete data sooner.” Organizations need a transfer-purpose retention rule tied to workflow completion. Automated transfers should have confirmed receipt, a short recovery period and enforced deletion. Exceptions should name an owner and expiry. A file needed as an authoritative record should move to a recordkeeping system designed for that purpose rather than remain in the internet-facing transfer layer. Operators should measure and report files older than policy, not merely document a default.
Progress shares a product-design role here. Defaults, administrator controls, expiry enforcement, reporting and safe automation shape customer behavior. The public regulator finding concerned Nova Scotia's use and governance, not a legal conclusion against Progress. Still, a vendor selling secure transfer software can reduce foreseeable misuse by making temporary handling the easiest mode, surfacing old data and enabling organization-wide retention policies. Customer misuse and product affordance can coexist as accountability questions.
The same logic applies to data elements. A payroll or benefits provider may need a person's name and account information for a specific exchange, but not every historical field in a source export. Data owners should challenge full-database extracts used for convenience. Tokenization, field suppression, per-client separation and purpose-limited files reduce what a transfer compromise exposes. These controls require work before an incident; they cannot be retrofitted after copies have left.
Logging determined who could say what happened
After containment, the central question was not whether a server had been vulnerable. It was whether someone used the vulnerability and what they obtained. That answer depended on evidence spread across the web server, MOVEit audit records, database, filesystem, endpoint tools, firewall and external observations. No single source was complete.
Progress told customers to investigate at least the preceding 30 days, inspect known indicators and look for unexpected downloads. The CISA advisory supplied network and file indicators and detection rules. Huntress identified IIS request patterns, suspicious compilation activity and cached artifacts associated with malicious pages. Rapid7 later described methods for identifying stolen data. These resources converted threat intelligence into local questions, but only where the underlying logs and artifacts existed.
Log retention is therefore a pre-incident control. If an organization retained seven days of web logs and learned of a May 27 event on June 5, decisive records might already be gone. If all logs remained on the compromised host, an attacker with sufficient access might alter them or the response team might overwrite them during restoration. Central, time-synchronized and access-controlled collection creates a more durable account.
Application audit logs are particularly important in managed transfer because a successful attack can resemble legitimate use: enumerate folders, create a session and download files. Volume, timing, source, account creation and unusual sequences may distinguish the activity. Network flow can confirm data movement but may not identify filenames under encryption. Database records may identify objects but not prove every byte transferred. A defensible conclusion should state the evidence basis and uncertainty rather than turn “no known indicator” into “no breach.”
The network-resource record helps fill gaps but has limits. External scans can show that a service responded on a public address before or after disclosure. Certificate histories and hosting records can connect infrastructure over time. Mandiant used overlaps in addresses, providers and certificates as part of attribution. Yet an external record rarely identifies the internal file set or confirms successful exploitation. It is corroboration and discovery evidence, not a replacement for host and application forensics.
Organizations also needed evidence from suppliers. A customer whose contractor ran MOVEit could not inspect the server itself. It depended on the contractor to preserve logs, commission forensics and provide client-specific findings. Contracts that say only “notify us of a breach” leave critical questions unanswered: how quickly, with what evidence, which data mapping, and whether the customer can receive relevant logs or an independent report. The campaign turned those clauses into operational dependencies.
An accountable evidence package should include the exact instance and version; exposure dates; patch and shutdown times; known indicators checked; log sources and retention gaps; observed suspicious sessions; files confirmed or reasonably believed copied; evidence about lateral movement; and the confidence level of each conclusion. That package allows a downstream organization to make its own legal and risk decision. A statement that “the issue has been remediated” describes current posture, not historical impact.
Exposure management had to bridge vendor and customer inventories
The internet-facing nature of MOVEit Transfer made asset discovery both easier and harder. Easier, because scanning services could often fingerprint the product. Harder, because the public endpoint might belong to a hosting provider, managed-service company or contractor rather than the organization whose data moved through it. A public scan could reveal the server while internal governance still failed to identify the accountable business owner.
Censys's observed decline from more than 3,000 hosts to roughly 2,600 suggested rapid shutdowns or changed visibility. It could not say how many remaining hosts were patched. A patched service could remain visible; a vulnerable service could sit behind access controls or evade fingerprinting. Counts also change with scan timing, response behavior and classification. Exposure management should use these observations as leads reconciled against internal records, not as a scoreboard.
For Progress, the lack of on-premise telemetry limited direct assurance. Privacy-preserving product design may reasonably avoid sending customer file details to a vendor, but version and security-health telemetry can be separated from content. The incident raises a design question: could customers opt into a mechanism that reports deployed versions and critical-patch status without revealing transfers? Even without telemetry, a vendor can use support entitlements, license records, partner channels and externally visible fingerprints for targeted outreach. Each method has coverage and privacy limits that should be explicit.
For customers, inventory must include purpose and data, not only IP and software. Knowing that a public transfer endpoint runs MOVEit is insufficient if nobody knows which departments, vendors and records use it. A useful register ties the endpoint to a technical owner, business owner, deployment model, version source, internet requirement, data classes, retention rule, suppliers, downstream customers and emergency shutdown procedure. Those fields determine who joins an incident call and what must happen after a vulnerability alert.
Exposure reduction can also challenge the assumption that all file-transfer functions require broad web access. Administrative interfaces can be separated. Partner endpoints can use allowlists or private connectivity where business patterns permit. An application firewall may add detection or block known attacks, though it cannot be treated as a universal fix for a novel chain. Segmentation can keep compromise of the transfer tier from becoming wider network compromise. Several affected organizations later reported no access beyond MOVEit; that boundary is a meaningful success even when data in the transfer service was lost.
The counterfactual is not an impossible world with no software defects. It is an environment where an unknown defect reaches fewer services, where the exposed tier holds less data, where activity is logged elsewhere and where operators can remove web access without halting every critical exchange. Those controls make zero-day risk governable because they do not depend on knowing the exact vulnerability in advance.
Supplier and customer responsibility are different, not interchangeable
Shared responsibility can become a phrase used to avoid assigning any responsibility. The MOVEit record supports a more concrete allocation.
Progress controlled the vulnerable code, secure-development practices, cloud environments, advisory content, supported-version patches and the clarity of the update sequence. Once alerted, it also controlled whether to bring Cloud down and how quickly to engage outside investigators and researchers. Its public filings document rapid containment and patching after discovery. They also document the existence of the critical defect, subsequent flaws, litigation, customer claims and regulatory inquiries. Both parts belong in the assessment.
On-premise operators controlled whether Transfer was exposed, how it was segmented, which versions remained deployed, whether emergency patches could be installed, how logs were retained and how much data sat in repositories. Operators compromised before May 31 cannot reasonably be blamed for missing an unavailable patch. They can still be assessed on controls that existed independently of the disclosure, especially retention and evidence readiness.
Service providers controlled a further boundary. A payroll processor, pension data service, consultancy or government contractor often knew which clients' files occupied its server. It controlled client segregation, incident investigation and the speed and specificity of customer notices. A provider that notified a customer weeks later transferred investigative delay downstream. A provider that could quickly identify a client's exact files gave that customer a chance to notify people accurately.
Data-owning organizations retained responsibility for selecting providers, minimizing shared fields, maintaining a supplier map and preparing to communicate with affected people. “Our systems were not compromised” is valuable technical scoping, but it is not a complete accountability answer where the organization's data was entrusted to another system. CMS, Ofcom and CalPERS each publicly distinguished their own networks from supplier or transfer environments while still taking notification action. That is the correct conceptual split: network custody may change; obligations to people do not disappear.
Regulators and public cyber authorities controlled another part of the response. CISA converted active-exploitation evidence into a federal remediation requirement and shared indicators. The UK NCSC coordinated guidance and reporting. The UK Financial Conduct Authority told regulated firms to assess exposure and third parties in its MOVEit statement. Privacy regulators later examined whether data practices and notifications met legal standards. These institutions could not patch private servers, but they could create common urgency and evaluate governance after the fact.
Individuals controlled almost none of the pre-incident conditions. Most did not choose MOVEit, know which processor held their records or have the ability to demand deletion from a transfer repository. Advice to monitor credit or replace identifiers may reduce personal harm after notice, but it is not shared responsibility for the breach. The parties with architectural, contractual and operational control carry the corresponding duties.
The corporate accountability record continued after the exploit window
Progress's first quarterly filing reported four customers indicating possible indemnification claims, eleven putative class actions and cooperation with law-enforcement and privacy inquiries. By its 2023 annual report, the numbers and legal complexity had grown: the company disclosed customer letters, individual litigation, government inquiries and an October 2023 SEC subpoena seeking documents and information related to MOVEit.
These disclosures are evidence of claimed and investigated liability, not proof that every allegation was valid. Civil complaints state plaintiffs' positions. An SEC inquiry is not an enforcement finding. In August 2024, Progress announced that the SEC had concluded its investigation without recommending enforcement action. That outcome narrows one regulatory branch; it does not decide private claims, foreign privacy issues or the quality of every customer control.
The filing record also places materiality in context. MOVEit Transfer and Cloud represented about 4% of Progress revenue for the six months ending May 31, 2023, according to the July filing. Progress remained operational, while customers and individuals experienced the distributed incident. Corporate continuity at the vendor and severe harm across users can coexist. A materiality assessment focused on one issuer is not a complete measure of systemic impact.
Progress later described insurance, investigation, legal and professional expenses. Those numbers help trace the vendor's cost but remain a partial ledger. Maximus, states, schools, pension systems and other organizations carried their own investigation and notification expense. Individuals bore risks that do not appear in Progress's statements. Accountability analysis should resist treating the most visible public company's booked cost as the event's total loss.
The public record also contains positive response evidence. Progress engaged external firms, took Cloud offline, released supported-version patches, collaborated with CISA and researchers, conducted further code review and established a service-pack program. Customers such as Nova Scotia preserved enough evidence to confirm a narrow theft window and no lateral movement, then published a detailed report. These actions matter because accountability is not only blame for the initial defect; it is also the quality of containment, disclosure and learning.
The harder question is whether the learning became durable. Service-pack cadence, code review and cyber-resiliency statements are inputs. Stronger evidence would include measurable secure-development changes, patch adoption visibility, tested customer-notification coverage, product controls for retention, and independent assurance over the changes. Public filings necessarily summarize. Customers making future procurement decisions should ask for current control evidence rather than infer it from crisis communications.
What a defensible control model would require
The first requirement is a mapped trust boundary. Every managed-transfer deployment should have a named product owner, operator, data owners, service providers and recipient classes. The map should distinguish vendor-operated cloud, dedicated cloud and on-premise installations. It should show where responsibility changes and which party preserves evidence. Without that map, the first days of an incident are spent discovering the service chain.
The second is an externally reconciled asset inventory. Internal configuration records should be compared with DNS, certificate and internet-scan observations. Differences should become tickets: an unexpected exposed host, an obsolete certificate, a service assigned to a former owner, or a product fingerprint outside the approved range. The objective is not to prove compromise from scanning. It is to find systems that internal governance has forgotten.
The third is enforced data lifecycle. Transfer folders should expire by policy, with receipt confirmation and narrow exceptions. Administrators should see age and volume by data owner. Business teams should receive reports of files older than the approved window. Sensitive exports should contain only required fields, and client data should be separated enough to support fast scoping. A transfer platform should not quietly become the easiest archive.
The fourth is forensic readiness. Web, application, database, operating-system, endpoint and network logs should be time-synchronized, centrally retained and protected for a period matched to plausible discovery delay. Teams should test whether they can answer which files a session accessed. Incident playbooks should preserve evidence before rebuild, include supplier contacts and distinguish patching from historical investigation.
The fifth is emergency exposure control. Organizations should be able to block the vulnerable interface while maintaining a documented fallback for critical transfers. Restoration criteria should include both remediation and evidence review. Repeated vendor patches should be tracked by exact version and instance. “Current” should have a timestamp.
The sixth is a notification contract that works under pressure. Providers should commit to initial notice within a defined period, continuing updates, preservation of evidence, client-specific file mapping and access to an independent forensic summary. Data owners should maintain current contact data and pre-approved notice workflows. A supplier's uncertainty should be transmitted honestly, not hidden until every file is reviewed.
The seventh is assurance proportional to concentration. A provider moving data for hundreds of customers creates aggregation risk even if each individual contract is small. Procurement should assess the number and sensitivity of data sets sharing an environment, not only annual spend. Alternatives, segmentation and exit plans should be evaluated before the platform becomes irreplaceable.
These controls would not guarantee that CVE-2023-34362 could never be exploited. They would change the result. Fewer unknown services would face the internet. Less historical data would be available. Evidence would survive. Suppliers could identify affected customers faster. Data owners could issue precise notices. The incident would still be serious, but the vulnerability would have less leverage over the service chain.
Final assessment: accountability follows the ability to change the outcome
The 2023 MOVEit campaign was a product vulnerability event, a mass data-theft campaign and a supplier-governance failure at the same time. Reducing it to any one of those frames loses explanatory power.
The strongest evidence assigns Progress responsibility for a critical SQL injection flaw in a high-trust product and for the security of its operated cloud service. The same record shows that Progress moved quickly once a customer report revealed unusual activity: it investigated, shut down Cloud, issued patches, warned customers and expanded code review. These are not contradictory findings. A vendor can respond effectively after discovery and still be accountable for the product weakness and for proving that its development and assurance practices improved.
Customers and service providers did not create CVE-2023-34362. Their controls nevertheless determined exposure and loss. The Nova Scotia findings make that point unusually concrete: retaining files beyond the transfer purpose significantly enlarged the breach. Censys's observations show that public exposure could be independently discovered, but not equated with compromise. Victim timelines show that patching stopped further use while forensic review established what happened before the patch. Supplier notices show data crossing organizational boundaries faster than accountability information returned.
The thousands-of-organizations headline is real as an order of magnitude, but it must be read correctly. It combines directly operated MOVEit environments, dedicated services, contractors and downstream customers identified through public notices and threat reporting. It does not mean thousands of identical intrusions with identical evidence. The campaign's scale came from reuse: one product across many internet-facing instances, and some instances across many data owners.
The durable lesson is therefore not simply “patch faster.” In a zero-day campaign, defenders may begin after theft. The better test is whether the system was designed to fail with limits: limited exposure, limited stored data, limited network reach, durable evidence and a short path from operator to data owner to affected person. Those are the controls that turn a software flaw from a global disclosure cascade into a contained incident.
MOVEit crossed technical, contractual and jurisdictional boundaries. Accountability should cross them too, without becoming diluted. The vendor answers for the product and its response. The operator answers for deployment, evidence and retention. The service provider answers for client segregation and escalation. The data owner answers for minimization, oversight and notification. Regulators test whether those duties were real. The people whose records were moved through the system should not have to reconstruct that chain themselves.