This is the second of two posts on the Instructure Canvas data breach. The first post, “The Breach Instructure Saw Coming (And What It Means for the Rest of Us),” covers the ShinyHunters attack history, the full breach timeline, the extortion campaign, and what institutions should be demanding from their EdTech vendors. Start there if you want the full picture. This post is about what you do with what’s in your own hands.
Instructure confirmed that ShinyHunters breached Canvas, exposing student names, email addresses, messages, and student ID numbers across potentially thousands of institutions worldwide. Within 24 hours of declaring the incident contained, a second intrusion hit the platform mid-finals, taking every Canvas instance globally offline. Schools canceled exams. Faculty scrambled. Students who had done nothing wrong paid the price for a security failure that happened well above their pay grade.
And then Instructure reached an “agreement” with the people who did it. Data reportedly returned. Copies reportedly deleted. The company hasn’t disclosed what that agreement cost. What I can tell you is that it won’t be absorbed quietly. Whatever was paid will redistribute through contract renewals, pricing, and investment decisions that Canvas institutions will encounter down the road. The students and institutions affected by this breach will pay for it more than once.
If you’re a Blackboard admin reading this, you may feel like a spectator to someone else’s crisis. I’d encourage you to resist that feeling.
You cannot control what your vendors do, but you have more control over your own house than you might think. The Canvas situation is a vivid illustration of something every LMS administrator knows in the abstract but rarely has urgent cause to act on: the security of your institution’s learning environment is only partly a vendor problem. The rest of it is yours. And if this week didn’t make that real, I’m not sure what will.
Let’s talk about where Blackboard stands, and then let’s talk about what you can do today.
Blackboard’s security posture is worth understanding before you need it.
Before I get to the checklist, I want to spend a moment on Blackboard’s own security program. Not as marketing copy, but as a baseline for what your institution should expect and be actively verifying.
Blackboard publishes its security program in meaningful detail through its Trust Center, and the documentation is more substantive than you’ll find at many comparable vendors. The program is aligned to NIST standards and holds ISO 27001 certification for information security management, along with ISO 27701 for data privacy and ISO 27017/27018 controls specific to cloud service providers. Several Blackboard products complete annual SOC 2 Type 2 examinations. Blackboard also actively maintains current HECVAT responses, the Higher Education Community Vendor Assessment Toolkit from EDUCAUSE that many of my colleagues rely on in procurement and security review processes.
On the development side, Blackboard applies security engineering guidelines derived from several organizations. The alphabet soup of acronyms can leave any admin confused, so here’s a brief explanation of each. The Open Web Application Security Project (OWASP) across its entire software development lifecycle. If you’re not familiar with OWASP, think of it as the industry’s most widely referenced roadmap for building software that doesn’t get compromised in embarrassing ways. Their “Top Ten” list (the ten most critical web application security risks) is essentially the required reading list for development teams. Blackboard specifically builds countermeasures for those Top Ten risks into its development process, which means the known, well-documented attack vectors are being addressed at the code level before the software ever reaches your institution.
Beyond OWASP, Blackboard references the National Institute of Standards and Technology, or NIST. NIST publishes the gold standard for cybersecurity risk management; it’s the framework that federal agencies are required to follow and most serious enterprise vendors use as their baseline. The SANS Institute produces the most widely respected security training and research in the industry; their guidelines are written by practitioners, for practitioners, which is why they carry real weight. The Center for Internet Security (CIS) publishes specific, prescriptive benchmarks for hardening systems and platforms. Their focus is less “here are principles to consider” and more “here is exactly how to configure this securely.”
Why does any of this matter to you as an administrator? Because when a vendor says they “follow industry best practices,” that phrase means absolutely nothing. It’s the security equivalent of saying food is “homemade.” These frameworks (NIST, SANS, OWASP, CIS) are the specific, auditable, publicly available standards that give those words actual meaning. A vendor that can point to them by name, explain how they apply them, and back it up with SOC 2 Type 2 reports and third-party penetration testing results is a fundamentally different conversation than one handing you a glossy one-pager with a padlock icon on it. Blackboard performs both internal static analysis (reviewing the code itself for vulnerabilities before it ships) and dynamic analysis (testing the running application for weaknesses), and supplements that with outside penetration testing from third-party security vendors. That layered approach — internal review plus external challenge — is what responsible security practice actually looks like in execution.
The test, as always, is execution. Having the right frameworks documented and consistently operationalizing them are two very different things. The Canvas situation is a sharp reminder of that gap. I’m not saying Blackboard has that gap. I’m saying no one should assume they don’t, and the best way to close the assumption is to verify. Use the HECVAT. Request the SOC 2 Type 2 report. Ask specific questions. That’s not adversarial. It’s responsible institutional stewardship.
Five things you can do today.
These are not aspirational items for your Q3 security roadmap. These are things you can do this week. Some of them take ten minutes. None require a change management process or a budget request.
1. Change your system administrator password. Right now, if you haven’t recently.
This is foundational to the point of being embarrassing to mention, and yet I keep encountering institutions where the Blackboard admin account password was set during implementation and has never been rotated. The Illuminate Education breach was enabled in part by credentials from an employee who had left the company three years prior. Three years. The account was still active. The credentials still worked.
Set a rotation schedule, document it, and follow it. If your institution has a password policy for privileged accounts, your Blackboard admin credentials should be subject to it. If there isn’t a policy, build one.
2. Audit and rotate your REST API keys and secrets.
Every active integration in your Blackboard instance has a corresponding REST API application with a key and secret. When was the last time you looked at that list? Pull it up right now and ask yourself three questions for each entry: Is this integration still in active use? Who created this application, and are they still at the institution? When were the key and secret last rotated?
A REST integration tied to a departed employee’s personal development account is a real risk sitting quietly in the background of more Blackboard environments than most people would like to admit. Audit the list, remove anything no longer active, and rotate keys for everything that is. While you’re in there, check that each application carries the minimum necessary entitlements. If an integration doesn’t need system-level access, it shouldn’t have it.
3. Pull a full list of accounts with system roles and audit every one.
Open your Blackboard Administrator Panel, go to Users, and filter for accounts carrying system-level roles: System Administrator, System Support, and any custom roles your institution has created with elevated privileges. How many are there? Do you know who all of them are? Are any tied to former employees, former contractors, or former vendor support staff?
This audit should happen at minimum once per semester and should be embedded in your off-boarding process. Elevated role accounts are the highest-value targets in your environment. Every account belonging to someone who no longer needs access is an unnecessary open door.
4. Disable inactive user accounts on a defined schedule.
Set a policy that defines what “inactive” means for your institution (90 days, 180 days, whatever fits your academic calendar) and enforce it consistently. Inactive accounts that retain valid credentials are one of the most common and most preventable attack vectors in enterprise systems.
If you don’t currently have an automated process for this, consider building one through a scheduled data source integration or a scripted API call against the Blackboard REST APIs to identify and disable accounts that haven’t logged in within your defined threshold. At minimum, do a manual audit now and put a recurring item on your calendar to repeat it.
5. Enable Single Sign-On, or enable two-factor authentication for administrative accounts.
This is the single highest-leverage change most Blackboard institutions have not fully implemented, and the one I think about every time I see a breach involving credential theft.
SSO is the better solution. It moves authentication entirely under your institution’s identity management system, centralizes your audit trail, and ensures that Blackboard accounts are automatically suspended when an employee is off-boarded through your IdP. If your institution isn’t there yet, that conversation belongs on the priority list with your identity management team, not in a future planning backlog.
If full SSO implementation isn’t immediately in reach, enable two-factor authentication for administrative accounts as a bridge measure. The cost of setup is low. The protection is meaningful. A compromised admin password is a far less catastrophic event when the attacker also needs a second factor tied to a physical device your former employee no longer has.
None of this makes you immune. Security doesn’t work that way, and anyone who tells you otherwise is selling something. What these five steps do is meaningfully reduce your attack surface, close the most common credential-based attack vectors, and demonstrate to your institution’s leadership and accrediting bodies that you are operating with intentionality rather than optimism.
The Canvas breach is a cautionary tale about what happens when a vendor is caught underprepared by an adversary that had already identified them as a target. The “agreement” that followed is a cautionary tale about what that unpreparedness ultimately costs, and the fact that institutions absorb more of that cost than the vendor ever will. Your job as a Blackboard admin is to make sure your institution’s exposure is as limited as possible, and that you did everything in your power to limit it before anything happened.
That’s what we do.
Technically Yours,
The Blackboard Guru
