Why optional 2FA fails
Every team that "offers" two-factor authentication ends up with the same enrolment curve: the security-minded people enable it in week one, and the busiest, most privileged accounts never do. Those are precisely the accounts an attacker wants. Making it mandatory is the whole point, and the difficulty is entirely about doing it without locking people out or drowning support in tickets.
This guide assumes the free Dragon Login Security is installed and a few people have enrolled voluntarily, so you know it works on your site. If not, start with securing the WordPress login.
Step 1: decide the policy by role
Dragon Login Security Pro enforces per role, so the policy can be proportionate:
| Role | Policy | Why |
|---|---|---|
| Administrator | Required, short grace period (7 days) | Can install code; the account that matters most |
| Editor, Shop Manager | Required, 14 to 30 days grace | Publishes and handles orders; larger group, more hand-holding |
| Author, Contributor | Required with a longer grace, or optional | Low privilege; enforce if they log in from shared machines |
| Subscriber, Customer | Optional, unless accounts hold payment or personal data | Friction costs sign-ups |
Two enforcement modes exist. Grace period: the user can log in normally until the deadline, sees a reminder each time, and is blocked after. Block until enrolled: the next login goes straight to enrolment. Use grace for the rollout, and block-until-enrolled for new accounts created after it.
Step 2: take the friction out with trusted devices
The most common objection is "I don't want to type a code every morning". Trusted devices answers it: after a successful second factor, the browser can be remembered for a period you choose (30 days is a sensible default for staff; shorter for shared machines), and is not challenged again until it expires. Combine it with passkeys, which take one touch, and the daily cost of 2FA rounds to zero.
Set the trust period before you announce the rollout, so the first experience people have is the easy one.
Step 3: turn on risk-based re-challenge
A trusted device is a convenience, not a blank cheque. With risk-based re-challenge on, a login from a new IP address or device triggers a fresh second-factor challenge even inside the trust window, and sends an alert. That is the control that catches a stolen session cookie or a password used from somewhere new, and it is the one that auditors ask about.
Point the alerts at an inbox someone reads. A re-challenge alert at 3am from a country nobody is in is the kind of message that should wake somebody.
Step 4: announce, then enforce
Send one short message before the grace period starts. Say what is changing, when, how to enrol (Users, then Profile, then Login Security), that passkeys are the easy option, and where backup codes go. Then switch enforcement on. The reminder on every login does the rest.
During the grace period, watch the compliance report: it lists every user by role with their enrolment status, and exports as CSV. The day before the deadline, contact the stragglers by name. On the deadline, the ones who ignored it are blocked at their next login and enrol then. That is not a failure of the rollout; it is the rollout working.
Step 5: prepare support for the three real cases
- Lost phone. Backup codes first. If none remain, an administrator runs
wp dragon-login-security disable-2fa <username>and the user re-enrols. - New laptop. The first login from it is a re-challenge by design. A passkey synced through iCloud or a password manager carries over; an authenticator app on the old phone still works.
- Shared computer. Do not trust the device. Shorter trust periods, or none, for roles that use shared machines.
Write these three answers down once and support tickets become copy-and-paste.
WooCommerce customers
If customers hold stored payment methods, subscriptions or personal data, the Pro edition extends 2FA to customer accounts on the front end, optional or enforced. Keep it optional for ordinary shops: the drop in conversions is real and the accounts are not worth much. Enforce it where an account is worth stealing.
Proving it
The compliance report is the evidence. Export it at the end of the rollout and file it with your other security records; if you follow the CRA checklist, it is the artefact behind the "2FA for administrators" item.
Checklist
- Policy per role decided and written down
- Trusted-device period set
- Risk-based re-challenge on, alerts going to a monitored inbox
- Staff message sent with enrolment steps
- Enforcement enabled with a grace period
- Stragglers contacted before the deadline
- Compliance report exported and filed