Accellion and the file transfer server nobody owned

The week

On February 1, 2021, the Washington State Auditor’s Office disclosed a breach of Accellion’s File Transfer Appliance. Personal information about people who had filed unemployment claims in the state had been exposed. People who had filed for unemployment during the worst months of the pandemic learned that their personal details had been stolen from an office they had never dealt with.

The auditor is the state’s independent watchdog, and it had a good reason to hold the data. It had received the claimant data from the state’s Employment Security Department for its review of the large-scale unemployment fraud the state suffered in 2020. To move those files back and forth, the auditor used the Accellion service.

The auditor’s notice set out the scale. The exposed records related to about 1.6 million unemployment claims filed between January 1 and December 10, 2020. They included names, Social Security numbers or driver’s license or state ID numbers, bank information and places of employment. The claimants included members of the public, many state employees, and people whose identities had been used for fraudulent claims. A smaller set of records, including data held by the Department of Children, Youth and Families, was also exposed, as was financial data from local governments and state agencies.

The timeline was short and awkward. The unauthorized access took place on December 25, 2020. The auditor’s use of the system had ended on December 31, for unrelated reasons. Accellion announced a security incident in January, and the auditor learned on January 12 that its files were affected. By the time of the February 1 notice, the auditor had told law enforcement, the Attorney General’s Office and the agencies and local governments whose data was involved.

A file transfer appliance is a piece of equipment, or software running like one, whose job is to move large or sensitive files securely between organizations. It does the work that email attachments are too small or too insecure to do. Organizations typically set one up so that partners can upload and download files through a web page, without anyone needing to share a network.

The auditor was one of many Accellion customers affected. Attackers had exploited vulnerabilities, meaning flaws in the software that let outsiders do things they should not, in the product from December 2020 into January 2021. Accellion learned of the first flaw in mid-December and issued a fix on December 23. Attackers then used further flaws against customers. The product was a file sharing appliance about two decades old, which Accellion was already retiring in favor of a newer platform. Its own maker wanted customers to move away from it.

The first public disclosures came from outside the United States. On January 10, the Reserve Bank of New Zealand said a third-party file sharing service it used had been illegally accessed. On January 15, Australia’s corporate regulator, ASIC, disclosed an incident involving a server it used to transfer documents. Washington’s notice brought the episode home to U.S. state government, and more disclosures followed through February and March.

The list of disclosed victims showed how widely such tools spread. It included public bodies in New Zealand and Australia, universities, a law firm and a U.S. grocery chain. Many received extortion demands: pay, or the stolen information will be published. Stolen data from some appeared on a leak site associated with the Clop ransomware group, a criminal operation known for this kind of pressure.

Formal analysis followed within weeks. On February 22, Mandiant published a technical account of the intrusions and the extortion that followed. On February 24, CISA issued a joint advisory with cyber agencies from Australia, New Zealand, Singapore and the United Kingdom. It listed four vulnerabilities, named the fixed version and said the product would reach end of life on April 30, 2021. It urged customers to update, check for signs of compromise, reset credentials and consider moving to a supported file-sharing platform. It reported affected federal and state and local government bodies, and private firms in the medical, legal, telecommunications, finance and energy sectors.

The week’s news made one uncomfortable point clear. Some of the most sensitive data a government holds was passing through a tool that few senior officials could have named, let alone described.

The Accellion breaches were easy to file as a vendor problem: a legacy product, unpatched flaws, a criminal group. On that reading, the fix is simple. Replace the product, and the danger goes away.

That reading misses why the same pattern returned again and again. Managed file transfer occupies an awkward place in public sector architecture. It moves some of the most sensitive data an agency holds, between agencies, auditors, contractors and partners, yet it rarely appears on anyone’s list of critical systems.

Four conditions turned it into the perimeter, the outer edge where an organization meets the outside world and where attackers look first. Each condition needs its own fix: ownership, lifecycle, retention and custody.

The argument proceeds in order. It first explains what file transfer is and how attacks on it unfold, since the four conditions only make sense against that background. It then takes ownership, lifecycle, retention and custody in turn. Two closing sections show how the four compound and what a single quarter of housekeeping can achieve, followed by questions for agency leaders.

