Everything you need to secure every sign-in.

Smarto Login Security decides where people sign in, how they prove who they are, and what happens to their sessions afterwards. A hidden URL or a missing button is never the only protection. The free plugin is complete on its own, with no account, license or time limit.

• Login URL and redirects: your own login address, a hidden wp-login.php and wp-admin, and the page people land on after login and logout.
• Two-factor authentication: authenticator apps, email codes and backup codes, required for the roles you choose.
• Brute-force protection: failed-login limits per IP and per account, rate limits for password reset and registration, and username protection.
• CAPTCHA: Google reCAPTCHA v2 or v3, or hCaptcha, on the forms you pick.
• IP rules: blocklist and allowlist with IPv4, IPv6 and CIDR ranges.
• Sessions and accounts: see who is signed in, end sessions, suspend accounts, read the Login History and get email alerts.
• WooCommerce: My Account login, registration and lost-password forms get the same protection. Checkout is never changed.

1. 1Install Smarto Login Security from Plugins > Add New Plugin and activate it.
2. 2Open Login Security > Login URLs and choose a custom login address. Open it in a private window to test it before you sign out.
3. 3Open Login Security > Authentication and choose which roles must use two-factor authentication. Each user sets up their own methods on their profile page.
4. 4Review Login Protection, CAPTCHA and IP Rules.
5. 5Open Diagnostics to check your setup.

The Login Security overview shows what is protected, users in required roles who have not set up 2FA yet, and recent security events.

1. 1Open Login Security > Login URLs and turn on Use a custom login URL.
2. 2Type a Login address: 3 to 60 lowercase letters, numbers and hyphens. Avoid obvious words like "login" or "admin".
3. 3Optional: choose where to send visitors who open wp-login.php or wp-admin. Leave it empty to show your theme's 404 page, which reveals nothing.
4. 4Click Save changes, then open the new address in a private window and sign in to test it.

• Email the new address to the site admin when it changes is on by default, so the address is never lost.
• Record visits to the hidden wp-login.php and wp-admin adds them to the Login History as "Blocked visit to hidden login", with the username when someone tries to sign in there. Guests opening /login, /admin or /dashboard are recorded too. Repeat visits from the same IP to the same place within an hour add to the entry's visit count instead of a new row. Signed-in users are never blocked or recorded.
• Password reset links, logging out and other WordPress actions keep working on the new address.
• Staff can sign in only on the custom login URL (on by default once the custom URL is on): anyone who can use the dashboard is refused on every other login form, such as WooCommerce My Account or another plugin's login page, even forms the plugin has never seen. They see the usual "wrong username or password" message, so a stolen password reveals nothing, and you get an email alert. Customers and members are not affected, and apps that use application passwords keep working.
• Where people sign in lists the places people signed in from in the last 30 days, found automatically from the Login History, and whether staff are allowed there. "No login form" means another plugin or tool signed someone in directly, for example an auto-login link; those sign-ins are not limited by this setting.
• Need staff on one front-end form? With Pro, add it under Integrations > Other login forms and choose the roles allowed there.

The overview lists sign-in attempts on your custom address from IPs that never signed in successfully. If you see them, someone knows the address: change it and consider blocking the IPs.

• Default page after login and Default page after logout, in Login Security > Redirects. A What happens now card at the top shows where people end up with your saved settings.
• With WooCommerce: Page after signing in on My Account. Empty means customers stay on My Account.
• Return users to the page they were trying to reach sends people back to the page that asked them to sign in.
• Redirects are limited to your own site, so they cannot send people to another domain.
• People without dashboard access, such as WooCommerce customers, are never sent to the dashboard.

Redirects for a single role or user are part of Smarto Login Security Pro.

1. 1Open Login Security > Authentication and keep the methods you want to offer switched on.
2. 2In Require 2FA for these roles, pick the roles that must use it, for example Administrator and Shop manager.
3. 3Choose when someone in these roles has not set up 2FA yet: remind them on the dashboard, send them an email code at every sign-in, or let them in once and require setup before they can use the dashboard.
4. 4Click Save changes. Each user sets up their own methods under Users > Profile.

