Why Drupal two-factor authentication matters for editor and admin accounts
Any Drupal account that can publish content, change site configuration or reach personal data is a privileged account, and a password alone is a weak gate for it. The second factor is the control that makes a stolen or guessed password less useful to an attacker. Drupal core provides password login, but it does not on its own require a second step for every role, so a team that wants editors and administrators to prove possession of a device has to add that capability deliberately. The contributed TFA module is the usual way to do this inside Drupal. It adds time-based one-time password (TOTP) enrollment and recovery codes on top of the core login form, and it is licensed under GPL-2.0-or-later, the same license as Drupal core, so there is no license fee to plan for. Confirm the TFA release that matches your Drupal version on its Drupal.org project page before you scope the work.
Teams usually need this control first on sites where a single compromised editor account can change what thousands of visitors see or where administrator access can alter code and configuration. Three situations raise the priority: sites with several people holding editor or administrator roles, sites hosted on shared infrastructure where many tenants share a login surface, and sites that are publicly reachable from the internet with no VPN or network allow-list in front of the login page. A site that is only reachable from an internal network with its own sign-in controls has different needs, but the role list still decides who must enroll. Before you build anything, list every role that can publish, edit configuration, manage users or view personal data, and check which of those roles currently use only a password.
Two-factor enrollment does not by itself answer every question about how strong sign-in should be. Decide early whether the enforcement belongs in Drupal or in a central identity provider, because that choice changes who manages recovery, how lockouts are handled and where logs live. Whatever you choose, record the decision with the roles it covers, so an auditor or a new administrator can see why the control exists and how it is applied. The rest of this page works through the TFA settings, the enforcement model and the cases where a central identity provider is the better home for the control.
Which second-factor option fits which Drupal account population
This table compares TOTP apps, recovery codes, role-based enforcement in the TFA module and delegating MFA to an identity provider. Read each row against the account population you are protecting, then check the operational burden on users and administrators before choosing. The main takeaway is that the TFA module covers local Drupal accounts, while federated sign-in moves the second factor to the identity provider.
| Option | What it protects | Burden on users and admins | When it fits |
|---|---|---|---|
| TOTP authenticator app (TFA module) | Local Drupal password sign-in for editors and administrators against stolen or guessed passwords | Users enroll an app once and enter a time code at each sign-in; admins handle lost-device resets | Local accounts on a site with no central identity provider, or as a fallback for named admin accounts |
| Recovery codes (TFA module) | Access to an account when the authenticator device is lost, replaced or wiped | Users must store single-use codes safely; a lost code list without a reset path locks people out | Every site that enables TOTP, paired with a documented reset procedure owned by a named administrator |
| Role-based enforcement (TFA settings) | Makes second-factor enrollment mandatory for chosen roles, such as content administrators or site builders | Forced enrollment at first sign-in adds a setup step; roles must be reviewed when staff change responsibilities | Sites where only privileged roles need a second factor and anonymous or basic authenticated users do not |
| Identity provider MFA via OpenID Connect or SAML | Sign-in policy, second factor and account lockout are enforced centrally for every application, not only Drupal | Users sign in through the corporate identity page; Drupal admins manage role mapping and account linking instead of enrollment | Organizations with an existing identity provider, multiple applications or a policy that requires MFA across the estate |
| Mixed population with local break-glass accounts | Keeps a local administrator path if the identity provider or its MFA service is unavailable | Break-glass credentials must be stored, tested and audited; more accounts to review | Federated sign-in is in place but operators need a controlled way back in during an outage |
| Anonymous and public-facing account populations | Does not usually apply; second factors protect sign-in, not public content | Adding MFA to customer or commenter accounts raises drop-off with little security benefit for most sites | Rarely, where a customer account holds sensitive personal or transactional data; confirm the requirement with the data owner |
Setting up TFA enforcement on a Drupal site
This sequence takes a Drupal site from a version check to enforced two-factor sign-in for editor and administrator roles, with tested enrollment, recovery and a staged rollout to existing accounts. Each step ends with a check so the team knows whether to move on.
Confirm Drupal and PHP versions
The site owner and the lead developer record the Drupal core version in use and check it against the Drupal core release schedule, then confirm the PHP version against the Drupal.org PHP requirements for that release. Drupal 10 requires PHP 8.1 or later, Drupal 11 requires PHP 8.3 or later and Drupal 12 requires PHP 8.5 or later, and no supported Drupal version runs on PHP 7. Also note the scheduled end-of-life date for the current core line, because it sets when the site must move and when this configuration must be tested again. Done when the team has a written version record, and the PHP runtime on staging matches the requirement for that core version.
Install the TFA module with Composer
A developer adds the contributed TFA module to the Composer project on a development branch, using the version line that matches the installed Drupal core, and commits the updated composer.json and composer.lock files. Installing through Composer keeps the module version in source control so that later core and module updates are reviewed together. Done when the module code is present in the repository and the build pipeline completes on the branch without dependency conflicts.
Enable the module on staging
A developer enables the module on a staging copy of production, either through the Extend page or with Drush, and exports the resulting configuration so the change is tracked. Confirm that the module's required dependencies are enabled and that no new warnings appear in the status report. Done when the staging site shows the module as enabled, the configuration export contains the new settings, and a second deployment of the same code reproduces the state without manual steps.
Configure allowed methods and recovery codes
The site owner and developer decide which second factors the site accepts, such as time-based one-time password apps, and confirm the recovery code settings, including how many codes a user receives and how they are displayed. Check which methods the module offers in the installed version and confirm with the security team whether any additional method is acceptable under the organization's policy. Done when the chosen methods and recovery settings are documented in the configuration, and a test account can complete setup with each allowed method.
Require enrollment for editor and administrator roles
The developer assigns the TFA requirement to the editor and administrator roles in the module's role settings, leaving other roles unchanged until the rollout plan is approved. Confirm that the setting applies to the roles as intended, and that users in those roles are prompted to set up a second factor on their next sign-in. Done when a staging account in each role is redirected to enrollment before reaching content or admin pages, and an account outside those roles is not affected.
Test enrollment and recovery with staging accounts
The QA lead creates test accounts for each affected role and runs the full path: first sign-in, enrollment with an authenticator app, sign-in with a one-time code, use of a recovery code, and a reset by an administrator. Repeat the test for failed codes and expired sessions, and confirm that recovery codes are single use. Done when every path passes on staging, the results are recorded with dates and tester names, and the team agrees on the support steps for a locked-out editor.
Plan the rollout to existing users
The project lead schedules the production change with the content and operations teams, communicates the enrollment steps to affected users, and sets the order in which roles are switched on. Agree who handles lockout requests and how administrators reset a second factor for a user. Repeat the core update and TFA regression tests whenever the Drupal core release schedule brings a new security or bugfix release, because a core update can change how sign-in and forms behave. Done when the rollout plan is approved, support contacts are named, and a dated retest is in the operations calendar.
Security and operational considerations for second-factor sign-in
Turning on second-factor sign-in for Drupal editors and administrators creates new places where accounts can be lost, secrets can leak and failures can go unnoticed. The cards below cover the decisions that keep the module protective after launch: how recovery codes are handled, how lockouts are resolved, where secrets are stored, what gets logged and how quickly the module is patched.
Recovery code handling
Recovery codes let a user sign in when their authenticator app is lost, so each one is effectively a password. Decide before launch who issues codes, how users store them (a password manager, not a shared document or a sticky note) and whether codes are single use. Check that a used code cannot be reused and that a user can regenerate the set after a device change. Ask the implementer to confirm how the module behaves in your version.
Lockout and helpdesk procedure
A locked-out administrator is a common cause of emergency access requests on privileged accounts. Write a helpdesk script that verifies identity through a channel other than the sign-in form, resets second-factor enrollment and records the reason. Keep at least one break-glass administrator whose recovery path is tested and stored under your privileged access controls. Agree in advance who may approve a reset for an administrator account.
Secrets and encryption settings
TOTP seeds are secrets that must be protected at rest, so confirm where the module stores them and which encryption key or settings protect them. Keep the site's secret material out of version control and out of exported configuration, and plan how it is rotated. Include the database backup in your restore tests, because a backup with seeds but a lost key is unusable and a backup with the key but no seeds is a security exposure.
Logging failed second-factor attempts
Repeated wrong codes on an editor or administrator account can signal password theft or a phishing kit that has already captured a password. Decide which events to record (failed codes, lockouts, enrollments and resets), where those logs go and who reviews them. Forward them to your central log platform so they survive a site compromise. Confirm that logs do not capture submitted codes or seeds.
Prompt patching of the module
The Drupal Security Team publishes advisories for contributed projects as well as core, and fixes ship in scheduled security windows. Because the second-factor module sits on the sign-in path, a vulnerability there affects every privileged account. Subscribe to advisories for the module, assign an owner who can apply the update within your change process and test sign-in on staging after each release.
Keeping the module on a supported core
Second-factor enforcement only protects accounts while the site runs a supported Drupal core. Check the core release schedule against your planned upgrade window so that a move to a new major version does not leave the module behind. Test the module against each new core release in staging before it reaches production.
When to push multi-factor authentication to the identity provider instead
Push MFA to the identity provider when your organization already runs one for workforce sign-in and enforces multi-factor authentication there. In that case, centralizing enforcement avoids a second enrollment system, a second set of recovery procedures and a second place where policy can drift. The TFA module still has a role in that model only if you keep local editor or administrator accounts, so the decision is about which login path editors actually use, not just which tool is preferred.
Two contributed modules make federated sign-in possible. The SAML Authentication module (*samlauth*) lets a Drupal site act as a SAML service provider, and its 8.x-3.14 release supports Drupal 10.3 and later and Drupal 11, according to its Drupal.org project page. The OpenID Connect module lets external OpenID Connect providers authenticate users and can create accounts on first sign-in. Confirm the release that matches your Drupal version and check the project page for the provider clients you need before you commit to either module.
Before switching, design and test three things. First, account mapping: decide how the identity provider's subject or email claim links to an existing Drupal user, how roles are assigned from provider groups, and what happens to accounts that no longer exist upstream. Second, admin fallback login: keep a tested path for a local administrator to sign in if the identity provider is unavailable, and store its credentials under your break-glass procedure. Third, session behavior: confirm session lifetime, logout propagation and how a revoked account is cut off on the Drupal side. Each item should be verified in a staging copy of the site with a real provider test tenant.
Limits to confirm before you commit to a TFA design
Which Drupal core and PHP versions does the TFA module release support?
Check the compatibility statement on the module's project page for the exact release you plan to install, because support depends on both Drupal core and the PHP version your hosting runs. Drupal 10 requires PHP 8.1 or later, Drupal 11 requires PHP 8.3 or later and Drupal 12 requires PHP 8.5 or later, according to the Drupal.org PHP requirements page, so a site on an older PHP version cannot take a current release of either major version. Record the core version, the PHP version and the module release in your design document, then confirm the pairing in a staging copy of the site before you commit. Plan the same check again before each Drupal major upgrade, since the supported pairing changes with each version.
Does the TFA module support the second-factor methods our users need?
Confirm each method you intend to allow against the module documentation rather than assuming it is available. Typical choices include time-based one-time password apps, recovery codes and any hardware or email-based methods, and the available methods can differ between module releases and between contributed plugins. Write down the list of methods your editors and administrators must be able to use, then test enrollment and sign-in for each one with a real account in staging. Also check how a user who loses a device is handled, since the recovery path is usually where a method gap shows up.
How does TFA behave on a multisite install and with Drush or other CLI access?
Multisite behavior needs a specific test, because each site has its own users, roles and configuration, and a setting that is correct on one site may not carry over to another. Confirm whether enforcement and enrollment settings are configured per site and whether any shared configuration is exported and imported across sites. For Drush and other command-line access, confirm whether the module applies its checks to command-line logins, whether scripts that use one-time login links are affected, and how automated jobs authenticate. Document the answer for each case, because deployment pipelines and maintenance scripts often depend on it.
How does TFA interact with SSO and our admin fallback accounts?
If users sign in through a SAML or OpenID Connect provider, the identity provider may already enforce multi-factor authentication, so Drupal-side TFA can add a second prompt or may not apply at all. Test each combination of sign-in path, including local accounts, SSO-only accounts and any break-glass administrator account, and confirm which prompts a user sees. Keep at least one fallback administrator path that you have tested, and make sure enforcement settings cannot lock every administrator out at once. Record who can disable TFA for a locked account and how that action is logged.
What happens to existing sessions and API tokens when TFA is enabled?
Confirm this in the module documentation and in staging, because behavior for sessions that were already open and for token-based access is not something to assume. Check whether enabling enforcement logs out current sessions, whether users who have not yet enrolled are blocked on their next request, and whether REST, JSON:API or other token-based clients can still authenticate. Also confirm whether any scripted integration uses a basic-auth or API user that would be affected by a second-factor prompt. Plan a rollout window and a communication to affected users before you switch enforcement on in production.
Who maintains the module and how quickly are security fixes released?
Check the maintainer activity, release history and open security advisories on the module's Drupal.org project page before you depend on it. Drupal's security releases follow a published schedule, with security releases on the third Wednesday of the month according to the Drupal core release schedule, and the Drupal Security Team handles advisories for contributed projects. Ask whether the module has a current security contact and whether the release you plan to use is covered by a supported branch. Record the review date in the design so the choice is revisited at each upgrade cycle.
Can our own team verify these limits, or do we need a partner?
Your team can answer most of these questions with the module documentation and a staging environment that matches production. The work is mainly systematic testing: one matrix of sign-in paths, roles, methods, multisite sites and CLI cases, with a recorded result for each cell. A partner is useful when the matrix is large, when the site is integrated with SSO or several sites, or when staff lack time to run it. DeployOpen can plan and run this verification as part of a fixed-scope engagement, with the test cases and results agreed in writing before work starts.
What a DeployOpen two-factor engagement covers
A DeployOpen two-factor engagement covers the planning, configuration, testing and documentation of second-factor sign-in for your Drupal site, with the scope agreed in writing before work starts. The first stage settles the enrollment and enforcement model: which roles must enroll, which may defer, how long a grace period runs, which sign-in paths (the standard login form, one-time login links, and any SSO route) must be covered, and who owns exceptions. These decisions are made with your security and editorial leads before any module is installed, because they determine what the configuration has to do. Where your organization already runs an identity provider, the same stage decides whether Drupal keeps its own second factor or relies on the provider's MFA, and records that choice with its reasons.
The build stage installs and configures the TFA module on the agreed roles, sets the permitted second-factor methods, and wires in recovery codes and any role-based enforcement rules. Where SSO is in scope, the work also covers the integration points with the identity provider, such as the SAML Authentication module (samlauth) or the OpenID Connect module, so that a user is not challenged twice or left without a valid path. The verification stage tests each path a real user can take, including lost device, lost recovery codes, and a locked account, and confirms that an administrator can reset enrollment without disabling protection for everyone else. Confirm with your Drupal team which module versions your current Drupal release supports before scoping, since compatibility is checked per release.
The engagement ends with runbooks for help desk staff, the enrollment and reset procedure, and a record of configuration and test results that your team keeps. DeployOpen prepares these controls and this evidence so that your organization or an independent auditor can review them against the requirements that apply to you. DeployOpen does not issue audit reports, attestations or certifications, and the assessment itself remains with your auditor or certification body. Ask any proposal to name the deliverables, the environments tested, the handover format and what happens to the runbooks after the initial work, since ongoing support is a separate, optional retainer.
How DeployOpen scopes and supports Drupal two-factor work
A two-factor rollout touches configuration, roles, recovery, identity decisions and the login flow itself. DeployOpen handles these as one written scope, priced from that scope, and deployed inside your own infrastructure.
Fixed scope agreed in writing
Most engagements are fixed-scope, so the roles that must enroll, the TOTP and recovery code behavior, the enforcement dates and the handover items are agreed in writing before work starts. Ask for the scope to list which roles are covered, which sign-in paths are included (including any API or Drush access), and who signs off on the rollout. Changes after sign-off go through a written change to the scope.
Quotes derived from scope
DeployOpen does not publish a price list. A quote follows from the written scope, so the main cost drivers are the number of roles and environments, whether the identity provider decision is still open, and how much recovery and help desk material you need. When requesting a quote, ask which items are one-time build work and which are recurring support or upgrade effort.
Security testing of the login flow
On request, DeployOpen can test the resulting sign-in flow, including enrollment, code verification, recovery codes, lockout behavior and session handling after enforcement. Testing is scoped separately from the build so the results are independent of the people who configured the site. Confirm the test scope, the environment used and how findings are reported before work starts.
Deployment in your infrastructure
DeployOpen plans, builds and hardens Drupal inside your own cloud accounts, data centers or air-gapped networks, so the site, its database and any recovery material stay under your control. Confirm where secrets, backups and logs for the two-factor setup are stored, and who holds administrative access to the hosting environment.
Retainers for support and upgrades
Ongoing support, upgrades and continuous testing are available as retainers. For two-factor work this typically covers reviewing TFA module updates, checking enforcement after core releases and handling help desk escalations for locked-out editors. Ask what response expectations the retainer sets, since no service levels are published in advance.
Part of Chainscore Labs
DeployOpen is a Chainscore Labs company and works only on open-source platform implementation, security testing and compliance readiness. We prepare systems and evidence for compliance assessments but do not issue audit reports or certifications, so independent auditors remain responsible for any formal assessment of your controls.
