One day before fall semester began, the University of Texas at San Antonio told its students, faculty, and staff that classes wouldn’t start on time because the university detected “attempted unauthorized activity” at the edge of its network and, out of an abundance of caution, took a big chunk of its own systems offline. This might have included email, phones, registration web pages, payment deadlines, and more. Classes were postponed for three days. As of their last update (paywalled website), no evidence any data was actually stolen.
What concerns me isn’t the attempt at compromising university online infrastructure; that happens all the time. What made me furrow my eyebrows in concern was the fact that UTSA didn’t get breached, at least not that anyone has confirmed, yet they switched off access themselves. At the start of the term. Which stopped school from starting. In the InsideHigherEd article linked above, ransomware against higher ed is up more than eight percent year over year, and every Canvas LMS Admin knows things are getting worse. But the lesson from San Antonio isn’t about the attack that didn’t happen. It’s about the precaution that did.
This is something to think about before your own term starts, because if a potential attack happened to your institution tomorrow, most Admins may not be able to answer the big question: when the campus goes dark, does Canvas go with it?
“Canvas is up” and “Students can reach Canvas” are two different things
Here’s the problem. You check status.instructure.com, you see all green, and you move on with life. Instructure Canvas is up and running normally. Courses are available. No cause for concern.
But wait…that doesn’t mean your students, faculty, and staff can log in to Canvas.
Canvas authentication isn’t one specific URL like https://www.canvasinsider.blog. A school’s infrastructure might have “vanity URLs,” easy to remember web addresses that redirect to the school’s official login page for Canvas. These vanity URLs are managed by the school, and Instructure has nothing to do with this. When your campus takes systems offline “out of an abundance of caution,” it’s usually those vanity links that get disabled. Canvas is up yet unreachable at the same time, which is the worst of both worlds, because Instructure’s status page says everything is fine while your Canvas support inbox fills with students who can’t get in.
Authentication is the first, and worst, thing to break. Your students don’t just log into Canvas. They log into your institution’s identity provider, which then forwards them over to Canvas. Shibboleth, ADFS, SAML, Entra ID, Okta, whatever you run. If your IT administrators firewall off the IdP, or the IdP depends on a directory service that got isolated, or the single sign-on certificate lives on a server someone quarantined out of precaution, Canvas is a locked building with the lights on. Everyone can see it, and nobody can get in. Like a big-box retail store at 4:57 am, three minutes before the Black Friday sales open at 5 am. And here’s something not normally considered that will bite: the Canvas mobile apps authenticate the same way, so “just use the app” is not the default recommendation your helpdesk support staff can easily use at a time like this.
Enrollment sync is the second. Your school’s Student Information System feeds Canvas. If that integration pauses during an incident, the immediate damage is quiet, but it compounds like little bits of detritus clogging a sink drain. Enrollment add/drop stops flowing. The student who registered this morning isn’t in their course that afternoon. A day or two of a frozen SIS feed at the start of term is a support ticket nightmare that staff will be digging out of for a week after systems resume.
LTI tools are the third, and they fail independently. Your proctoring tool, your online book publisher content, your plagiarism checker each have their own auth handshake and their own vendor. An offline campus network can sever some connections and not others. So Canvas half-works, which is half-horrible, because it generates the most confusing and complex tickets of all: “my course loads but the quiz won’t open for me.”
Notifications are the quiet fourth. Canvas hands outbound mail to your SMTP relay or a campus-approved sender. Take email offline and Canvas keeps generating notifications launched into a void. Students don’t get the “your course syllabus quiz is due this Friday” message, instructors don’t get submission alerts, and the school loses its primary channel for telling everyone what’s going on. This brings up the real problem.
The communication plan fails for the systems it’s meant to explain
The cruelest detail in every one of these incidents? The methods an institution would use to tell people about the outage are often the tools that are down. If your emergency communication plan routes through campus email, and campus email is shut down, you have a emergency-outage-plan.docx file located somewhere on a Sharepoint site and nothing in practice.
UTSA got a statement out because someone had a communication channel that didn’t depend on the systems they’d just shut off. Do you? If your answer involves the phrase “we’d send an email,” you don’t have a plan, you have a crossed-fingers hope.
What to actually check before your term starts
This is a pre-flight checklist to have a few conversations with colleagues at your institution this week while things are still quiet.
Break-glass admin access. Do you have at least one Canvas admin account that can authenticate locally, independent of your SSO? My institution does. I have a back door into the system for those just-in-case situations. If your only path into Canvas is the same IdP that just went down, you can’t even manage the outage. Test it. Then store the credentials somewhere that isn’t behind systems that might go offline.
Know your auth failure mode. Sit down with your IdP team and ask the literal question: if you isolate the identity provider during an incident, what happens to Canvas logins?
Map your LTI blast radius. List every external tool connected to Canvas, how do people authenticate to it, and does it survive a campus network outage. The results might raise other conversations.
Confirm your SIS sync recovery. If the integration pauses for 48 hours, how do you catch up, and how long does the backlog take to clear?
Build a non-standard communication protocol. Find a way to reach students and faculty that does not involve campus email or intra-network systems. A status page on a third-party website, a social media account, an SMS service, or more. Also, decide now who’s authorized to post to it. Because meeting about this while an incident is happening is the wrong time to figure out who has the username, password, and the MFA authenticator app on whose phone.
Write down the decision tree. Who declares an incident impacting Canvas? Who liaises with Instructure? Who creates and posts the targeted messaging to students, faculty, and staff? UTSA moved fast because somebody had already answered these questions. Decisions made on a calm, quiet Tuesday will be a better experience than at 6am on the first day of class.
My point isn’t to create a headache
I’m not telling you to expect an attack. I’m trying to articulate that even a precaution can mess up your Canvas experience. The industry spends its security budget on preventing the breach and restoring after it, and there is virtually nothing spent on the third aspect: maintaining access to services while the systems are off, on purpose or otherwise.
Your Canvas LMS is where that third aspect gets tested first, because Canvas is the second-most visible system on campus, email being the first, and the one online platform students notice within minutes because they are on Canvas many times during the day. When your campus goes dark, Canvas doesn’t have to go with it. It’s up to the plan your institution created, or didn’t, before the term began.
Draw the map. You’ve still got time.