Instructure's Own Documents Don't Add Up

Methodology Note

This is the first installment of After the Breach, a Cloudskope series that examines major cybersecurity incidents once the news cycle has moved on and the public record is complete enough to support analytical reconstruction. The series exists because the most important questions about a vendor breach usually cannot be answered in the first 72 hours, when most coverage is published. They can be answered two and three weeks later, when court filings, congressional correspondence, vendor walk-backs, and the threat actor's own subsequent statements have all entered the public record.

This first installment reconstructs the Canvas / Instructure incident of April–May 2026 using a specific methodology: we read Instructure's own publications against each other and against the public record. We do not rely on Cloudskope opinion. We rely on documents the company itself has published — press releases, status page updates, the incident update FAQ, the trust center, and statements made by the company's CISO and CEO. Where the documents do not reconcile, we note where they do not reconcile and let the reader weigh the implication.

Cloudskope previously published commentary on this incident on May 7, 2026. That analysis was issued in the heat of the news cycle and was cited by Brian Krebs at KrebsOnSecurity alongside Mandiant in his Canvas coverage. The present reconstruction is issued with two weeks of additional distance. The May 7 analysis stands. This reconstruction extends it.

Every analytical claim is sourced. Where the analysis relies on inference rather than direct evidence, the inferential step is named. ShinyHunters is the threat actor. We treat the actor's public statements as evidence of the pattern the actor was describing, not as established fact about what the vendor did. Where the actor's account has not been disputed by Instructure, we note that.

The intent of this reconstruction is not to indict any individual. It is to demonstrate a methodology — one any CISO, general counsel, board member, or private-equity diligence team can apply to their own vendor stack today. The question this piece teaches the reader to ask is: does what the vendor has published about itself reconcile with what the vendor has now had to admit? For the Canvas incident, the answer is documented below. For your vendors, you are going to have to do the work yourself.

Executive Summary

Between September 2025 and May 12, 2026, Instructure made a series of public statements about its security posture and its response to the Canvas breach. Read in chronological order, those statements are individually defensible. Read against each other, and against the public record now available, they describe a company whose published self-portrait does not match what the company has subsequently had to acknowledge.

Three findings carry the analysis.

One. The dwell time is in the public record but not in Instructure's communications. The threat actor accessed Canvas systems on April 25, 2026. Instructure detected the intrusion on April 29, 2026 — four days later. Independent reporting establishes this. Instructure's own statements always start the timeline on April 29 and never acknowledge the four days during which an attacker was inside the environment and the company was unaware.

Two. The company's own incident page describes deploying EDR as part of the response. Instructure's incident update page, still live as of this writing, states verbatim that “as part of our response, we have rolled out CrowdStrike's Falcon Endpoint Detection & Response tool across the Instructure network.” The natural reading of that language — “as part of our response” combined with “have rolled out” — is that the tool was not deployed network-wide at the time of either the April 25 intrusion or the April 29 detection. Instructure had renewed SOC 2 Type II certification on December 9, 2025, four months before the breach. The company has not publicly clarified the gap between those two facts.

Three. The May 2 containment claim and the May 6 resolution claim were made during a period in which, by the attacker's own subsequent account, negotiations were being attempted. Instructure's CISO publicly stated on May 2 that “we believe the incident has been contained,” and on May 6 that the incident was “resolved with Canvas fully operational and no indication of ongoing unauthorized activity.” On May 7, ShinyHunters defaced approximately 330 institutional Canvas login pages during finals week and stated publicly: “ShinyHunters has breached Instructure (again). Instead of contacting us to resolve it they ignored us and did some 'security patches.'” Instructure has not publicly disputed the characterization that negotiation overtures were ignored.

These three findings, taken together, are not a moral conclusion. They are an information-asymmetry finding. Instructure's customers — universities, school districts, ministries of education — spent two weeks reading the company's public statements without access to the operative facts. The facts existed. Some were in the warning record before the breach. Some were in the attacker's public statements during the breach. Some were in the company's own documents about itself. The gap between what was knowable and what customers were told is the second breach. The piece below documents that gap.

Part I — The Warning Record (September 2025 to April 24, 2026)

This part establishes what Instructure knew, or should have known, before the April 25, 2026 intrusion. None of this is hindsight. All of it was in the public record at the moment Canvas was compromised.