Application passwords are separate credentials and do not ask for 2FA (WordPress design). Suspensions and lockouts still apply to them, and you can limit them to administrators or turn them off under Integrations.

All settings are in Login Security > Login Protection. The limits are shared by every login form, so attackers cannot switch forms to get more tries. A locked visitor sees the lockout as soon as they open the login page. IPv6 addresses are counted per network (/64), because one connection can switch between many addresses. Allowlisted IPs can skip lockouts, rate limits and CAPTCHA (an option under IP Rules).

• One error message for wrong usernames and wrong passwords.
• The same reply to password reset requests for unknown accounts.
• Blocked ?author=N lookups.
• The REST API user list hidden from visitors.
• Optional: remove author names from oEmbed data, remove the users sitemap, and hide author archives for chosen roles.

Find these under Login Security > Login Protection > Username protection.

1. 1Open Login Security > CAPTCHA and click a provider card.
2. 2Click Get keys, create keys for your domain, and paste the Site key and Secret key. Each provider keeps its own keys, so you can switch back without pasting them again. Saved keys show only their first and last four characters; paste a new one to replace it, or clear the field and save to remove it.
3. 3Click Test these keys. A window opens with the check: complete it (or click Check keys for the invisible types). It runs a real check with the keys in the form, saved or not, and says whether they work on your domain or what is wrong.
4. 4Choose the look: theme (light, dark or matching the page), size, and for reCAPTCHA v3 and v2 invisible where the badge sits or whether it is hidden. A hidden badge adds Google's required notice under the form.
5. 5Tick the forms to protect: WordPress login, registration, lost password and new password, and the same four WooCommerce forms.
6. 6Click Save changes.

• When to show it on login forms: every time, or only after a number of failed sign-ins from the same IP address within an hour. Real people usually never see it; attackers do.
• Show the CAPTCHA in the site language, or let it follow the visitor's browser.
• Load reCAPTCHA from recaptcha.net for visitors in countries where google.com is blocked.
• If the provider cannot be reached: block the form (safer) or allow it and log the error.
• Allowlisted IP addresses skip the CAPTCHA.

• Blocklist: these IPs and ranges cannot sign in.
• Allowlist: these IPs can optionally skip lockouts, rate limits and CAPTCHA.
• Single addresses, IPv6 and CIDR ranges such as 203.0.113.0/24 all work. Rules can expire and have a note.
• The overview lists IPs that tried your custom login address, with a Block IP link next to each.

1. 1Open Login Security > Settings. The How your IP address is detected card shows what the server sees.
2. 2If "Used by this plugin" shows your proxy or CDN instead of your own IP, choose the matching Client IP source, for example CF-Connecting-IP for Cloudflare.
3. 3List the proxy's IP ranges under Trusted proxies and save.

Forwarded headers are trusted only from the proxies you list, so visitors cannot fake their IP address. The Login History country is worked out from the same IP, so a wrong IP source also means a wrong country.

• Login Security > Active Sessions lists who is signed in, last activity, sign-in time, IP address with country, browser and sign-in method.
• Every browser or device is its own session. A session stays Signed in until the person logs out or it expires (after 2 days, or 14 with "Remember Me"), even when the browser is closed. So one person can have several sessions, and an old one can show last activity days ago.
• Your own session is marked This browser and cannot be ended from the list. If you have other sessions still signed in, for example from an earlier sign-in that never logged out, End my other sessions ends them all. Sessions with the same browser and IP as yours are marked as a likely earlier sign-in.
• End one session or all of a user's sessions. The session is revoked in WordPress, so the cookie stops working right away.
• Another plugin or tool as the method means the sign-in did not use the WordPress login form, for example a one-click login from your hosting.
• Choose which roles are tracked under Settings > Session monitoring, and how long ended sessions are kept.
• Block sessions created outside the protected login flow (under Settings) destroys sessions that code created without WordPress authentication, for users who need 2FA.

