This page describes the settings for passkeys, two-factor authentication (2FA), reCAPTCHA, WooCommerce and shortcode integrations, allowlisted IP addresses, and related Login Security data. For help setting up or using a passkey, see Passkeys. For help setting up 2FA or logging in with 2FA, see Two-Factor Authentication.

Authentication Options

User Summary

This table counts the total users for each user role and shows how many users have 2FA or passkeys active or inactive. On sites with a large number of users, counts are replaced with a “Show User Counts” button, since counting WordPress users by role can be slow. Clicking the button will show the table, but may take several seconds on some sites.

If you have required 2FA for some roles, the “2FA Inactive” column will also include a link to view users who will have 2FA required but have not yet set it up in their accounts. Click the link to see which users are still in the grace period, and which have been locked out.

If you have required passkeys for some roles, the passkey inactive count can similarly help you find users who have not registered a passkey yet, including users who are still in the grace period or who have been locked out.

Users who have custom capabilities outside of a normal role or users who have multiple roles are counted under “Custom Capabilities / Multiple Roles”.

Note: For multisite installations, only the main site is currently counted here. The WordPress “Users” page for each sub-site can be used to see which users have 2FA activated or inactive, and users who have been locked out when 2FA is required for their role. Passkeys on multisite are currently limited to super-admins.

Passkeys

A passkey is a password replacement that lets a user sign in with a device unlock method such as fingerprint, face recognition, a device password, a PIN, a security key, or a password manager. Administrators can choose which roles can use passkeys.

Enable Passkeys

Passkeys are globally disabled by default on new installations. When an administrator turns on Enable Passkeys for the first time on a single-site installation, all supported roles are set to Optional. Users in those roles can register and use passkeys, while username/password login remains available unless an individual user chooses Passkeys only for their own account.
Turning off Enable Passkeys prevents users from registering or signing in with passkeys, but it does not delete registered passkeys or saved role settings. Those settings are restored when passkeys are turned back on.

Who Can Use Passkeys?

Passkeys can be enabled for individual roles, except on multisite (see below). Each user can register and manage their own passkeys when their role is enabled.

Important: Before enabling passkeys for other users, test passkey registration and login with any login-related plugins or theme customizations on the site.

For each role, you can choose from the following:

• Disabled – Users in this role cannot register or use Wordfence passkeys.
• Optional – Users in this role can register and use passkeys. Username/password login remains available unless the individual user chooses “Passkeys only” on their My Passkeys page.
• Required – Users in this role must use a passkey after any configured grace period expires. Username/password login is blocked for those users.

Important: Before requiring passkeys for a role, users in that role should register more than one passkey or use a password manager that syncs passkeys to more than one device. Users should test passkey login in another browser, another device, or a private browsing window before logging out.

On multisite installations, passkeys are currently limited to Super Admins, and, once enabled, Super Admins are set to Optional by default.

Requiring passkeys for WooCommerce customers is not recommended. If customers need passkey access, use the Optional setting and enable WooCommerce integration or the Passkey/2FA management shortcode, so customers can manage passkeys outside wp-admin.

Passkeys are tied to the domain where they were originally registered, as part of the WebAuthn standard, which prevents them from being used in phishing attacks. If you are migrating a site to a new domain, passkeys from the original domain will not work on the new domain. If you have set some roles to “Required” for passkeys, or have disabled password-based logins for individual users, you will need to allow password logins for them. After migration, you will need to change “Passkey Credential Domain” and “Allowed Passkey Hostnames” to match the new site, which will allow registering passkeys on the new domain.

Passkey Advanced Settings

Passkey Credential Domain

The Passkey Credential Domain controls which domain passkeys are created for. Passkeys are connected to a specific domain, which is known as the “WebAuthn Relying Party ID”. Most sites should leave this unchanged.

When no value is set, Wordfence uses the site’s main domain based on the current Home URL, falling back to the Site URL if needed. After passkeys have been registered, Wordfence preserves the credential domain used by existing active passkeys unless an administrator changes the Passkey Credential Domain or all passkeys are removed.

