What happened and why it matters for every institution running an LMS
A major, widely used education technology platform has been compromised. Early reports suggest student and staff data may have been exposed, including personal information and user messages, although the full scope is still emerging.
This is not an isolated incident. It is part of a pattern. And it should make all of us in the sector pause and think carefully about how learning platforms are delivered, governed and trusted.
For years, large proprietary SaaS vendors, many of them venture-capital-funded, have argued that open source LMS platforms are too risky, too complex, or poor value compared with their own enterprise clouds. This latest breach underlines a different reality.
I understand why the SaaS message lands. Institutions want confidence. They want stability. They want the technological burden removed so educators and internal teams can focus on what matters. I couldn’t advocate more strongly for that outcome.
But the question worth asking now is whether a large centralised SaaS model is actually the lower risk choice or whether it simply moves the risk somewhere less visible until something goes wrong.
At Catalyst, our belief is that open source, ownership, control and governance give education institutions a stronger foundation. Not because open source removes every risk, no platform does, not Moodle, not Canvas, not anything. But because it gives institutions more freedom to inspect, shape and govern the systems they rely on.
No platform is perfectly safe. The real question is how much visibility, control and response capability an institution has.
Data segregation and sovereignty
The fundamental LMS security problem with most large SaaS providers is that they optimise for scale. That often means multi-tenant architectures with many institutions’ data pooled together, centralised identity and logging, and a single, massive attack surface. Attackers go where the data is centralised, and the reward is largest. When something breaks in that model, it breaks big.
Our managed Moodle services are designed around segregation and sovereignty as first principles. Each institution runs in its own logically and, where required, physically segregated environment. Compromise of one institution’s environment does not automatically expose others. Infrastructure, databases, storage and backups are isolated and governed according to each institution’s risk profile and regulatory requirements.
Institutions also choose where their data lives: region, jurisdiction and, where mandated, specific providers or sovereign infrastructure. Data flows, retention policies and cross-border transfer controls are implemented and documented in line with regulatory needs, GDPR, FERPA and local equivalents. The institution remains the data controller. We operate as a processor under their instructions, not as a black-box application vendor.
This doesn’t eliminate cyber risk. Nothing does. But it changes the shape of that risk. Instead of one giant monoculture, you have smaller, contained environments, governed with clear contracts, processes and oversight. That is a very different proposition from a model where millions of students’ records sit behind a single set of credentials.
Risk doesn’t disappear when you outsource everything to a single, centralised provider. In many cases, it concentrates.
Open source code is a security advantage
One of the strongest criticisms we hear from SaaS vendors is that open source is less secure because anyone can see the code. I’d argue the opposite. Transparency is a security advantage, not a liability.
With an open source LMS like Moodle, the full codebase is auditable by your internal teams, external security auditors and the global Moodle community, which means tens of thousands of developers and institutions worldwide. Vulnerabilities are more likely to be discovered and remediated through many eyes than hidden behind proprietary walls. Security updates follow a transparent process: you can see the issue, the fix and the reasoning. Moodle publishes a formal security advisory process, and the community holds it accountable.
With closed SaaS, you are asked to trust security claims you cannot independently verify. You depend entirely on the vendor’s internal processes, resourcing decisions and priorities. When a breach occurs, you receive a notification and a press release, not a code patch and a plan.
Our role as a managed services provider is to sit in the middle. We track Moodle security advisories and the wider open source ecosystem. We proactively patch, test and roll out fixes. We contribute back where appropriate, strengthening the commons that our customers rely on.
But, and this is important to say clearly, open source is not secure by magic. All software has bugs and all platforms have vulnerabilities, Moodle is no different in that respect and no serious person should claim otherwise. The difference is in how the platform is governed, how risk is contained, and how much control the institution retains. That means patching, testing, monitoring, change control, clear ownership, incident response and transparent reporting. That is the managed service wrapper around the platform. Not unmanaged open source. Not blind trust in a vendor’s promise.
Individual control of platform access and API permissions
In a cloud-native, API-driven world, the perimeter is not just a firewall. It is who and what you choose to trust.
A typical large SaaS LMS concentrates many functions into one integrated system: identity, content, communication, analytics, AI and more. That can be convenient. But it also means a single identity breach can cascade across multiple services, third-party integrations often carry more permissions than strictly necessary, and institutions have limited ability to shape access controls beyond what the vendor’s roadmap allows.
This is where education data security often breaks down in ways that go unnoticed until it is too late. Risk doesn’t only sit in the application itself. It sits in identity. It sits in API permissions. It sits in integrations and third-party tools. It sits in the decisions about who and what is allowed to connect to the platform, and with what level of privilege.
With a managed Moodle service under proper governance, institutions can define those boundaries themselves through fine-grained roles and permissions aligned to their own security model. API access tokens and scopes are managed according to their appetite for integration and risk. The ability to say no to certain categories of integration or to sandbox them without waiting for a vendor feature. Identity federation aligned with institutional IAM strategy. Central control over user lifecycle, MFA, risk-based access and audit logging.
Instead of a take-it-or-leave-it access model from a SaaS vendor, institutions get a platform they can shape, with a partner whose responsibility is to implement a platform around their policies, not to substitute for them.
Vendor trust vs. partnership
One of the biggest questions education leaders should be asking after any major LMS data breach is not simply, “is our platform secure?” The better question is: what are we actually trusting?
Trusting a vendor’s marketing promise is not the same as having a governed partnership with clear expectations, clear ownership and agreed outcomes. Many institutions moved to large SaaS solutions on the strength of “we’ll take care of everything” assurances. Certification and reputation matter. Contracts matter. But none of them replaces the ability to inspect, question and shape the service your institution relies on.
Dependency says: trust us, we’ll handle it. Partnership says: let’s agree the outcomes, inspect the evidence, govern the risk and keep improving togetoperationaliseher.
With Moodle under a managed service model, institutions own the platform. If they decide to move to another provider, the platform and data move with them. Our job is to deliver availability, performance and security as specified in our agreements, not to keep anyone captive. We agree on expectations and outcomes upfront, run joint governance forums, and provide transparent reporting on uptime, incidents, changes and security posture. Institutions can commission independent audits and penetration tests against their own environment. They can review configurations, logs and documentation.
We encourage and enable institutions to inspect and shape what they are trusting, not just accept it.
The cost–benefit equation
Another common line from large SaaS competitors is that open source is low return on investment once you factor in hosting and management costs. Our customers typically see the opposite when the full picture is considered.
The real value of open source is not cheap software. It is strategic leverage. With Moodle, there are no per-student or per-course licensing fees to the platform owner. Investment goes into hosting, management, support, integrations and value-added features, all under the institution’s control and negotiable. Institutions are free to extend, customise or integrate without waiting for a proprietary vendor’s roadmap or incurring punitive licensing costs when their needs evolve.
There is also a lock-in question that does not get talked about enough. If a SaaS vendor changes pricing, feature sets or terms, including data usage and AI training rights, room to manoeuvre can be limited. Migrating away from a proprietary SaaS platform can be complex, risky and costly by design. With an open source managed service, switching providers or bringing elements in-house is substantially more feasible.
Money saved on licence fees can be redirected to digital pedagogy, content development, training and an improved student experience. Institutions can co-fund or co-develop features that directly serve their needs and share them with the wider community. Over time, this builds internal understanding and capability around core learning infrastructure, rather than deepening dependency on a vendor’s black box.
Freedom to innovate, with reduced systemic risk
At the heart of all of this is a philosophy about what educational institutions deserve.
Learning platforms now sit at the heart of teaching, assessment, communication and the student experience. They deserve to be governed with that level of seriousness. Institutions should own their core platforms and data, not rent them on the vendor’s terms. Innovation should happen within an ecosystem where they can experiment, integrate and adapt without being constrained by proprietary walls. Risk should be distributed, governed and transparent, not concentrated into a single opaque service.
A segregated, strongly governed managed Moodle service gives institutions:
- Control over where their data resides and how it is protected
- Transparency into the code and processes that run their learning environment
- The ability to define and enforce access and integration policies aligned to their own risk tolerance
- A partnership model based on agreed outcomes, not marketing claims
- A cost–benefit profile that unlocks resources for real educational impact
Major SaaS breaches will continue to make the news. The question for institutions is not whether technology is perfectly safe, nothing is, but whether the operating model they choose gives them the freedom, control and resilience their students and staff deserve.
Questions institutions should be asking now
Whether your institution uses Canvas, Moodle, Totara or another learning platform, a major breach should prompt practical governance questions:
- What data is held in our learning platform?
- Where is that data hosted?
- Who has privileged access?
- Is MFA enforced for high-risk accounts?
- What third-party integrations and APIs have access?
- How quickly are security patches applied?
- What logging and monitoring is in place?
- Are backups regularly tested?
- What is the incident response process?
- What visibility do we have over risks, changes and configuration?
- How easy would it be to move platform or provider if needed?
Concerned about learning platform risk, resilience or vendor lock-in?
Catalyst works with education institutions to deliver secure, stable and scalable open source learning platforms with clear governance, data ownership and long-term control.
Start a conversation with our team.
