Enforce 2FA in WordPress: pilot, recovery and rollout
Updated by Nazmul Hasan Rupok on
When you set out to enforce 2FA, WordPress gives you nothing to do it with: two-factor sign-in is something each person turns on for themselves, or never does. The accounts that most need it, the ones that can install plugins and publish, are often the ones whose owners are busiest. A requirement closes that gap, as long as it is rolled out so that nobody ends up staring at a page that refuses them.
This guide is the rollout plan: which roles to cover, how long to give people, what to have ready before you press save, what to tell your team, and what happens on the day the grace period ends. WordPress user roles security covers the setting itself in brief, and WordPress two-factor authentication covers setting up your own account.
Quick summary
- Start with Administrator and Editor, plus Shop manager on a store. Leave customer and member roles out.
- Have your recovery link and printed recovery codes ready first. BetterShield checks them when you add a role.
- The default grace period of 14 days suits most teams. Seven works for a small team you can talk to.
- Tell people before you save: what is coming, which app to use, where to set it up, and how long they have.
- After the grace period, the dashboard sends people to setup until they finish. The enrollment policy does not itself block the initial password sign-in.
How enforcement works, and why that matters
In BetterShield, Require two-factor of a role on BetterShield › Protection › Two-Factor is enforced inside the dashboard, after the password. During the grace period, people see a countdown on every dashboard page, and get one email three days before it ends. After it, every dashboard page sends them to the setup screen until they finish. Their profile, signing out, the front of the site and tools that use the REST API keep working throughout.
That design decides how a rollout can fail. The policy directs dashboard users to a setup form instead of rejecting their initial password sign-in. A broken enrollment flow or a missing factor can still prevent them from doing their work. Safe mode, from your recovery link, stands the requirement down entirely.
One thing to know up front: the requirement asks for app codes. A passkey does not satisfy it, even one that signs in without a code.
The deadline belongs to each account
Follow the rollout from preparation to a verified enrollment.
- Before the requirement
Prepare recovery and a pilot.
- During the grace period
The account gets time to enroll.
- After the grace period
Dashboard work waits for setup.
Before the requirement
- What this means
- Enroll your own administrator first. A usable recovery route and a second administrator reduce the chance that one device stops the rollout.
- Your next check
- Test an Editor account on staging, including its profile and the enrollment screen.
During the grace period
- What this means
- The clock starts when the account first meets the requirement. Saving the policy is not a universal calendar deadline for every dormant user.
- Your next check
- Track who has completed setup and contact people who have not, using your own enrollment list.
After the grace period
- What this means
- The free plugin redirects covered dashboard users to enrollment. It does not turn every front-end or API route into a two-factor gate.
- Your next check
- Confirm enrollment, a fresh sign-in and recovery before extending the policy to another role.
Step 1: Enforce 2FA for editors and administrators first
Cover the roles that can change the site, then widen.
| Role | What it can do | Our advice |
|---|---|---|
| Administrator | Install plugins, change settings, manage users | Always |
| Editor | Publish and change everyone’s content | Yes |
| Shop manager | Run the store from the dashboard | Yes, on a store |
| Author, Contributor | Write their own posts | A second wave, once the first group is done |
| Subscriber, Customer, member roles | Read, buy, use their account | No |
Customers are a special case. WooCommerce keeps them out of the dashboard, and the requirement is asked in the dashboard, so ticking Customer would never send them to setup; at most their Sign-in security tab would show a countdown. The screen says so when you tick such a role. Customers can still turn two-factor on themselves under My Account › Sign-in security.
Roles added by other plugins are listed too. Look at what each one can do before ticking it: a role that edits content belongs in the first wave, a role that only reads does not.
Step 2: Get your way back in ready
The requirement covers you as well, so set up your own two-factor before you save. Then make sure you can get in on the day something unexpected happens:
- A recovery link that works, stored outside the site.
- Printed recovery codes, which do not depend on email.
When you add a role, BetterShield checks for these. If there is no working link and no unused printed code, or the recovery options were not checked in the last day, Check the way back in first opens with the reason. Check now runs the check and tries again, Open Recovery takes you to fix it, and Go ahead anyway saves regardless, which the activity log records as “Sign-in change made without a recovery check”. See Set up recovery, and WordPress 2FA backup codes for how personal backup codes differ from the site’s printed codes.
Step 3: Pick a grace period
Grace period, in days runs from 0 to 90, and the default is 14.
| Team | Grace period |
|---|---|
| Two or three people you talk to every day | 7 days |
| A typical team, or anyone who travels | 14 days |
| Freelancers, volunteers, people who log in monthly | 30 days |
| People who have all set it up already | 0 |
How the clock runs is what makes this safe to switch on:
- Each account’s window starts the first time it opens a dashboard page while its role is ticked. Accounts that have existed for years get the full window.
- An account that never opens the dashboard, its profile or My Account › Sign-in security never starts its clock.
- Untick a role and tick it again later, and everyone in it gets a fresh window.
Zero sends people to setup on their next dashboard page. Use it only after the intended group and recovery flow have been tested.
Step 4: Tell people before you save
A short message saves most of the questions. Cover:
- What: from a date, signing in to the dashboard also needs a six-digit code from an app.
- Which app: any app that makes six-digit codes. BetterShield names 1Password, Google Authenticator, Microsoft Authenticator, Authy and Bitwarden.
- Where: Profile › Two-factor sign-in, or Protection › Two-Factor for people who manage BetterShield. It takes about two minutes.
- The backup codes: ten codes shown once at the end of setup. Keep them in a password manager or on paper, away from the phone.
- How long: the grace period, and that a countdown will show on every dashboard page, with one email three days before it ends.
- Who to ask: the person who can turn it off for them if their phone is lost.
For people without a smartphone, any app that makes six-digit codes works, such as a password manager that does.
Step 5: Save, then watch progress
Tick the roles under Require two-factor of a role, set the grace period, and press Save requirement.
From then on, people in those roles see “This site asks accounts like yours to use two-factor sign-in. You have 14 days left to set it up.” with Set it up now on every dashboard page. Their profile’s Two-factor sign-in section says much the same, above Set up two-factor.
To follow along:
- The Two-factor required for tile names the roles.
- Each setup appears in the activity log as “Two-factor turned on”.
- On any account under Users, the Two-factor sign-in section says whether it uses two-factor.
A per-role report of who has a second factor is part of BetterShield Ultra, as the Sign-in report.
What happens when the grace period ends
The person still signs in with their password. Every dashboard page then takes them to the setup screen: their profile for most roles, or Protection › Two-Factor for people who manage BetterShield. The profile says “This site requires two-factor sign-in for your role.” The post editor and every other dashboard screen wait until they finish, and the moment they do, the dashboard is theirs again.
Two details trip people up:
- Someone who set up two-factor and later turns it off keeps their original deadline. If it has passed, the dashboard sends them straight back to setup.
- A person who has only a passkey is still asked for the app codes.
If someone is stuck, an administrator can open their account under Users and press Turn off two-factor for this account under Two-factor sign-in, so they can set it up again. Two-factor with an app covers lost phones step by step.
Agencies and multisite networks
On a multisite network, a network administrator sets Require two-factor across the network on BetterShield › Network. It is a floor: each site enforces the network’s roles plus its own, and a site cannot untick a role the network requires. Where both set a grace period, the shorter applies, and each site’s clock still runs from when that site first saw the account.
For separate client sites, set the requirement on one, then move it with wp bettershield settings export and wp bettershield settings import <file> --apply --user=<an administrator>. An import without --apply only shows what would change. The two-factor requirement travels; people’s two-factor setups stay on their own site.
Tell the client’s team before you save, not after, and make sure the client’s own administrator has a recovery link of their own.
Run a pilot with a clear completion check
Use a staging site with a test Editor before changing a busy team’s policy. Keep a working administrator session available. Set a zero-day requirement for that test role there, then sign in as the test user: ordinary dashboard work should lead to enrollment, the profile should remain reachable, and completing setup should restore dashboard access. Test with the same extensions and sign-in forms the live site uses.
On the live site, use a grace period people can meet and record three facts per person: enrollment completed, a fresh sign-in succeeded, and backup codes are stored somewhere they can recover. Do not collect the codes themselves. A reminder email being sent is not proof that the person received or read it.
Worked example (fictional): a small publication has an administrator, three editors and a contributor who visits monthly. The administrator pilots the change with one editor, then covers the remaining editors. The contributor gets a separate invitation and support window. The team does not assume that every account’s deadline is exactly fourteen days after the administrator saved the setting.
If enrollment is unavailable or a custom login flow behaves differently, stop widening the rollout. Identify the affected role and flow, help that person recover, and retest before continuing. A grace period reduces disruption; it does not repair a broken form or replace a recovery plan.
Common mistakes
- Saving before setting up your own. You are in the roles you tick. Set yours up first.
- Ticking Customer. It asks nothing of customers, because they never see the dashboard. Point them to My Account › Sign-in security instead.
- A zero-day window for a team that has not heard about it. It sends everyone to setup on their next dashboard page. Announce first, or use 14 days.
- Expecting passkeys to count. The requirement asks for app codes.
- Leaving tools on the account password. A tool that signs in over XML-RPC with the password is refused once that account uses two-factor. Give it an application password.
- Running two-factor in two plugins. People can be asked twice. Pick one.
Frequently asked questions
Does enforcing 2FA lock people out of WordPress?
The free plugin requires enrollment inside the dashboard after password sign-in, with a grace period. Other rules, a lost factor or an unusable enrollment screen can still prevent access. Pilot the flow, keep recovery ready and verify completion.
Can I enforce 2FA for editors only?
Yes. Tick Editor under Require two-factor of a role and leave the rest unticked. We recommend adding Administrator too.
Do passkeys count toward the requirement?
No. It asks for an authenticator app. A passkey is a good addition, and on a two-factor account one unlocked with a fingerprint, face or PIN signs in without a code.
What about WooCommerce customers?
They are not asked, because WooCommerce keeps them out of the dashboard where the requirement lives. They can turn two-factor on themselves under My Account › Sign-in security.
Can I enforce 2FA across a whole multisite network?
Yes. Require two-factor across the network on BetterShield › Network sets roles for every site. Each site can add roles but not remove the network’s.
Conclusion
Enforcing two-factor is mostly preparation: your own setup and recovery first, the powerful roles before the rest, a grace period that fits your team, and a message before the save. The requirement then does the reminding for you, while your pilot and recovery checks handle the cases a reminder cannot solve.
BetterShield is free on WordPress.org. Every option is in Require two-factor.