Enter a hostname here only if you need to use a different credential domain. For example, example.com permits passkeys on www.example.com, while www.example.com limits passkeys to www.example.com and its subdomains.

Changing the Passkey Credential Domain after users have registered passkeys can block existing passkeys. If the new domain is different from, or does not include, the domain existing passkeys were created for, affected passkeys must be re-registered. This is a security feature of passkeys, that prevents a valid passkey from being used on a phishing domain.

Staging and development sites that use a different domain from the live site cannot share passkeys with the live site. Do not push a staging hostname into the live site’s Passkey Credential Domain setting.

Allowed Passkey Hostnames

Passkey login and registration responses are accepted only from trusted login hostnames. Most sites can leave this list unchanged.
Defaults include this site’s configured Site/Home URLs, the Passkey Credential Domain when set, and the base/www hostnames for the domain derived with the Public Suffix List.

This setting can be used if your site uses something like blog.example.com, if it has not been populated automatically. Enter one hostname per line, without a protocol, port, or path. Only list hostnames that you control and actively serve for login.

Existing passkeys may be blocked on any hostnames or ports removed from this list. Make sure every hostname and port users use to log in remains listed.

Public Suffix List

Wordfence uses the public suffix list (maintained by Mozilla) to determine the default passkey credential domain based on this site’s full URL. You generally do not need to update this list beyond the original fetch, but you may do so if significant changes have occurred to the hostname used by the site. It might be necessary when migrating a site to a new domain with a different TLD, where existing passkeys would not be able be used, for example.

If updating the public suffix list would change the site’s default passkey credential domain, Wordfence asks for confirmation because existing passkeys may stop working unless a Passkey Credential Domain is set.

Passkey sign-in counter validation

Passkey sign-in counters can help detect the rare case of cloned passkeys, but some authenticators always report zero or may reset the counters. The default setting balances strictness and reliability by rejecting non-zero counters that are not higher than the stored counter.

You can choose from the following:

• Allow any counter value.
• Reject non-zero counters that do not increase (recommended).
• Reject counters that do not increase or reset to zero.

If counter validation blocks a passkey that should be valid, the user may need to remove and re-add that passkey.

Two-Factor Authentication (2FA)

Two-factor authentication protects username/password login by requiring a second authentication method. Administrators can choose whether each role can use or require 2FA once 2FA is enabled.

Enable 2FA

2FA is globally disabled by default on new installations. When an administrator turns on Enable 2FA on a new single-site installation, all supported roles are set to Optional. Users in those roles can choose to set up 2FA, but 2FA is not required unless an administrator changes a role to Required.

On upgraded sites or sites that already have saved 2FA role settings, Wordfence preserves those settings. On some upgraded sites, only Administrators may be set to Optional while other roles are Disabled until an administrator changes the role settings. Review Who can use 2FA? after enabling 2FA to confirm which roles are Disabled, Optional, or Required.

Turning off Enable 2FA prevents users from signing in with 2FA, but it does not delete existing 2FA credentials or saved role settings. Those settings are restored when 2FA is turned back on.

Who can use 2FA?

2FA is required only for username/password login. If passkeys are enabled, a valid passkey login is a substitute for the 2FA step. If passkeys are enabled and a role is set to Required for passkeys, that role’s 2FA setting cannot be changed until the passkey role requirement is changed.
For each role, you can choose from the following:

• Disabled – This role cannot use 2FA.
• Optional – This role can use 2FA, but is not required to enable it.
• Required – This role will need to have 2FA enabled in order to log in with a username and password. Users are granted a grace period by default, from the date that this option is enabled.

Important: When 2FA is required for admins, the requirement does not apply until at least one admin has set up 2FA. This prevents all admins from being locked out by mistake. Requiring 2FA for customers on e-commerce sites is not recommended as some customers may experience difficulties setting up or using two-factor authentication. Instead, use the Optional mode for users with the customer role, which will allow customers to enable 2FA, but will not require them to do so.