A loading dock on the internet

Every organization needs to send files to other organizations. Often those files are too large or too sensitive for email. An agency may need to send a contractor a database extract with thousands of names and Social Security numbers, or receive a monthly claims file from a partner. Email attachments have size limits, are easy to send to the wrong person, and linger in inboxes indefinitely.

Managed file transfer, often shortened to MFT, is the category of software built for this job. It works like a secure loading dock: a sender drops a file off at the dock, the system notifies the recipient, and the recipient comes to collect it. The dock keeps a record of who dropped off what and who picked it up. The “managed” part means the organization can control who has access, track what moves, and set rules for how long files stay.

Three ways files move

File transfer platforms usually support three kinds of exchange. People use a web page to upload and download files by hand, as the Washington auditor’s staff would have done. Systems connect automatically over protocols such as SFTP, usually on a schedule. Applications call the platform through an interface to send or fetch files as part of a larger process.

Each kind has its own accounts, its own credentials and its own logs. A platform that started with a few human users can end up carrying nightly automated feeds for several programs. The security posture that suited the first use may not suit the tenth.

File transfer also happens outside dedicated products. Cloud collaboration suites allow external sharing links. Many agencies use them to send files to partners, and the same questions of ownership, retention and custody apply. The rest of this article focuses on dedicated platforms, but the habits carry over.

Why the design attracts attackers

Two features of this design matter for security:

• It has to be reachable from the internet. Partners outside the organization need to connect to it, so it cannot be locked away inside the internal network. That makes it a natural target, because attackers anywhere in the world can find it and probe it.
• It concentrates valuable data. By design, the files moving through it are the ones considered too sensitive for ordinary channels. An attacker who gets in finds a curated collection of the organization’s most important records.

A third feature is less obvious. A transfer platform keeps an index: a database of every file, who uploaded it and who it was meant for. That index is what makes the platform manageable. It is also a map for an intruder, who can use it to find everything worth taking without searching.

An “appliance” is a self-contained device or software package that is installed once and then tends to be left alone. That convenience is part of the problem. Appliances are easy to forget. They often run their own operating system, which the customer cannot patch independently, and their logs may stay on the device unless someone arranges to send them elsewhere.

When attackers find a vulnerability in a widely used, internet-facing product like this, they can often break into many customers at once by scanning for every installation and exploiting the same flaw. A single software weakness becomes a mass breach.

An ordinary day, and an attack

Inside a typical agency, the file transfer service runs unnoticed in the background. An analyst logs in through a web browser, uploads a spreadsheet and enters the recipient’s email address. The recipient gets a notice with a link, signs in and downloads the file. Some connections are automated: a partner’s computer connects every night at two in the morning, drops off a file and disconnects, with no human involved. Over the years, a single platform can end up running hundreds of these exchanges, manual and automated, for many different teams.

That variety is what makes the platform valuable, and it is also what makes it hard to secure. Nobody sees the whole picture. The analyst sees only her uploads. The partner sees only its nightly drop. The IT team sees a server that is up and running, which is all it was asked to watch.

An attack on a product like this usually follows a recognizable path, described here in general terms. First, a criminal group discovers or buys knowledge of a flaw that lets it bypass the login page or run its own commands on the appliance. Second, it scans the internet for every installation of that product, which is easy because each one answers in a recognizable way. Third, it uses the flaw on as many installations as it can, often within days, before the vendor issues a fix or before customers apply it. Fourth, it copies whatever files it finds and leaves. Finally, it contacts the victims with a demand.

What the Accellion intrusions looked like

Mandiant’s account, published three weeks after the Washington notice, followed that path closely. From mid-December 2020, attackers used a flaw that let them inject commands into the appliance’s database through a crafted web request. They then installed a web shell, a small program planted on a web server that lets an intruder operate it through a browser. Mandiant named this one DEWMODE.

DEWMODE did one job well. It queried the appliance’s own database and displayed every file with its path, name, uploader and recipient. The intruder could then download any file through the shell. The platform’s index, built to help administrators, became the attacker’s shopping list.

