Authlify documentation

Authlify is the free plugin on WordPress.org (its directory slug is modify-login). Authlify Pro is a separate add-on that needs the free plugin installed and active.

Requirements

• WordPress 6.4 or newer.
• PHP 7.4 or newer. Passkeys need PHP 8.0 or newer; everything else works on 7.4.
• Passkeys also need the site to run on https (browsers only allow them in a secure context; localhost works while developing).

Install the free plugin

1. Go to Plugins → Add New, search for “Authlify”, then click Install Now and Activate.
2. Or upload the zip under Plugins → Add New → Upload Plugin.
3. Or with WP-CLI:

   wp plugin install modify-login --activate

What activation changes

Nothing about how people log in changes yet: the login page stays at wp-login.php until you choose a new address. Brute-force lockouts and the activity log are on from the start. Two-factor login is available, but each person turns it on for themselves. CAPTCHA, the honeypot, the breached-password check and the hardening options stay off until you switch them on.

Authlify creates three database tables (activity log, lockout counters and passkeys) and a daily clean-up task. Its screens live under the Authlify menu: Dashboard, Login URL, Security, Two-factor, Designer, Activity, Settings and Docs.

Multisite

Network-activate Authlify to manage one set of settings for the whole network from Network Admin → Authlify. Settings start from the main site’s settings, and only super admins can change them. See WooCommerce and multisite.

Installing Authlify Pro is covered in Install Pro and activate your licence.

After activation a notice says “Authlify is active. Nothing is hidden yet.” Its button, Choose my login URL, opens the Login URL screen. The notice disappears once you save a new address.

1. Go to Authlify → Login URL.
2. Type a new address under New login address, or use the suggestion shown under the field (“Need an idea?”), and click Save changes.
3. A notice asks you to confirm. Click Open and confirm the new URL. It opens in a new tab and switches the address on.
4. Bookmark the new address. Authlify also emails it to the site admin address and to you.
5. Open Authlify → Dashboard. Leak Check runs on its own a few seconds after the address changes and reports whether the address can be discovered.

Until you confirm, both the old and the new address work, so a typo cannot lock you out. An unconfirmed change expires after 30 minutes and the old address stays. Cancel the change in the notice ends it early.

About ten minutes of settings that stop almost every automated attack without bothering real people.

1. Login URL. Choose a private address and confirm it. Keep Show visitors on Page not found.
2. Visitor IP address. Go to Authlify → Security → Brute force and check that Detected setup says Matches your setting. If your site is behind Cloudflare or a proxy, change Where visitors connect from first; otherwise lockouts can hit everyone at once.
3. Never lock out. Add your own fixed office or home IP address, if you have one.
4. Brute force. Keep the defaults: 5 failed attempts in 15 minutes, a 15-minute lockout, escalating lockouts on.
5. CAPTCHA. Choose Cloudflare Turnstile (or ALTCHA if nothing may be sent to another company) and turn on Test mode for a few days, then turn it off. See Add a CAPTCHA without blocking real people.
6. Hardening. Set XML-RPC to Block multi-password requests (or Off if you do not use the mobile app or Jetpack), and turn on Username discovery and Login error messages.
7. Two-factor. Set it up for your own administrator account from your profile, and store the backup codes safely.
8. Breached passwords. Turn it on under Authlify → Security → Passwords, at least for administrators and editors.
9. Activity. Keep 90 days of history and turn on the Lockout email.

Day one

• Keep a second browser (or a private window) logged in while you change the login address, the CAPTCHA or two-factor settings.
• Change the login address and confirm it. Test it in a private window.
• Tell the other people who log in about the new address. Links inside WordPress (emails, the admin bar, “Log in” links) update on their own.
• If a page cache is in use, check that the login address is not cached (see Cache conflicts).

During the week

• Run the CAPTCHA in test mode. The Safety panel shows how many submissions would have been blocked in the last 7 days.
• Look at Authlify → Activity. Failed logins for usernames that do not exist are bots; failures on real accounts from one place may be a forgotten password.
• Check the Leak Check result on the dashboard. “Passed” means none of the known routes reveal your login address.

After a week

• Turn off CAPTCHA test mode if nobody real would have been blocked.
• Ask everyone with an administrator account to set up two-factor login.
• Export your settings (Authlify → Settings → Import & export) and keep the file with your site backups.

Almost every attack on a WordPress login is a script posting guesses to wp-login.php. When the login page lives at an address only you know, those scripts get a “page not found” and give up. It is not a replacement for strong passwords or lockouts, but it removes most of the noise.

Go to Authlify → Login URL. The screen has two tabs: Login URL and Redirects.

Settings

Reserved addresses

Some words are refused because WordPress uses them, for example login, admin, dashboard, wp-admin, wp-login, register, feed, search, author, sitemap and WordPress query words such as p or s. The address also cannot match an existing page or post.

What to expect