Please note that some users will lose their 2FA codes over time, often from a lost or broken phone. If the user also did not save their backup codes, or saved them on the same device, they may not be able to log in. You may need to disable 2FA for them, but you should validate their identity, to be sure that someone is not trying to take over their account with a stolen password.

By default, users must be able to see wp-admin pages in order to set up 2FA. If you use WooCommerce, you can enable “Show Wordfence Login Security menu on WooCommerce Account page” to allow customers to manage 2FA from their account page. If you use a membership or forum plugin that does not allow low-privileged roles to see wp-admin, you can enable the Passkey/2FA management shortcode and place a shortcode on the user’s account page.

2FA Advanced Settings

Allow remembering device for 30 days

When this option is enabled, users can click a checkbox to remember their device for 30 days, allowing logins without entering a 2FA code during that period. This sets a cookie unique to their device that will allow them to log in without using 2FA from that device and browser. This feature is for convenience, but it is less secure than requiring 2FA for each username/password login.

Require 2FA for XML-RPC call authentication

This option is set to Required by default, to prevent logins without 2FA via xmlrpc.php. Attackers often target xmlrpc.php with password guessing attacks, so it is important to keep this feature enabled if possible.

Plugins, features, and external apps or services that require authenticated XML-RPC calls are usually not compatible with this option. For example, if you use the WordPress app on your phone with a user account that uses 2FA, you will most likely need to set this option to Skipped, unless you have specific IPs or ranges you can safely add to the allowlist.

Custom applications that log in via XML-RPC may be made compatible if they can generate a TOTP code and append the current code to the password during authentication. Codes still expire after the first use, so this may not be practical if your custom application may send authenticated requests more than once every 30 seconds.

If you are developing a new app or integration, using WordPress application passwords may be the best solution, and should be implemented using the Authorization HTTP header. When the passkey role setting for a role has been set to “Required”, ordinary username/password XML-RPC authentication is blocked for users in that role, and application passwords should be used for API access if needed.

NTP

Wordfence Login Security uses NTP (Network Time Protocol) to check if your server’s clock is correct or if an adjustment needs to be applied. The accuracy of the clock is necessary for authenticator devices to generate a valid code for two-factor authentication.

Many shared hosts block NTP access, so Wordfence will disable its use of NTP if it detects multiple failures over a few hours. This will reset periodically, in case it was a temporary failure. Fortunately, most hosts correctly maintain their server clocks, so if this option has been automatically disabled, 2FA can often continue working without issues.

You can enable this option if it was automatically disabled, in order to try again, or you can disable it if you do not want your site to use NTP.

General

The General section contains shared Login Security settings that can affect 2FA, passkeys, reCAPTCHA, and administrative behavior.

Grace Period

For roles that require 2FA or passkeys, the grace period gives users a number of days to set up the required authentication method before they lose account access. The default is 10 days, based on when the requirement was enabled, or the account’s creation date, whichever is newer.

Admins (or super-admins on multisite), do not get a grace period by default. When creating an admin, you can choose the option “Allow a grace period for this user prior to requiring Wordfence 2FA or passkeys”, if necessary.

If a user is locked out, you can set a grace period for that specific user on their Profile page, 2FA page, or Passkeys page. You can also revoke a grace period that was set manually.

Important: If the Grace Period is set to 0 and a role is set to Required for 2FA or passkeys, users in that role who have not already set up the required authentication method will not be able to log in. This includes newly created users. You would need to manually allow a grace period for each affected user.

Send Notifications

“Send Notifications” emails users in the selected role to remind them to set up required authentication. Notifications are available only when at least one role is set to Required for passkeys or 2FA and a grace period is defined. We recommend using this as a reminder, after other communication that explains these features in more detail. The notification fields are available for roles where 2FA or passkeys are set to Required and a grace period is defined. Choose a role and click the Notify button to send an email to users who are still in the grace period.
You can optionally define a relative URL, such as /my-account/ for WooCommerce, and can also include a query string or fragment if needed. Leaving the URL blank sends Wordfence’s Login Security page.

