by
wpformation
5 (6 reviews)
Login Armor
Thirteen security modules + AI briefing: hide login, request firewall, brute force, 2FA, password policy, sessions, hardening, audit log. No upsells.
Login Armor ranks #8,436 among WordPress.org plugins with 600+ active installations, a 5/5 rating from 6 reviews, and was last updated Oct 8, 2026. Data from WordPress.org, refreshed twice daily — see methodology.
Compatible with WP 7.1.4
v2.10.0
Current Version v2.10.0
Updated 4 weeks ago
Last Update on 08 Oct, 2026
Refreshed 1 week ago
Last Refreshed on
Top 25% by installs
Downloads +316% this week
Actively maintained
Rank
#8,436
—
No change
Active Installs
600+
+20%
KW Avg Position
40.2
0.4 worse
Downloads
9.3K
+11 today
Support Resolved
100%
—
No change
Rating
100%
Review 5 out of 5
5
(6 reviews)
Next Milestone 700
600+
700+
405
Ranks to Climb
-
Growth Needed
8,000,000
Active Installs
Pro
Unlock Exact Install Count
See the precise estimated active installs for this plugin, calculated from real-time ranking data.
- Exact install estimates within tiers
- Track install growth over time
- Milestone progress predictions
Need 49 more installs to reach 700+
Rank Changes
Current
#8,436
Change
Best
#
Downloads Growth
Downloads
Growth
Peak
Upgrade to Pro
Unlock 30-day, 90-day, and yearly download history charts with a Pro subscription.
Upgrade NowReviews & Ratings
5.0
6 reviews
Overall
100%
5
6
(100%)
4
0
(0%)
3
0
(0%)
2
0
(0%)
1
0
(0%)
Support Threads Overview
Resolved
Unresolved
1
Total Threads
1
Resolved
0
Unresolved
100%
Resolution Rate
Security History
Source: WPVulnerabilityNo known vulnerabilities on record for Login Armor. Checked 2 months ago.
Track This Plugin
Get detailed analytics, keyword tracking, and position alerts delivered to your inbox.
Start Tracking FreePlugin Details
- Version
- 2.10.0
- Last Updated
- Oct 08, 2026
- Requires WP
- 6.8+
- Tested Up To
- 7.1.4
- PHP Version
- 8.1 or higher
- Author
- wpformation
Support & Rating
- Rating
- ★ ★ ★ ★ ★ 5
- Reviews
- 6
- Support Threads
- 1
- Resolved
- 100%
Keywords
Upgrade to Pro
Unlock keyword rankings, search positions, and detailed analytics with a Pro subscription.
Upgrade Now
TL;DR
AI summary of the plugin's readmeLogin Armor is for agencies, freelancers, and professionals managing WordPress sites that need to pass security audits. It replaces the need to juggle multiple security plugins by combining login protection, brute force lockout, two-factor authentication, and hardening into one lightweight package.
- Hide login URL
- Brute force lockout
- Two-factor authentication
- Activity log with CSV export
- Detection and incident engine
- Login page security headers
- Breach password detection (HIBP)
- WP-CLI command suite
Frequently Asked Questions
Common questions about Login Armor
Hide Login should not: when you switch it on, it offers to email the new URL to the site address, and wp login-armor status prints it at any time from SSH. Deleting the slug from the database turns Hide Login off and gives you wp-login.php back, and wp login-armor rescue prints every way back in without changing anything. One option can, and it says so on its own row: Force HTTPS. It is off by default, it is never switched on by the safe baseline, and the plugin refuses to switch it on from a connection that is not already HTTPS. It also stands down by itself, and tells you so in the admin, if the proxy in front of your site starts reporting HTTPS from an address you have not listed in Trusted proxy IPs, which is what happens when a CDN or a load balancer changes address. If you still end up locked out, one command puts it back: wp option patch update login_armor_hardening force_https false. If you cannot reach a shell either, there is a break-glass switch: add define( 'LOGIN_ARMOR_SAFE_MODE', true ); to wp-config.php. wp-login.php answers again, the second factor is not demanded, the request firewall and the bot challenge drop back to logging only, and Force HTTPS stops enforcing all four of its effects, without any setting being rewritten. It is a constant and not an option, so it cannot be flipped from the database, and it is read once, while the plugin file loads: only code that runs before that can arm it, which means wp-config.php, a must-use plugin, or a plugin that loads earlier. A theme, or anything running on a WordPress hook, cannot, because by then the answer is already fixed. Brute-force lockouts are deliberately left running: clear your own address from the admin notice, or with wp login-armor rescue --ip=<your ip> --yes, which also lifts a blocked network that contains it. Delete the line to restore full protection. The "Block subnet" button refuses the network your own address belongs to.
No. Everything is lazy-loaded and indexed. On a normal login flow the extra SQL cost is under 2 ms.
Yes. Choose the proxy header in Settings and list the exact IP addresses or CIDR ranges of the proxies that are allowed to supply it. Forwarding headers are ignored when the immediate network peer is not explicitly trusted.
Yes, subdomain and subfolder. Each site has its own modules, logs, and thresholds.
Yes. Since 2.8.3 the root .htaccess rules go where the server applies them: the directory the site is served from (web/ under Bedrock), next to WordPress's own rewrite rules, rather than WordPress's directory (web/wp/). Under Bedrock, the safe-mode constant is set with Config::define( 'LOGIN_ARMOR_SAFE_MODE', true ); in config/application.php. Login Armor does not rotate your security keys: under Bedrock they live in .env and belong to your deployment. Know before you rotate them that it signs everyone out, and that the authenticator-app secrets are encrypted with AUTH_KEY: after a new AUTH_KEY, users sign in with a backup code, or an administrator runs wp login-armor 2fa reset <user> --yes and they enrol again. The Activity Log notices the change of keys; wp login-armor activity reset-chain starts a new baseline.
Yes. It was checked on a clone of a real headless back end (Nginx, Redis object cache, a Next.js front end reading the REST API). The hidden login URL, two-factor and brute-force lockouts protect the back office, while the public REST API, application passwords (previews, publishing scripts, MCP connectors) and revalidation webhooks keep working, even from an address that is locked out of the login form. Turn on headless mode (Settings > Headless back end). It keeps "Restrict REST API" and "Disable application passwords" off, the two settings that close what your front end reads and refuse what your scripts write with, whether the change comes from the screen, an import or WP-CLI. The Request Firewall never inspects REST requests, so it leaves your API alone, even in blocking mode, and it does not protect it either. Only its "Bad user agents" family blocks pages outside the REST API (feeds, the sitemap) when curl or python request them. Failed application passwords are logged and shown as their own incident, "Application password refused". Only unknown accounts count toward the lockout: an application password cannot be guessed, while a script holding a revoked one would otherwise lock your own address. Login Armor also records which networks each application password is used from, and alerts you the first time one is used from a hosting provider it has never been used from; you approve the network from the user's profile if it is one of your services. On a multisite network, a site administrator cannot approve the network of a password that belongs to another account, because WordPress requires the "manage_network_users" capability to edit another profile: a super administrator can, and everyone can on their own profile. If fail2ban watches the hidden login URL, count HTTP 429 too: it is what Login Armor answers once it locks an address. Do not add a fail2ban jail on the 401 answers of the REST API: it would ban the cloud addresses your front end reads from, for the whole site.
Yes. The Activity Log can forward every entry to an HTTPS endpoint you own (Settings > Activity Log): signed JSON (HMAC-SHA256), queued and retried, with the integrity-chain hashes so that your collector can verify the journal even if the local database is wiped. Alerts (incidents, lockouts, administrator accounts) go by email, Slack, Discord or webhook. The Events and Activity lists export to CSV, and every login attempt fires the login_armor_log_recorded action, which a must-use plugin can send to syslog or a SIEM.
Yes. Turn on "Write failures and lockouts to the system log" (Settings > Brute force). Each failed login that counts toward the lockout, and each lockout, then writes one line under the identity login-armor, facility auth: auth_failure ip=<address> vector=<form|xmlrpc|rest|other> reason=<code> and lockout ip=<address> level=<1|2>. Never the login typed. A wrong application password of an existing account is not counted, so fail2ban never bans your own scripts. Filter (/etc/fail2ban/filter.d/login-armor.conf): [Definition] then failregex = login-armor\[\d+\]: (?:auth_failure|lockout) ip=<HOST>. Jail, with the systemd journal: [login-armor], enabled = true, backend = systemd, journalmatch = SYSLOG_IDENTIFIER=login-armor, maxretry = 5, findtime = 600, bantime = 3600; with a log file instead of the journal, logpath = /var/log/auth.log. Setting up fail2ban is done as root on the server, and LoginArmor's allow list does not stop fail2ban: add your own addresses to ignoreip.
Yes, but disable overlapping modules on one side to avoid double lockouts. With WPS Hide Login or Rename wp-login.php, whose only job is hiding the login page, LoginArmor refuses to switch its own hidden login address on, and stands down with a notice if both end up active: never two hidden addresses at once.
Up to five custom tables in your own database: login events, brute-force attempts, incidents, and, when you switch the Activity Log on, its journal and its forwarding queue. Nothing leaves your server unless you enable a feature that says it does.