diff --git a/security/brute-force-update.md b/security/brute-force-update.md
new file mode 100644
index 00000000..cc927f1d
--- /dev/null
+++ b/security/brute-force-update.md
@@ -0,0 +1,212 @@
+# Brute Force Attacks
+
+A **brute force attack** is the simplest way to break in: an attacker repeatedly tries username/password combinations until one works. Because these attempts are automated and often distributed (botnets), even unsuccessful attacks can overwhelm your site with requests.
+
+This is not unique to WordPress—every web application that exposes a login surface can be targeted—but WordPress’s popularity makes it a common focus. The guidance below reflects current best practices for WordPress sites in 2025 and replaces older, more fragile techniques.
+
+---
+
+## Key Defenses at a Glance {#key-defenses}
+- **Use strong, unique passwords and a password manager.**
+- **Enable two‑factor authentication (2FA)** for all administrator accounts (use a plugin or your identity provider; WordPress core does not include 2FA).
+- **Consider passkeys (WebAuthn)** via a reputable plugin for phishing‑resistant login.
+- **Rate‑limit login attempts** at the edge (WAF/CDN) or the web server.
+- **Put a CAPTCHA/turnstile on login** to slow bots (e.g., Cloudflare Turnstile, reCAPTCHA).
+- **Protect or disable XML‑RPC** if you don’t need it; otherwise restrict and rate‑limit it.
+- **Keep WordPress core, themes, and plugins up to date.**
+- **Monitor and alert** on authentication anomalies; ban abusive IPs temporarily.
+- Prefer **edge/WAF protections** (Cloudflare, Sucuri, host‑provided WAF) so bad traffic is blocked before it reaches your server.
+
+> Tip: Obscuring the login URL can reduce noise but should not be your only defense.
+
+---
+
+## WordPress‑Level Protections {#wordpress-level}
+### Enforce Strong Passwords {#strong-passwords}
+WordPress shows a strength meter when changing passwords. Encourage unique, long passwords (or passphrases) and the use of password managers. Avoid dictionary words and personal info.
+
+### Two‑Factor Authentication (2FA) {#2fa}
+Enable 2FA for all administrators and privileged users using a reputable plugin or your identity provider (TOTP app, hardware key, SMS fallback). As of 2025, **WordPress core does not ship 2FA**; it must be added via a plugin or SSO/IdP.
+
+### Passkeys (WebAuthn) {#passkeys}
+Passkeys provide phishing‑resistant, passwordless login using platform authenticators (Face ID/Touch ID, Windows Hello, security keys). Add via a maintained plugin that supports WebAuthn/Passkeys and enroll at least two authenticators per admin.
+
+### Application Passwords (for Integrations) {#application-passwords}
+For API access by trusted apps/services, use **Application Passwords** (introduced in WordPress 5.6). They scope access and can be revoked without changing your user password.
+
+### Limit Login Attempts (App Layer) {#limit-login}
+If your host/CDN doesn’t rate‑limit at the edge, a security plugin can throttle login attempts. Note that app‑level plugins still execute within PHP and thus consume some resources under heavy attack; prefer edge or server‑level throttling when possible.
+
+### XML‑RPC Considerations {#xmlrpc}
+`xmlrpc.php` is a frequent brute‑force target (especially the `system.multicall` method). If you don’t use XML‑RPC, disable it. If you do (e.g., Jetpack, mobile apps), restrict it (WAF rules) and rate‑limit aggressively.
+
+---
+
+## Server / Proxy / WAF Protections {#server-proxy}
+> These examples require server or proxy access and may vary by environment. Test in staging before applying to production.
+
+### Apache (examples) {#apache}
+**Block or rate‑limit abusive login attempts** (examples require appropriate modules such as `mod_rewrite`, `mod_authz_host`, or third‑party tools like ModSecurity or mod_evasive).
+
+**Deny by IP (Apache 2.4+):**
+```apache
+# wp-login.php: allow specific IPs only
+
+ Require ip 203.0.113.15 203.0.113.16
+
+```
+
+**Send 401/403 to a static error page:**
+```apache
+ErrorDocument 401 /401.html
+ErrorDocument 403 /403.html
+```
+
+> Consider ModSecurity rulesets (e.g., OWASP CRS) to detect and block brute‑force patterns at the server layer.
+
+### Nginx (examples) {#nginx}
+**Rate‑limit login and XML‑RPC:**
+```nginx
+# Define a shared zone for rate limiting
+limit_req_zone $binary_remote_addr zone=logins:10m rate=10r/m;
+
+server {
+ # ...
+
+ location = /wp-login.php {
+ limit_req zone=logins burst=20 nodelay;
+ include fastcgi_params;
+ # pass to PHP-FPM or upstream as usual
+ }
+
+ location = /xmlrpc.php {
+ limit_req zone=logins burst=20 nodelay;
+ include fastcgi_params;
+ # pass to PHP-FPM or upstream as usual
+ }
+}
+```
+
+**Deny by IP:**
+```nginx
+location = /wp-login.php {
+ allow 203.0.113.15;
+ allow 203.0.113.16;
+ deny all;
+ # pass to PHP-FPM or upstream as usual
+}
+```
+
+**Custom error pages:**
+```nginx
+error_page 401 /401.html;
+error_page 403 /403.html;
+```
+
+### Caddy (v2) (examples) {#caddy}
+**Password‑protect `/wp-login.php` with Basic Auth:**
+```caddyfile
+# Hash passwords first: `caddy hash-password`
+basicauth /wp-login.php {
+ user1 JDJhJDEw$example-hash-value...
+ # add more users as needed (one per line)
+}
+```
+> Caddy requires **hashed** passwords in the Caddyfile.
+
+**Limit access to `/wp-login.php` by IP:**
+```caddyfile
+@blacklist {
+ not remote_ip forwarded 203.0.113.15 203.0.113.16
+ path /wp-login.php
+}
+respond @blacklist "Forbidden" 403 {
+ close
+}
+```
+
+**Return 401 for `/wp-admin/*` and serve a custom error page:**
+```caddyfile
+@wpadmin path /wp-admin/*
+respond @wpadmin "Unauthorized" 401
+
+handle_errors {
+ @need401 status 401
+ rewrite @need401 /401.html
+ file_server
+}
+```
+
+**Deny “no‑referrer” POSTs to login/comments (optional, use with caution):**
+```caddyfile
+# Legitimate clients or privacy tools may omit Referer; test before enforcing.
+@protected path_regexp protected (wp-comments-post|wp-login)\.php$
+@no_referer {
+ not header Referer https://{host}*
+ method POST
+}
+abort @no_referer
+```
+> Using `abort` immediately drops the connection, which is efficient for bots.
+
+For more Caddy discussion and rationale, see: *Using Caddy to deter brute force attacks in WordPress* (community thread).
+
+### Windows IIS (examples) {#iis}
+**Restrict WP Admin by IP using `web.config`:**
+```xml
+
+
+
+
+
+
+
+
+
+
+```
+
+**Custom 401 page:**
+```xml
+
+
+
+
+
+
+```
+
+---
+
+## Host / CDN WAF Protections {#waf}
+A managed WAF (Cloudflare, Sucuri, or your hosting provider) can:
+- Filter known bad IPs and automated login attempts at the edge.
+- Enforce bot management, challenge‑pages, and login‑specific rules.
+- Apply **rate limits** to `/wp-login.php` and `/xmlrpc.php` globally.
+- Add **CAPTCHA/turnstile** challenges for suspicious requests.
+
+> Advantage: traffic is blocked before reaching your server, preserving resources during high‑volume attacks.
+
+---
+
+## Additional Hardening & Operational Tips {#hardening}
+- **Do not use the username `admin`.** Create a separate admin account and demote or remove legacy users.
+- **Limit administrator count;** use least‑privilege roles for day‑to‑day work.
+- **Audit logs** for failed logins and enumerate sources; temporarily block abusive IPs (e.g., Fail2ban).
+- **Avoid permanent country blocklists.** They can block legitimate users and are difficult to maintain.
+- **Ensure HTTPS everywhere** to protect credentials in transit.
+- **Backups:** Maintain tested, offline‑capable backups and rehearse restore procedures.
+
+---
+
+## See Also {#see-also}
+- WordPress Advanced Administration: [Security](https://developer.wordpress.org/advanced-administration/security/)
+- WordPress Advanced Administration: [Hardening WordPress](https://developer.wordpress.org/advanced-administration/security/hardening/)
+- WordPress.com: [Brute Force Attack Protection](https://developer.wordpress.com/docs/platform-features/brute-force-attack-protection/)
+- WordPress Core: [Application Passwords (integration guide)](https://make.wordpress.org/core/2020/11/05/application-passwords-integration-guide/)
+- Using Caddy to deter brute force attacks in WordPress – community thread: https://caddy.community/t/using-caddy-to-deter-brute-force-attacks-in-wordpress/13579
+
+---
+
+## Notes on Deprecated / Legacy Content {#legacy-notes}
+Older guidance often recommended heavy `.htaccess` rewrites, country IP blocklists, or BasicAuth over the entire `/wp-admin` directory. Today these measures are either unreliable, break AJAX‑based plugins, or degrade user experience. Prefer **edge‑level WAF**, **2FA**, **passkeys**, and **targeted rate‑limiting** instead. When you do apply server‑level blocks, scope them narrowly (e.g., `/wp-login.php`, `/xmlrpc.php`) and document exceptions your site needs (mobile apps, Jetpack, SSO).
diff --git a/security/brute-force.md b/security/brute-force.md
deleted file mode 100644
index de40a68a..00000000
--- a/security/brute-force.md
+++ /dev/null
@@ -1,296 +0,0 @@
-# Brute Force Attacks
-
-Unlike hacks that focus on vulnerabilities in software, a Brute Force Attack aims at being the simplest kind of method to gain access to a site: it tries usernames and passwords, over and over again, until it gets in. Often deemed 'inelegant', they can be very successful when people use passwords like '123456' and usernames like 'admin.'
-
-They are, in short, an attack on the weakest link in any website's security… you.
-
-Due to the nature of these attacks, you may find your server's memory goes through the roof, causing performance problems. This is because the number of http requests (that is the number of times someone visits your site) is so high that servers run out of memory.
-
-This sort of attack is not endemic to WordPress, it happens with every webapp out there, but WordPress is popular and thus a frequent target.
-
-### Throttling Multiple Login Attempts {#throttling-multiple-login-attempts}
-
-One of the most common kinds of attacks targeting internet services is brute force login attacks. With this form of attack, a malicious party tries to guess WordPress usernames and passwords. The attacker needs only the URL of a user site to perform an attack. Software is readily available to perform these attacks using botnets, making increasingly complex passwords easier to find.
-
-The best protection against this kind of attack is to set and recommend and/or enforce strong passwords for WordPress users.
-
-It is also recommended for hosts to throttle login attempts at the network and server level when possible. It's helpful to throttle both maximum logins per site over time, and maximum attempts per IP over time across server or infrastructure to mitigate bot password brute-force attacks. This can be done at the plugin level as well, but not without incurring the additional resource utilization caused during these attacks.
-
-### Protect Yourself {#protect-yourself}
-
-A common attack point on WordPress is to hammer the `wp-login.php` file over and over until they get in or the server dies. You can do some things to protect yourself.
-
-#### Don't use the 'admin' username {#dont-use-the-admin-username}
-
-The majority of attacks assume people are using the username 'admin' due to the fact that early versions of WordPress defaulted to this. If you are still using this username, make a new account, transfer all the posts to that account, and change 'admin' to a subscriber (or delete it entirely).
-
-You can also use the plugin [Change Username](https://wordpress.org/plugins/change-username/) to change your username.
-
-#### Good Passwords {#good-passwords}
-
-The goal with your password is to make it hard for other people to guess and hard for a brute force attack to succeed. Many automatic password generators are available that can be used to create secure passwords.
-
-WordPress also features a password strength meter which is shown when changing your password in WordPress. Use this when changing your password to ensure its strength is adequate.
-
-Things to avoid when choosing a password:
-
-* Any permutation of your own real name, username, company name, or name of your website.
-* A word from a dictionary, in any language.
-* A short password.
-* Any numeric-only or alphabetic-only password (a mixture of both is best).
-
-A strong password is necessary not just to protect your blog content. A hacker who gains access to your administrator account is able to install malicious scripts that can potentially compromise your entire server.
-
-To further increase the strength of your password, you can enable [Two Step Authentication](https://developer.wordpress.org/advanced-administration/security/mfa/) to further protect your blog.
-
-#### Plugins {#plugins}
-
-There are many [plugins available to limit the number of login attempts](https://wordpress.org/plugins/tags/brute-force) made on your site. Alternatively, there are also many [plugins you can use to block people from accessing wp-admin](https://wordpress.org/plugins/search.php?q=admin+rename) altogether.
-
-### Protect Your Server {#protect-your-server}
-
-If you decide to lock down wp-login.php or wp-admin, you may find you get a 404 or 401 error when accessing those pages. To avoid that, you will need to add the following to your .htaccess file.
-
-```
-ErrorDocument 401 default
-```
-
-You can have the 401 point to 401.html, but the point is to aim it at _not_ WordPress.
-
-For Nginx you can use the `error_page` directive but must supply an absolute url.
-
-```
-error_page 401 https://example.com/forbidden.html;
-```
-
-On IIS web servers you can use the `httpErrors` element in your web.config, set `errorMode="custom"`:
-
-```
-
-
-
-```
-
-#### Password Protect wp-login.php {#password-protect-wp-login-php}
-
-Password protecting your wp-login.php file (and wp-admin folder) can add an extra layer to your server. Because password protecting wp-admin can break any plugin that uses ajax on the front end, it's usually sufficient to just protect wp-login.php.
-
-To do this, you will need to create a .htpasswd file. Many hosts have tools to do this for you, but if you have to do it manually, you can use this [htpasswd generator](https://hostingcanada.org/htpasswd-generator/). Much like your .htaccess file (which is a file that is only an extension), .htpasswd will also have no prefix.
-
-You can either put this file outside of your public web folder (i.e. not in /public_html/ or /domain.com/, depending on your host), or you _can_ put it in the same folder, but you'll want to do some extra security work in your .htaccess file if you do.
-
-Speaking of which, once you've uploaded the .htpasswd file, you need to tell .htaccess where it's at. Assuming you've put .htpasswd in your user's home directory and your htpasswd username is mysecretuser, then you put this in your .htaccess:
-
-```
-# Stop Apache from serving .ht* files
-
- Order allow,deny
- Deny from all
-
-
-# Protect wp-login.php
-
- AuthUserFile ~/.htpasswd
- AuthName "Private access"
- AuthType Basic
- require user mysecretuser
-
-```
-
-The actual location of AuthUserFile depends on your server, and the 'require user' will change based on what username you pick.
-
-If you are using Nginx you can password protect your wp-login.php file using the [HttpAuthBasicModule](https://nginx.org/en/docs/http/ngx_http_auth_basic_module.html). This block should be inside your server block.
-
-```
-location /wp-login.php {
- auth_basic "Administrator Login";
- auth_basic_user_file .htpasswd;
-}
-```
-
-The filename path is relative to directory of nginx configuration file nginx.conf
-
-The file should be in the following format:
-
-```
-user:pass
-user2:pass2
-user3:pass3
-```
-
-Unfortunately there is no easy way of configuring a password protected wp-login.php on Windows Server IIS. If you use a .htaccess processor like Helicon Ape, you can use the .htaccess example mentioned above. Otherwise you'd have to ask your hosting provider to set up Basic Authentication.
-
-All passwords must be encoded by function `crypt(3)`. You can use an online [htpasswd generator](https://hostingcanada.org/htpasswd-generator/) to encrypt your password.
-
-#### Throttle Multiple Login Attempts
-
-One of the most common kinds of attacks targeting internet services is brute force login attacks. With this form of attack, a malicious party tries to guess WordPress usernames and passwords. The attacker needs only the URL of a user site to perform an attack. Software is readily available to perform these attacks using botnets, making increasingly complex passwords easier to find.
-
-The best protection against this kind of attack is to set and recommend and/or enforce strong passwords for WordPress users.
-
-It is also recommended for hosts to throttle login attempts at the network and server level when possible. It’s helpful to throttle both maximum logins per site over time, and maximum attempts per IP over time across server or infrastructure to mitigate bot password brute-force attacks. This can be done at the plugin level as well, but not without incurring the additional resource utilization caused during these attacks.
-
-#### Limit Access to wp-login.php by IP {#limit-access-to-wp-login-php-by-ip}
-
-If you are the only person who needs to login to your Admin area and you have a fixed IP address, you can deny wp-login.php (and thus the wp-admin/ folder) access to everyone but yourself via an .htaccess or web.config file. This is often referred to as an _IP whitelist_.
-
-**Note:** Beware your ISP or computer may be changing your IP address frequently, this is called dynamic IP addressing, rather than fixed IP addressing. This could be used for a variety of reasons, such as saving money. If you suspect this to be the case, find out out how change your computer's settings, or contact your ISP to obtain a fixed address, in order to use this procedure.
-
-In all examples you have to replace 203.0.113.15 with your IP address. Your Internet Provider can help you to establish your IP address. Or you can use an online service such as [What Is My IP](https://www.whatismyip.com/).
-
-Examples for multiple IP addresses are also provided. They're ideal if you use more than one internet provider, if you have a small pool of IP addresses or when you have a couple of people that are allowed access to your site's Dashboard.
-
-Create a file in a plain text editor called .htaccess and add:
-
-```
-# Block access to wp-login.php.
-
- order deny,allow
- allow from 203.0.113.15
- deny from all
-
-```
-
-You can add more than one allowed IP address using:
-
-```
-# Block access to wp-login.php.
-
- order deny,allow
- allow from 203.0.113.15
- allow from 203.0.113.16
- allow from 203.0.113.17
- deny from all
-
-```
-
-Are you using Apache 2.4 and Apache module [mod_authz_host](https://httpd.apache.org/docs/2.4/mod/mod_authz_host.html)? Then you have to use a slightly different syntax:
-
-```
-# Block access to wp-login.php.
-
- Require ip 203.0.113.15
-
-```
-
-If you want to add more than one IP address, you can use:
-
-```
-# Block access to wp-login.php.
-
- Require ip 203.0.113.15 203.0.113.16 203.0.113.17
- # or for the entire network:
- # Require ip 203.0.113.0/255.255.255.0
-
-```
-
-For Nginx you can add a location block inside your server block that works the same as the Apache example above.
-
-```
-error_page 403 https://example.com/forbidden.html;
-location /wp-login.php {
- allow 203.0.113.15
- # or for the entire network:
- # allow 203.0.113.0/24;
- deny all;
-}
-```
-
-Note that the order of the deny/allow is of the utmost importance. You might be tempted to think that you can switch the access directives order and everything will work. In fact it doesn't. Switching the order in the above example has the result of denying access to all addresses.
-
-Again, on IIS web servers you can use a web.config file to limit IP addresses that have access. It's best to add this in an additional `
-
-
-
-
-
-
-
-
-
-
-
-```
-
-#### Deny Access to No Referrer Requests {#deny-access-to-no-referrer-requests}
-
-Extended from [Combatting Comment Spam](https://codex.wordpress.org/Combating_Comment_Spam/Denying_Access#Deny_Access_to_No_Referrer_Requests), you can use this to prevent anyone who isn't submitting the login form from accessing it:
-
-```
-# Stop spam attack logins and comments
-
- RewriteEngine On
- RewriteCond %{REQUEST_METHOD} POST
- RewriteCond %{REQUEST_URI} .(wp-comments-post|wp-login)\.php*
- RewriteCond %{HTTP_REFERER} !.*example.com.* [OR]
- RewriteCond %{HTTP_USER_AGENT} ^$
- RewriteRule (.*) https://%{REMOTE_ADDR}/$1 [R=301,L]
-
-```
-
-Nginx – Deny Access to No Referrer Requests
-
-```
-location ~* (wp-comments-posts|wp-login)\\.php$ {
- if ($http_referer !~ ^(https://example.com) ) {
- return 405;
- }
-}
-```
-
-Windows Server IIS – Deny access to no referrer requests:
-
-```
-
-
-
-
-
-
-
-
-
-```
-
-Change example.com to your domain. If you're using Multisite with mapped domains, you'll want to change example.com to `(example.com|example.net|example.org)` and so on. If you are using Jetpack comments, don't forget to add jetpack.wordpress.com as referrer: `(example.com|jetpack\.wordpress\com)`
-
-#### ModSecurity {#modsecurity}
-
-If you use ModSecurity, you can follow the advice from [Frameloss – Stopping brute force logins against WordPress](https://web.archive.org/web/20230113232859/https://www.frameloss.org/2011/07/29/stopping-brute-force-logins-against-wordpress/). This requires root level access to your server, and may need the assistance of your webhost.
-
-If you're using ModSecurity 2.7.3, you can add the rules into your .htaccess file instead.
-
-#### Fail2Ban {#fail2ban}
-
-Fail2ban is a Python daemon that runs in the background. It checks the logfiles that are generated by Apache (or SSH for example), and on certain events can add a firewall rule. It uses a so called filter with a regular expression. If that regular expression happens for example 5 times in 5 minutes, it can block that IP address for 60 minutes (or any other set of numbers).
-
-Installing and setting up Fail2ban requires root access.
-
-#### Blocklists {#blocklists}
-
-It appears that most brute force attacks are from hosts from Russia, Kazachstan and Ukraine. You can choose to block ip-addresses that originate from these countries. There are blocklists available on the internet that you can download. With some shell-scripting, you can then load blockrules with iptables.
-
-You have to be aware that you are blocking legitimate users as well as attackers. Make sure you can support and explain that decision to your customers.
-
-Besides blocklists per country, there are lists with ip-addresses of well-known spammers. You can also use these to block them with iptables. It's good to update these lists regularly.
-
-Setting up of blocklists and iptables requires root access.
-
-#### Cloud/Proxy Services {#cloud-proxy-services}
-
-Services like CloudFlare and Sucuri CloudProxy can also help mitigate these attacks by blocking the IPs before they reach your server.
-
-### See Also {#see-also}
-
-* [Sucuri: Protecting Against WordPress Brute Force Attacks](https://blog.sucuri.net/2013/04/protecting-against-wordpress-brute-force-attacks.html)
-* [How to: Protect WordPress from brute-force XML-RPC attacks](https://www.saotn.org/how-to-wordpress-protection-from-brute-force-xml-rpc-attacks/)
-* [Liquid Web: ModSecurity Rules To Alleviate Brute Force Attacks](https://www.liquidweb.com/kb/wordpress-modsecurity-rules/)
-* [Swiss Army Knife for WordPress (SAK4WP)](https://github.com/orbisius/sak4wp/) – Free Open Source Tool that can help you protect your wp-login.php and /wp-admin/ but not /wp-admin/admin-ajax.php with one click and much more
-