WT Hardening

No. Everything is wired through WordPress hooks. Deactivating the plugin instantly reverts all changes (except HSTS, which browsers cache, so enabling HSTS is a conscious decision).

Possibly, if you actually rely on them. Disable the XML-RPC module in the settings. The other protection layers stay active.

The table stays in the database (useful for later analysis). On full uninstall the tables are dropped cleanly.

Tested on a single-site install. Settings, tables and cleanup jobs are per site; tables are created on each site the first time the plugin runs there, and uninstalling removes the data from every site of the network. Multisite is not yet formally supported, so file an issue if something breaks.

Wait until the lockout expires, log in from another network (e.g. your phone’s mobile data), or ask another administrator to click Unlock under Webmasters.Team → WT Hardening → Login log tab. With WP-CLI access you can remove the lockout directly: wp db query "DELETE FROM wp_wt_hardening_lockouts WHERE ip='1.2.3.4'" (adjust the table prefix; for IPv6 use the /64 network shown in the log, e.g. 2001:db8:1:2::/64). Add your office IP to the allowlist to avoid this in the future.

Nothing. Since 1.1.1 Cloudflare is recognised automatically. When a request comes from Cloudflare’s published IP ranges (updated weekly from cloudflare.com, with a bundled copy as fallback), the visitor address is taken from the CF-Connecting-IP header, also with Site behind Cloudflare / proxy left at No. The header is ignored for requests from any other address, so it cannot be spoofed by hitting your server directly. Choosing Cloudflare explicitly works the same way. Without this every visitor would appear with a Cloudflare IP, so one attacker could lock everyone out.

Set Site behind Cloudflare / proxy to Reverse proxy on the local network. X-Forwarded-For is then trusted only from private-network addresses. When the plugin sees such a proxy while the setting is still No, it shows a notice on its admin pages.

Modules only register the hooks they actually need. The event log is a single INSERT per event. No scanner, no background work beyond an hourly and daily cleanup of old rows. Real impact on response time: under 1 ms.

Because Strict-Transport-Security has a sticky effect (browsers remember the header for a year). Enabling it too early (before your entire traffic works on HTTPS without errors) can lock users out of the site for a long time. Turn it on once HTTPS is rock-solid. includeSubDomains is a separate setting (off by default) because it also forces HTTPS on every subdomain; preload is never added.

The header is sent only over HTTPS. When HTTPS ends at a proxy, WordPress sees plain HTTP and the plugin relies on the X-Forwarded-Proto: https header, but only from a proxy it trusts: Cloudflare’s IP ranges (always) or, with Site behind Cloudflare / proxy set to Reverse proxy on the local network, a private-network address. From any other address the header is ignored, so it cannot be spoofed.

No. The policy hooks into form validation (profile, registration, reset) and the REST API users endpoints. Programmatic user creation bypasses these hooks by design. For a typical client workflow (users are created through the admin panel) this is enough.

The login limiter stores the IP address and the login typed in failed attempts (kept for the configured counter window, at most 7 days) and in lockouts (kept until 24 hours after they end). The event log stores the user, IP address and event details, including logins typed in failed attempts and the email of new users (kept for the configured retention, 30 days by default). Everything stays in your database. The data is included in Tools → Export Personal Data, and Tools → Erase Personal Data deletes the person’s event log entries and removes their login from attempts and lockouts. The attempt and lockout records themselves, with their IP addresses, are kept until they expire (a security log); the erase tool reports them as retained and explains why. Mention the login security log in your privacy policy: the plugin adds suggested text with the current retention periods to Settings → Privacy → Policy guide.