Login Policy » Email-only login
TL;DR
WP fail2ban lets you keep public usernames available throughout WordPress while requiring email addresses for normal authentication. It does not hide usernames; it stops treating them as valid login identifiers.
A username attempt receives a plain Forbidden response and goes to the soft filter. It may come from a bot, but it may also come from a user with an old saved credential, so repetition gives fail2ban the confidence to act.
WP fail2ban Free includes the control, configured in wp-config.php. Premium lets you configure it through WordPress admin and use the event history to plan the change around the people who still log in with usernames.
Separate public identity from login
Your authors can keep public names, author pages, and URLs. Your themes, plugins, or integrations can continue using public user information. The username remains available wherever the site needs it; the email address becomes the identifier WordPress accepts at login.
An attacker may still discover that alice is an author on your site, but alice is no longer part of a valid login. Publishing a username no longer automatically tells an attacker what to type into the login form.
An email address is not a secret. It may be published, leaked, or discovered somewhere else, and an attacker who already knows it can still try to authenticate. The benefit is precise: WordPress no longer supplies a valid login identifier as a side effect of publishing normal information about an author.
Give username attempts their own signal
Many bots enumerate a username and immediately try it at login. Once you require an email address, WP fail2ban refuses that attempt and records it separately from an ordinary failed password.
The event remains soft because a legitimate user, browser, or password manager may still present a username after the policy changes. A configured fail2ban jail can allow for an isolated mistake and act when the pattern repeats.
Plan the change from real activity
Premium lets you prepare for email-only login before you change what WordPress accepts. Filter the event log for successful logins, and you can see at a glance who is still using a username. You can remind those users to switch while their existing login still works.
As successful username logins tail off, the log shows you when enough people have changed their habits to make the policy change safely.
People who have logged in with usernames for years may need time to update saved credentials, and a large membership or publishing site may need you to manage the change carefully.
The event log turns that migration from guesswork into a change you can plan around your users.
Keep the boundary precise
Email-only login does not hide usernames, strengthen weak passwords, prevent stolen credentials from working, or replace two-factor authentication or passkeys. It removes the username from normal authentication while leaving the public WordPress features that use it alone.
If your site exposes email addresses as readily as usernames, the control provides less separation. If an integration genuinely needs username authentication, you may need a different login policy.