The shell also had a cleanup routine. When triggered, it removed traces of itself from the web server’s logs, cleared an administrative log and deleted the shell files. An agency that relied on logs stored on the appliance could find little evidence of what had been taken.

The extortion came weeks later and from a different set of actors. Mandiant tracked the data theft and the extortion as separate clusters of activity. The first emails went from free email accounts to a few people at each victim. If nobody replied, the next wave went to many more staff from hundreds of accounts. In at least one case the attackers contacted the victim’s partners with links to the stolen data. Victims were directed to the Clop leak site and a private negotiation page. Mandiant found links to a financially motivated group it tracked as FIN11, but said the evidence was insufficient to attribute the intrusions to it.

Why the outcome depended on the conditions

The speed matters. By the time a fix is announced, the theft may already have happened. So the conditions around the product, how much it stores, who can reach it and who is watching it, decide how bad the outcome is. A well-run appliance and a neglected one may share the same flaw; they will not lose the same amount of data.

Detection is part of those conditions. CISA reported observing large data transfers over the standard web port from federal agency addresses to an address associated with the activity. An agency that watches the volume of data leaving its transfer platform, and keeps logs somewhere the attacker cannot erase, has a chance to see the theft as it happens. One that relies on the appliance to report on itself does not.

Ownership: a tool that belongs to everyone and no one

File transfer tools are usually bought to solve one exchange, such as sending audit extracts, receiving claims files or sharing records with a contractor. Each use is small, so a program office or an operations team buys the tool, and nobody reviews it as an enterprise platform. Over time it gathers connections to dozens of partners, each set up by a different person for a different project.

Take a county human services department. Years ago, its finance team set up a file transfer appliance to exchange payment files with the state. Then the eligibility team used it to share case files with a contractor. Then the legal office used it to send records to outside counsel. Each new use made sense. Nobody ever stepped back to ask who was responsible for the whole thing.

The result is a system that touches highly sensitive data without an executive owner. When the vendor announces end of life or a critical patch, nobody is accountable for acting fast. Security teams may not even know the appliance exists, because it was installed as a utility.

Who should own it

The owner needs authority over the platform and a stake in the data. In most agencies that points to a named executive in the central IT function, with the business owners of each data flow as sponsors of their connections. The platform owner keeps it patched, monitored and inventoried. Each sponsor confirms, at each review, that their connection is still needed and that the data on it is what they expect.

State government adds a complication. Many states have independently elected officials, such as auditors, treasurers and secretaries of state, who run their own offices and often their own IT. Washington’s State Auditor is one. A state chief information officer may set enterprise standards for executive branch agencies, but cannot always direct an independent office. Ownership in that setting depends on agreement, shared services and the terms of data sharing agreements, rather than on a single line of command.

Counties and cities differ again. Many have a small IT team that supports dozens of departments, and departments buy their own tools. The practical owner is often the county’s IT director, with authority granted by the county executive or board to require registration of any system that holds resident data.

Finding the tools nobody listed

An inventory cannot be built from memory. The agency’s internet-facing footprint is the best place to start. External scans, firewall rules that allow inbound file transfer traffic, and domain and certificate records all reveal transfer services. Purchasing records and card statements catch tools bought outside central IT. CISA offers free vulnerability scanning of internet-facing systems to state, local, tribal and territorial governments, which helps smaller agencies see what attackers see.

Federal agencies have a mandate. Since April 2023, CISA’s Binding Operational Directive 23-01 has required federal civilian agencies to run automated asset discovery every seven days and vulnerability enumeration every 14 days. State and local governments are not bound by it, but the cadence is a useful benchmark.

The register

The first fix is administrative. Give file transfer an owner, put it on the list of critical systems, and require that owner to maintain three things:

• A register of partner connections, with the business purpose, the internal sponsor and the date each was last used.
• A list of data types that flow through each connection, so the agency knows what a compromise would expose.
• A review cycle that closes connections no current program depends on.

A first review usually finds connections no current program needs: a contractor whose engagement ended, a pilot project that never went further, a partner that switched to another method. Closing them is an immediate reduction in exposure at no cost.