Allowlisted IP addresses that bypass 2FA, passkey requirements, and reCAPTCHA

Requests from these IP addresses bypass 2FA, passkey requirements, username/password restrictions for passkey-required accounts, and reCAPTCHA. You can use this to skip additional authentication on networks you trust, like if you have a static IP and want to skip 2FA when connecting from your usual location. Another example is if you have a network with a trusted range of IPs, such as allowing users on your corporate network to log in without additional authentication unless they are logging in from outside the network.
Allowlisted IPs must be placed on separate lines. You can specify ranges using formats such as 127.0.0.1/24, 127.0.0.[1-100], or 127.0.0.1-127.0.1.100.

Disable XML-RPC authentication

This option rejects all XML-RPC requests that require authentication, whether they have a valid username and password or not. It applies to all logins, not only those for users with 2FA enabled or passkeys required.

This option is not compatible with the WordPress phone app, some Jetpack plugin features, or most other services that use XML-RPC with a WordPress username and password.

General Advanced Settings

Always show Login Security menu

When enabled, roles can see the Login Security menu even when both passkeys and 2FA are disabled for that role. This can help users understand why passkeys or 2FA are unavailable for their account.

How to get IPs

When using the standalone Wordfence Login Security plugin without the full Wordfence plugin, you will see choices for how the plugin gets visitor IP addresses. This is important if you use the allowlist feature, to be sure the plugin can detect visitors’ IPs. In most cases, you can leave this set to the default value, “Use the most secure method to get visitor IP addresses.” If the correct IP is not shown, you can choose one of the other options, based on how your server has been set up.

A preview of your detected IP appears below the choices. If you know your public IP address, you can compare it to this, to be sure the correct IP is detected.

If your server is behind one or more proxies, you can click “Edit trusted proxies” to add the proxy IP addresses or ranges.

If you are using the full Wordfence plugin, the “How to get IPs” section does not appear, since the full plugin has a similar section, and enhanced automatic detection.

Show Last Login Column on WP Users Page

When enabled, the last login timestamp is shown for each user on the WordPress Users page. When used with reCAPTCHA, the most recent reCAPTCHA score is also shown for each user.

Delete Login Security tables and data on deactivation

If enabled, Login Security settings and data, including 2FA records and registered passkeys, are deleted on deactivation. If later reactivated, users who previously had 2FA or passkeys active will need to set them up again.

reCAPTCHA

This CAPTCHA implementation uses Google’s reCAPTCHA v3. reCAPTCHA is now a part of Google Cloud Fraud Defense. See documentation from Google for more details:

https://cloud.google.com/security/products/fraud-defense

Enable reCAPTCHA on the login and user registration pages

Please note that the Google reCAPTCHA feature currently works for the default WordPress login and registration pages and also the default WooCommerce login and registration page, so it may not work on custom login and registration pages generated by your theme or other plugins. Enabling this feature will add a CAPTCHA test to WordPress’s login and registration forms. After enabling the checkbox you will need to enter a Site Key and Secret Key, available below. Currently you will need to press the “v3 Admin Console” button and not the “Get Started” button:

https://www.google.com/recaptcha/about/

Note: To use the CAPTCHA on the default WooCommerce login and registration page, you must also enable WooCommerce integration. We recommend testing your WooCommerce login forms after enabling this option, to be sure there are no conflicts with other plugins that modify login forms.

How it works

When this feature is enabled, it displays a reCAPTCHA logo on the WordPress login and registration forms. Unlike older CAPTCHA implementations, it does not require the user to read distorted letters, click road signs, or click a checkbox. Instead, Google calculates a score for each user.