September 2025: Instructure's Salesforce Environment Is Compromised by ShinyHunters

In September 2025, ShinyHunters compromised Instructure's Salesforce business environment through what was later determined to be social engineering against employees with privileged access. The company acknowledged the incident and stated that the data accessed was limited to “business contact information.” Customer relationship records, internal organizational structure, and the names of personnel within partner institutions were among the data exposed. The same campaign was tracked by Google Threat Intelligence Group as part of the broader UNC6040 and UNC6240 activity targeting Salesforce environments globally, a campaign Google's published analysis indicates affected more than 1,000 organizations.

What Instructure knew on October 1, 2025 was this: a sophisticated, named cybercriminal collective with a documented history of large-scale extortion against major enterprises had successfully accessed an Instructure-controlled environment containing institutional customer data. ShinyHunters' operational tempo is months, not weeks. Any responsible threat model in October 2025 would have anticipated follow-on activity.

September 12, 2025: FBI FLASH Alert on ShinyHunters Targeting of Salesforce Environments

Within days of the Instructure compromise, the Federal Bureau of Investigation issued a FLASH alert specifically warning about ShinyHunters targeting of Salesforce environments and naming the operational designations involved. A federal law-enforcement FLASH alert is not a private notification. It is a public warning distributed through industry information-sharing partnerships including sector ISACs, and routinely picked up by trade press. Any organization with a CISO function and a federal-coordination relationship would have received and reviewed the alert within days of issuance.

Instructure's December 9, 2025 press release announcing the renewal of SOC 2 Type II certification describes the company's posture as including “continuous monitoring, dedicated incident response and rigorous internal and external testing.” We do not assert that Instructure failed to receive or process the FBI FLASH alert. We note that the alert was public, that it specifically described the threat actor that had just compromised the company, and that any organization that received and acted on the alert would have hardened the relevant environments before April 2026.

October 2025 to February 2026: The Penn Pattern Emerges in Public Reporting

Beginning in October 2025 and continuing through February 2026, the University of Pennsylvania experienced a series of incidents publicly attributed to ShinyHunters: alumni and graduate-school affiliates received targeted spam emails referencing data drawn from the Graduate School of Education's records. Penn handled the early incidents as Penn-specific events. The press, including The Daily Pennsylvanian, reported them as Penn-specific events.

In February 2026, ShinyHunters told The Daily Pennsylvanian directly that Penn had been given an opportunity to pay a $1 million ransom to prevent the further release of stolen files, and that Penn had declined. The story remained, in the public framing, a Penn-specific story. Instructure's role as the data custodian was not yet publicly named. This is the moment at which a vendor with operational maturity would have engaged the question internally: if our Salesforce environment was compromised by ShinyHunters in September, and that same actor is now publicly extorting one of our institutional customers, what is our exposure? Instructure has not publicly addressed whether this internal question was asked.

March 5, 2026: ShinyHunters Publishes Penn Donor Data

On March 5, 2026, ShinyHunters published 461 megabytes of stolen Penn data, including donor records, internal memoranda, and confidential correspondence. The publication followed Penn's February refusal to pay and was the operational execution of the threat the actor had publicly made. The Penn publication confirmed that ShinyHunters had retained data from earlier in the campaign and was actively monetizing it months later, and it documented the actor's playbook: initial compromise, intelligence gathering, extortion demand, publication if non-payment. Both points were established in the public record fifty-one days before the Canvas intrusion.

March 18, 2026: A Federal Court Lowers the Bar for Sponsor Liability

On March 18, 2026, a federal court in the Northern District of California denied Bain Capital's motion to dismiss in the PowerSchool data breach litigation. The ruling permitted plaintiffs to proceed against the private-equity sponsor directly — not merely against its portfolio company — on negligence and aiding-and-abetting theories. The ruling changed the procedural landscape for breach litigation against private-equity-backed vendors. Until March 18, the default expectation was that sponsors would be dismissed early from portfolio-company breach suits. After March 18, that default no longer held.

We note the ruling because it was in the public record at the moment of the Canvas intrusion, and because its existence is directly relevant to the litigation posture every private-equity-owned vendor would have been considering in April 2026. We do not, in this piece, name the private-equity sponsor of Instructure or make any claims about that sponsor's operational decisions. We note only that the procedural rules governing such claims changed six weeks before the Canvas intrusion.

