Was this forwarded to you by a friend? Sign up, and get your own copy of the news that matters sent to your inbox every week. Sign up for the On EdTech newsletter. Interested in additional analysis? Upgrade to the On EdTech+ newsletter.

Eleven days ago, I argued that Instructure was treating a vendor-level security crisis primarily as a status-page incident, and that the absence of any named executive owning the response — no equivalent of Josh Coates's 2012 "we are embarrassed, we are sorry, we will do better" — was eroding trust faster than the breach itself. Yesterday's customer-focused "Technical Deep Dive on Recent Security Incident" webinar was the company's most substantive public-facing communication to date. It also confirmed, in nearly every choice of format and phrasing, that the playbook has not changed.

The technical content was genuine, but the framing was lawyered and carefully read by script. And the people on screen — Chief Architect Zach Pendleton, CISO Steve Proud, and CrowdStrike incident response head James Perry — were, conspicuously, still focused only on the technical platform.

The webinar ran roughly twenty-five minutes, with a same-day rerun and a next-morning replay for customers who could not attend live. The short, tightly-produced format was itself the message: this is being handled as an engineering problem.

To Instructure's credit, the company was explicit up front about the scope it had chosen.

That is not bait-and-switch, as the description and target audience design was accurate. My disagreement is with the underlying scope choice and the message control.

Pendleton named one of the most important constraints at the top of the session, namely that due to a lot of attendees they would not be able to take live Q&A. But they promised to address some of the questions that had already been submitted prior to the webinar.

What followed was Pendleton asking a set of pre-selected questions, with Proud answering from prepared material. Other questions went into the webinar's Q&A function for later triage on the incident update page.

Credit where it's due: the technical narrative was more detailed than anything Instructure has put in writing so far.

Both recent hacking events originated from the Free-for-Teacher tier, and both relied on stored cross-site scripting payloads (a linked file with hidden code) submitted via support tickets. The April 22 payload sat dormant until April 25, when a customer service representative opened the ticket; the code then executed in the rep's authenticated session and the threat actor used those elevated privileges to obtain data via Canvas's APIs between April 28 and April 30. Instructure detected the activity on April 29 and revoked access by April 30. The May 7 event was a second cross-site scripting vulnerability — this one in the Canvas discussion feature — exploited via a different code path and used to push a CSS file through the custom themes feature, deploying the ransom note to roughly 300 accounts before Canvas was placed in maintenance mode that afternoon.

The remediation was organized into three tiers — access and authentication hardening (additional multi-factor authentication checkpoints, disabling OAuth token generation via JavaScript, an Okta reauthentication framework for customer-account access), platform and web security controls (the cross-site scripting fixes and consolidated sanitization), and threat detection (CrowdStrike Falcon across the Canvas platform, behavioral alerting tied to the specific tactics observed). Free-for-Teacher is being reinstated in what Proud called a "secure limited capacity" with all administrative and support functionality stripped out.

That is real and useful information, and IT teams will be able to do something with it. The webinar earned the "technical deep dive" half of its billing.

The "crisis response" half is where the gaps are.

The most consequential admission in the webinar was understated. Proud described that the second exploit “allowed the threat actor to sidestep our earlier fix.”

Instructure publicly told customers on May 6 that Canvas was fully operational and there was no ongoing unauthorized activity, a message that I flagged in my earlier post as not holding up to reality. By the next day, the related-but-distinct cross site scripting path — one that survived the May 1–5 remediation work conducted with CrowdStrike already engaged — was exploited successfully enough to deploy the ShinyHunters ransom note across roughly 300 accounts.

The technical question this raises is not whether Instructure fixed the specific vulnerability they found first. The question is whether they did proper variant analysis on that vulnerability — looking for sibling bugs, related token-generation flows, the same class of issue in other surfaces — or whether they shipped a narrow patch and called it done. The May 7 outcome suggests the latter. The webinar did not address it as a process failure. It treated the second vulnerability as a separate event with its own timeline rather than as evidence that the first remediation was incomplete.

The webinar discussed two attack events — April 22/25 and May 7. It did not discuss the third.

ShinyHunters publicly took credit for a September 2025 social-engineering breach of Instructure's Salesforce instance, well before either of this spring's Canvas exploits. Outside reporting has tied that earlier incident to the same threat actor now claiming the Canvas breach. The webinar did not name ShinyHunters, did not reference the September 2025 incident, and did not characterize what is now at least three publicly known compromise attempts as a pattern of repeated targeting.

There may be sound legal reasons to avoid naming a threat actor under active forensic and law-enforcement engagement. There is no equally sound reason to omit the recurrence framing entirely. A customer hearing this webinar with no outside context would conclude they were learning about two inter-related bounded incidents. A customer who has read the trade press would conclude that the company is presenting an incident timeline while declining to acknowledge the broader recurrence problem. Those are very different positions for a vendor to be putting its customers in.

The webinar's clearest treatment of the Canvas partner ecosystem came as a side note in Proud's brief comment about expanding the company's web application firewall (WAF) coverage.

That is a meaningful admission. The integration layer — LTI tools, embedded apps, the customizations institutions and partners build on top of Canvas — is constraining how aggressively Instructure can lock down the application surface, and those tradeoffs are still being negotiated. LTI was not the attack vector. But it is in scope for the remediation work in a way the webinar otherwise did not engage.