One drawback is that you cannot see the reason that Google has given a lower score. There may be cases where a real user is blocked from logging in or registering, if Google determines that they may be a bot.

Scores from each user’s last login attempt are shown on the standard WordPress Users page. Keep in mind that it may be from the user attempting to log in, or a bot attempting to log in with their username. Scores are also aggregated in a chart on the Login Security settings page, including both good and bad login attempts.

The reCAPTCHA service requires scripts that are loaded from Google and calls to their servers to validate that visitors are more likely to be real people.

What users will see

Generally, most users should see only a Google reCAPTCHA logo on the login and registration pages.

If any valid users get a low score from Google reCAPTCHA and are blocked while logging in, they will see a message saying “Additional verification is required for login”, and asking them to check their email. They should receive an email with a link that will allow them to log in.

Users with 2FA enabled will automatically skip the CAPTCHA scoring if entering the password and 2FA code together in the password field, since they are already required to enter a valid 2FA code. Users who log in with a valid passkey also skip the CAPTCHA challenge, since passkey login is not subject to password brute force or dictionary attacks in the same way as username/password login.

If registration is enabled on your site and a user is blocked from registering due to a low score from reCAPTCHA, they are shown a form to send a message to the main admin email address listed on the WordPress General settings. This is necessary since there is no user record with a known email address for them yet. This form is rate-limited, so bots cannot send repeated requests.

reCAPTCHA human/bot threshold score

You can adjust the threshold used by the captcha if it is too strict or too lenient for your site. The default value is 0.5. You can use the score history chart described below to see the typical scores for your site. If valid users are sometimes blocked by the captcha, you can set the score lower to 0.4 or 0.3 if necessary. If bots are being allowed too often, you can raise the score to 0.6 or 0.7 for example.

reCAPTCHA score history

This chart aggregates the scores for any login attempts, from both humans and bots. Typically you should see a spike toward the high end for users and the low end for bots. You can use these results to decide if you need to adjust the threshold above. You can reset the chart using the “Reset Score Statistics” link below it.

If scores of 0.0 appear common and regular users are sent validation emails, you may have a conflict with another plugin’s JavaScript, a caching issue, or an incorrect reCAPTCHA key.

Run reCAPTCHA in test mode

When this option is enabled, the captcha will record scores in the chart above but it will not block bots or visitors.

This is intended to be used for a short period — likely a few days or a few hours, depending on your traffic — to decide on whether you need to set the threshold above or below the default of 0.5 or to check for conflicts with other plugins or themes. Because it is important to remember to disable test mode, since the captcha will not block bots during testing, this option adds an admin notice that can be dismissed only by disabling test mode.

Customizing CAPTCHA behavior with WordPress filters

You can customize some aspects of the CAPTCHA process with WordPress filters in your theme’s functions.php file, or in custom plugins.

The filter wfls_registration_blocked_message can be used to customize the message when registration is blocked. You can write a custom message to replace the default message and admin contact link, for example, directing the visitor to email you or complete a different contact form. Your filter should return the message that you want to display to the visitor. As an example, if you want people to visit your page at /contact/ when blocked:

function my_wfls_registration_blocked_message() {
	return '<strong>REGISTRATION BLOCKED</strong>: Registration could not be completed. Please visit our <a href="/contact/">contact page</a> for help.';
}
add_filter('wfls_registration_blocked_message', 'my_wfls_registration_blocked_message');

The filter wordfence_ls_require_captcha can be used to disable the CAPTCHA in circumstances of your choice. This may be useful for plugins that contain REST endpoints with authentication that should not require a CAPTCHA. Your filter should return false to bypass the CAPTCHA requirement when necessary, or otherwise true when the CAPTCHA should be required.

WooCommerce and Custom Integrations

WooCommerce & Custom Integrations adds Login Security to WooCommerce and custom account pages. Test WooCommerce forms and custom account pages after enabling or changing these settings to confirm compatibility with the site’s theme and other plugins.

WooCommerce Integration