• Suspend from Users or Login Security > Suspended Users, for a set time or until you restore it, with an internal reason.
• Suspended users are signed out everywhere and refused by every login form, XML-RPC and application passwords.
• Choose whether suspended users are told their account is suspended, and the message they see.

• Filter by event group or a single event, dates, user or IP address.
• Each event shows the time, user, IP address, country, the exact page (Where) and details such as the sign-in method or the reason it failed.
• Changes made in the dashboard (settings, IP rules, suspensions) are on the Admin Activity page instead.
• Blocked visit to hidden login means someone opened the hidden wp-login.php or wp-admin and was turned away. "Sign-in attempt, blocked" means they also tried a username there.
• Entries are kept for 30 days by default, then removed automatically. A line at the top of the page shows whether it is recording.

Country is looked up in an IP to country database included with the plugin, so no IP address leaves your site. It works on every host, with or without a CDN. Countries are approximate (VPNs and mobile networks can show another country), and local or private addresses show a dash. Country data: IP Geolocation by DB-IP.

• Login Security > Admin Activity lists settings changes, IP rules added or removed, suspensions and restores, ended sessions, two-factor changes and temporary access.
• Done by shows who made the change; Affected user shows the account it changed, for example the suspended user.
• Settings changes name the sections that changed, for example "Custom login URL".
• Filter by type of change, dates, user or IP address. Entries are kept for 30 days by default.

1. 1Open Login Security > Settings and find Logs and data retention.
2. 2Record the Login History and Record Admin Activity are on by default. Untick one to stop recording it.
3. 3Set Keep the Login History for (days) and Keep Admin Activity for (days). Both are 30 days by default. Older entries are removed automatically.
4. 4Click Save changes.

With the Login History off, the Overview counts and the alerts for a new IP address or a leaked login URL stop working, because they need past sign-ins.

• Lockouts after repeated failed logins.
• Every login by a privileged user, or only logins from a new IP address.
• Sign-in attempts on your custom login URL from an IP that never signed in.
• Suspicious activity, suspensions and restores, sessions ended by an administrator.
• Security settings changes, and CAPTCHA or email provider failures.

Set the recipients and events in Login Security > Notifications. Similar emails are grouped, with at least 60 minutes between them by default. Choose which roles count as privileged under Settings.

• The My Account login, registration and lost-password forms share the failed-login limits, rate limits and CAPTCHA.
• Customers are sent to My Account after login, not the dashboard.
• Checkout is never modified.
• Turn it on or off under Login Security > Integrations.

Neither can show a CAPTCHA or ask for a 2FA code, because there is no form. Lockouts, IP rules and suspensions always apply to both. Choose under Login Security > Integrations.

• XML-RPC: On (WordPress default, accounts that need 2FA are refused), Block sign-ins (pingbacks from other sites still arrive) or Off completely (every request is refused). Some mobile apps, desktop editors and site connection services still use XML-RPC, so check before you turn it off.
• Application passwords: Everyone (WordPress default), Administrators only or Off. Saved application passwords are kept and work again if you allow them later.
• The Integrations page shows Protected once XML-RPC sign-ins are blocked and application passwords are limited, and Limited while either is left open.

These switches only relax extra restrictions. A normal WordPress password is still required. The custom login address is also emailed to the site administrator whenever it changes.

With WP-CLI:

wp smarto-ls login-url reset
wp smarto-ls ip clear
wp smarto-ls lockouts clear
wp smarto-ls 2fa reset <user>

