Moodle multi-factor authentication for campus logins: what the built-in feature does
Moodle has shipped multi-factor authentication in core since 4.3, so a campus that needs a second factor on Moodle logins does not have to start with a third-party plugin. The real decision for the institution is whether the built-in feature covers the login paths, user groups and policies it needs, and that depends on the release it runs. This section explains what the feature does at a high level so the team can decide whether to configure it directly or plan around its limits.
At a high level, the feature lets site administrators require a second verification step after a user enters a username and password. The parts the team must configure and test are the factors each user can enroll, the conditions under which the prompt appears, and how the site handles users who have not yet enrolled a factor. The available factors, policy options and exemption controls are tied to the release in use, so the team should read the multi-factor documentation for its exact version before writing a configuration baseline. Do not assume that a factor or setting described in a newer release exists on an older site.
Teams usually consider a second factor for three reasons. A regulator, auditor or internal policy may expect stronger authentication for systems that hold student records, assessment data or staff information, and the team should map that expectation to the control wording its assessor will use. Shared or generic accounts, such as those used by a department or a tutor group, are hard to tie to one person with a password alone. Logins exposed to the public internet, including guest or externally reachable entry points, form the third reason. Each reason changes which users and login paths the policy must cover.
Before enabling anything, write down three decisions: which roles and cohorts must enroll a second factor, which login paths the policy applies to, and which accounts are exempt and why. Service accounts used by integrations often cannot answer a prompt, so each exemption needs a named owner, a review date and compensating controls such as restricted network access. Test every decision on a staging copy of the site at the same release, and confirm with that version's documentation which factors and exemption options exist. Keep the test results with the configuration so the audit trail matches what the site actually does.
Which MFA options to enable and when each fits
This table compares the main MFA configuration decisions for a Moodle site, with the situations where each option fits and the support effort it tends to create. Read each row as a choice you make once for the whole site or for specific roles and cohorts. Enrolment rules and recovery paths drive most help desk volume, so decide them before the first login prompt reaches learners.
| Decision | When it fits | Support effort and what to confirm |
|---|---|---|
| Narrow set of second factors | Learner devices and policies are uniform, and the institution can supply or standardize the authenticator. | Fewer enrolment questions. Confirm the exact factor names and availability in the documentation for your Moodle version. |
| Broad set of second factors | Learners use many personal devices and may not have a smartphone or a stable number for messages. | More first-login questions and more troubleshooting per factor. Confirm each factor's setup steps and any prerequisites before enabling it. |
| Forced enrolment for staff and administrators | Accounts hold elevated privileges, such as course creation, grading or site configuration. | A concentrated burst of help requests at the first forced prompt. Plan a short support window before the enforcement date. |
| Optional enrolment with reminders | A pilot or early phase where you want to measure adoption before tightening access. | Lower immediate load, but coverage can stall. Confirm what reporting shows enrolment status per user and per role. |
| Coverage by role or cohort | Staff and admins are covered first, and learner cohorts follow in stages tied to course start dates. | Each cohort boundary creates questions about who is covered. Publish the scope in writing and check it against your enrolment data. |
| Grace period before enforcement | Users need time to enroll on their own devices, and the institution wants a visible deadline. | Support requests cluster near the deadline. Confirm how the grace period is set, whether it is per user or per site, and what happens when it expires. |
| Backup codes as a recovery path | Phone loss or replacement is common, and users can store codes safely in a password manager or printed copy. | Lowers reset requests if users keep codes. Confirm how codes are generated, how many remain, and whether regeneration is allowed. |
| Administrator reset as a recovery path | Teams are small and the number of locked-out users is low enough for a managed queue. | Each reset is a manual task. Define who may reset, how identity is verified, and how resets are logged for audit. |
How MFA and SSO interact in Moodle
The first decision is where the second factor is checked. Moodle's built-in multi-factor authentication, available since Moodle 4.3, can challenge users who sign in with a local account, meaning a password stored in Moodle's own user table through the manual accounts plugin. When Moodle instead hands sign-in to an external identity provider through SAML 2.0 or OAuth 2, the identity provider usually performs the authentication and the second factor, and Moodle accepts the result it receives. Choose one enforcement pattern for each login route before you configure anything. The two patterns produce different prompts, different logs and different recovery paths, and mixing them without a plan is the most common source of confusion during rollout.
Double prompts are the most visible risk. When both Moodle and the identity provider challenge the same user, learners see two factor prompts in one sign-in, which generates support tickets and abandoned logins. Check the enforcement policy on the identity provider's client for Moodle, then check whether Moodle's MFA settings also apply to users who arrive through the SAML2 single sign on plugin (auth_saml2) or the OAuth 2 authentication plugin in your version. Test with at least four accounts: a learner, a staff member, a site administrator and a user whose login route is SSO. Record every prompt each one sees. Do not assume the two sets of settings are independent until your own tests confirm it.
Sessions and logouts behave differently on each side. A Moodle session and an identity provider session are separate objects with separate lifetimes. Moodle may keep a user signed in after the identity provider session has expired, or the identity provider may require a fresh factor while Moodle still holds a valid session. Confirm with the identity team how long each session lasts, whether the identity provider re-prompts for MFA after a set period, and whether a logout from Moodle ends the identity provider session. Single logout support depends on the plugin version and the identity provider's configuration, so confirm it in a test environment. Also check how mobile app sessions and browser tabs left open on shared computers are handled.
Confirm these points with the identity team before choosing a pattern. Ask which factors the identity provider enforces, for which groups, and whether it sends an authentication context in the SAML assertion or OAuth token that tells Moodle MFA already happened. Confirm the attribute mapping for username and email, because the SAML2 plugin creates users from field mappings configured in Moodle. Agree who owns recovery when a learner loses a device, and whether that process runs through the identity provider, Moodle administrators or both. Finally, establish whether service accounts, web service tokens and scheduled integrations use interactive sign-in at all. Those accounts usually cannot complete an interactive factor, so their exemptions need a deliberate design that does not weaken the interactive path.
A practical default follows from the identity estate. Illustrative example: an institution that already runs a central identity provider enforcing MFA for every application would normally enforce the factor there, then turn off the duplicate Moodle challenge for SSO login routes once tests pass. An institution with mostly local accounts and no central identity provider would enforce the factor in Moodle and document the local login route as the primary path. Mixed estates need both routes documented in the same runbook, with a named owner for each. Whichever pattern you choose, write down the expected prompts per login route, the session lifetimes on each side and the exemption list, and re-test them after every Moodle minor release.
Setting up Moodle MFA in sequence, with checks at each step
This sequence moves Moodle multi-factor authentication from a version and requirements check to a cohort-by-cohort rollout, with a verification before each move forward. Each check gives the team evidence that sign-in, recovery and integrations behave as intended before more users are affected.
Confirm Moodle version and server requirements
The platform team checks the Moodle version in use against the release notes for the target version, including the minimum PHP, database and web server requirements. Moodle 5.1 requires 64-bit PHP 8.2 or later, and its release notes say the web server document root must point to the new public directory. Moodle 5.3 raises the PHP floor to 8.3 and requires PostgreSQL 17 or MariaDB 11.4 or later. Confirm the target version's support window, then record the version, PHP and database versions in the change ticket. The step is done when a written compatibility note is approved by the platform owner and the staging build matches production versions.
Decide the authentication method for each population
Working with the identity owner and registrar, group users into populations such as staff, students, external tutors and service accounts. For each group, decide whether sign-in runs through an existing identity provider over SAML 2.0 or OAuth 2, through LDAP, or through local accounts, and whether MFA applies at the identity provider or in Moodle. Note which accounts are used by LTI tools, web services or the mobile app, because those flows need separate testing. Record exemptions for service accounts with a named owner and a review date. The step closes when the population matrix is signed off by security and the academic or business owners.
Enable and configure MFA in staging
In a staging site built from a recent production copy, the Moodle administrator enables the multi-factor authentication plugins available in the installed version, sets the factors allowed for each role, and configures any SSO plugin such as auth_saml2 with its field mapping. Confirm the plugin's listed version support matches the Moodle version before enabling it. Review the configuration against the decided matrix and export it so changes can be repeated in production. The check is that a test account of each population can sign in with the expected factor, and that a disallowed factor is refused.
Test enrolment and lost-device recovery
With a pilot group of volunteers from each population, run factor enrolment on staging, then simulate a lost phone by removing the device and following the documented recovery path. Confirm that an administrator or help desk role can reset a factor without disabling MFA for the account. Record the time each recovery takes and the number of help desk steps, and compare against what the support team can staff. The step is complete when every pilot user has enrolled and recovered at least once, and the recovery runbook has been updated with any gaps found.
Check login logs, LTI and mobile app access
Review Moodle's logs for the pilot sign-ins to confirm that successful and failed MFA attempts are recorded with the expected detail for your audit needs. Then test the integrations that do not behave like a browser login: LTI launches from connected tools, web service tokens, and the official Moodle mobile app, which needs its own mobile services settings to be reviewed. Confirm that exempt service accounts still function and that human accounts cannot bypass MFA through these routes. The step closes when each integration has a passing test and the log review has been signed off by security.
Pilot, correct and approve for production
Run the configuration on a live pilot cohort for a period agreed in the change plan, collecting help desk tickets, failed sign-in patterns and integration errors. Fix the configuration in staging first, retest the affected paths, then apply the same change to production. Confirm the rollback steps by reverting a non-critical setting on staging and reapplying it. The step is done when the pilot exit criteria in the plan are met and the owner approves the rollout.
Roll out by cohort and monitor
Enable MFA for each remaining cohort in an order set in the plan, usually starting with staff and administrators before large student groups. Before each cohort goes live, publish the enrolment instructions and recovery route, brief the help desk, and confirm the support queue can absorb the expected volume. After each cohort, review login logs, lockout counts and integration errors, and pause if a threshold agreed in advance is crossed. The step produces a completed rollout record and a standing review schedule for exemptions and new integrations.
Handling service accounts and exemptions without weakening the rollout
Most accounts are people signing in through a browser or the mobile app. For these users the exemption question is usually not whether to exempt them, but whether a group, role or network location should be allowed to sign in with a weaker factor during a transition. Any such exception should be time-limited and tied to a named owner, because it is the path most likely to outlive the rollout.
Typical exemption approach: a temporary grace period or a cohort-based enrollment deadline, rather than a permanent exemption list.
Risks it creates:
- Accounts that never enroll remain protected only by passwords, which is the exposure the rollout is meant to close.
- Learners who share credentials or sit on shared devices can be exempted by accident when a role or cohort is mislabeled.
- Staff with elevated course roles may be in a group that was exempted for learner convenience.
Compensating controls to consider:
- Enforce enrollment through a dated deadline and report on accounts still outstanding.
- Restrict any remaining bypass to a defined campus network range, and review it at each release cycle.
- Keep exemptions out of staff and course-creator roles.
Before relying on any exemption, confirm in your Moodle version exactly how the factor policy is scoped (site, role or cohort) and how grace periods are recorded and expired.
Web services, LTI tool connections, data sync jobs and API tokens cannot answer an interactive factor prompt. They usually authenticate with a stored token or a dedicated user, so the usual response is to exempt them from multi-factor authentication. That is often reasonable, but the exemption moves the security boundary to the token and the network path, which is where the controls must go.
Typical exemption approach: a dedicated service user excluded from the interactive factor policy, with access limited to specific web service functions.
Risks it creates:
- A long-lived token is equivalent to a password that never prompts for a second factor.
- Service users with broad roles can read or change far more data than the integration needs.
- Shared service accounts make it hard to tell which system performed an action.
Compensating controls to consider:
- Restrict token use to approved source IP ranges where the integration runs.
- Scope each token to the minimum set of web service functions it calls.
- Create one service account per integration and avoid reusing administrator accounts.
- Log authentication and web service calls and send them to your central log store.
Before relying on an exemption, confirm in your Moodle version which web service functions the token can reach, whether IP restrictions can be set on tokens, and how token expiry and revocation work.
Every Moodle site needs a way back in if the identity provider, the factor service or the site configuration fails. An emergency administrator account is the usual answer, but it is also the highest-value target on the platform. The goal is a break-glass path that is rarely used, tightly held and loudly observed, not an account that quietly skips the new controls.
Typical exemption approach: a small number of local administrator accounts kept outside the normal identity flow, with credentials stored in a sealed secrets vault.
Risks it creates:
- A password-only administrator account is a direct route to full site control if its credential leaks.
- Break-glass accounts often go unmonitored because they are rarely used.
- Emergency credentials that are never rotated become stale and may be known to former staff.
Compensating controls to consider:
- Keep the number of emergency accounts small and record who holds the sealed credentials.
- Alert on every sign-in to these accounts and review each use after the fact.
- Rotate the credentials after each use and at a scheduled interval.
- Restrict the emergency path to a management network range where possible.
Before relying on this path, confirm that your Moodle version lets you disable or restrict the local administrator login without removing recovery options, and test the recovery procedure on a non-production copy.
Planning the support load of a campus-wide MFA rollout
Most of the support load from a Moodle MFA rollout comes from a small set of predictable sources, so the support plan should be built around them before enforcement starts. The largest group is usually device enrolment: learners who must register an authenticator app, a security key or another factor during their first login, often while they are in the middle of a course. Lost or replaced phones generate the next group, because a learner who has lost the device they used for one-time codes cannot sign in until someone verifies them and clears or re-enrols the factor. Clock drift on a learner's device can make one-time codes fail even when the factor is correct, and these tickets look like password problems to the person who raises them. Students without a personal smartphone, shared accounts used by study groups or departments, and learners who rely on assistive technology or on a screen reader during enrolment also need their own routes. Ask your team to list each source, the cohort it affects and the channel where the ticket will arrive.
Sizing help desk coverage works best by cohort rather than by a single campus total. Group learners by programme, intake, delivery mode, time zone and whether they study on campus or remotely, then estimate contact likelihood for each group using your own enrolment figures and pilot results. First-year cohorts and distance learners often generate contact in different hours, and enforcement dates tend to produce a spike that falls off after the first weeks. Staff roles also matter: academic staff who are enrolled as teachers may need faster resolution than students, and administrators who hold elevated permissions should not be handled through the same queue. Do not treat any volume estimate as settled until a pilot cohort has produced real contact data. When you ask a partner or internal team for a plan, request the assumed contact rates by cohort, the hours of cover, the escalation path to Moodle administrators and the expected staffing for the first enforcement week.
Self-service guidance and FAQs reduce the tickets that a help desk would otherwise absorb. Write the FAQ around the sources listed above: how to enrol a factor, what to do with a new phone, how to fix a rejected one-time code, what to do when no personal device is available, and how to request accessibility support. Test every enrolment step on a device and browser set that matches your learner population, including older phones and the browsers your accessibility office recommends. Confirm which steps Moodle presents itself and which steps belong to your identity provider if you combine MFA with single sign-on, because the wording and the failure messages will differ. Keep the guidance short, versioned and linked from the login page, and assign an owner who updates it after each Moodle minor release that changes the authentication screens.
A communication timeline should run well before enforcement, and each message should tell learners and staff what to do next, when, and who to contact. Typical sequences include an early notice that MFA is coming, a pilot period for a named group, a reminder that enrolment is open and a final notice shortly before enforcement with the exact support channels. Agree the dates with the registrar, the accessibility office and the teaching leads, because they will receive the questions. Decide in advance who may reset a factor, which is one of the most consequential decisions in the plan. Typical options are first-line staff verifying identity against institutional records, a named Moodle administrator for complex cases and no reset through email alone. Record each reset with the operator, the reason and the verification method, and confirm the same policy with your SSO and identity team so a learner cannot be recovered through one route that the other route would have refused.
Security and operational considerations for Moodle MFA
Enabling a second factor changes how accounts recover, how administrators change policy, and what the site records about sign-ins. The items below are review points for your team to check against your own configuration, not guarantees that a given setting is secure or compliant.
Recovery codes and reset flows
Recovery codes and self-service reset paths are the most common way a second factor gets bypassed. Review who can generate or reissue recovery codes, where codes are stored when users print or save them, and whether a password reset can remove an enrolled factor without a second check. Confirm how support staff verify identity before resetting a factor for a learner or instructor, and test each path with a sample account before rollout.
Auditing administrator changes to MFA
Changes to which factors are enabled, which roles must enrol, and which accounts are exempt can weaken the whole site without any user noticing. Review who holds the site administrator role and related capabilities, and confirm that changes to authentication plugin settings appear in the site logs. Decide who approves a policy change and how that approval is recorded before the change is made.
Logging and retention of authentication events
Sign-in successes, failures and factor challenges are useful evidence during an incident, but they are also personal data. Confirm which authentication events Moodle writes to its logs, how long your institution keeps them, and where log data is copied, including any external log store or backup. Check that log access is limited to the staff who need it and that the retention period matches your institution's written policy.
Personal data in factor enrolment
Factor enrolment can store phone numbers, device identifiers and similar details tied to a user. Identify which fields are collected for each factor the site enables, who can view them, and whether an enrolled device can be removed when a person leaves. Check how these records are handled in the site's data export and deletion procedures, and confirm the approach with your data protection officer.
Supported release and security updates
A second factor is only as dependable as the platform beneath it. Confirm which Moodle release your site runs and its security support end date on the Moodle releases page, and plan upgrades before that date. Include plugins that handle authentication or factor delivery in the same review, since their update cycle may differ from core.
Web server document root for Moodle 5.1
From Moodle 5.1, the web server document root must point to the new public directory rather than the main Moodle folder. If it does not, the site may expose directory listings or show errors, and code outside the public directory may become reachable. Check the document root in each web server configuration, including staging and disaster recovery copies, after any upgrade to 5.1 or later.
What buyers ask before hiring help with Moodle MFA
What drives the cost of a Moodle MFA rollout?
The main cost drivers are the number of user groups that need different rules, how complex the SSO setup is, how many exemptions must be designed and audited, and the support model you choose after go-live. Each group (staff, students, faculty, guest users, alumni) may need its own factor policy, grace period and enrolment path. SSO complexity matters most when MFA is enforced by the identity provider rather than by Moodle, because the two policies must be tested together. Exemptions for service accounts, integrations and API users add design and review work. Ask any provider to price these items separately in a written scope, and ask whether the price covers pilot testing, staff communications and a defined period of help desk support after launch. Pricing is set by the written scope, so DeployOpen issues a quote only after those inputs are agreed.
How long does a campus-wide Moodle MFA rollout take?
Duration depends on how many user populations you phase in, how much of the identity setup already exists, and how many approvals sit between the project team and the decision owner. A pilot with one faculty or a small course group usually comes before the full population, and the time between phases is often set by help desk readiness rather than by configuration work. If your identity provider already enforces MFA, the Moodle side is shorter. If MFA, SSO and group mapping must be built together, plan for more testing cycles. Ask for a timeline tied to named milestones such as pilot exit criteria, communications sign-off and cutover date, instead of a single duration. Any timeline should be confirmed against your own change calendar, and no fixed duration is implied here.
What does the institution need to provide for MFA work?
A Moodle MFA project needs four groups of people. The identity team owns the identity provider, directory attributes and any MFA enforcement outside Moodle. Moodle administrators own site configuration, authentication plugin settings, roles and course-level exceptions. The help desk owns enrolment recovery, lost device handling and user-facing scripts, and needs training before pilot users arrive. A named decision owner signs off on factor choices, exemptions and the rollout schedule. Without a decision owner, factor and exemption decisions tend to stall in review. Ask who in your organization holds each role and how many hours per week each person can commit during the build and pilot. These are the inputs that most often change the scope.
Can our own team implement Moodle MFA without a partner?
Yes, a team with Moodle administration skills and identity experience can often do the core configuration in house, especially for a single population and a standard identity setup. Outside help is most useful where several identity sources, multiple user groups or unusual exemptions must be combined, or where the team has no one who has tested SSO with Moodle before. Be honest about capacity: MFA changes affect every login, so the pilot, rollback plan and help desk material need the same care as the configuration. Ask a partner to show how they will split work with your staff, what they will hand over, and which tests they will run. Whichever route you take, decide the ownership model before the build begins.
How does MFA work with SAML or other SSO in Moodle?
Where a single sign-on provider handles authentication, the usual pattern is to enforce MFA at the identity provider so every application gets the same policy, and to keep Moodle's own factor settings for cases where the login does not pass through that provider. The SAML2 Single sign on plugin (auth_saml2), maintained by Catalyst IT, creates users from SAML assertions with field mapping configured in Moodle, so the attributes your provider sends determine how accounts and groups are created. Test the following in a staging site: whether the MFA claim reaches Moodle, what happens to users created before the change, how fallback manual login behaves, and whether mobile app sign-in is affected. Confirm the plugin's support for your Moodle version in its directory listing before you commit to it.
How do Moodle upgrades affect an MFA configuration?
A Moodle release can change authentication settings, plugin compatibility and the server requirements that MFA depends on, so treat every upgrade as a retest of the MFA path. Moodle 5.1 requires 64-bit PHP 8.2 or later and sets a new web root at the public directory, and Moodle 5.3 requires PHP 8.3 or later and a PostgreSQL 17 or MariaDB 11.4 database. Upgrading to 5.1 requires sites on Moodle 4.2.3 or later, and upgrading to 5.3 requires Moodle 4.4 or later. Any authentication or SSO plugin must also support the target version, so check plugin compatibility before the upgrade window. Ask your provider to include regression tests for login, MFA enrolment and exemptions in each upgrade plan, and to record which configuration changes are tied to each release.
Which MFA factors should a Moodle site enable first?
Choose factors by the risk of the account and the support load each one creates, not by what is available. Start from the accounts that carry the most access, such as administrators and course creators, then extend to staff and students. The factor choice affects enrolment steps, device loss procedures and accessibility requirements, so the help desk and accessibility team should review it before pilot. Some factors depend on a mobile app, a hardware token or an identity provider, and each adds dependencies to the rollout plan. Ask your provider to document the factor options available in your Moodle version, the enrolment step for each, and how a user recovers access without an administrator in the loop.
Limits to confirm in your environment before rollout
Several limits on a Moodle MFA rollout depend on your installed version, your server stack and your identity provider, so none of them can be assumed from a product page. The cards below cover the checks to run in your own environment before you set a rollout date, in roughly the order they block the work.
Factors and policies in your installed version
Confirm which MFA factors and enforcement policies the Moodle version you run actually provides, since the built-in MFA capability arrived in Moodle 4.3 and its options can differ across later releases. Check the current documentation for your exact version rather than relying on a newer release's notes. Record which factors your users can enroll in and whether enforcement can target roles, cohorts or the whole site.
Identity provider enforcement and interaction
Determine whether your identity provider can enforce MFA itself and whether Moodle will still prompt for a second factor after federated sign-in. Double prompts, or a gap where neither layer enforces MFA, are common outcomes when the two are configured separately. Test the SSO path with a pilot group, including the SAML2 or OAuth 2 plugin you plan to use, before changing site-wide policy.
Minimum PHP and database versions
Check the minimum PHP and database versions for the exact target release. For example, Moodle 5.1 requires 64-bit PHP 8.2 or later and PostgreSQL 15 or later, while Moodle 5.3 raises the floor to PHP 8.3 and PostgreSQL 17. Upgrading MFA may therefore also require an OS, PHP or database upgrade, which carries its own schedule and risk. Confirm these values in the release notes for your target version.
Direct upgrade eligibility
Confirm that your current site can upgrade directly to the target release. Moodle 5.1 requires sites to be on Moodle 4.2.3 or later, and Moodle 5.3 requires Moodle 4.4 or later. If your site is older, you will need intermediate upgrades, each with its own testing, before MFA configuration makes sense. Check this before scoping, because it can add more work than the MFA rollout itself.
Third-party authentication plugins
Identify any installed plugins that override authentication, login or session behavior, including custom themes, SSO connectors and local plugins. These can bypass or duplicate the core MFA prompt, or break after an upgrade. List every auth plugin in use, check its maintenance status against your target version, and test sign-in for each one, because a plugin that is out of date may block the upgrade entirely.
Web server document root for 5.1 and later
From Moodle 5.1, the web server document root must point to the new public directory rather than the main Moodle folder. If it does not, the site may show directory listings or errors. Confirm how your web server, reverse proxy and load balancer are configured, and update them in the same change window as the upgrade, so that authentication endpoints are not exposed or broken during cutover.
How DeployOpen works on this
DeployOpen plans and implements Moodle inside infrastructure you control, including the multi-factor authentication built into Moodle since 4.3. We start from a written scope that names the factors, identity sources, exemptions and user groups involved, then build, test and document the rollout before handing it over.
How we scope
- Confirm your Moodle version and whether your site runs 4.3 or later, since MFA depends on that release line
- List the factors to enable, such as authenticator apps, security keys or recovery methods, and who may use each
- Map how MFA interacts with your SSO provider, so sign-in and second-factor prompts do not conflict
- Define exemptions for service accounts, API users and integrations, with an owner for each exception
How we build
- Configure MFA policies per user group in a staging copy of your site before anything reaches learners
- Test enrollment, login, recovery and lockout paths with a sample of accounts from each group
- Set up the authentication chain with your identity provider and check behavior for SSO and direct logins
- Record configuration, settings and rollback steps so your team can reproduce the build
How we hand over
- Deliver a runbook covering enrollment steps, recovery procedures, exemption handling and escalation paths
- Train administrators and help desk staff on the support flows they will handle during the first weeks
- Document the verification results and the open items agreed in the written scope before handover
- Agree who owns each exemption and how reviews are scheduled after go-live
How we support
- Ongoing support, upgrades and testing are available as a retainer, covering Moodle minor releases and MFA changes
- Review MFA settings when you upgrade Moodle, since prerequisites and server requirements change between releases
- Confirm with your identity provider vendor which factor and protocol features your version supports before planning changes
- Fixed-scope engagements mean any later change to the rollout is scoped and agreed in writing before work starts
