The LMS security checklist: practical controls, grouped by area

An LMS security checklist is a structured list of controls that protect your learning platform, its learner data and its availability. The essentials are: enforce MFA and least privilege for anyone with elevated rights, patch the core platform and every plugin on a schedule, design against the OWASP Top 10 web risks, encrypt data in transit and at rest, test restores rather than just taking backups, centralise logs, harden the hosting stack, meet your privacy obligations, and rehearse an incident response plan.

Learning platforms are attractive targets. They hold personal data for employees, students or customers, often including minors or regulated professionals, and they run large plugin ecosystems maintained by many different authors. The checklist below is grouped by area so you can assign an owner to each group and review it on a schedule. It applies to Moodle, WordPress-based LMSs, Open edX, Canvas and custom platforms, with platform notes where they matter.

The LMS security checklist at a glance

1. Access control and MFA

• Use SSO where possible so password policy, MFA and deprovisioning live in your identity provider. Our guide to LMS SSO with SAML or OIDC covers the setup.
• Require MFA for every privileged account: site administrators, managers, instructors with grading rights and anyone who can install plugins. NIST SP 800-63B-4 requires verifiers at AAL2 to offer at least one phishing-resistant option, so prefer passkeys or security keys for admins.
• Follow current password guidance for local accounts. NIST SP 800-63B-4 sets a minimum of 15 characters for single-factor passwords (8 when used with MFA), checks against a blocklist of compromised passwords, and drops forced periodic changes and composition rules.
• Apply least privilege. Review custom roles and capabilities; LMS roles often accumulate permissions over years of "just this once" changes.
• Keep one break-glass admin account outside SSO, protected by MFA and tested regularly.
• Protect login endpoints with rate limiting and lockout or progressive delays.
• Control impersonation features such as "log in as" and restrict them to a small group, with every use logged.
• Set sensible session timeouts, shorter for administrators and for shared devices in classrooms and training centres.

2. Patching and plugin hygiene

• Run a supported release of your LMS and its runtime (PHP, Python, Node.js, database). Unsupported branches stop receiving security fixes.
• Subscribe to the vendor's security advisories and apply security releases within a defined window, faster for critical issues.
• Keep an inventory of every plugin, theme and library with its version, maintainer and last update. Remove anything unused or abandoned rather than just disabling it.
• Prefer plugins with an active maintainer and a track record of security fixes; review custom plugins with the same rigour as core code.
• Test updates in staging with a copy of production data (masked where required) before deploying. Our Moodle performance guide describes a staging workflow that also serves security updates well.
• On WordPress, disable the built-in file editor with DISALLOW_FILE_EDIT, as recommended in the WordPress hardening guide.

3. OWASP Top 10:2025 risks in an LMS

The current edition is the OWASP Top 10:2025. Here is how each category typically shows up on learning platforms:

1. A01 Broken Access Control: learners viewing other learners' submissions, grades or certificates by changing an ID in a URL; instructors accessing courses they do not teach.
2. A02 Security Misconfiguration: debug mode left on, directory listing, public course backups, default credentials.
3. A03 Software Supply Chain Failures: compromised or abandoned plugins, unpinned dependencies, untrusted build pipelines.
4. A04 Cryptographic Failures: weak TLS, unencrypted backups, secrets stored in plain text.
5. A05 Injection: SQL injection in custom reports, stored XSS in forum posts or quiz feedback.
6. A06 Insecure Design: certificate verification pages that leak personal data, exam flows that can be bypassed.
7. A07 Authentication Failures: no MFA, weak session handling, missing brute-force protection.
8. A08 Software or Data Integrity Failures: unsigned update packages, unsafe deserialisation, unverified webhooks.
9. A09 Security Logging and Alerting Failures: no record of who changed a grade or role.
10. A10 Mishandling of Exceptional Conditions: error pages exposing stack traces, failures that leave access open.

Integrations deserve the same scrutiny. LTI tools, webhooks from payment or HR systems, and REST API tokens all create new entry points. Scope every API token to the minimum functions it needs, verify webhook signatures, review which LTI tools receive learner names and emails, and remove integrations nobody owns. Web service tokens with administrator scope are one of the first things we check for.

For custom LMS development, use the OWASP Application Security Verification Standard (version 5.0.0, May 2025) as the detailed requirement set behind these categories.

4. Data protection, encryption and privacy

Encryption and secrets

• Serve every page over HTTPS with modern TLS and HSTS; redirect all HTTP traffic.
• Encrypt databases, file storage and backups at rest, and restrict who can access the keys.
• Store API keys, SMTP credentials and SSO secrets in a secrets manager or protected environment configuration, and rotate them when staff leave.
• Keep uploaded files outside the web root and serve them through the application's access checks. Moodle's own security recommendations cover data directory permissions and running the built-in Security overview report.

Privacy and GDPR

• Collect only the learner data you need; HR integrations should not copy salary or health fields into the LMS.
• Maintain records of processing and a data processing agreement with every vendor and plugin service that touches personal data.
• Define retention rules for inactive accounts, logs and assessment attempts, and automate deletion or anonymisation.
• Have a tested process for access, correction and erasure requests. GDPR Article 32 expects measures such as encryption, the ability to restore data in a timely manner, and regular testing of security measures.

5. Backups and restore tests

• Back up the database, file store and configuration together so a restore is consistent.
• Follow a 3-2-1 approach: multiple copies, different storage, at least one offsite and immutable or offline to survive ransomware.
• Set a recovery point objective and recovery time objective with the business, and size backup frequency to match.
• Test a full restore at least quarterly to a separate environment and time it. An untested backup is an assumption.
• Encrypt backups and restrict who can download them; a course or site backup is a full copy of learner data.
• Monitor backup jobs and alert on failures or unexpectedly small backup sizes, which often signal a silent problem.

6. Logging, audit and incident response

Logging and audit

• Log authentication events, role and permission changes, plugin installs, configuration changes, grade overrides and bulk data exports.
• Ship logs to a central store the web server cannot modify, with retention that matches your policy.
• Alert on high-risk events: new administrators, repeated failed logins, logins from unusual locations and mass downloads.

Incident response

• Write a short plan naming who decides, who investigates, who communicates, and how to reach your host and key vendors out of hours.
• Pre-agree containment steps: maintenance mode, credential rotation, disabling a plugin, restoring from a known-good backup.
• Know your notification duties. Under GDPR Article 33, controllers must notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach.
• Run a tabletop exercise each year and after major platform changes.

7. Hosting hardening

• Isolate the database from the internet; allow connections only from application servers.
• Give the application's database user only the privileges it needs, as the WordPress hardening guide recommends.
• Put a web application firewall and DDoS protection in front of the LMS, tuned to avoid blocking legitimate quiz and upload traffic.
• Harden the operating system and web server: minimal packages, automatic security updates, SSH keys only, no root login.
• Separate environments and credentials for production, staging and development.
• For multi-tenant or high-traffic platforms, scan the external attack surface regularly and review cloud permissions.

How we can help

We run security reviews and hardening projects for Moodle, WordPress LMS, Open edX and custom platforms, and provide ongoing patching and monitoring. See our LMS security services and maintenance and support plans, or contact us to walk through this checklist against your platform.