Enable WooCommerce integration if you want Wordfence Login Security features to work on supported WooCommerce login and registration forms. This includes passkey login, 2FA prompts, and reCAPTCHA where applicable. Test the WooCommerce login and registration forms after enabling this option, especially if the site uses plugins or theme customizations that modify login behavior.
Currently, the CAPTCHA is not compatible with the WooCommerce option “Allow customers to create an account during checkout” as it is only applied on the default, standalone WooCommerce registration form. However, the CAPTCHA icon can appear on the checkout page if “Allow customers to log into an existing account during checkout” is enabled because it is applied to WooCommerce login forms.

Show Wordfence Passkeys and Wordfence 2FA Menus on WooCommerce Account Page

When enabled, separate Wordfence Passkeys and Wordfence 2FA entries are added to the WooCommerce account menu so users can manage their credentials outside of the WordPress admin area.

This option is available after WooCommerce integration is enabled. If customers or other low-privileged users cannot access wp-admin, the WooCommerce account menu or the shortcodes below may be the only place they can manage passkeys or 2FA.
The Wordfence 2FA menu is hidden for a user when passkeys are enabled and that user must sign in with passkeys only.

Use single-column layout for WooCommerce/shortcode Login Security management interface

When enabled, the passkey and 2FA management interfaces embedded through the WooCommerce integration or via a shortcode will use a vertical stacked layout as opposed to horizontal columns. Adjust this setting as appropriate to match your theme. This may be overridden using the stacked attribute for individual shortcodes, such as [wordfence_passkey_management stacked="false"] or [wordfence_2fa_management stacked="true"].

Passkey/2FA management shortcode

When enabled, the wordfence_passkey_management and wordfence_2fa_management shortcodes can be used to let users manage passkey and 2FA credentials on custom account pages. Depending on how the site is built, you may be able to simply use the shortcode in your user account page template, but in other cases, a developer may need to edit PHP files or adjust custom CSS styles to make the passkey and 2FA management areas fit with your site.
Test these shortcodes while logged in as a customer, subscriber, or another low-privileged role that needs access to passkey or 2FA management. This option is not necessary for sites where users can see the Login Security menu when using wp-admin, or when using the separate option to show the Login Security menu on the WooCommerce account page.

WP-CLI

Wordfence Login Security includes WP-CLI commands for passkeys, passkey role settings, and grace periods. These commands are useful for administrators who manage sites from the command line or need to recover access for a user.

Passkey commands

List passkeys registered for a user. The user can be a user ID, login, or email address.

wp wordfence login-security passkeys list admin
wp wordfence login-security passkeys list 123 --format=json

The list command supports table, json, csv, yaml, and count output formats. Output includes the passkey ID, label, credential ID, transports, sign count, created time, and last-used time.

Remove a registered passkey from a user. Use the passkey ID shown by the list command.

wp wordfence login-security passkeys remove admin 4
wp wordfence login-security passkeys remove 123 4 --yes

Change whether username/password login is allowed for a user while the user has passkeys. This cannot be changed when passkeys are required for one or more of the user’s roles.

wp wordfence login-security passkeys password-login admin disabled
wp wordfence login-security passkeys password-login 123 enabled

Passkey role commands

List passkey settings for roles.

wp wordfence login-security passkey-roles list
wp wordfence login-security passkey-roles list --format=json

The list command supports table, json, csv, yaml, and count output formats. Output includes the role slug, role name, passkey state, and the time the role became required, if applicable.

Change a role between disabled, optional, and required. On multisite, only super-admin is supported, and super-admin passkeys cannot be disabled.

wp wordfence login-security passkey-roles set editor optional
wp wordfence login-security passkey-roles set administrator required

Grace period command

Reset the additional authentication grace period for a user. The user can be a user ID, login, or email address. The optional --days value must be between 0 and 99.

wp wordfence login-security grace-period reset admin
wp wordfence login-security grace-period reset 123 --days=14