The register also changes incident response. When a flaw is announced, the owner can say within an hour which platforms run the product, which partners connect to them and what data could be exposed. Without a register, that answer takes days, and the first draft is usually wrong.

Lifecycle: legacy appliances outlive their support

Every piece of software has a lifecycle. It is launched, updated and supported for some years, and eventually its maker announces “end of life,” meaning it will stop fixing problems. After that point, newly discovered flaws stay open forever.

The Accellion appliance was an old product its maker was encouraging customers to leave. Customers who had not migrated were running technology near the end of its supported life, on a platform attackers had studied closely. Old, widely deployed products are attractive to attackers precisely because there has been plenty of time to learn how they work.

Reading the vendor’s signals

Formal end-of-life dates are only the last signal. Long before them, a vendor that is steering customers to a new product stops investing in the old one. New features go to the new platform. Engineering attention follows. Security reviews of old code become less frequent. A product that is still supported on paper can be one the vendor no longer understands well.

In Accellion’s case, the maker described its appliance as a 20-year-old product nearing end of life and urged customers to move to its newer platform, built on a different code base. The formal end-of-life date of April 30, 2021 was announced in the same months as the breaches. Customers that had treated the earlier encouragement as marketing found themselves migrating during an incident.

Why replacement is slow

Public agencies face real obstacles to replacement. Budget cycles, procurement timelines and the effort of reconnecting every partner to a new platform all slow it down. A migration may mean asking dozens of outside organizations to change how they send files, each on its own schedule.

Those obstacles are the reason lifecycle planning has to start early. An end-of-life notice should trigger a funded migration plan with a date rather than a line on a risk register that waits for next year’s budget. A risk register is the list where organizations record known risks; it is useful, but listing a risk does not reduce it.

Migration as a partner program

A file transfer migration is mostly a partner program, with technology as the smaller part. The register shows who has to move. The owner groups partners into waves, starting with those carrying the most sensitive data and those with the strongest technical teams. For each wave, the agency sets up the new connection, runs both in parallel for a short period, confirms that files arrive correctly, and then closes the old connection.

Each partner needs a named contact, a deadline and a reason. Automated connections need new credentials and often new network rules on both sides. Human users need new accounts and a short guide. The migration is also the best moment to drop connections nobody needs, so the new platform starts smaller than the old one.

The choice of new platform has its own trade-offs. A cloud-hosted service moves patching to the provider, which helps an agency that struggles to patch quickly. It also moves custody of the data to the provider. Federal agencies generally need a cloud service with a FedRAMP authorization. State and local agencies follow their own state’s cloud and security requirements. Ownership, retention and contract terms remain the agency’s job wherever the platform runs.

Holding the line until migration

Where migration cannot happen quickly, compensating steps are available:

• Internet exposure can be limited to known partner addresses, so that only approved organizations can even reach the login page.
• Monitoring can flag unusual download volumes or new administrative accounts, two common signs that someone is stealing data.
• Retention on the device can be shortened, so there is less to steal.

Each step buys time; none makes an unsupported product safe.

Patch speed is the other half of lifecycle. Since November 2021, CISA’s Binding Operational Directive 22-01 has required federal civilian agencies to fix vulnerabilities listed in its Known Exploited Vulnerabilities catalog within set deadlines. File transfer flaws have appeared in that catalog repeatedly. State and local agencies can adopt the catalog as their own priority list, and many security teams do.

Retention: transfer tools turn into storage

A transfer service is meant to move data, and the loading dock is not supposed to be a warehouse. Yet files often stay on the appliance long after the recipient has downloaded them. Sometimes nobody configured deletion. Sometimes users rely on the tool as a convenient archive, because it is easier than finding the proper place to file something.

When attackers reach the appliance, they find a store of sensitive files rather than a few in transit. A breach that might have exposed last week’s transfers instead exposes years of them.

This is the most tractable of the four conditions. Automatic deletion after confirmed delivery, or after a short fixed period, limits what any compromise can expose. It costs little and needs no new system. The trade-off is minor inconvenience. Partners who miss a download must ask for the file again, which is a small price for a much smaller store of stolen data.