April 22, 2026: Updated COPPA Rule Takes Effect

On April 22, 2026, the Federal Trade Commission's updated Children's Online Privacy Protection Rule took effect. The rule tightened consent and breach-notification requirements for data on children under thirteen and authorized civil penalties of up to $53,088 per affected child. The rule's effective date precedes the April 25 Canvas intrusion by three days. For a learning management system whose K–12 user base includes large populations of users under thirteen, the regulatory exposure created by the COPPA update was material on April 22 and was not retroactive.

What Was Knowable on April 24, 2026

On the day before the Canvas intrusion, the following was in the public record: ShinyHunters had compromised Instructure's Salesforce environment in September 2025; the FBI had issued a FLASH alert specifically warning about ShinyHunters targeting of Salesforce environments; ShinyHunters had used that access to extort the University of Pennsylvania and had published 461 MB of Penn data after Penn declined to pay; the federal courts had ruled six weeks earlier that a private-equity sponsor could be sued directly for portfolio-company cybersecurity decisions; and the updated COPPA rule had taken effect three days earlier. None of this is hindsight. All of it was knowable. The question of what Instructure did with what was knowable is a question Instructure can answer. The company has not.

Part II — The Active Breach (April 25 to April 29, 2026)

The threat actor accessed Canvas systems on April 25, 2026. Instructure detected the intrusion on April 29, 2026. This is the four-day period during which an attacker was inside the environment and the company was unaware.

The Dwell Time

That the April 25 access date is correct is established by multiple independent secondary sources. Dark Reading reports that Instructure first discovered the intrusion four days late, on April 29. Help Net Security reports that ShinyHunters claimed responsibility for a breach of Canvas on April 25, 2026. The maintained reference record of the incident, triangulated across multiple sources, treats April 25 as the established access date.

Instructure's own statements never acknowledge April 25. Every Instructure communication begins the timeline on April 29: “On April 29, 2026, we detected unauthorized activity in Canvas.” The company's incident page, its status updates, and its letter responses to congressional inquiry all start the clock on April 29.

The choice to begin a timeline on detection rather than on access is itself a framing decision. Detection is the moment the defender becomes aware. Access is the moment the attacker became present. The two are not the same. Standard incident response practice, as documented in NIST Special Publication 800-61, distinguishes between the two and reports both. We do not assert that Instructure has lied about the dwell time. We note that the public record establishes a four-day dwell that Instructure's own statements do not acknowledge. The reader can weigh that.

The Intrusion Mechanism: Free-For-Teacher and the XSS Path

Instructure's incident update page now states that the intrusion exploited an issue related to its Free-For-Teacher accounts. BleepingComputer's Bill Toulas confirmed through correspondence with Instructure that the technical vector was multiple cross-site scripting vulnerabilities in user-generated content surfaces within the Free-For-Teacher account program.

The Free-For-Teacher program is a thirteen-year-old onboarding tier that provisions production Canvas tenants for individual teachers without institutional verification. The architectural pattern — multi-tenant production infrastructure with an unverified-account class on the same data plane as paying institutional customers — has been a documented property of the platform since at least 2013. CVE-2018-1999024, disclosed eight years ago, documents an XSS vulnerability in Canvas's MathJax and jQuery layer. The vulnerability class exploited in April 2026 is not novel. The architectural pattern that enabled exploitation at scale is not novel. Instructure has now shut down Free-For-Teacher under public pressure. The shutdown is a forensic acknowledgment that the architecture did not survive contact with a determined actor. The shutdown was not a 2025 decision. It was a May 2026 decision under duress.

The CrowdStrike Question: Reading Instructure's Own Page

Instructure's incident update page, still live as of the time of this writing, contains the following verbatim language: “As part of our response, we have rolled out CrowdStrike's Falcon Endpoint Detection & Response tool across the Instructure network to provide 24/7 monitoring capabilities.”

We quote this in full because the language is the analytical artifact. Read carefully: “as part of our response” combined with “have rolled out.” The construction places the EDR rollout temporally within the incident response phase. The natural reading is that the tool was not deployed network-wide at the time of either the April 25 intrusion or the April 29 detection. We acknowledge other readings are possible. It is conceivable that Instructure had EDR deployed on some systems and has now rolled it out across the entire network. Instructure has not publicly clarified.

