Controls your IT team can check for themselves
Single sign-on, provisioning, two-factor sign-in, audit logs and retention rules, with the option to run the whole platform inside your own network.
Identity & access
- SAML 2.0 SSO (Okta, Entra ID, OneLogin, Ping, ADFS)
- SCIM 2.0 provisioning and deprovisioning
- Passkeys (WebAuthn), TOTP 2FA and phone OTP
- Seven roles with per-menu permissions
- Audited, database-authorized admin impersonation
Application security
- Prepared statements for database access
- CSRF protection on every form submission
- Uploads validated by real MIME type, random filenames, executables denied
- Scoped API tokens with per-token rate limiting
- Built-in security scanner
Data governance
- Configurable auto-purge of logs, sessions, analytics, proctoring snapshots and AI chats
- Optional anonymization of inactive accounts
- Data-subject request queue with deadline tracking
- Consent logging and cookie-consent banner
- Audit logging of sensitive actions
Deployment & operations
- Self-host on your own PHP/MySQL infrastructure
- In-app database migrations with backups
- System health and storage tools
- Protected, login-gated media streaming
- Or use our managed cloud
LMS Advisor provides security and privacy controls that help you meet your own obligations. We don’t claim SOC 2, ISO 27001, HIPAA or FERPA certification of the platform.
Identity and access
Staff sign in through your SAML 2.0 identity provider, such as Okta, Microsoft Entra ID, OneLogin, Ping or ADFS. SCIM 2.0 provisioning creates accounts and group memberships from the directory and deactivates people when they leave, without touching their training history. For people outside your directory there is Google sign-in, email and password, passkeys (WebAuthn) and one-time codes by SMS or WhatsApp.
Two-factor authentication can be made mandatory per role. Repeated failed passwords lock the account for a period you configure, and failed sign-ins take the same time whether or not the email exists, so the login form does not reveal who has an account.
Inside the platform, seven roles and per-menu permissions decide who can see and change what. Branch scoping keeps a location’s managers inside their own branch.
Application safeguards
- Passwords are hashed with bcrypt, and database queries use prepared statements.
- Every form submission carries a CSRF token.
- Uploads are checked by their real MIME type and stored under random file names, and executables are refused.
- Responses send security headers, including HSTS, nosniff, a strict referrer policy and a permissions policy that limits camera and microphone access to the site itself.
- API tokens are rate limited per token, and sign-in and SCIM endpoints have their own limits.
- Course media streams only to signed-in users instead of sitting at a public URL.
A scanner for self-hosted installs
Many self-hosted servers have nobody watching them day to day. The built-in scanner walks the install looking for known malware signatures, executable files hidden among uploads and code files that no longer match their baseline hash. It also checks stored HTML for injected scripts or iframes, and audits configuration for problems like an exposed .env file, debug mode left on or missing .htaccess protections. Suspicious files can be quarantined from the admin screen.
Retention and privacy
Each category of time-based personal data has its own retention setting: audit logs, session history, analytics events, the sent email queue, read notifications, proctoring snapshots, exam audio clips and AI Tutor conversations. A daily job purges anything past its limit in small batches and records the run in the audit log. Enrollments, attempts, grades and certificates are deliberately left out, because regulated employers often have to keep them.
Inactive learner accounts can be anonymized after a set period, which strips personal details and keeps anonymous completion records. GDPR and CCPA data subject requests go into a queue that tracks each deadline.
Audit trail
Sensitive admin actions, including impersonation and retention runs, are written to the audit log, and the log itself has a retention setting so you can keep it as long as your policy requires.