What deletion has to cover

Deletion settings are rarely as simple as one switch. Many platforms set retention per folder, per workspace or per user group, so a global policy can be overridden locally. Some mark files as deleted but keep them for a recovery period. Backups and replicas may hold copies long after the primary is gone.

Metadata deserves attention too. The Accellion web shell showed that a list of files, uploaders and recipients is valuable on its own. File names often contain case numbers, program names or personal names. A platform that deletes files but keeps their index forever still tells an intruder a great deal.

Records law

Retention also interacts with records law. Government bodies must keep certain documents for set periods, and some files on a transfer platform may be public records. So the deletion rule should be agreed with the records officer, and the copy of record kept in the system meant to hold it. The transfer tool carries a copy in transit; the official copy lives somewhere designed for long-term keeping.

The conversation with the records officer is usually easier than expected. Records schedules govern the record, not every copy of it. A transfer platform that holds a duplicate of a file already filed in a case system is rarely the place where the record has to live.

Proving it works

Retention settings should be checked rather than assumed. A quarterly report of the oldest file on each transfer platform, and of total volume held, shows whether the policy is working. If the oldest file is three years old, the policy is not working, whatever the configuration document says.

The same report can show the share of files deleted on schedule, the folders exempt from the policy and who approved each exemption. Exemptions tend to grow. A short list that the owner reviews each quarter keeps them in check.

Custody: your data on someone else’s appliance

The Washington case had a feature that matters for every agency. The people affected were unemployment claimants. The data came from the Employment Security Department. The breached system belonged to the auditor, another state office that had received the data for a legitimate oversight purpose.

Residents do not distinguish between agencies. To a claimant, it is all “the state.”

When data shared for oversight, research or contracted services is exposed, the originating agency bears much of the reputational cost and often much of the notification work, contacting affected people and fielding their calls.

What the agreement should say

Data sharing agreements are the documents agencies sign when one gives data to another. They should therefore specify:

• How data will be transferred.
• Where it will rest, and for how long.
• What security the recipient will maintain.
• Who notifies whom, and how fast, if the recipient is breached.

Which party must notify residents under a given state’s breach law in these arrangements is a question for agency lawyers. The answer is not always intuitive, and the time to find out is before an incident.

Rules that travel with the data

Some data carries federal conditions wherever it goes. State unemployment information is subject to federal confidentiality rules in 20 CFR Part 603, which set conditions for disclosure, including agreements and safeguards. Federal tax information held by state agencies falls under IRS Publication 1075. Criminal justice information falls under the FBI’s CJIS Security Policy. Health information held by covered entities and business associates falls under HIPAA.

Each regime asks the same practical questions: who may receive the data, how it moves, where it is stored and when it is destroyed. A data sharing agreement that answers them for the most demanding regime involved will usually satisfy the others. Agencies should check with counsel which rules apply to a given flow, because the obligations differ in detail.

Oversight bodies, and minimizing what moves

Custody applies within government as much as with private contractors. It can feel awkward to impose security terms on a fellow agency, especially an oversight body. But the claimants in Washington were affected regardless of which office held the file.

Auditors and inspectors need data to do their work, and their independence matters. A good agreement respects both. It sets a standard transfer method, a retention period tied to the audit, and notification duties, without giving the audited agency any say over the audit itself.

Minimization is the other lever. Not every analysis needs full Social Security numbers or bank details. Some can work with tokens or partial identifiers. The counter-argument is real: a fraud audit often has to match records exactly across systems, and that may need full identifiers. Where it does, the agreement should limit how long the full data is held and where. Where it does not, sending less is the cheapest protection there is.

Four weaknesses that compound

The four conditions reinforce each other. An unowned tool is not migrated on time, accumulates retained files, and holds data that belongs to other organizations. No fix depends on buying a new product, though a migration may follow from them.

The stakes are concrete:

