The recent security incident that affected Canvas LMS, operated by Instructure, should not be read as an opportunity to single out a specific provider. In security, every serious system learns, corrects, and improves. The right approach is to take the conversation for what it is: a clear signal that online teaching platforms are no longer secondary systems.
An LMS concentrates much more than courses. Users, roles, messages, grades, evidence, integrations, submissions, reports, and an important part of an institution’s operational continuity all live there. For many organizations, if the LMS stops, part of the educational or training process stops too.
According to Instructure’s public communication, the incident involved unauthorized access to part of its environment. The company indicated that the data involved included users, emails, course names, enrollment information, and messages. It also stated that, according to its investigation, course content, submissions, and credentials were not compromised. Instructure attributed the exploited path to an issue related to its Free-For-Teacher accounts and took measures such as temporarily disabling that service, revoking privileged credentials and tokens, rotating internal keys, restricting token creation paths, and strengthening monitoring. (Instructure )
On the other hand, AP News reported that the ShinyHunters group claimed responsibility for the incident and threatened to publish data from nearly 9,000 institutions and 275 million people. Instructure later announced that it had reached an agreement with the unauthorized actor for the return and destruction of the data, although it acknowledged that there is no complete certainty when dealing with criminals. (AP News )
The important point for those who manage e-learning is not only what happened with Canvas LMS, operated by Instructure. The point is what responsibility any organization that uses an LMS has when operating educational data and processes.
It is not Canvas LMS vs Moodle LMS
Krestomatio works with Moodle LMS, but it would be irresponsible to present this as a simplistic comparison between platforms. No LMS is free of risk simply because it is commercial, open source, self-managed, or administered by a provider.
Although there is no public evidence that Moodle LMS was directly affected by this incident, the relevant risk is categorical: any LMS concentrates identity, communication, assessments, integrations, evidence, and academic continuity. Moodle LMS, like any broad software used globally, also has security procedures, corrected versions, and recommendations for administrators (Moodle ). Its documentation recommends updating regularly, using HTTPS, running security reviews, maintaining backups, and testing restoration processes. It also maintains a responsible disclosure process so registered sites have the opportunity to apply patches before details are published widely (Moodle ).
The practical difference is not in assuming that a platform “is secure” by default. It would be in how it is operated.
A managed LMS is not just hosting
In many organizations, an LMS starts as a technical installation: server, database, domain, certificates, and users. That can work at the beginning, but it is not enough when the system becomes critical.
A managed service for Moodle LMS must include continuous operation. That means keeping the LMS updated, reviewing external components, controlling changes, managing backups, observing the platform, and reducing unnecessary exposure.
At Krestomatio, Moodle LMS is treated as a managed platform, not as an isolated installation. Operations are supported by automated infrastructure, reproducible deployments, and controls designed to reduce operational risk.
Among the practices that are part of this approach are:
- Periodic updates of the LMS and its infrastructure, with control over versions and relevant components.
- Plugin review and validation, because an LMS is not only its core; plugins extend functionality, but they also expand the risk surface.
- Separation of components and permissions, so services such as the application, database, cache, storage, and automation do not depend on unnecessary credentials or privileges.
- Controlled use of secrets, preventing credentials from being exposed in manifests, logs, or automation processes.
- Reproducible deployments, with versioned images and infrastructure definitions.
- Network policies and workload isolation, to reduce lateral exposure within the platform.
- Backups, monitoring, and observability, because security is also the ability to detect, respond, and recover.
- CI/CD validations, to reduce manual changes and make operations more consistent.
These measures do not eliminate risk. Nothing serious in security promises that. What they do is reduce exposure, increase traceability, and improve response capacity.
Security is shared
A managed provider can handle much of the technical operation: infrastructure, updates, backups, monitoring, deployments, hardening, plugin review, and operational response.
But an LMS platform also depends on institutional decisions.
The institution must define who can administer courses, who can create users, how identity systems are integrated, what data is stored, how long it is retained, and what procedure is followed when suspicious activity appears. It must also train its users to recognize phishing attempts, report unusual messages, and protect their credentials.
End users have a more limited responsibility, but not an irrelevant one: using appropriate passwords, not sharing access, being wary of unexpected messages, and reporting strange signals.
In security, the line between provider, institution, and user should not be ambiguous. When that responsibility is unclear, incident response becomes slow and costly.
Cost-benefit: “cheap can become expensive”
Operating an LMS has visible costs and hidden costs.
The visible ones are hosting, the domain, basic support, and some technical hours. The hidden ones appear when updates must be applied without breaking active courses, plugin compatibility must be reviewed, backups must be recovered, an incident must be answered, infrastructure changes must be validated, or unusual access must be investigated.
That is why, when evaluating an online teaching platform, the question should not only be how much it costs to have Moodle LMS running. The right question is how much it costs to operate it well.
A well-managed LMS does not guarantee that incidents will never happen. But it does reduce the probability of common mistakes, improves operational continuity, and provides more clarity when action is required.
The LMS remains as relevant as ever
Recent incidents do not make the LMS less relevant. On the contrary, they show that digital education and corporate training increasingly depend on stable, auditable, and well-administered platforms.
The LMS remains a central piece for educational institutions, companies, academies, and organizations that need to organize learning processes. What changes is the level of expectation: it is no longer enough for the platform to “be online”. It must be maintained, updated, observed, and operated with discipline.
At Krestomatio, Moodle LMS is approached with that vision: a platform that is useful for teaching, but also a platform that deserves professional operation.
Security is not a one-week campaign. It is continuous work, responsible collaboration, and constant improvement.
For organizations that already use Moodle LMS, or that are evaluating an e-learning platform, Krestomatio can help review current operations, identify priorities, and assess the cost-benefit of a managed service.