The reason this matters: on December 9, 2025, four months before the breach, Instructure issued a press release announcing the renewal of its SOC 2 Type II, ISO 27001, and PCI DSS 4.0.1 certifications. In that release, Instructure's CISO stated that “security is a central pillar of the trust we build with our customers and partners,” and the release described the company's posture as including continuous monitoring and dedicated incident response.

These two documents — the December 2025 SOC 2 renewal announcement and the May 2026 incident update — are both published by the same company. We do not claim that they contradict. We note that they do not naturally reconcile, and that the reconciliation is a question the company is in the best position to answer. SOC 2 Type II does not, on its face, attest to specific tooling like EDR; it attests to the operation of the controls the organization describes during the audit period. The certification could be entirely valid even if the organization's described controls did not include network-wide EDR deployment.

The question, then, is not whether the SOC 2 is invalid. The question is: what was Instructure's described control posture during the SOC 2 Type II audit period, and does that posture match what the May 2026 incident update now describes as having been rolled out as part of the response? This is exactly the question CISOs running vendor diligence should now be asking of every SaaS vendor whose certifications appear on a procurement checklist. Trust, but verify. SOC 2 reports are not public, but vendors will share them under NDA on request. The question to ask is not “are you SOC 2 certified.” The question is “what did your SOC 2 Type II describe about your EDR posture, and is that posture unchanged today.” A vendor that has rolled out EDR as part of a breach response has, by the natural reading of its own language, changed posture since the audit.

We are not the only ones who will ask this question. Plaintiff's counsel in the federal class actions now pending against Instructure will ask it during discovery. The House Homeland Security Committee, in its May 11, 2026 letter demanding briefing by May 21, has implicitly already asked it. Cyber-insurance underwriters reviewing renewal applications from private-equity-backed SaaS vendors are now asking it of their other portfolio risks.

Part III — The Incident Response (April 29 to May 12, 2026)

This part walks through the decisions Instructure made publicly during the response phase. At each decision point, we note what was done, what was said, what the record now shows, and what alternative conduct would have looked like. The structural finding that emerges is the central methodological point of this piece. While Instructure's public statements during this period projected progression — “contained,” “resolved,” “no ongoing unauthorized activity” — the threat actor was, by their own subsequent account on May 7, attempting to negotiate with the company and being ignored. Customers reading the public statements did not have the operative information. The threat actor did. The company did. The customers did not.

Decision 1: Initial Disclosure Timing and Language

Instructure's first public acknowledgment of a security incident came on April 30, when the company's status page noted “limited disruption to tools relying on API keys.” The framing was operational, not security-related. On May 1, the company released a statement describing a cybersecurity incident perpetrated by a criminal threat actor. The May 1 reframing followed roughly twenty-four hours of independent reporting and criminal-forum activity that had publicly tied the disruption to a security incident. The April 30 framing did not survive contact with the public record. The standard of practice for vendor incident disclosure within 24 to 72 hours of detection is that the disclosure should accurately characterize the event class. “Limited disruption to tools relying on API keys” is not the standard-of-practice characterization of a ShinyHunters compromise.

Decision 2: The May 2 Containment Claim

On May 2, Instructure's CISO stated publicly: “We believe the incident has been contained.” The statement was reproduced by multiple outlets including KrebsOnSecurity and by Instructure's institutional customers in their own communications to faculty and students. Containment, as a term of art in incident response, refers to a verifiable state in which the attacker no longer has active access paths. It is distinct from resolution, which requires verified elimination of access and remediation of the underlying vulnerability.

The May 2 statement was made three days after detection and seven days after the April 25 access date. On May 7, five days after the containment claim, ShinyHunters demonstrated publicly that the access path had not, in fact, been eliminated. The May 7 defacement exploited the same issue that led to the unauthorized access the prior week, per Instructure's own subsequent acknowledgment. The May 2 containment claim, in retrospect, was either made on insufficient evidence, accurate as of May 2 but defeated by attacker action between May 2 and May 7, or made knowing the access path had not been definitively eliminated. The public record does not disambiguate among these. None of the three readings is favorable.

Decision 3: Whether to Acknowledge the ShinyHunters May 3 Leak-Site Posting

