WordPress XML-RPC authentication is not a setting that should be disabled automatically on every website. The right choice depends on whether the site uses the WordPress mobile app, Jetpack features, publishing tools, synchronization services, backups, or other integrations that authenticate through xmlrpc.php.
Wordfence provides two materially different controls: requiring two-factor authentication for XML-RPC call authentication and rejecting every authenticated XML-RPC request. The first adds an authentication requirement; the second blocks the authenticated request altogether. Before changing either option, inventory the services your site actually uses, select the least disruptive control that meets your requirements, and test critical workflows.
What WordPress XML-RPC Authentication Controls Actually Change
Both settings concern authenticated requests made through xmlrpc.php. They do not have the same operational effect, so treating them as interchangeable can create unexpected compatibility problems.
Requiring 2FA versus blocking authentication
Wordfence’s “Require 2FA for XML-RPC call authentication” setting prevents username-and-password logins through XML-RPC unless the request also satisfies the configured second-factor requirement. In practical terms, a service that sends only a WordPress username and password may no longer authenticate successfully.
The stricter “Disable XML-RPC authentication” option rejects every XML-RPC request that requires authentication, including requests containing valid credentials. It applies to all authenticated XML-RPC logins, not only accounts using two-factor authentication or passkeys. Therefore, requiring 2FA preserves a possible authentication path for compatible integrations, while disabling authentication removes that path entirely.
Neither option is automatically necessary for every site. The useful question is not simply whether XML-RPC exists, but whether a required service depends on authenticated XML-RPC and which authentication method that service can support.
Should You Disable XML-RPC Authentication?
Not by default. Full blocking may be appropriate when the site has no required dependency on authenticated XML-RPC and the owner has tested the consequences. However, Wordfence documents that the setting can disrupt the WordPress phone app, some Jetpack features, and most other services using XML-RPC with a WordPress username and password.
If authenticated XML-RPC is still needed, requiring 2FA may be less disruptive, provided the integration can complete the required authentication flow. A supported application-password-based integration may also provide a separate credential path. This is a site-specific risk and compatibility decision, not a universal WordPress or Wordfence requirement.
A practical decision rule
Use a simple sequence before choosing the strict setting:
- Identify every service that publishes, synchronizes, reports statistics, performs backups, or otherwise connects to the site.
- Determine whether each relevant service authenticates through XML-RPC and whether it can use the authentication method you plan to require.
- Choose full blocking only when required services have been identified and tested without authenticated XML-RPC.
- If an integration still depends on authenticated XML-RPC, retain a compatible path and test the least disruptive control instead.
Where practical, make the change on staging or during a maintenance window. Record the selected setting and the integrations tested so that a future administrator can understand why the configuration was chosen.
How to Require 2FA for XML-RPC in Wordfence
In Wordfence Login Security settings, the relevant control is “Require 2FA for XML-RPC call authentication.” Its documented purpose is to prevent username-and-password authentication through xmlrpc.php unless the request also satisfies the configured second-factor requirement. This creates a stricter authentication condition without rejecting every authenticated XML-RPC request outright.
That distinction matters for integrations. Wordfence states that authenticated XML-RPC applications are usually not compatible with requiring 2FA. The WordPress phone app is a documented example of an application that may not support this flow. A custom XML-RPC application may be compatible if it can generate a TOTP code and append the current code to the password, but the short lifetime of such codes can make repeated requests impractical in production.
Compatibility checks before enabling the control
Before enabling the requirement, review the authentication capabilities of each connected service rather than assuming that a normal login flow will continue to work. Check whether the application can provide the required second-factor data and whether it has a documented, dependable way to repeat authenticated requests.
Trusted IP allowlisting may sometimes be considered as an alternative, but it requires careful verification. Addresses should be stable, trusted, and maintained by the relevant service. An overly broad or outdated allowlist can weaken access controls. After changing the setting, test the integration itself, not only the WordPress admin login.
When Full XML-RPC Authentication Blocking Is Appropriate
Wordfence’s “Disable XML-RPC authentication” option is the more restrictive control. It rejects every XML-RPC request that requires authentication, even when the request contains valid credentials. The setting therefore affects all authenticated XML-RPC logins, rather than only accounts that do not use 2FA or passkeys.
Full blocking is most defensible when the site’s required workflows have been reviewed and no necessary service depends on authenticated XML-RPC. It should not be presented as a guaranteed security improvement for every website. Its benefit must be weighed against the operational effect on connected applications and the availability of a practical recovery path.
What the strict setting can break
A service that uses a WordPress username and password through XML-RPC may stop authenticating after the setting is enabled. The request can fail even when the credentials are correct, because the control rejects the authenticated XML-RPC request itself.
This is why a site owner should not enable the strict option solely because it appears more restrictive. Confirm the site’s dependencies first, then verify publishing, synchronization, statistics, backups, and other critical functions after the change. If a required workflow fails, restore a compatible configuration while investigating the integration.
Apps and Services to Test Before and After the Change
The documented compatibility examples include the WordPress mobile app, some Jetpack features, and most other services that use XML-RPC with a WordPress username and password. Jetpack documents XML-RPC as a communication mechanism between Jetpack and a WordPress site, so blocking or misconfiguring authenticated XML-RPC can affect Jetpack connection or feature behavior.
The list is not exhaustive. The reviewed documentation does not identify every plugin, mobile app, SaaS platform, host configuration, or connected service that may use authenticated XML-RPC. Impact depends on the specific integration, account, authentication method, allowlist, firewall, hosting environment, and other security plugins.
A focused compatibility checklist
Review the services actually installed and used on the site. Before changing the control, record which ones handle the following workflows:
- Publishing or managing content through the WordPress mobile app or another connected application.
- Jetpack communication and the Jetpack features enabled on the site.
- Synchronization between the website and another service.
- Statistics or reporting connections that authenticate with WordPress credentials.
- Backups or other connected services that rely on authenticated XML-RPC.
After the change, test each relevant workflow with a realistic operation. Do not infer success from the ability to sign in to wp-admin. If communication fails, review the integration’s authentication method together with firewall, hosting, allowlist, and other security-plugin rules. Treat the examples above as categories to investigate, not as a complete inventory.
Application Passwords as an Integration Alternative
Application passwords are revocable, per-application credentials intended for programmatic access. WordPress documentation describes their use with the REST API and, where enabled, XML-RPC. They are separate from the interactive password used for browser-based wp-admin login.
For a supported integration, a separate credential can limit the impact of one connection and allow that credential to be revoked without changing the main account password. This can be useful when an integration supports application-password-based API access, but it is not a universal solution for every XML-RPC service.
When this alternative is suitable
Use application passwords only when the specific integration supports them. Create separate credentials for separate applications, store them as secrets, revoke unused credentials, and avoid exposing the main WordPress password. HTTPS is required for this authentication approach because the credentials are sent through HTTP authorization headers. Application passwords provide a programmatic credential path; they are not interactive wp-admin login passwords.
A Safe XML-RPC Security Rollout Checklist
A controlled rollout reduces the chance that a security change will silently interrupt an important workflow. The process should be based on the site’s real integrations rather than on a generic assumption that every XML-RPC request is unnecessary.
Pre-change, change, and post-change steps
- Pre-change: record the current Wordfence XML-RPC settings and inventory the WordPress mobile app, Jetpack features, publishing tools, synchronization services, statistics, backups, and other connected applications actually used.
- Pre-change: identify which services authenticate through XML-RPC and whether they support the proposed 2FA or application-password flow.
- Change: choose the least disruptive control compatible with the site’s requirements. If authenticated XML-RPC remains necessary, do not assume that full blocking is suitable.
- Change: apply one control at a time, preferably on staging or during a maintenance window where practical.
- Post-change: test the site’s actual publishing, synchronization, statistics, backup, Jetpack, and connected-application workflows.
- Post-change: document the result, including any service limitations, allowlist decisions, and recovery steps.
- Ongoing: repeat the compatibility review after later changes to authentication, firewall, hosting, or security-plugin rules.
Do not use an overly broad or outdated IP allowlist as a substitute for compatibility review. If a required service is disrupted, adjust the configuration rather than assuming that a failed connection is acceptable.
Wordfence’s two XML-RPC controls solve different operational problems. Requiring 2FA can restrict username-and-password authentication while leaving a path for compatible integrations. Disabling XML-RPC authentication rejects every authenticated XML-RPC request, including valid credentials, and may stop the WordPress mobile app, some Jetpack features, and other connected services.
For that reason, disable authenticated XML-RPC only after confirming that required dependencies have been ruled out and critical workflows have been tested. Where supported, application passwords can provide separate, revocable programmatic credentials, but HTTPS and integration compatibility remain essential. Explore our WordPress plugins, WooCommerce extensions, themes and membership plans to find the right tools for your website.