What the webinar did not address: whether LTI-based integrations could have been exploited to access integrated applications; whether the proactive cycling of "many partner tokens" was precautionary or evidence-driven; whether integrated apps got any guidance beyond the generic log-review recommendations. Perry's "no lateral movement" finding from CrowdStrike narrows the blast radius within Instructure's product portfolio. It does not clear the partner ecosystem, and the webinar made no attempt to.

That ongoing gap in communication — not just from the webinar — has led to third-party integration vendors absorbing the customer-education work in Instructure's place. The security models for LTI 1.1 and LTI 1.3 are fundamentally different: 1.1 uses shared consumer keys and secrets between the LMS and the tool; 1.3 uses OAuth 2.0 with asymmetric public/private key cryptography. LTI 1.3 integrations generally do not require token rotation in response to an LMS-side incident the way 1.1 integrations do. Those are distinctions Instructure was in the best position to communicate. Many customers received generalized security language and credential-rotation guidance that did not draw the line, which then generated token rotation requests against tool vendors for whom rotation was not technically meaningful. Tool providers ended up producing the practical 1EdTech standards education the original communications should have included — migration guidance from 1.1 to 1.3, customer reassurance, and weeks of explanation about why a Canvas breach did not require their 1.3 customers to do anything.

The most striking omission was not technical at all. Across twenty-five minutes of webinar, Instructure said nothing about academic continuity. Nothing about students who could not access assignments. Nothing about finals that were pushed back.

This is the breach's actual customer-facing impact, and the webinar treated it as out of scope.

Some of that silence has a legal explanation. Acknowledging operational harm in detail before potential lawsuits creates discoverable admissions. But the harm is already documented in public — by the institutions themselves, in their own crisis communications, in trade and general press coverage. I do not believe that declining to acknowledge what is already on the public record meaningfully reduces litigation exposure. It does meaningfully reduce trust. That asymmetry should drive the comms strategy, and it visibly is not.

The most-repeated scripted phrase across the webinar was "no evidence" — and it was almost always positioned defensively. No evidence of employee credentials before cycling, lateral movement out of Canvas, data exfiltration from the May 7th breach.

In each case the statement was most likely true and is genuinely useful for customer log analysis. But "no evidence of X" is not the same as "X did not happen," and the cumulative effect of stacking those phrases through a twenty-five-minute session is to leave customers with a sense of reassurance the underlying facts do not quite support. That is also lawyer-vetted construction. It is what you say when discovery is still alive and class actions are foreseeable.

The Chief Architect fronted both customer-facing webinars. Within that role, the briefing fit — the agenda was the architecture and the controls, and the briefing delivered competently against both. But putting the Chief Architect at the center of two consecutive crisis communications, rather than adding a non-technical member of the executive team, is itself an organizational signal.

The CISO scope is the harder case. The security section was substantive within the traditional CISO mandate — attack path, containment, hardening, monitoring, no-lateral-movement, token controls — but the traditional CISO scope is itself part of the issue. A modern CISO at a platform company whose customers are public institutions in the middle of finals does not get to treat customer operational impact and ecosystem trust as someone else's department. If the role as defined inside Instructure stops at the Canvas platform perimeter, that role definition is a problem the company will need to address regardless of how this specific incident closes out.

And the broader scope-of-response gap is bigger than any single role. A Canvas-scale breach is not a security event with academic, operational, and partner external consequences attached. It is a platform crisis composed of academic, operational, partner, and security dimensions. Treating the security dimension as the public face of the response leaves the other three effectively unaddressed. To my knowledge there is no parallel webinar for academic-continuity contacts. There is no parallel briefing for LTI partners. There is no acceptance that the company missed its own May 6 resolution claim, that the response is following a pattern of repeated ShinyHunters targeting, or that institutions carried the public explanation through the worst week.

There is concrete evidence of how this gap is playing out. Institutions did not turn Canvas access back on when Instructure said it was ready on May 6. Many waited days; some waited longer. Some required their own internal validation before allowing students back in. Others appear to have been operating on the assumption that the vendor's all-clear was incomplete — or that they simply did not have the information they would have needed to validate it on their own.

Ecosystem partners describe the same gap from their side: they did not get the information they needed from Instructure either, and several have told me as much. When customers and partners are independently signaling that the company's response did not include them, the response architecture is not working. Customers and partners are not adversaries in a security incident; they are participants in it, and they need to be treated as such. The choice to communicate at them rather than with them is the most concrete signal yet that the company needs to include both groups in how it handles security issues going forward.

The webinar was useful for what it was: a substantive technical briefing for IT teams, delivered with appropriate forensic backing, on what happened and what was done about it. And a clear improvement over earlier communications.

It is insufficient as a crisis response.

What the comms posture across this week suggests is a company optimizing for litigation exposure — narrow claims, careful "no evidence" phrasing, script reading, no acknowledgment of recurrence or ecosystem risk or academic continuity — when the more consequential threat is to institutional trust. For a vendor whose moat is built on being the academic operating layer that institutions can rely on, that is the wrong optimization. The litigation will be defended either way. The trust, once lost, is much harder to argue back.

The main On EdTech newsletter is free to share in part or in whole. All we ask is attribution.

Thanks for being a subscriber.