On May 3, 2026, ShinyHunters publicly added Instructure to its leak site and claimed the theft of approximately 3.65 terabytes of data from Canvas customers. Instructure's public response to the May 3 posting was minimal. The company's status page continued to characterize the incident as contained. What we know, from ShinyHunters' subsequent May 7 statement, is that the threat actor was at this point characterizing Instructure's posture as non-engagement.

We are careful here: ShinyHunters is a criminal actor with motive to misrepresent. The actor's account of being ignored is the actor's account. But Instructure has not provided an alternative account, and the May 7 escalation is consistent with a negotiation that had failed rather than one that had not been attempted. The decision to decline engagement may have been the right one; the FBI's standing guidance is that organizations should not engage with extortion actors. What was not addressed, in any of Instructure's public communications, was the implication of that decision for customers. Customers reading Instructure's public statements between May 3 and May 6 did not have that information. The threat actor did. The company did. The customers did not.

Decision 4: Whether to Disclose the September 2025 Salesforce Precedent

In its public communications between April 29 and May 12, Instructure did not publicly disclose the September 2025 Salesforce-environment compromise. The September 2025 incident is not referenced in the incident update page. It has not been publicly tied by Instructure to the April 2026 events. The two incidents are technically distinct — different systems, different vectors, different data sets. They were not, however, different actors. The same group was responsible for both. The same group had used the data from the September compromise to publicly extort the University of Pennsylvania.

Cloudskope previously noted on May 7 that “Penn was the named target. Instructure was the mechanism.” That observation has been borne out. Customers evaluating the April 2026 incident without knowledge of the September 2025 incident were evaluating the wrong incident. The non-disclosure of the September 2025 precedent is the largest single gap between what was knowable and what customers were told.

Decision 5: The May 6 Resolution Claim

On May 6, 2026, Instructure publicly stated that the incident was “resolved with Canvas fully operational and no indication of ongoing unauthorized activity.” The statement was reproduced by Duke University, the University of Pennsylvania, and other institutional customers in their communications to faculty and students. Resolution, in incident response terminology, requires verified elimination of the attacker's presence and remediation of the underlying vulnerability. The May 6 claim made both.

Twenty-four hours later, on May 7, ShinyHunters defaced approximately 330 institutional Canvas login pages by exploiting the same issue that produced the initial compromise. The actor retained sufficient access to execute a coordinated, multi-institution defacement during finals week. The May 6 resolution claim was, at minimum, premature. It sits in the same category as the May 2 containment claim: the vendor's public posture projected closure while the threat actor's access path remained available.

Decision 6: Communication Conduct During the May 7 Defacement

At approximately 3:30 PM Eastern on May 7, 2026, ShinyHunters defaced institutional Canvas login pages at universities and school districts in the United States, United Kingdom, Canada, and Australia. The defacement displayed a black-and-red message reading “ShinyHunters has breached Instructure (again)” and announced a May 12 deadline for ransom negotiation. Per the Daily Pennsylvanian and the Duke Chronicle, the defacement was visible to students mid-final-exam for approximately fifty minutes before Instructure took the affected pages offline. During that window, the company's executive leadership had visibility into a coordinated criminal action affecting approximately 330 institutional customers and millions of students. No contemporaneous Instructure public statement during the active defacement acknowledged the May 7 events as security-related, the connection to the May 1 incident the company had publicly called contained, or the implication for customers managing live exams.

Decision 7: The “Scheduled Maintenance” Framing

At approximately 4:20 PM Eastern on May 7, 2026, the ShinyHunters defacement was replaced on Canvas login pages by a Canvas-branded page reading: “Canvas is currently undergoing scheduled maintenance. Check back soon.” The replacement message was, on its face, inconsistent with the operational facts. The platform was not in scheduled maintenance. The platform was in an active criminal extortion event. The substitution was visible to millions of students at thousands of institutions during finals week.

The May 7 framing has now been retired by Instructure. The company's incident update FAQ describes the May 7 events as the unauthorized actor making changes to the pages that appeared when some students and teachers were logged in through Canvas. The walk-back is in the public record. It was not accompanied by any acknowledgment that the May 7 framing had been issued. Cloudskope characterized the May 7 framing in its May 7 analysis as a misrepresentation. That characterization has not been disputed by Instructure. This is, in the narrow sense relevant to this piece, the most clearly documented gap between what the company said and what the company knew. The company knew at 4:20 PM Eastern on May 7 that the platform was in an active criminal extortion event. The company chose to characterize the situation as scheduled maintenance. The two are not reconcilable.