• The login page answers at https://example.com/your-address/. With plain permalinks it is https://example.com/?your-address; the screen shows the exact form under Current login URL, with a Copy button.
• The login page is never cached and tells search engines not to index it.
• Logged-out visitors get the chosen response for wp-login.php (including disguised variants such as //wp-login.php or URL-encoded names), wp-register.php and any page under /wp-admin/. Inside /wp-admin/, the “page not found” response is a redirect to /404/ on your site.
• The WordPress shortcuts /login, /admin and /dashboard stop working for logged-out visitors.
• WordPress links to wp-login.php (lost password, “Log in” links, emails) point to your new address automatically.
• admin-ajax.php and admin-post.php stay reachable, so front-end forms keep working. Password-protected posts keep working too.
• Logged-in people who open the login address go straight to the dashboard. wp-login.php itself shows the blocked response to everyone, so always use your own address.

Limitations

• On a private site (Force login), visitors are sent to your login address, so it is no longer secret.
• WooCommerce’s My Account login form and other front-end login forms are not hidden; lockouts and CAPTCHA protect them instead.
• On multisite, wp-signup.php and wp-activate.php are not hidden because the network needs them.
• Do not run a second “hide login” plugin at the same time. Authlify names the one it finds at the top of the Login URL screen.

Authlify Pro can ban addresses that keep requesting the hidden addresses: see Honeypot login URL.

Find your situation in the table, then follow the steps below it. None of these needs FTP access to the plugin files or a support ticket; the wp-config.php and WP-CLI routes need access to your server (file manager, SFTP or SSH).

1. You forgot the login address

1. Check your email. Every time the address changes, Authlify emails it to the site admin address (Settings → General) and to the person who changed it. The subject is “[Your site name] Your login address”. While you are still logged in somewhere, Authlify → Login URL → If you ever lose the login URL → Email it to me now sends it again.
2. WP-CLI. Print the address:

   wp authlify url get

   If it prints wp-login.php followed by “(custom login URL is off)”, no custom address is set.
3. wp-config.php. Open wp-config.php in the root of your WordPress installation and add this line above the line that says “That’s all, stop editing!”:

   define( 'AUTHLIFY_DISABLE_HIDE', true );

   The custom address is switched off at once and /wp-login.php works again. Log in there, check or change the address under Authlify → Login URL, then remove the line.

If wp-config.php contains define( 'AUTHLIFY_SLUG', '…' );, that value is the login address. While AUTHLIFY_SLUG is set, the Login URL field is locked. If both constants are set, AUTHLIFY_DISABLE_HIDE wins.

2. Turn the custom address off from the command line

wp authlify url reset

This switches the custom address off (and cancels any unconfirmed change), so you log in at wp-login.php. It refuses to run while AUTHLIFY_SLUG is defined; remove that line instead. To set a known address directly, without the confirmation step:

wp authlify url set my-private-door

set refuses to run while AUTHLIFY_SLUG or AUTHLIFY_DISABLE_HIDE is defined, and applies the same rules as the Login URL screen (length, characters, reserved words, existing pages).

3. Locked out after wrong passwords

1. Wait. The message says how long. The first lockout lasts 15 minutes by default; repeat lockouts last longer.
2. Email yourself an unlock link. Click “Is this your account? Email me an unlock link.” under the lockout message and enter your username or email address. The link goes to the account’s own email address, works for 30 minutes, and lets that one account log in from the same device and address; the lockout for everyone else stays. At most 3 requests per hour per account and address (10 per hour per address in total). Nothing is sent when nothing is locked, or when the account does not exist.
3. Ask another administrator. They go to Authlify → Security → Brute force → Locked out right now and click Unlock next to your address, or Unlock everyone.
4. WP-CLI. List the active lockouts, then unlock one address, a network, or everything:

   wp authlify lockouts
   wp authlify unlock 203.0.113.7
   wp authlify unlock 198.51.100.0/24
   wp authlify unlock --all

   Unlocking an address also clears its network lockout. --all also lifts paused accounts. With Authlify Pro, wp authlify unlock also lifts honeypot bans.

4. Your address is on the block list

“Access from your network is blocked.” means your address matches Always block. Another administrator can remove it on Authlify → Security → Brute force. With WP-CLI you can empty the list:

wp eval "\Authlify\Settings::update( array( 'ip_denylist' => '' ) );"

5. The CAPTCHA stops you logging in

Add this line to wp-config.php, log in, fix the keys or choose another provider under Authlify → Security → CAPTCHA, then remove the line:

define( 'AUTHLIFY_DISABLE_CAPTCHA', true );

While it is set, every CAPTCHA is off and the CAPTCHA tab says so.

6. You cannot pass the two-factor step

1. Recovery email. On the two-factor step, “Can’t use your methods? Email me a recovery link” sends a one-time link to the account’s email address. See Two-factor recovery.
2. Another administrator can reset you under Authlify → Two-factor → Reset for a user.
3. WP-CLI. Remove a person’s authenticator app, backup codes and passkeys (user ID, login name or email; note the underscore):

   wp authlify reset_2fa [email protected]

4. wp-config.php. This turns two-factor login off for everyone without deleting anything; Pro two-factor rules and passkey-only roles pause too:

   define( 'AUTHLIFY_DISABLE_2FA', true );

7. An Authlify Pro rule blocks you

Country rules, login hours, honeypot bans and the “refuse the new login” session limit are all switched off by:

define( 'AUTHLIFY_PRO_DISABLE_RULES', true );

If agency white-labelling hides Authlify from your own account, define( 'AUTHLIFY_PRO_AGENCY_OFF', true ); lifts every agency restriction.

Remove every emergency line from wp-config.php as soon as you are back in. While it is there, that protection is off for everyone.

Many “hide login” plugins can be found in one request: a password-reset link, a redirect from /wp-admin/ or a theme link gives the secret address away. Leak Check tries those routes against your own site, as a logged-out visitor, and reports what it finds.

Where to find it

The Health panel on Authlify → Dashboard (with a Run Leak Check button), a status line on Authlify → Login URL, a dashboard checklist item, and Tools → Site Health.

How it works

• It only sends requests to your own site, logged out, without following redirects and without ever submitting a password. Each request carries a signed header, so the probes are not written to the activity log.
• It checks that the login address works and is not cached, then tries about forty routes: wp-login.php and disguised variants, every login action (register, lost password, logout and others), /wp-admin/ pages, the /login, /admin and /dashboard shortcuts, and public pages such as the homepage, a post, a 404 page, robots.txt, the sitemap, the feed and the REST index.
• A route leaks if it shows the login form, or mentions the address in a redirect or in the page.
• It also warns about things that help attackers without revealing the address: XML-RPC multi-password requests, usernames in the REST API and ?author= scans.

When it runs

• About ten seconds after the login address or hiding settings change, and once a week, while Automatic Leak Check is on.
• When you click Run Leak Check (at most once every 30 seconds).
• It does nothing while no custom login address is set.

Reading the result

Leak Check tests known routes on your own site. It cannot see links to your login address posted elsewhere, and it does not test pages behind a login.

Go to Authlify → Login URL → Redirects.

Settings

• Everyone: After login and After logout. Leave them empty for the WordPress default (the dashboard, or the page the person came from).
• By role: open a role to give it its own After login and After logout addresses. Empty fields use the addresses for everyone.
• Use {username} or {user_id} in an address, for example /members/{username}/. {username} is the person’s URL-friendly name (their “nicename”), not necessarily the name they log in with.

Which address wins

• After login: a specific destination in the login link (redirect_to) wins, unless it is just the dashboard. Then the first of the person’s roles that has a rule, then the address for everyone.
• After logout: a specific destination in the logout link always wins, then the role rule, then the address for everyone.
• People who cannot use the dashboard are sent to the homepage instead of a wp-admin address.

Only addresses on this site, or on hosts your site allows for redirects, are used. Anything else falls back to the WordPress default.

A password-guessing script tries thousands of passwords. Limiting failed attempts per IP address stops it, while everyone else keeps logging in as normal. Go to Authlify → Security → Brute force, panel Limit login attempts.

What to expect

• When one or two attempts remain, the error says so (not when Login error messages is on).
• A locked-out visitor sees “Too many failed login attempts. Please try again in N minutes”, with a link to email themselves an unlock link.
• The lock applies to the address, for every account, administrators included. People already logged in are not affected.
• Logins through XML-RPC, the REST API and application passwords are counted and locked too.
• An IPv6 visitor is counted by their /64, because one connection usually owns a whole /64.
• A successful login clears that address’s failure count, but not an active lockout.
• Current lockouts and paused accounts are listed under Locked out right now, with Unlock and Unlock everyone. Old counters are cleaned up daily.

Lockouts only work if Authlify sees each visitor’s real IP address. Behind Cloudflare or a proxy, set Visitor IP address first. On multisite the counters and lockouts are shared by the whole network.

Behind Cloudflare, a load balancer or a reverse proxy, every request seems to come from the proxy. If Authlify locked that address, it would lock out everyone. Forwarding headers carry the real address, but anyone can fake them, so Authlify only reads them from proxies it can trust.

Go to Authlify → Security → Brute force, panel Visitor IP address.

Set it up behind Cloudflare

1. Under Where visitors connect from, choose Through Cloudflare and save.
2. Check that Detected setup shows Matches your setting and that “Your IP address as seen now” is your own public address.
3. The activity log can now record the country Cloudflare reports (Authlify → Activity → Settings → Country).
4. Authlify marks the login page as not cacheable. If you use Cloudflare APO or a “Cache Everything” rule, add a bypass rule for your login address as well.

Only choose Through Cloudflare when traffic really passes through Cloudflare. Otherwise Authlify ignores the header and uses the connecting address. The Cloudflare ranges are built into the plugin, and the X-Real-IP header is not used. Tools → Site Health warns when the setting and your setup disagree.

Go to Authlify → Security → Brute force, panel Allow and block lists.

• Never lock out: your office or home IP. Failures from these addresses are not counted, they are never locked out, and they never see a CAPTCHA or the honeypot.
• Always block: these addresses can never log in. They get “Access from your network is blocked.” They can still view the site.
• Enter one IPv4 or IPv6 address or CIDR range per line (commas also work), for example 203.0.113.7, 198.51.100.0/24 or 2001:db8::/32. Invalid entries are refused when you save.
• You cannot save a block list that contains your own current address.

Both lists only apply while brute-force protection is on, and they use the address from the Visitor IP setting, so set that first.

A CAPTCHA stops scripts that guess passwords, create fake accounts or post spam before they reach WordPress. Go to Authlify → Security → CAPTCHA. The tab has three panels: CAPTCHA provider, Where and when and Safety.

What to expect

• The provider’s script loads only on pages that show a protected form.
• A failed check shows an error on the form and is logged as “CAPTCHA failed” with the reason. Failed CAPTCHA checks do not count towards lockouts.
• Logins through XML-RPC, the REST API and application passwords cannot show a CAPTCHA; the brute-force limits cover those.
• Addresses on Never lock out never see a CAPTCHA. Logged-in people never see one on comments or checkout.
• The block-based WooCommerce checkout is not covered.

If a CAPTCHA ever stops you logging in, add define( 'AUTHLIFY_DISABLE_CAPTCHA', true ); to wp-config.php, log in, fix the settings and remove the line.

Save keys safely

1. Choose the provider and paste the Site key and Secret key.
2. Under Preview, click Show preview and complete the check. The provider’s script loads only when you click.
3. Click Save changes. Authlify checks the secret key with the provider using that preview answer. A wrong key is refused and nothing is saved, so a typo cannot lock anyone out.

Saving without completing the preview is refused, unless test mode is on (then it saves with a warning). If the provider cannot be reached, the keys are saved with a warning. Answers solved on another website are refused.

1. Go to Authlify → Security → CAPTCHA and choose a provider. Cloudflare Turnstile suits most sites; ALTCHA needs no account and sends nothing elsewhere.
2. Paste the site key and secret key (not needed for ALTCHA), click Show preview and complete it.
3. Turn on Test mode, set When to show it to Only after failed logins, and save.
4. After a few days, the Safety panel shows how many submissions would have been blocked in the last 7 days. Check Authlify → Activity for “CAPTCHA failed” entries from real users.
5. Turn test mode off.

Go to Authlify → Security → CAPTCHA, panel Safety, and turn on Honeypot (off by default).

• It adds a hidden field to the same forms the CAPTCHA protects. People, screen readers and password managers never see it; bots that fill in every field do.
• It also adds a signed time stamp. A form sent back in under 2 seconds, with a missing or altered stamp, with a stamp older than a day, or with a stamp already used, is refused.
• It works with or without a CAPTCHA provider, and test mode applies to it too.

A honeypot stops simple scripts, not determined attackers. Use it with lockouts, and a CAPTCHA where spam is a problem.

Go to Authlify → Security → Hardening. Every option here keeps the WordPress default until you change it.

The same tab holds the Private site panel: see Force login.

Go to Authlify → Security → Hardening, panel Private site.

• Force login (off by default): “Require login to view the site”.
• Public pages: paths that stay public, one per line (commas also work). A path includes its sub-pages: /shop covers /shop/ and /shop/item, but not /shopping. Use / for the home page only. Full URLs are accepted; only the path is used. There are no wildcards.

What to expect

• Logged-out visitors are redirected to your login address and come back to the page they wanted after logging in.
• Anonymous REST API requests get “You must be logged in to use this site.” (HTTP 401).
• The login page, robots.txt, admin-ajax and scheduled tasks keep working. RSS feeds are redirected too.

On a private site the custom login address is no longer secret. XML-RPC is not affected (set it to Off if you do not need it). Pages other services must reach, such as payment callbacks, webhooks or a WooCommerce shop, need a Public pages entry.

Go to Authlify → Security → Passwords, panel Breached passwords.

• Breached-password check (off by default): “Refuse passwords found in known data breaches”.
• Roles: tick the roles to check. Leave all unticked to check everyone.

When it runs

Whenever a password is set: profile screens, adding a user, password resets, registration forms that ask for a password, and WooCommerce registration, account details and checkout account creation. It does not run at login, so existing passwords keep working.

How the password stays private

Authlify hashes the password with SHA-1 and sends only the first 5 characters of the hash to the Have I Been Pwned range service (api.pwnedpasswords.com). The service answers with every breached hash starting with those characters, and Authlify compares the rest on your server. Neither the password nor its full hash leaves your site. Answers are cached for a day.

A breached password is refused with a message saying how often it appeared in breaches, and is logged as “Breached password refused”. If the service cannot be reached within 3 seconds, the password is accepted.

Authlify Pro also checks existing passwords at login and adds length, history and expiry rules: see Password policy.

A stolen or guessed password is not enough when the account also needs a code from the owner’s phone or a passkey on their device. Settings live at Authlify → Two-factor; each person sets it up under Users → Profile → Two-factor login.

Setting it up (each person)

1. Authenticator app: click “Set up an authenticator app”, scan the QR code with Google Authenticator, 1Password, Authy or a similar app, enter the 6-digit code and click “Verify and turn on”. The Two-factor screen also has Set up for my account.
2. Backup codes: 10 one-time codes are created after the first method. They are shown once, so save them. Each works once; you are warned when two or fewer are left, and “Create new codes” replaces the whole set.
3. Passkeys: click “Add a passkey” and follow the browser’s prompt.

Signing in

• After the correct password, the “Confirm it’s you” step asks for the code or passkey. “Having trouble?” switches to another method, such as a backup code.
• Authenticator codes work once. After 5 wrong codes the person has to sign in again, and wrong codes count towards brute-force lockouts.
• “Remember me” from the password step is kept. Logins from WooCommerce My Account and other front-end forms continue to the same step.
• Apps that log in with the account password over XML-RPC or the REST API are refused for people with two-factor; they must use an application password.

Who uses it

The Who uses two-factor login panel lists, per role, how many people use an authenticator app or passkey (backup codes alone do not count). The Users list gets a “2FA” column, and the dashboard checklist shows how many administrators use it.

In the free plugin two-factor is opt-in per person. If Two Factor, WP 2FA or Wordfence Login Security is active, Authlify steps aside and says which plugin is in charge. Authenticator secrets are encrypted with keys derived from your wp-config.php security keys; changing AUTH_KEY or SECURE_AUTH_SALT makes them unreadable, so people then need a backup code, a passkey or a reset.

Authlify Pro can require two-factor for chosen roles, and adds email codes, trusted devices and sudo mode: see Required two-factor for roles.

Requirements

• PHP 8.0 or newer (with OpenSSL). On older PHP the option is greyed out on the Two-factor screen, with the version shown.
• https (or localhost while developing), and a browser or device that supports passkeys.

Add a passkey

Under Users → Profile → Two-factor login, click Add a passkey, confirm with the device, and give it a name such as “MacBook Touch ID”. Passkeys can be renamed or removed there.

Use it

• As the second step: after the password, choose “Use my passkey”.
• Instead of the password: with Passkey sign-in on, the login form shows “Sign in with a passkey” once anyone on the site has added one, in browsers that support passkeys. It counts as both factors and needs the device’s PIN or biometric.
• Passkey sign-in respects lockouts; failures are logged but do not count as wrong passwords.

A passkey belongs to the site’s domain. After moving the site to another domain, everyone must add their passkeys again. Only public keys are stored; the private key never leaves the device.

Recovery email (self-service)

• On the two-factor step, “Can’t use your methods? Email me a recovery link” sends a link to the account’s email address. It is also available from a separate “Account recovery” form, which asks for the username or email and the password.
• The link works once, for 15 minutes, and replaces any earlier link. At most 3 links per account per hour (and 5 requests per address per hour from the separate form).
• Opening it shows a confirmation page first, so email scanners cannot use it. It signs the person in once and takes them to their profile to set up a new method. Existing methods are kept, and the site admin address is notified.
• It is only offered after a correct password, and when the account has a valid email address.

Reset by an administrator

Go to Authlify → Two-factor, panel Reset for a user: find the person by username or email and click Reset. It removes their authenticator app, backup codes and passkeys (you never see their secrets), so they can sign in with their password and set up again. Administrators can also use “Reset two-factor login” on the person’s profile.

WP-CLI and emergency switch

wp authlify reset_2fa <user-id|login|email>

To turn two-factor off for everyone without deleting anything, add define( 'AUTHLIFY_DISABLE_2FA', true ); to wp-config.php, and remove it as soon as you are back in.

Go to Authlify → Designer. Nothing changes on your login page until you switch a design on and save.

Brand the login page in a few minutes

1. Click Match my site to start from your theme’s colours, font and logo, or pick a template.
2. Adjust the sections on the left. The preview updates as you go.
3. Use the screen switcher above the preview to check the other screens, and the device buttons for tablet and phone sizes.
4. Turn on Use this design and click Save (or Ctrl/Cmd+S). Open your login address in a private window to see the result.

Templates and Match my site

• Twelve templates: Default, Minimal light, Minimal dark, Glass over photo, Split image left, Split image right, Corporate blue, Soft gradient, Midnight, Warm sand, High contrast (WCAG AAA) and Sidebar.
• Match my site builds a design from your theme’s colours, font and logo (theme.json and the Site Editor, the Customizer, and popular themes such as Astra, GeneratePress, Kadence and Blocksy). It reads your own site only, and nothing is saved until you click Save.

Sections

Colours, Layout (centred card, split image, sidebar, full bleed or the classic WordPress placement), Background, Logo, Form, Fields, Button, Links & text, Messages and Custom CSS. Fonts are system fonts, bundled fonts (Inter, Nunito, Space Grotesk, Lora) or your theme’s font; nothing is loaded from a font CDN. A warning appears when text and background colours have too little contrast.

Every screen

One design styles Log in, Lost password, Register, Reset password, the two-factor step, the lockout message, Confirm admin email, the log-out confirmation and the “session expired” pop-up.

Saving and undo

• Undo and Redo (Ctrl/Cmd+Z) keep 100 steps. Unsaved work is kept as a draft for a day and offered back when you return.
• More actions: revert to saved, reset to the Default template, start from plain WordPress, export the design as JSON, or import one.
• Styles are compiled into a small CSS file in wp-content/uploads/authlify/, or printed inline if that folder is not writable.
• Custom CSS is limited to 20,000 characters, and anything that could run scripts or load remote styles is removed.

Authlify Pro adds 22 templates with animated and video backgrounds, branded emails, login blocks and a popup: see Premium templates and effects.

Go to Authlify → Activity, with a Log tab and a Settings tab. The dashboard shows the latest entries and seven-day totals.

What is recorded

Logins, failed logins, lockouts and unlocks, blocked addresses, CAPTCHA failures, logouts, password resets, login address changes, log clearing, two-factor and passkey events, recovery emails and refused breached passwords. Each entry keeps the time, event, user, username, IP address, browser (user agent), country when known, and details such as the channel (login form, XML-RPC, REST API or WooCommerce) and the reason for a failure.

Using the log

• Filter by event or date range, or search for a username or IP address. Clicking an IP address searches for it (a partial match).
• Export CSV downloads the filtered entries (up to 100,000 rows). Cells that could be read as spreadsheet formulas are neutralised.
• 50 entries per page, with Newer and Older buttons.

Settings

Clear the log → Delete all entries empties the log at once. It cannot be undone.

On multisite the log is shared by the network, so each site’s Activity screen shows entries from all sites, and clearing it clears every site.

Authlify Pro adds login alerts, chat and webhook channels, a local country database and scheduled CSV exports: see Login alerts.

Go to Authlify → Settings, which has three sections: Switch plugins, Import & export and Data.

Switch from another plugin

Authlify lists the plugins whose settings it finds in your database, even if that plugin is no longer active. Click Import to copy them; nothing in the other plugin is changed.

After importing a login address, deactivate the other plugin’s login feature at once. Two plugins changing the login address can reveal it or lock you out.

Move from WPS Hide Login without a gap

1. Install and activate Authlify while WPS Hide Login is still active.
2. Go to Authlify → Settings → Switch plugins and click Import next to WPS Hide Login. Authlify takes over the same address straight away.
3. Deactivate WPS Hide Login immediately.
4. Log in at the same address in a private window, then check Leak Check on the dashboard.

Export and import

• Export settings → Download saves authlify-settings-YYYY-MM-DD.json with your settings and login page design. The CAPTCHA secret key and any unconfirmed login address change are left out. The file does contain the login address, so store it privately.
• Import settings: choose a file exported by Authlify and click Import. Only settings this site knows are imported; the CAPTCHA secret key, the uninstall choice and the setup status never are.
• The login address is only imported when you tick Also import the login URL. It then goes through the usual confirmation step.

Data on uninstall

On uninstall (off by default): when on, deleting the plugin from the Plugins screen removes all Authlify settings, logs, lockout counters, two-factor data, passkeys, the compiled login styles and scheduled tasks. Deactivating never deletes anything, and with the setting off a reinstall picks up where you left off.

Database tables

On multisite these tables are shared by the network. Settings are stored in the authlify_settings option (a network option when network-activated) and the design in authlify_design. Two-factor data is user meta: the authenticator secret is encrypted, backup codes and one-time tokens are stored only as hashes.

Retention and anonymisation

• Log entries are deleted after 90 days by default (Authlify → Activity → Settings → Keep entries for); 0 keeps them forever.
• Anonymize IPs applies to new entries.
• Passwords are never stored or logged by Authlify, including failed ones.

Personal data requests

Authlify registers “Authlify login activity” with the WordPress Export Personal Data and Erase Personal Data tools (Tools menu). They cover log entries linked to the person’s account; failed attempts with a username that does not exist are not linked to anyone. Authlify also adds suggested text to Settings → Privacy → Policy guide.

Permissions

Every Authlify screen needs the manage_options capability (administrators), or manage_network_options when network-activated. Each person manages only their own two-factor methods; administrators can reset them but never see secrets or codes.

Nothing outside your site is contacted unless you turn on a feature that needs it. The free plugin loads no fonts, scripts or images from a CDN on its own, and sends no usage data. Emails go through your site’s own mail setup.

Authlify Pro

1. Make sure the free Authlify plugin is installed and active. Pro requires it (WordPress 6.4+, PHP 7.4+).
2. Download the Authlify Pro zip from your purchase email or your account on store.mantrabrain.com.
3. Go to Plugins → Add New → Upload Plugin, choose the zip, click Install Now and Activate.
4. Go to Authlify → Settings → License, paste your Licence key and click Activate licence. The screen shows the expiry date and how many sites use the licence.

Pro adds its screens to the existing Authlify menu: Two-factor → Rules & report, Sign-in methods (Social & SSO, Passwordless), new tabs under Security (Password policy, Sessions, Access rules), Designer → Emails & extras, Activity → Alerts, and Settings → Agency and License. Your free settings carry over untouched.

Licence and updates

• An active licence gives you updates through the normal WordPress update screens, and support.
• Every Pro feature keeps working when the licence lapses; only updates and support stop. Nothing security-related is switched off.
• Refresh status re-checks the licence. Deactivate on this site frees the activation before you move the licence to another site; uninstalling does not deactivate it at the store.
• Without a saved key, the site contacts the licence server only when you click Check for updates or View details.

wp authlify-pro license status
wp authlify-pro license activate <key>

Go to Authlify → Two-factor → Rules & report, panel Require two-factor login.

What people see

• During the grace period, after signing in, a “Protect your account” screen offers Set it up now or Remind me next time. wp-admin shows a reminder with a Set it up button.
• When the grace period is over, the sign-in does not complete: a setup wizard runs first (authenticator app, email code if offered, passkey where possible), then creates backup codes and signs the person in. The setup link lasts 30 minutes.
• People already signed in are sent to the wizard on their next page view. XML-RPC and REST logins, including application passwords, are refused until they finish.
• People in a required role cannot remove their last two-factor method.

Coverage report

The Coverage report panel lists each role with Users, With 2FA, In grace, Overdue and Without 2FA. Click a number to see the people (up to 200), or Download CSV for everyone.

Rules pause while two-factor login is turned off on the Two-factor screen, while AUTHLIFY_DISABLE_2FA is set, or while another two-factor plugin is active. With the grace period set to none, everyone in the chosen roles, including you, goes to the wizard straight away; you are asked to confirm if that includes you.

Go to Authlify → Two-factor → Rules & report, panel Methods and devices, Email codes (“Offer email codes as a two-factor method”, on by default). A Send test email button is in the Tools panel on the same screen.

• Each person turns it on under Users → Profile → Email codes: a code is sent, they enter it, and backup codes are created if they had none.
• At sign-in, a 6-digit code is emailed. It expires after 10 minutes and allows 5 attempts. “Send a new code” is available after 60 seconds.
• At most 10 code emails per person per hour, shared by all purposes (sign-in, setup, sudo confirmation and passwordless codes). Only the newest code works.

Email is weaker than an authenticator app or passkey: anyone who can read the mailbox can sign in. Turning the setting off stops new setups; people who already use email codes keep them.

Go to Authlify → Two-factor → Rules & report, panel Methods and devices: Trusted devices (“Let people remember a device”, off by default) and Remember for (30 days by default, 1–365).

• The two-factor step gets a “Remember this device for N days” box (not for passkey sign-in, where it is not needed).
• A signed, HttpOnly cookie marks the browser; the server stores only a hash, with the browser, system, IP address and dates. Up to 20 devices per person.
• People see and forget devices under Remembered devices on their profile. All of a person’s devices are forgotten when their password changes or their two-factor is reset. Forget all in the Tools panel forgets everyone’s.

Ask people to confirm it is really them before sensitive changes, so a stolen session cookie cannot take over the site. Go to Authlify → Two-factor → Rules & report, panel Sudo mode: Confirmation (off by default) and Ask again after (15 minutes by default, up to 720).

What asks for confirmation

• Opening Plugins → Add New, Themes → Add New or Users → Add New; installing, updating, activating or deleting plugins and themes.
• Giving someone an administrator-level role, or making it the default role for new users.
• Creating application passwords.
• Saving or importing Authlify settings, resetting someone’s two-factor, creating temporary access links, removing your last two-factor method, adding a passkey and connecting a social account.
• The matching REST API requests from a browser session (for example from the block editor).

How it works

• The person confirms with their two-factor method, or their password if they have none. The confirmation lasts for the chosen minutes, per session.
• After confirming, the interrupted form is sent again; any passwords or keys in it are asked for again rather than stored.
• 5 failed confirmations sign the person out, and failures count towards lockouts.
• Not asked in WP-CLI, cron or with application passwords.

Go to Authlify → Sign-in methods → Passwordless, section Login links and codes, panel Sign in without a password.

What people see

• An “Email me a login link” (or code) link on the login form and the WooCommerce My Account login form.
• The answer is the same whether or not the account exists. Opening a link shows a “Log me in” button first, so email scanners cannot use it up. Only the newest link works.
• Requests are limited to 10 per hour per address and 3 per 15 minutes per account; lockouts apply.

Give a developer, support agent or client time-limited access without sharing a password. Go to Authlify → Sign-in methods → Passwordless → Temporary access.

Create a link

1. In New temporary access link, enter a Name, choose a Role (Editor by default; Administrator shows a warning) and Expires after (1 hour to 30 days, 3 days by default).
2. Optionally enter an address under Email the link; it becomes the user’s email.
3. Optionally set Maximum uses (0 means unlimited until it expires), Allowed IP addresses, When it ends (delete the user and give their content to you, or keep the user without a role) and Two-factor login (whether to skip the second step).
4. Create the link. It is shown once. You need permission to create users, and sudo confirmation if it is on.

How it works

• A new user named temp-… is created. Opening the link shows a Sign in button; each sign-in counts as a use.
• The temporary user cannot sign in with a password, reset it or create application passwords, and their session ends at the expiry.
• The Temporary access links list shows each link’s status, expiry, uses and last use, with Revoke. Expired links are cleaned up hourly. Every use is recorded in the activity log.

Google, Microsoft, Apple, GitHub and any OpenID Connect provider (Okta, Entra ID, Auth0, Keycloak and others). Go to Authlify → Sign-in methods → Social & SSO.

Set up a provider

1. Open the provider’s row and turn on Show this sign-in option.
2. Copy the Callback URL into the provider’s console (also called the redirect URI; Apple calls it the Return URL and needs https). It is your login address plus ?action=authlify_social&provider=google (or microsoft, apple, github, oidc). If you change the login address, update it at the provider.
3. Paste the Client ID and secret back, then click Test connection.

Secrets are stored encrypted, never shown again, and left out of exports and the REST API.

Account rules

• A person is recognised by the provider’s account ID once linked. Otherwise a verified email is required.
• Auto-link (off by default) links an existing account with the same verified email. When off, people sign in with their password once and connect from their profile.
• New accounts, per provider: follow the site’s “Anyone can register” setting, always allow, or never. Role for new accounts never uses editor- or administrator-level roles.
• Allowed email domains limit a provider to your company’s domains (one per line).
• Administrator accounts are blocked from social sign-in unless you allow their role.
• Show buttons on: login, registration and WooCommerce My Account (all by default).
• Two-factor, lockouts and access rules still apply after a social sign-in.

Microsoft work accounts only count as verified with the xms_edov optional claim, so auto-linking and sign-up may be refused without it.

Without WooCommerce, put the same security page on any page with the shortcode:

[authlify_account_security]

If the Security tab shows “page not found”, re-save Settings → Permalinks.

Go to Authlify → Security → Sessions.

• Session length and devices, per role: Stay signed in for at most N hours and Devices at the same time. Leave a field empty for no limit; with several roles, the strictest value applies.
• Over the session limit: “Log in, and end the oldest session” (recommended, the default) or “Refuse the new login until a session ends”.
• Idle logout: Log out after N minutes without activity (0 turns it off; at least 2 minutes), For these roles (all when none are ticked). A “Stay logged in” warning appears a minute before.

Active sessions

Each profile lists active sessions (browser, IP address, country, last activity) with End and Log out everywhere else; administrators viewing someone else also get Log out everywhere.

Go to Authlify → Security → Password policy.

Rules apply on profile screens, password resets, new users, WooCommerce account forms and the REST users endpoints. Passwords set directly by code or WP-CLI are not checked.

Go to Authlify → Security → Access rules.

Login by country

Rule: off (default), only allow the listed countries, or refuse them (two-letter codes, one per line). It affects logging in only; visitors from anywhere can still read the site. Addresses on Never lock out are always allowed. An unknown country is allowed, except in allow mode once the local country database is ready. It also applies to social sign-in and passwordless sign-in.

Login hours

Per role, the days and times (in the site’s time zone) when people may log in; overnight windows work. A role with no days ticked is unrestricted; with several roles, any allowed role lets the person in. Existing sessions are not ended.

A rule that would block you as you save it is refused. If you are ever locked out by a rule, add define( 'AUTHLIFY_PRO_DISABLE_RULES', true ); to wp-config.php, log in, fix the rule and remove the line. Adding your IP address to Never lock out also skips login hours.

While your login address is hidden, anyone requesting the old addresses is guessing. Go to Authlify → Security → Access rules, panel Honeypot login URL. It needs a custom login address with hiding on.

Logged-in people, allow-listed addresses and addresses that logged in successfully in the last 30 days are never banned. Bans are listed under Banned IPs with Unban; wp authlify unlock also lifts them.

Go to Authlify → Activity → Alerts, with sections Email alerts, Chat and webhooks and Reports and logs. Everything is off until you turn it on.

Alerts to users

• New device: email people after a login from a new device (browser, system and network). New country: after a login from a new country (needs a country source under Activity → Settings). Both off by default; limit them to roles if you like. The first login after you turn this on is only recorded.
• Copy admins: send the site admins a copy of every new-device alert.
• Each alert has a This wasn’t me: secure my account button (valid 7 days). It ends every session, forgets the device and emails a password reset link; the person cannot sign in until the password is changed.
• At most 3 alerts per person per hour.

Alerts to site admins

Under Email me when, tick the events: an administrator account is locked out; a user is made an administrator or super admin; a new administrator is created; an application password is created or used; a user turns off two-factor login; the login URL changes; failed logins pass the hourly limit; any IP is locked out; a user logs in from a new device or country; a user reports a login with “This wasn’t me”; an IP is banned by the honeypot login URL.

• Failed-login limit: 100 failed logins in one hour by default.
• Send admin alerts to: one address per line; empty means the site admin address.
• Hourly email limit: 20 by default, for all alert emails together. At most three emails per kind of event per hour. Emails are queued and sent in the background.

Reports and logs

• Attack insights: attacks by country, top IP addresses, targeted usernames and a 30-day trend on the dashboard.
• Weekly digest: logins, failed attempts, lockouts, new devices and the most targeted usernames, emailed to the admin recipients.
• Email the activity log as CSV: off, weekly or monthly, to Send exports to (empty: the admin alert recipients), with a Send now button.
• Delete failed-attempt noise after N days: failed logins, CAPTCHA failures and blocked requests go sooner than the main retention (0 uses the normal retention).

Go to Authlify → Activity → Alerts → Chat and webhooks. Up to 10 channels, each with its own events under Send these events.

Send a test message checks a channel. Stored URLs, tokens and secrets are shown masked.

Delivery

Messages wait in a small queue and are sent in the background with a 5-second timeout and no redirects. A failure is retried once after 5 minutes, then logged as “Alert delivery failed”. After three failures in a row a channel pauses for 15 minutes. Noisy events are throttled per hour and summarised; the queue keeps at most 200 routine messages per channel and drops messages older than a day. Local and private-network addresses are refused.

Verify the signature

Each JSON request carries X-Authlify-Event, X-Authlify-Delivery (a unique ID, repeated only on a retry), X-Authlify-Timestamp and X-Authlify-Signature: sha256=<hex>. The signature is an HMAC-SHA256 of the timestamp, a dot and the raw body, keyed with the whole signing secret.

<?php
$secret = 'whsec_…';
$body   = file_get_contents( 'php://input' );
$time   = isset( $_SERVER['HTTP_X_AUTHLIFY_TIMESTAMP'] ) ? $_SERVER['HTTP_X_AUTHLIFY_TIMESTAMP'] : '';
$expect = 'sha256=' . hash_hmac( 'sha256', $time . '.' . $body, $secret );
$got    = isset( $_SERVER['HTTP_X_AUTHLIFY_SIGNATURE'] ) ? $_SERVER['HTTP_X_AUTHLIFY_SIGNATURE'] : '';

if ( ! ctype_digit( $time ) || abs( time() - (int) $time ) > 300 || ! hash_equals( $expect, $got ) ) {
    http_response_code( 401 );
    exit;
}
$payload = json_decode( $body, true );
http_response_code( 204 );

The body contains delivery, event, title, text, site, site_name, time and a data object (user_id, username, ip, country, device, url, where they apply). Hash the raw bytes before decoding, refuse timestamps older than five minutes, and remember delivery IDs for five minutes to stop replays.

1. Go to Authlify → Activity → Settings and, under Country, choose Local country database (DB-IP Lite, CC BY 4.0). Save.
2. The free DB-IP Lite country file (about 5 MB) is downloaded from download.db-ip.com and rebuilt monthly into wp-content/uploads/authlify-geo/. It needs the PHP zlib extension. If an update fails, the previous database is kept.
3. Status and Update now are under Activity → Alerts → Reports and logs.

Lookups happen on your server; no visitor address is sent anywhere. While selected, it replaces CDN country headers and powers the Country column, new-country alerts, country rules and attack insights. Site Health warns if the database is missing or older than 62 days. Choosing another source deletes the files.

Pro adds 22 templates to the gallery in Authlify → Designer:

• The Effect section adds flowing gradients, aurora glow, floating orbs, falling snow, petals or leaves, festive lights or a video background, with colours and cycle length.
• Effects only run for visitors who have not asked their device to reduce motion. Videos are muted, loop and have a pause button.
• A default Video (MP4 or WebM, ideally under 5 MB) and Poster can be set under Authlify → Designer → Emails & extras → Default video background; without one, a built-in loop plays.

Go to Authlify → Designer → Emails & extras, panel Branded emails.

Every Authlify Pro email (alerts, digests, reports, login links and codes) is HTML with a plain-text version. Use Preview and send yourself a test email from the same panel.

Add these in the block editor or Site Editor, in the Authlify category. Forms post to your real login address, so lockouts, CAPTCHA and two-factor still apply.

Blocks

Popup shortcode

[authlify_login_popup label="Log in" style="button" redirect="" design="no"]

The popup opens only when clicked (and again after a failed attempt).

Site Editor login page

Under Authlify → Designer → Emails & extras → Site Editor login page, choose a published page that contains the Login form block, the Login popup block or the popup shortcode. Logged-out visitors who open your login address then see that page, with your theme’s header and footer. Lost password, two-factor and other actions still use the standard screen, and ?action=login always shows it. It needs a custom login address.

Go to Authlify → Settings → Agency.

Agency users

Tick the people on your team (super admins always count). Restrictions apply only to everyone else, and saving without yourself in the list is refused.

White-label

• White-label (“Use my own name and details”): Plugin name (Pro shows as “Name Pro”), Menu label, Description, Author and Author URL.
• Vendor branding: remove Authlify links and logo (docs, support, “View details”).
• Who sees the plugin: Hide menu hides the menu and screens, and Hide plugin hides both plugins on the Plugins screen, from everyone but agency users.
• Code-level names (REST routes, WP-CLI commands, page addresses) are not renamed.

Client handoff

Handoff mode (“Only agency users can change settings”): other administrators keep the dashboard, activity log and their own two-factor, but cannot change Authlify settings, the login design, or the License and Agency screens, from the screens or the REST API.

Multisite network

When network-activated, Per-site settings → Site admins may: change nothing (default), only make settings stricter, or change anything not locked. Locked settings can never be changed by sites. Sites with their own settings lists the overrides and resets sites to the network settings.

Design sync

Create a sync key under This site’s sync key (shown once). On another site, Copy a design between sites with the Other site address and Its sync key: Pull replaces this site’s design, Push replaces the other site’s. Design file moves a design as JSON instead.

A sync key can read and change the login design, so treat it like a password and revoke it when done. If white-labelling locks you out of your own settings, add define( 'AUTHLIFY_PRO_AGENCY_OFF', true ); to wp-config.php.

Authlify (free)

Authlify Pro

The disable switches weaken the site while they are set. Remove them as soon as you are back in.

Read-only constants defined by the plugin: AUTHLIFY_VERSION, AUTHLIFY_FILE, AUTHLIFY_DIR, AUTHLIFY_URL, AUTHLIFY_BASENAME, and AUTHLIFY_PRO_VERSION when Authlify Pro is active.

All free hooks start with authlify_, Pro hooks with authlify_pro_. The ones below are stable for integrations.

Events (actions)

Filters

Pro also provides the function authlify_pro_require_sudo( $reason, $return ) to ask for sudo confirmation in your own admin action; it returns true, or a WP_Error when confirmation is needed.

Some hooks can switch protection off (trusting a different client IP, skipping a CAPTCHA or two-factor step, exempting people from policies). They exist for specific integrations, are documented in the code only, and any code that uses them is security-critical.

Put this in a small plugin or mu-plugin. It runs after each activity log entry is written, so it respects the log settings.

add_action( 'authlify_logged', function ( $event, $row, $id ) {
    if ( ! in_array( $event, array( 'login_failed', 'lockout' ), true ) ) {
        return;
    }
    wp_remote_post( 'https://siem.example.com/ingest', array(
        'timeout'  => 3,
        'blocking' => false,
        'body'     => wp_json_encode( array(
            'event'    => $event,
            'username' => $row['username'],
            'ip'       => $row['ip'],
            'time'     => $row['created_at'],
        ) ),
    ) );
}, 10, 3 );

To record your own events, register a label, then write an entry:

add_filter( 'authlify_log_events', function ( $events ) {
    $events['my_sso_login'] = __( 'Signed in with company SSO', 'my-plugin' );
    return $events;
} );

\Authlify\Log\Log::add( 'my_sso_login', array(
    'user_id'  => $user->ID,
    'username' => $user->user_login,
    'context'  => array( 'provider' => 'acme' ),
) );

Read and save settings with \Authlify\Settings::get( $key ) and \Authlify\Settings::update( array( … ) ).

Authlify Pro provides routes under /wp-json/authlify-pro/v1/. Authenticate with a WordPress application password for an administrator (or a logged-in cookie with the X-WP-Nonce header). Only users who can manage Authlify are allowed.

curl -u 'admin:xxxx xxxx xxxx xxxx xxxx xxxx' \
  "https://example.com/wp-json/authlify-pro/v1/activity?event=lockout&per_page=20"

The free plugin’s /wp-json/authlify/v1/ routes and Pro’s /authlify-pro/v1/identity/ routes serve the profile and designer screens only; they are internal and can change, so do not build integrations on them. With sudo mode on, settings changes over REST from a browser session ask for confirmation; application passwords are not asked.

• Not confirmed yet. A new address works for 30 minutes before confirmation and stops working if it expires. Log in at the old address, open Authlify → Login URL and confirm or save it again.
• A cached copy. A page cache or CDN may have stored a “page not found” answer for that address. Purge the cache and exclude the address (see Cache conflicts).
• Plain permalinks. The address is then https://example.com/?your-address. The Login URL screen shows the exact form.
• Server rules. Some web server rules (.htaccess, nginx or a host firewall) block unknown paths or anything containing “login”. The request must reach WordPress.
• Another plugin. A second “hide login” or security plugin may be changing the login address too.

If you cannot get in at all, use AUTHLIFY_DISABLE_HIDE as described in Locked out? Every way back in.

What Authlify does

• The login page sends “do not store” headers and sets DONOTCACHEPAGE, which most caching plugins respect.
• WP Rocket, LiteSpeed Cache, SiteGround Optimizer and Breeze are told to skip the login address automatically, including an address waiting for confirmation.
• Tools → Site Health shows “Exclude the Authlify login URL from your page cache” when it detects a cache that needs a manual exclusion (for example W3 Total Cache, WP Super Cache, WP Engine, Kinsta or Cloudflare APO), with the steps.

Symptoms of a cached login page

• “The link you followed has expired”, or a failed login right after entering the right password.
• The login address shows “page not found” after you changed it.
• CAPTCHA widgets that never load or always fail.

Fix

Exclude /your-address/ (and /wp-login.php) from every cache layer: the caching plugin, your host’s cache and the CDN. Then purge all caches.

Behind Cloudflare, a load balancer or a host’s proxy, every visitor can look like the same address, so one attacker locks everyone out.

1. Go to Authlify → Security → Brute force and look at Detected setup and “Your IP address as seen now”. If that address is not your own public IP (for example 10.x, 172.16–31.x, 192.168.x or a Cloudflare address), the setting is wrong.
2. Choose Through Cloudflare, or Through my own proxy and list the proxy addresses under Trusted proxies (your host can tell you them).
3. Click Unlock everyone, or run wp authlify unlock --all.

Never trust forwarding headers from everyone: attackers could then choose any address, including one on your Never lock out list. That is why Authlify only reads them from proxies you name.

Not showing

• Check the form is ticked under Forms. With Only after failed logins, login forms only show it after failures.
• Addresses on Never lock out never see a CAPTCHA.
• AUTHLIFY_DISABLE_CAPTCHA in wp-config.php turns it off; the CAPTCHA tab says so.
• A script optimiser that delays or combines JavaScript can stop the widget loading. Exclude the provider’s script and the login address.
• WooCommerce forms appear only when WooCommerce is active, and only the classic checkout is covered.

Blocking real people

• Turn on Test mode: it logs failures without blocking while you investigate.
• For reCAPTCHA v3, lower the Minimum score (for example to 0.3).
• Make sure the site key is registered for this domain in the provider’s dashboard.
• Check Authlify → Activity for “CAPTCHA failed” entries and their reason.

• Authlify sends email through wp_mail(), like the rest of WordPress. If password-reset emails do not arrive either, the problem is the site’s mail setup.
• Use an SMTP plugin or your host’s mail service, so mail is sent from an authenticated address. Check the spam folder.
• The login address email goes to the site admin address (Settings → General) and to the person who made the change.
• Unlock links go to the locked-out account’s own email address, and only while something is actually locked. Requests for unknown accounts are silently ignored.
• If mail is broken and you are locked out, use WP-CLI or the wp-config.php constants instead: see Locked out? Every way back in.

• PHP 8.0 or newer. On older PHP, the passkey option is greyed out on the Two-factor screen, with the PHP version shown. Ask your host to upgrade.
• https. Browsers only allow passkeys on secure pages (https, or localhost while developing).
• The same domain. After moving the site to a new domain, existing passkeys stop working and must be added again.
• The method is offered. “Passkeys and security keys” must be ticked under Offered methods on Authlify → Two-factor.
• The login button only appears once at least one person has added a passkey, and while Passkey sign-in is on.

• Hide login plugins (WPS Hide Login and similar) and the “change login URL” feature of security suites: run only one. Authlify names the one it detects on the Login URL screen. Import the address, then switch the other off.
• Two-factor plugins. When Two Factor, WP 2FA or Wordfence Login Security is active, Authlify adds no second step or passkey button, and the Two-factor screen says which plugin is in charge.
• Limit-login plugins and security suites can run alongside, but two sets of lockouts and two CAPTCHAs confuse people. Keep one of each.
• Login customizers such as LoginPress: import the design into the Designer, then deactivate them.
• Server firewalls (mod_security, host rules) may block the login address or CAPTCHA requests. Check the host’s logs if a request never reaches WordPress.

WooCommerce

• The My Account login form keeps working and is not hidden. Lockouts apply to it, and the activity log marks its logins with the “woocommerce” channel.
• CAPTCHA can protect the WooCommerce login, registration, lost password and classic checkout (guest orders) forms. The block-based checkout is not covered.
• The breached-password check also runs when customers register, change their password in My Account, or create an account at checkout.
• With Force login on, add your shop, cart, checkout and My Account paths to Public pages.

Multisite

• Network-activated, one set of settings applies to all sites and is managed from Network Admin → Authlify by super admins.
• The activity log, lockout counters and passkeys are shared tables, so lockouts apply across the network and each site’s Activity screen shows all sites.
• wp-signup.php and wp-activate.php are not hidden. “Application passwords: Administrators only” means super admins.
• When Authlify is activated site by site, each site’s own On uninstall choice applies; network-activated, the network setting decides for every site.

Authlify Pro adds per-site overrides with locks: see Agency tools.

What is the difference between Free and Pro?

The free plugin includes the private login address, Leak Check, brute-force lockouts, all CAPTCHA providers and the honeypot, two-factor login with authenticator apps, backup codes and passkeys, the breached-password check, hardening, redirects, the activity log, the login page designer, import and export, and WP-CLI, with no usage limits. Authlify Pro adds two-factor rules by role, email codes, trusted devices and sudo mode; passwordless and temporary access; social login and OpenID Connect; alerts and webhooks; sessions, password policy and access rules; premium designs, branded emails and blocks; agency tools and a REST API.

Is hiding the login page real security?

It removes the noise: most automated scripts only know wp-login.php, and Leak Check shows the address is not revealed. But an address is not a password, so keep lockouts on and add a CAPTCHA, the breached-password check and two-factor login.

Does Authlify send my data anywhere?

No, unless you turn on a feature that needs a service, and then only what that feature needs. See External services.

What happens when I deactivate or delete it?

Deactivating sends the login page back to wp-login.php at once, stops lockouts and two-factor, and keeps every setting for when you reactivate. Deleting keeps your data too, unless Authlify → Settings → Data → On uninstall is on; then it removes the three Authlify tables, every Authlify option and user meta (including two-factor secrets and passkeys), the compiled login styles and the scheduled tasks.

How do updates work?

The free plugin updates through WordPress.org, from Dashboard → Updates or the Plugins screen, and works with automatic updates. Authlify Pro updates from its own server while its licence is active.

What happens when my Pro licence ends?

Every Pro feature keeps working, including two-factor rules, alerts and access rules. Only one-click updates and support stop until you renew.