• Residents and customers whose data is stolen face fraud risk and anxiety, and they direct their anger at the agency they trusted.
• Cost arrives as notification, call centers, credit monitoring, investigation and legal work, often far exceeding what prevention would have cost.
• Regulators and legislators ask why sensitive data was left on an aging appliance, and those hearings are uncomfortable.
• Partners lose confidence in sharing data, which can slow the very oversight and services the transfers were meant to support.

The same pattern in banks and health systems

The conditions are not unique to government. Banks exchange files with processors, core providers and regulators. Health systems exchange claims, lab results and research extracts with payers, labs and universities. Each uses file transfer platforms, and each faces the same four conditions.

The rules differ. Under an interagency rule in force since 2022, a bank must notify its primary federal regulator within 36 hours of determining that a significant computer-security incident has occurred. Its service providers have their own duty to notify the bank. A HIPAA covered entity must manage business associates under written agreements and notify affected individuals of breaches of unsecured protected health information. A state agency follows its state’s breach notification law. The obligations differ, but each depends on knowing quickly what was on the platform.

Size changes the shape of the work. A large bank or health system usually has a platform team, a vendor management office and a security operations center, so the gap is coordination between them. A credit union, a community bank or an ambulatory network may have one administrator who set up the transfer tool years ago and also runs everything else. For them, a vendor-hosted service with sensible defaults, a short register and a retention setting may be the realistic goal. A core provider or managed service partner may carry part of the work under contract, which makes the contract terms the control that matters most.

Objections worth answering

One objection is that moving to a cloud service solves the problem. It shifts patching to the provider, which matters. It does not decide who owns the platform, how long files stay, or what the agreement with each partner says. Cloud services can be breached too, and the customer still has to notify.

A second objection is that file transfer should be replaced by direct system-to-system interfaces. For some flows that is right, and it removes a store of files altogether. Interfaces still face the internet, still need owners and still carry sensitive data, so the four conditions follow the data to its new route.

A third objection is that agencies cannot afford this work. Most of it costs staff time rather than money: a register, a review, a retention setting, a page in an agreement. The migration is the expensive part, and a smaller, cleaner platform is cheaper to migrate.

A quarter of housekeeping

An agency in good shape can answer, quickly and in writing, a handful of simple questions. It knows every file transfer tool it runs, who owns each one and which partners connect to it. It knows what data flows through each, when it falls out of support and how long files stay on it. Its data sharing agreements say how transfers happen and who calls whom after a breach.

Return to the county human services department, and suppose its new owner spends a quarter on housekeeping. She finds three transfer tools, not one, because the legal office bought its own. She closes eleven partner connections nobody has used in a year. She sets automatic deletion at fourteen days after agreement with the records officer, and the platform drops from years of files to a few weeks’ worth. She adds a page to the county’s standard data sharing agreement covering transfer, storage and notification. The work required no new product, and if a flaw in the county’s tool were announced tomorrow, the damage would be a fraction of what it would have been.

The security team should also watch the platform as closely as it watches email. Alerts for unusual download volumes, new administrator accounts and logins from unexpected countries are cheap to set up and give early warning that something is wrong. Logs should go to a central system the appliance cannot alter, so a cleanup routine like DEWMODE’s cannot erase the record.

Measures and evidence

A few measures show whether the housekeeping holds. They are the number of transfer platforms, the share of connections with a named sponsor, the age of the oldest file and the days remaining to each platform’s end of support. Days taken to patch flaws in the known-exploited catalog is a useful fifth.

Auditors and legislative oversight bodies tend to ask for the same evidence after an incident. They want to see the inventory as it stood before the breach, the data sharing agreement, the retention setting and when it was last checked, and the patch history. An agency that keeps those records current has most of its incident report written in advance.

The failures are familiar:

• Treating file transfer as a utility rather than as a system that holds the agency’s most sensitive records.
• Letting end-of-life notices wait for the next budget cycle.
• Assuming deletion is configured because someone once said it would be.
• Signing data sharing agreements that cover what data is shared but not how it travels or rests.
• Leaving old partner connections open in case they are needed again.

What to ask about the file transfer estate