Decision 8: The May 11 Statement of Apology

On May 11, 2026, Instructure's CEO issued a public statement of apology, stating in part: “You deserved more consistent communication from us, and we didn't deliver it. I'm sorry for that.” The May 11 apology is the company's first direct acknowledgment that its incident communications during the response period did not meet a standard the company itself recognizes. The apology does not specify which communications were inadequate. It does not retract any specific prior statement by name. It does not acknowledge the May 2 containment claim, the May 6 resolution claim, the May 7 scheduled-maintenance framing, or the non-disclosure of the September 2025 precedent. A statement of apology that does not name what is being apologized for is incomplete. The May 11 statement is partial acknowledgment. The remainder is in the public record.

Decision 9: The Ransom Payment Decision

On May 12, 2026, Instructure publicly stated that it had reached an “agreement” with the unauthorized actor and that the actor had agreed to delete the stolen data. The company did not confirm whether a ransom was paid. Inside Higher Ed and BleepingComputer reported that the agreement was, in effect, a ransom settlement. Extortion groups do not generally agree to delete stolen data and remove victims from leak sites without payment of some form.

The decision to pay a ransom is a business judgment that may be defensible under conditions of duress. The FBI's standing public guidance opposes payment. We do not, in this piece, argue that Instructure's decision to settle was the wrong decision. The company was operating under duress in finals week with thousands of institutional customers actively affected. Reasonable parties could disagree about whether to pay. We note instead that the decision was made by a company that had, four days earlier, publicly characterized the platform as undergoing scheduled maintenance. The trajectory from May 2's “contained” to May 6's “resolved” to May 7's “scheduled maintenance” to May 12's “agreement” is not the trajectory of a company that had the situation under control. It is the trajectory of a company adapting to facts that had outrun its public posture.

Decision 10: The “Digital Confirmation of Data Destruction” Framing

In its May 12 announcement of the settlement, Instructure stated that it had “received digital confirmation of data destruction (shred logs)” from the threat actor. We pause here because the phrase requires technical analysis. Digital confirmation of data destruction is not, in any technical sense available to us, a verifiable claim about exfiltrated data. The data was on the attacker's infrastructure for at least seventeen days between exfiltration and the May 12 settlement. The attacker had time to copy, mirror, archive, or sell the data to third parties. Shred logs are records produced by the entity claiming to have destroyed the data. They are not independently verifiable.

A criminal actor's signed attestation that they have destroyed the data is exactly as reliable as a criminal actor's signed attestation regarding any other matter. The phrase describes a claim made by the threat actor. It does not describe a forensic state that Instructure or any third party can verify. Instructure's customers — institutions that hold legal and ethical obligations to their students and families regarding the destruction of personal data — were, by the May 12 framing, being asked to accept the attacker's word that the data had been destroyed. The framing was reassurance. The technical content of the framing was the attacker's account. Trust, but verify applies here too: the institution that accepts the May 12 settlement framing at face value has, in effect, accepted the threat actor's word.

Part IV — The Pattern

We have walked through more than two dozen points of public record across nine months. Some are warning signs that preceded the breach. Some are decisions during the four-day dwell period when the company was unaware an attacker was inside. Some are response decisions during the public phase of the incident.

The methodological finding is consistent across all three phases: Instructure's own publications do not reconcile with what the company has subsequently had to acknowledge. The September 2025 Salesforce compromise is in the public record but is not referenced in Instructure's April–May 2026 communications. The four-day dwell time is in the public record but is not acknowledged in Instructure's timeline. The CrowdStrike rollout language on the company's own incident page suggests EDR was not deployed network-wide before the response, yet the SOC 2 Type II renewal four months earlier was issued with no indication of that deployment gap. The May 2 “contained” claim, the May 6 “resolved” claim, and the May 7 “scheduled maintenance” framing were each issued during a period in which, by the threat actor's own subsequent account, negotiations were being attempted and ignored. The May 12 “digital confirmation of data destruction” framing describes a verification posture the technical facts cannot support.