• Stored: usernames tried, IP addresses and their approximate country (looked up on your site, never online), browser user agents (optional), times, sign-in methods and results, and session activity for tracked roles.
• Never logged: passwords, verification codes, sign-in tokens and secrets. Codes and tokens are stored only as keyed hashes; authenticator secrets and provider keys are encrypted.
• Logs are kept for 30 days by default and old entries are deleted automatically. A suggested privacy-policy text is added to Settings > Privacy, and the data works with WordPress personal data export and erasure.
• No tracking or analytics, and nothing is sent to WP Smarto.
• Deleting the plugin removes its data only if Delete all plugin data when the plugin is deleted is on under Settings. Otherwise settings, history and 2FA setups are kept for a reinstall.

• Login routes: a login address per role or user, exclusive routes and routes limited to IP addresses.
• Redirects after login and logout per role and per user.
• Sign-in methods: SMS codes through your Twilio account, magic links and six-digit sign-in codes by email.
• Temporary access: time-limited links for a developer or support agent, without sharing a password.
• Live sessions: online, idle and offline status, an Online now view, and people stay online while they read the public site.
• IP-limited roles: roles that may sign in only from allowlisted IPs.
• Other login forms: role and IP rules for other plugins' login pages and AJAX logins.

1. 1Install and activate the free Smarto Login Security plugin.
2. 2Download Smarto Login Security Pro from your account dashboard on wpsmarto.com.
3. 3Upload it in Plugins > Add New Plugin > Upload Plugin and activate it.
4. 4Activate the license (next section).

Pro settings appear inside the pages you already know: routes under Login URLs, passwordless under Authentication, other login forms and Twilio under Integrations, and a new Temporary Access page.

1. 1Open Login Security > Pro License and click Activate license.
2. 2Log in to wpsmarto.com if asked and approve the site.
3. 3You return to WordPress with the license active. Updates arrive in Dashboard > Updates like any plugin.

Manage plans, sites and invoices in your wpsmarto.com dashboard. To move a license, deactivate it on the old site first, or remove the site from your dashboard.

1. 1Open Login Security > Login URLs and find Role-specific login routes.
2. 2Click Add route, give it a Name and an Address.
3. 3Choose the Roles that can sign in here, and add Individual users if needed. Only listed roles and users can sign in through a route.
4. 4Optional: tick Exclusive so those users can sign in only through this address and are refused on every other login form.
5. 5Optional: limit the route to these IP addresses. Save, then test the address in a private window.

• Rules by role: a page after login and after logout for each role.
• Rules for individual users: override the role rule for one person.
• Find them under Login Security > Redirects. Like the free redirects, they stay on your own site.

• SMS codes: add your Twilio Account SID, Auth token and Sender under Integrations, then turn on text messages under Authentication. Users add their number in international format, starting with +.
• Magic links by email: a sign-in link with a confirmation click, so email scanners that open links cannot use them.
• Sign-in codes by email: a six-digit code instead of a password.
• Choose the Allowed roles and the link or code lifetime under Authentication > Passwordless sign-in. Requests are rate limited.

1. 1Open Login Security > Temporary Access.
2. 2Link to an existing account, or create a temporary account with the role you choose.
3. 3Set how long the link works, whether it is single-use, and optionally the IP addresses allowed to use it.
4. 4Copy the link and send it. Revoke it at any time; revoking ends the sessions it created.

Set the default duration, the longest allowed duration and what happens to a temporary account when its access ends under Temporary access options. Every use appears in the Login History.

• Online, idle and offline status, and an Online now view on Active Sessions. Set the minutes for online and idle under Settings > Session monitoring.
• Keep people online while they read the public site: without it, someone reading a long page without clicking turns idle. A tiny script checks in every 2 minutes while a tracked user has a page of the site open.
• The country of each session is shown by the free plugin, under the IP address.

• Roles that may sign in only from allowlisted IPs: people in these roles can sign in only from addresses on your allowlist. Optionally sign them out when their IP changes to one that is not allowed.
• Other login forms (under Integrations): add a form by its page address or AJAX action name, then choose the roles allowed to sign in through it and the IP addresses it accepts.