PTFM? Is It Legal to Pay the Hacker? Canvas, Uber and the Criminal Law of Cyber Extortion
The Canvas/Instructure breach raises the question that every ransomware victim eventually confronts, but few want to say out loud. Not whether paying ransom is wise. Not whether it is cost-effective. Not whether the criminals can be trusted. Not whether “shred logs” actually means that stolen data is gone forever. Those are business, technical, ethical, and operational questions. They matter, but they are not the threshold legal question. The threshold legal question is simpler and more dangerous: is it legal to pay?
According to the Associated Press, Instructure, the company behind the Canvas learning-management platform, said that it “reached an agreement with the unauthorized actor involved” in a cyberattack that disrupted access to Canvas during finals and threatened data associated with thousands of schools. AP reported that ShinyHunters claimed responsibility, threatened to leak data involving nearly 9,000 schools and 275 million individuals, and that Instructure said the data was returned and that it received “digital confirmation” of destruction in the form of “shred logs.” Reuters reported substantially the same thing, adding that ShinyHunters told Reuters that the company and its customers would not be further targeted or contacted for payment, and that a ransomware negotiator said it was “fair to conclude that some money was sent.” AP also reported that Instructure said the breach appeared to involve student ID numbers, email addresses, names, and Canvas messages, but that it had found no evidence that passwords, dates of birth, government identification, or financial information were compromised.
Put aside whether this was a good incident response. Put aside whether payment incentivizes future attacks. Put aside whether the criminals actually destroyed anything. The law does not ask whether the victim made a wise bargain with a thief. The law asks whether the payment itself, the process surrounding the payment, the recipient of the payment, and the company’s related statements and omissions violated a statute, regulation, court order, contractual duty, sanctions regime, disclosure obligation, or criminal prohibition.
Say it Aint So, Joe – The Uber Ransomware Payment
In United States v. Sullivan, No. 23-927, 2025 WL 742124 (9th Cir. Mar. 13, 2025), amended and rehearing en banc denied, No. 23-927 (9th Cir. Nov. 12, 2025), the Ninth Circuit affirmed the conviction of Uber’s former Chief Security Officer for obstruction of justice and misprision of felony.
Uber, like Canvas, was hit by a ransomware attack where the attackers demonstrated that they had stolen information. Unver, like Canvas, agreed to pay the threat actors not only for the “return” of the stolen data, but for assurances by the threat actors that the stolen data had been destroyed – shredded. The goal in both cases was for the company suffering the ransomware attack to minimize the harm to its customers and data subjects from the theft.
If data is stolen, but not looked at or used, and then destroyed completely, is there a reportable data breach? The answer is likely yes, as a “breach” is typically defined as the unauthorized acquisition of unencrypted Personally Identifiable Information. But consider this scenario – a company laptop with unencrypted PII is left on the Boston T by a careless employee. It is found by a good Samaritan, who returns the laptop – maybe opened — maybe unopened, but there is no evidence of “use” of the data. Do we report the “breach” or do we not? Does it make any logical sense to notify a couple of million people that their data traveled to the Alewife station without permission? This is a concept that HIPAA/HITECH addresses for health information – the concept of a low-risk or low probability of harm “breach” — like sending a patient record to the wrong doctor, or the wrong lab. But all of this assumes that you can “trust” the hacker to do what they promised to do – to shred the data.
In the Sullivan case, Joe Sullivan authorized a payment by Uber to hackers who demonstrated that they had obtained data. The payment, made from Uber’s “bug bounty” program, relied on representations from the hackers that they had not viewed or examined any PII, that they had returned all copies of the purloined data. In the Sullivan case, unlike the Canvas case, Uber was already subject to a consent decree for a previous data breach, and part of the motivation for paying the ransom was to avoid having to inform the FTC that there had been an additional breach. In Canvas, because the breach impacted both the confidentiality of the data and the availability of the service, it was well known that the threat actors had attacked the system, so breach notification was not an issue. That distinction matters. Paying ransom may be risky, discouraged, sanctionable in some circumstances, contractually prohibited in others, and evidentiary dynamite in litigation. But it is not per se illegal under federal law merely because the recipient is a criminal. There is no general federal statute that says, “A cyber victim may never pay an extortion demand.” The law is more fractured and therefore more treacherous. A payment can become illegal because of who receives it. It can become illegal because of what the payer says about it. It can become illegal because it is used to conceal a crime. It can become illegal because the payment violates sanctions laws. It can become illegal because the company lies to a regulator, insurer, auditor, customer, investor, or court. It can become illegal because the payment is booked falsely, mischaracterized as a bug bounty, routed through a misleading contract, or paired with nondisclosure language designed to suppress legally required reporting.
The Sanctions Regime
The first legal problem is sanctions. The Office of Foreign Assets Control has warned that companies facilitating ransomware payments may violate OFAC regulations when the payment is made to a sanctioned person, sanctioned entity, sanctioned jurisdiction, or otherwise blocked party. OFAC, Updated Advisory on Potential Sanctions Risks for Facilitating Ransomware Payments 1–3 (Sept. 21, 2021), stated that ransomware payments may “risk violating OFAC regulations,” that the United States government “strongly discourages” ransom or extortion payments, and that companies should contact relevant U.S. government agencies if there is reason to suspect a sanctions nexus. Id. at 1–2. OFAC also warned that payment does not guarantee restored access or freedom from future attacks. Id. at 3. This is not merely guidance in the abstract. The International Emergency Economic Powers Act, 50 U.S.C. §§ 1701–1708, and implementing sanctions regulations can impose civil liability under a strict-liability framework in many sanctions contexts. The company does not get a legal pass because it was a victim. Because ransom demands come from unknown persons in unknown locations, paying the ransom runs the risk of being a payment to a Specially Designated National, or SDN. Increasingly, governments are responding by putting specific crypto wallets on the SDN list, rather than just persons or companies.
AML and Ransom
The second legal problem is money transmission and anti-money-laundering compliance. FinCEN has warned that persons involved in ransomware payments must be aware of OFAC-related obligations and that ransomware payments often involve convertible virtual currency, money services businesses, suspicious activity reporting obligations, and typologies associated with cyber-enabled crime. FinCEN, Advisory on Ransomware and the Use of the Financial System to Facilitate Ransom Payments, FIN-2021-A004 (Nov. 8, 2021). FinCEN noted that persons involved in ransomware payments must be aware of OFAC obligations, and it linked ransomware payments to broader financial-crime monitoring and reporting duties. Id. at 4–5. The victim company may not itself be a money services business, but the negotiation firm, payment facilitator, insurer, exchange, or forensic vendor may sit inside a regulated chain. That means the legal analysis must begin before the payment, not after the Bitcoin leaves the wallet.
Related issues include the possibility that a payment may constitute “material support” to the activity of the threat actor, or may be other inchoate offenses like aiding and abetting, facilitation, or even, as in the Sullivan case, misprison. Most recently, in Twitter, Inc. v. Taamneh, 598 U.S. 471 (2023). The companion case is Gonzalez v. Google LLC, 598 U.S. 617 (2023), the Supreme Court rejected the liability of entities like Twitter and Google for permitting (and having their algorithms encourage) access to information that facilitates terrorist attacks. But there is likely a difference between amplifying a message with an algorithm and writing a check (well, not a check, but you get the idea) to a cyberterrorist.
.
The legality of the Canvas payment, if there was one, therefore turns on facts not yet public. Who received the money? Was the recipient sanctioned? Was a payment facilitator used? Was OFAC screening performed? Was law enforcement contacted? Was CISA notified? Were the affected schools given accurate information? Were insurers told the truth? Were regulators told the truth? Were breach-notification obligations evaluated under state law, education privacy laws, contracts, and procurement requirements? Was the payment accurately booked? Were the “shred logs” represented as proof of destruction or merely as a criminal’s representation of destruction? Did any agreement purport to prevent the hackers from cooperating with law enforcement? Did the company preserve evidence? Did the company make statements to customers that understated what it knew?
The education context adds still more complexity. Canvas is not a peripheral application. It is infrastructure. It stores assignments, grades, messages, discussions, course materials, exams, submissions, and communications between students and faculty. A breach of that system may implicate state breach-notification statutes, contractual confidentiality obligations, institutional reporting duties, and potentially education-record privacy obligations, depending on the nature of the data and the relationship between the vendor and educational institutions. The Family Educational Rights and Privacy Act, 20 U.S.C. § 1232g, and its implementing regulations, 34 C.F.R. pt. 99, do not create a simple private damages remedy for every vendor breach, but they frame the confidentiality obligations around education records and school officials’ use of contractors. The legal issue is not just whether Canvas paid. It is whether schools, students, parents, regulators, and affected institutions received legally sufficient and materially accurate information.
This is why “shred logs” are not a legal conclusion. They are a fact to be evaluated. They may be relevant to mitigation. They may support a statement that the company received some form of digital confirmation from the threat actor. They do not prove that no copies exist. They do not eliminate breach-notification duties. They do not eliminate contractual duties. They do not eliminate litigation exposure. They do not eliminate sanctions risk. And they do not transform extortion into lawful commerce.
The cleanest way to understand the law is this: Paying ransom is not categorically illegal, but almost everything around paying ransom can create legal liability.
The legal advice after Canvas is therefore not “never pay.” It is more exacting. Do not pay a sanctioned actor. Do not pay without OFAC, AML, law enforcement, insurance, forensic, and governance review. Do not pay and lie about it. Do not pay and call it something it is not. Do not pay and suppress required notices. Do not pay and tell customers the data is “safe” when the best you have is a criminal’s promise. Do not pay and destroy the evidence. Do not pay and then claim the incident never happened. Cyber extortion creates a hostage crisis with data. The law may permit a company to try to rescue the hostage. It does not permit the company to hide the kidnapping.