Cloudskope wrote on May 7: “Penn was the named target. Instructure was the mechanism.” That framing has been borne out. The full sequence — September 2025 Salesforce compromise, the Penn extortion campaign through March 2026, the April 2026 Canvas compromise, the May 2026 escalation and settlement — describes an eight-month operation by a single threat actor against a single vendor environment. We extend the May 7 framing now, with the benefit of two weeks of additional record: the first compromise was the proof of concept. The April 2026 incident was the production run. The May 12 settlement was the operational ratification of a playbook that worked.

What Every CISO Should Read From This

This piece does not end with a moral conclusion. It ends with a methodology. Trust, but verify is older than this incident; it is older than this industry. What is new is the volume of vendor self-attestation that organizations now rely on for security assurance — SOC 2 reports, ISO certifications, trust centers, security pages, marketing-tier security overviews. Each of these is a form of vendor self-portrait. None of them is independently verified continuously. All of them assume that the picture the vendor paints of itself in the audit period is the picture that holds during the next breach. The Canvas incident teaches that the picture and the breach do not always match.

The CISO running vendor diligence today, on every vendor in the stack, should be asking three questions. They are not new questions. They are the questions this incident demonstrates have material consequences when not asked.

First. What does the vendor's most recent SOC 2 Type II describe as its EDR posture, its monitoring posture, and its incident response posture, and is that posture unchanged today? A vendor that has recently rolled out major tooling as part of a breach response has, by definition, changed posture since the audit. The certification is not invalidated, but the posture being certified is now stale.

Second. What does the vendor's most recent public statement about its security posture say, and does it reconcile with the vendor's most recent public acknowledgment of any incident? Two publications by the same vendor that do not reconcile are not, on their face, evidence of dishonesty. They are evidence of a question that needs to be asked. The vendor is in the best position to answer.

Third. When was the vendor's most recent incident, and how did the vendor's public communications during that incident map onto what the vendor has subsequently acknowledged? A vendor whose May 2 containment statement was defeated by May 7 attacker activity is a vendor whose containment claims, generally, carry less evidentiary weight. The historical track record of public statement against subsequent acknowledgment is a directly relevant input to vendor risk assessment.

These are not exotic questions. They are the questions any auditor, any general counsel, any board member would ask if they were doing the work. The Canvas incident is the worked example of why they need to be asked.

What Comes Next

The Canvas incident is not closed. The federal class actions, the House Homeland Security Committee briefing requested by May 21, the COPPA exposure under the updated rule, and the ongoing question of whether the threat actor has in fact destroyed the data all remain open. We will write again as the public record develops.

The structural conditions revealed by the Canvas case are not specific to Instructure. The vendor incident-conduct standard that this analysis implies is needed — and that no major industry body has published — is the absence the piece points toward. Cloudskope is preparing a draft standard for vendor incident conduct, which we will publish for industry comment in the coming weeks. The standard will codify expectations across five domains: temporal honesty, the question of when claims like “contained” and “resolved” may be made and on what evidence; linguistic honesty, the language of incident communications; attestation honesty, the standard for claims like “digital confirmation of data destruction”; communication cadence, the minimum frequency and content of incident updates; and ransom-related disclosure, the standard for communicating ransom-related decisions to customers. The Canvas case is the catalyzing example. The pattern it reveals is not unique to one vendor.

We will publish the draft standard as version 0.1, invite industry contribution, and iterate publicly. That is how standards work when they are written by people who have read the record carefully and are willing to be wrong in public. The presence of such a standard will not prevent the next breach. It will give customers the language to ask better questions, and vendors the language to answer them honestly.

For now, the immediate action available to every reader of this piece is the methodology demonstrated above. Read your vendors' own publications. Read them against each other. Read them against the public record of their incidents. Where the documents do not reconcile, ask the vendor to reconcile them. Trust, but verify.

Related Reading

Cloudskope, May 7, 2026: 275M Users Exposed in Canvas/Instructure Breach — the original Cloudskope analysis cited by KrebsOnSecurity.

Cloudskope Breach Library: Canvas/Instructure Breach 2026 — the factual reference companion to this analysis.

Cyber & IT M&A Due Diligence and Cyber Risk Assessment — the Cloudskope practices that apply the methodology in this piece. Cloudskope advises private equity sponsors, mid-market companies, and boards on cybersecurity due diligence, incident response, and standards-level questions. This piece is part of the After the Breach series.