Before You Add Any Tool to Your Fall Stack: 4 Vendor Security Questions the Canvas Breach Made Necessary¶
Last updated: July 29, 2026
On May 1, 2026, Instructure disclosed that Canvas had been breached. By then, the attackers had already been inside for six days.
The numbers in the disclosure were staggering: 275 million records. 3.65 terabytes of data. Names, email addresses, student identification numbers, and private messages between students and teachers, pulled from roughly 9,000 institutions across 50 countries. The U.S. Department of Education's Federal Student Aid office issued an emergency security alert on May 12 and had to update it on May 29 as the scope of the incident expanded.
Canvas is the single most widely used LMS in U.S. higher education. At the time of the breach, 41% of U.S. colleges and universities ran it. It is a large, well-funded, professionally operated product. And yet.
I am not writing this to relitigate what happened at Instructure. What I want to do is sit with the assumption that most of us carry when we evaluate an EdTech tool: well-known platform, established company, lots of users, must be reasonably safe. That assumption held for Canvas. Then it did not.
If you are building or refreshing your fall tech stack right now, the Canvas breach is useful information. Not because it should stop you from using digital tools, but because it surfaces a specific set of questions that are worth asking of every vendor before you hand them your students' data.
Thinking through your fall tool lineup? NavEd stores student records inside your school's isolated data environment. Your first five students are always free. See how it works
What the Breach Actually Revealed¶
A few details from the Canvas breach are especially useful for thinking about vendor risk:
The entry point was a low-trust account type. The initial compromise on April 25 came through Free-For-Teacher accounts, a no-cost Canvas account type commonly used outside enterprise-managed environments. These accounts did not have multi-factor authentication enforced. A large school district running Canvas under an enterprise contract had presumably negotiated security requirements. Free users in the same data environment had not. The breach exploited that gap.
The data exposed was not the most sensitive kind, but it was still consequential. Instructure confirmed that no passwords, birth dates, Social Security numbers, or financial information were involved. What was involved: names, email addresses, student ID numbers, and private messages between students and teachers. Those private messages are worth pausing on. A student's conversation with a teacher about struggling in a class, or a parent's message about a family situation, is now in someone else's hands. The legal exposure may be limited. The real-world impact on those students and families is not.
Named K-12 institutions affected included Orange County Public Schools in Florida, Arlington Public Schools in Virginia, and San Diego Unified School District in California, among others.
The FSA alert specifically called out FERPA implications. The Department of Education's Federal Student Aid office noted that some of the exposed messages may have incidentally included personally identifiable information, and requested information from Instructure about FERPA compliance. Small private schools that are not themselves subject to FERPA still use tools whose data practices are now under federal scrutiny.
None of this means Canvas was a reckless choice. It means that when a vendor holds data from 9,000 institutions on shared infrastructure, the blast radius of a single breach is enormous. That is a structural fact about how shared platforms work, not a moral judgment about any vendor's intentions.
The Mental Model Worth Updating¶
Here is the mental model most of us carry: if a tool is used by thousands of schools, it has been vetted by thousands of IT departments, and that vetting is a form of collective safety.
That logic is not wrong, but it is incomplete. When thousands of schools use the same platform, a single successful breach touches all of them simultaneously. The size that suggested safety becomes the mechanism of scale.
For a microschool founder, the more useful question is not "how many other schools use this?" but "if this vendor got hit, exactly what would the attacker get about my students?"
That is the question the four sections below are designed to help you answer before you sign anything.
Four Questions to Ask Any Vendor Before Signing Up¶
These are questions you can put directly to a vendor before committing to their platform. For the most important tools, ask them in writing and keep the responses. A vendor's willingness to answer clearly is itself informative.
Question 1: What student data do you actually store, and for how long?¶
This sounds obvious. It often is not. Many vendors collect more data than the core function requires, retain it longer than the service period, and store it in ways that are not immediately visible from the product interface.
Ask the vendor to name, specifically, every category of data they store about students. Then ask how long they retain each category after a student stops using the product.
What you are looking for: a vendor who has genuinely thought about data minimization will be able to answer this specifically. They will tell you that they store names, emails, and enrollment status, and that they delete student records within 90 days of contract termination. A vendor who has not thought about this will answer vaguely: "We store what is necessary to deliver the service" or "We keep records in accordance with applicable law." Those answers tell you they have not built minimization into their architecture.
The Canvas breach exposed messages between students and teachers. Those messages were a feature, not incidental data. A vendor who stores rich student interaction data to power their product is making a deliberate architectural choice. That choice increases the exposure if they get hit.
The question to send: "Can you give me a complete list of the specific data categories you store about my students, and the retention period for each after our contract ends?"
Question 2: How quickly will you tell me if you are breached, and what exactly will you tell me?¶
This question has a factual answer that varies significantly by vendor and by jurisdiction. In the Canvas breach, Instructure disclosed the incident on May 1, six days after the initial compromise on April 25. Many state laws require breach notification within 30, 60, or 72 hours. Some require notification to the school; some require notification directly to affected individuals.
Ask the vendor directly what their breach notification commitment is, and get it in writing. The answer you are looking for includes: a specific time window from detection to notification, a commitment to tell you what specific data was involved (not just "some user data"), and a description of how they will communicate with affected families if student data is compromised.
If a vendor cannot tell you their notification window, or if the answer is "in accordance with applicable law" without specifics, you are looking at a gap. "Applicable law" means different things in different states, and for small private schools without federal funding, the legal notification obligations may be minimal even when the practical impact is significant.
The practical reality: if your students' data is in a vendor's system when they get breached, and you learn about it from news coverage before hearing from the vendor, you are going to have a very difficult conversation with your families. Knowing the notification window before you sign up means you know what to expect and can plan accordingly.
The question to send: "What is your specific breach notification timeline, measured from detection? What categories of information will your notification to us include? Will you notify affected students and families directly, or is that our responsibility?"
Question 3: If one of your other customers gets compromised, can that affect my school's data?¶
This is the multi-tenant isolation question, and it is the one most microschool founders never think to ask.
Many EdTech platforms serve thousands of schools on shared infrastructure. The efficiency gains are real: shared databases, shared application servers, shared storage. If those shared systems are properly designed, data from one school is completely isolated from data belonging to another school. A breach that starts at School A should not expose data from School B.
But isolation is not automatic. It requires specific architectural choices. And the Canvas breach demonstrated what happens when a free-tier account type lacks the same security controls as paid accounts on the same platform.
Ask the vendor how they isolate data between customers. You are not looking for a technical architecture lecture. You are looking for a vendor who can describe, clearly and simply, why a compromise in another customer's environment cannot reach your data.
Some vendors use what is called schema-level isolation: each school's data lives in a completely separate database partition that other customers cannot access even if they find a vulnerability in the application layer. Others rely on application-level isolation, where a single database serves all customers and the application code enforces the separation. Both can be done well. Both can be done poorly. A vendor who cannot explain their approach has not thought about it.
The question to send: "If one of your other customers experiences a security incident, how does your architecture ensure that my school's data is not affected? Can you describe the isolation mechanism in plain terms?"
Question 4: Do your free-tier or trial accounts have access to the same data infrastructure as paid accounts?¶
The Canvas breach entered through Free-For-Teacher accounts. Those accounts existed in the same data environment as institutional contracts, without the same security requirements. That is the structural vulnerability.
This matters for you as a paid customer. If a vendor offers a free tier, a teacher trial, or any kind of open-access account type that sits alongside your paid account on the same infrastructure, you inherit some of the risk from those lower-trust accounts.
Ask the vendor directly whether free or trial accounts share infrastructure with paid accounts. Ask whether all account types, regardless of tier, are required to use multi-factor authentication. Ask whether there are account types in their system that have access to the general platform data environment without full security requirements.
This question is also worth asking about your own account. If your school signs up and two teachers use the platform without MFA enabled, and the vendor does not enforce it, you have the same structural exposure on your own end.
The question to send: "Do your free-tier, trial, or teacher accounts share the same data infrastructure as paid accounts? Is MFA enforced across all account types, or is it optional? Are there any account types in your system that can access platform data without full security controls?"
What to Actually Do in the Next Two Weeks¶
If you are finalizing your fall tools now, here is how to use the four questions above:
Start with the tools that hold the most data. Your student information system, your LMS if you use one, and any communication platform where students and teachers exchange messages are the highest-priority targets. A quiz app that only collects scores has a smaller blast radius than a platform that stores student profiles, messages, and progress data.
Ask the questions in writing. An email or a form submission creates a record. A sales call does not. Vendors who answer quickly and specifically are signaling that they have thought about this. Vendors who deflect, offer to schedule a call, or respond with legal boilerplate are also signaling something.
Read the breach notification clause in your contract before you sign. Most vendor contracts include a notification provision buried in the data processing agreement. Find it. Note the window. Note what they are obligated to tell you versus what they will tell you at their discretion.
Decide what data each tool actually needs. You often have more control than you realize over what a vendor collects. If a platform asks for a student's birth date and your use case does not require it, do not provide it. If a messaging tool is available, consider whether your school needs platform-level messaging or whether you have an existing communication channel that works. Every data category a vendor does not have is a data category they cannot lose.
A Note on How NavEd Approaches This¶
Since this post is published on our site, it is worth being transparent about how we handle the questions above rather than just pointing them at other vendors.
NavEd uses schema-level multi-tenant isolation: each school's data lives in its own PostgreSQL schema, completely separate from every other school's data. A compromise in one tenant's environment cannot access another tenant's data at the application or database layer. It is not the only way to build a multi-tenant SaaS, but it is the choice we made specifically because it limits blast radius.
We retain student data for the duration of your active subscription plus a defined off-boarding window. We do not sell or share student data with third parties. Our breach notification commitment is 72 hours from detection to your admin contact, with specific data category disclosure.
I am telling you this not as a sales pitch but because the questions above should apply to us exactly as they apply to any other vendor you are evaluating. If any of our answers are not satisfactory, that is information worth having before you sign up, not after.
Related Reading¶
If you want to go deeper on the compliance side of vendor evaluation, two posts that cover adjacent ground:
- COPPA 2026: The Vendor Audit Every Microschool Needs Now covers the FTC's April 2026 amendments: biometric data classification and third-party consent requirements that most EdTech vendors have not yet updated for.
- Student Data Privacy: FERPA for Small Schools walks through what FERPA does and does not require for small private schools and how state law fills the gaps.
The Canvas breach happened on the security side. COPPA and FERPA live on the compliance side. They are different questions with different answers, and both are worth working through before your fall cohort logs in.
Sources: FSA Partners Technology Security Alert, May 12 and May 29, 2026 | Ed Week: A Cyberattack on Canvas Could Cause Lasting Aftershocks for Schools | eSchoolNews: Will Schools Answer the Canvas Breach's Wake-Up Call? | Wikipedia: 2026 Canvas Data Breach