How To Fix WordPress Security Key Not Working

How to Fix WordPress Security Key Not Working

If you are locked out, seeing random logouts, or getting cookie errors, the problem often comes down to WordPress security keys and salts.

This guide explains what they do, why they fail, and the exact steps to restore access without damaging your installation.

What WordPress security keys do

WordPress security keys and salts are cryptographic strings stored in the wp-config.php file.

They help protect authentication cookies, nonces, and logged-in sessions by making stolen data harder to reuse.

WordPress uses these constants:

AUTH_KEY
SECURE_AUTH_KEY
LOGGED_IN_KEY
NONCE_KEY
AUTH_SALT
SECURE_AUTH_SALT
LOGGED_IN_SALT
NONCE_SALT

When they are missing, duplicated, incorrectly pasted, or mismatched with browser cookies, login behavior can break.

In some cases, the site still loads normally, but users cannot stay signed in.

Common symptoms of broken security keys

The issue is not always obvious.

A WordPress security key problem can show up as one or more of the following:

Repeated login redirects
“Cookies are blocked or not supported by your browser” messages
Session timeouts after a few seconds
Automatic logout from the dashboard
Unable to access wp-admin
Nonce verification failures in forms or admin actions

These symptoms can also be caused by caching, domain mismatches, SSL problems, or plugin conflicts, so it helps to isolate the source before making changes.

Why WordPress security key not working happens

The most common cause is an incorrect wp-config.php entry.

Security keys may be absent, partly replaced, or pasted with formatting errors after a migration, manual edit, or restore from backup.

Other frequent causes include:

Old cookies saved in the browser after keys were rotated
Reverse proxy or CDN caching authenticated pages
HTTP and HTTPS domain inconsistencies
Site URL changes after moving from staging to production
Security plugins rewriting login behavior
File permission problems that prevent WordPress from reading config correctly

Because cookies depend on both server-side configuration and browser state, the fix often requires both cleanup and regeneration.

Check wp-config.php first

Open the root directory of your WordPress installation and inspect wp-config.php.

Confirm that all eight security constants are present and spelled correctly.

Each line should look similar to this format:

define('AUTH_KEY',         'unique-phrase-here');
define('SECURE_AUTH_KEY',  'unique-phrase-here');
define('LOGGED_IN_KEY',    'unique-phrase-here');
define('NONCE_KEY',       'unique-phrase-here');
define('AUTH_SALT',       'unique-phrase-here');
define('SECURE_AUTH_SALT','unique-phrase-here');
define('LOGGED_IN_SALT',  'unique-phrase-here');
define('NONCE_SALT',      'unique-phrase-here');

Make sure you have not accidentally removed a semicolon, introduced an extra quote, or pasted the lines outside the PHP block.

Even one syntax mistake can cause broader site errors.

Regenerate fresh security keys

If the keys are missing, duplicated, or suspected to be compromised, generate new ones using the official WordPress secret-key service.

WordPress publishes a secure generator at the API endpoint commonly used by developers and administrators.

Replace the existing key and salt block in wp-config.php with the newly generated values.

Use a secure connection and copy the entire block exactly as provided.

Important: rotating keys invalidates existing login cookies.

That is expected and is usually the fastest way to fix persistent authentication issues.

Anyone currently logged in will need to sign in again.

Clear browser cookies and site cache

After updating keys, clear the browser cookies for your domain.

Old cookies signed with previous keys will no longer validate, so the browser may keep sending broken session data until it is reset.

Also clear any cache layers that might serve outdated pages:

WordPress cache plugins such as WP Rocket, W3 Total Cache, or LiteSpeed Cache
Server-level caching from Nginx, Varnish, or managed hosting panels
CDN cache, especially Cloudflare or Fastly
Browser cache and private browsing data

If you use object caching with Redis or Memcached, flush that cache too.

Although object caching does not store authentication cookies directly, it can still contribute to stale session behavior during troubleshooting.

Verify your site URL and SSL settings

WordPress stores site URLs in the database and uses them to determine cookie scope.

If siteurl and home do not match the live domain, or if one uses HTTP while the other uses HTTPS, login sessions can fail.

Check these settings in the dashboard under Settings > General or directly in the database if you cannot log in.

Confirm that both values use the same protocol and domain, for example https://example.com.

Also verify that your SSL certificate is active and that redirects are consistent.

Mixed content, forced HTTPS rules, or misconfigured proxy headers can interfere with secure authentication cookies.

Temporarily disable plugins that affect login

Security plugins, caching plugins, and membership tools can alter login sessions or cookie behavior.

If regenerating keys does not solve the issue, test with plugins disabled.

Recommended approach:

Rename the plugins folder via FTP or hosting file manager to disable all plugins at once.
Try logging in again.
If it works, restore the folder name and reactivate plugins one by one.

Pay special attention to Wordfence, iThemes Security, Solid Security, login limiters, two-factor authentication tools, and any plugin that changes the default login URL.

Inspect file permissions and server configuration

Incorrect permissions can prevent WordPress from reading or applying configuration changes reliably.

As a general guideline, directories should usually be set to 755 and files to 644, though hosting environments may vary.

Also review these server-level factors:

PHP version compatibility with your WordPress release
Broken .htaccess rules on Apache
Misconfigured wp-config.php placement or duplication
Reverse proxy headers that affect HTTPS detection

If your host uses a managed stack, ask support whether any WAF, login protection, or session handling rule is interfering with cookies.

Use recovery methods if you cannot access wp-admin

If you are fully locked out, you can still fix security keys through file access or database tools.

Use FTP, SFTP, or your hosting file manager to edit wp-config.php.

If necessary, access the database through phpMyAdmin to confirm site URL values.

For emergency troubleshooting, you can also:

Rename plugin folders to bypass problematic extensions
Switch to a default theme by renaming the active theme directory
Regenerate security keys directly in wp-config.php
Clear cookies in an incognito window before testing again

These methods are especially useful on production sites where downtime must be minimized.

How to prevent WordPress security key problems in the future

Once the site is working again, reduce the chance of a repeat issue by following a few maintenance habits.

Keep a secure backup before editing wp-config.php
Avoid manual formatting changes when copying keys
Use HTTPS consistently across the entire site
Document plugin changes that affect authentication
Rotate keys only when there is a real need, such as a suspected compromise
Test login behavior after migrations, domain changes, or CDN updates

It also helps to store credentials and recovery access in a password manager, so troubleshooting can happen quickly if a lockout occurs.

When to suspect a deeper security issue

If the same login failures return after regenerating keys and clearing caches, the cause may be deeper than configuration.

Look for malware, compromised admin accounts, altered core files, or a malicious plugin that rewrites authentication behavior.

Signs of a larger problem include unexpected admin users, unfamiliar redirects, hidden code in wp-config.php, or repeated file changes after cleanup.

In that case, run a full malware scan and compare core files against a clean WordPress download.

Table of Contents