1. How many file transfer tools do we run, including ones bought by individual programs, and who owns each one?
2. When does each reach the end of its vendor support, and is a funded migration plan in place?
3. What is the oldest file on each platform today?
4. Which partner connections have not been used in the past six months, and why are they still open?
5. When we share data with another agency or a contractor, does the agreement say how they will store it and who notifies residents if they are breached?

These are questions of ownership and housekeeping rather than technology, and they are exactly the ones the Accellion breaches showed were going unasked.

They are also questions an agency head can ask without a technical briefing. The answers should come back within a week. If they take longer, that delay is itself the finding.

With hindsight

Accellion was the first of a series. The same criminal group, or actors associated with it, later exploited other managed file transfer products. Fortra’s GoAnywhere was hit in early 2023, and Progress Software’s MOVEit Transfer in mid-2023, which affected a very large number of organizations including many government bodies. Cleo’s products followed at the end of 2024.

Accellion’s own product reached its announced end of life on April 30, 2021, three months after the Washington notice. Customers who were still running it by then had no further fixes to wait for.

MOVEit was the largest of the campaigns. In June 2023, CISA and the FBI issued a joint advisory on Clop’s exploitation of a MOVEit Transfer flaw. Victims reported over the following months ran into the thousands of organizations. They included federal agencies, state governments, universities, health systems, banks and their service providers. In Oregon and Louisiana, motor vehicle agencies disclosed that driver’s license and ID records for millions of residents had been taken.

GoAnywhere and Cleo followed the same shape on a smaller scale. In each case CISA added the exploited flaw to its Known Exploited Vulnerabilities catalog, which gave federal civilian agencies a fixed deadline to remediate. Other organizations moved at their own pace, and the attackers counted on that gap between disclosure and patching. The more files a platform held, the more each day of that gap was worth to them.

Each time the method was similar: a flaw in an internet-facing transfer service, mass data theft, and extortion without encryption. Classic ransomware scrambles an organization’s files so it cannot work, then demands payment for the key. In these campaigns, the attackers skipped that step. They simply copied the data and threatened to publish it. For the victim, that means there may be no outage, no locked screens and no obvious alarm, just a ransom note and a stolen archive.

The custody problem also returned at scale. Many people affected by MOVEit had never dealt with the organization whose server was breached. Their data had been sent to a payroll provider, a benefits administrator, a pension fund or a records service. The Washington pattern, where residents learned of a breach at an office they had never heard of, became common.

The repetition shows the problem was structural rather than specific to one vendor. Replacing Accellion with another product did not by itself protect anyone. What protected agencies was the set of habits around the product, whichever product it was.

Agencies that inventoried their transfer services, set retention limits and wrote transfer terms into data sharing agreements after 2021 were better placed when MOVEit hit. They knew where their transfer tools were, they held fewer old files, and they knew who had to tell whom. Those that had treated Accellion as a one-off vendor failure found themselves repeating the same scramble two years later.

Rules moved too. For federal civilian agencies, CISA’s directives on known exploited vulnerabilities (2021) and asset discovery (2022, in force from April 2023) turned inventory and patch speed into requirements. Banks became subject to a 36-hour incident notification rule in 2022. Public companies faced SEC disclosure rules for material cybersecurity incidents from December 2023. In May 2024 the SEC amended Regulation S-P to require covered financial firms to oversee service providers and notify affected customers. The FTC’s Safeguards Rule began requiring many non-bank financial firms to report certain breaches in 2024.

State and local governments gained fewer new requirements. They also lost some support. In 2025, federal funding for the MS-ISAC, the information sharing center many of them rely on, was cut back. More of the housekeeping described here now depends on each government’s own staff and budget.

By 2026 managed file transfer is widely recognized as high-value infrastructure, although many agencies still struggle to name a single owner for it. That gap is the quickest to close. Naming an owner costs nothing, and it is the step from which every other fix follows: the register, the migration plan, the deletion rule and the contract terms.

The pattern extends beyond file transfer. The systems most likely to hurt an organization are often the unremarkable utilities that nobody owns. A periodic question of “what do we run that touches sensitive data and does not have a named owner?” is one of the cheapest risk reviews available.