1524 Plugin Mysql_Native_Password Is Not Loaded | Login

You usually see error 1524 right when a client tries to sign in, often after a server upgrade, a container rebuild, or a new default auth setting. It can feel like your password suddenly stopped working. In most cases, your password is fine. The server is rejecting the auth method tied to that user.

This guide walks you through the fast checks, the safest long-term fix, and the few cases where enabling mysql_native_password still makes sense. The goal is simple: get back in, keep access stable, and avoid repeating the same outage on the next upgrade.

What Error 1524 Is Telling You

Error 1524 is MySQL saying it can’t use the authentication plugin named in the account row. For many setups, that plugin name is mysql_native_password. On MySQL 8.4, that server-side plugin ships disabled by default, so accounts that rely on it can’t authenticate unless you explicitly enable it. MySQL 8.4 manual calls out that behavior for 8.4 and later.

Two patterns show up again and again:

• Upgrade happened — You moved to MySQL 8.4 and older users still point at mysql_native_password.
• Client mismatch — Your app, driver, or GUI tool is pinned to an auth method that no longer matches the server’s policy.

Check Plugin State Without Guessing

Before you change anything, verify what the server can load right now. This keeps you from chasing the wrong fix on a mixed fleet where dev, staging, and prod run different images.

1. List loaded plugins — Run SHOW PLUGINS; and scan for mysql_native_password and caching_sha2_password.
2. Check startup options — Run SHOW VARIABLES LIKE '%native%'; and look for options that control native auth on your version.
3. Confirm user mapping — Run SELECT CURRENT_USER(); after a successful login to see the exact 'user'@'host' row in play.

If you’re on MariaDB, the story can differ. MariaDB still documents the mysql_native_password plugin for compatibility, yet you can still trigger 1524 if the plugin isn’t loaded or user metadata is corrupted.

1524 Plugin Mysql_Native_Password Is Not Loaded With MySQL 8.4 And Later

If your server version is MySQL 8.4.x, start here. MySQL 8.4 disables the server-side mysql_native_password plugin unless you enable it at startup. That is why a MySQL 8.0 setup can log in fine, then a MySQL 8.4 upgrade breaks the same accounts.

The clean fix is to move users to caching_sha2_password so you’re aligned with the default auth path in modern MySQL. Enabling mysql_native_password can be a short-term bridge when you’re blocked by an older client or a third-party app that can’t handle the newer plugin yet.

Quick Version Check

1. Check the server version — Run SELECT VERSION(); so you know if you’re in the MySQL 8.4 behavior zone.
2. List auth plugins in use — Run SELECT user, host, plugin FROM mysql.user ORDER BY user, host; to spot accounts tied to mysql_native_password.
3. Confirm the failing account — Try the login again and note which username and host entry it maps to.

Compatibility Table For Common Setups

Get Back In First

When you’re locked out, you need a path back to a working admin session before you can change users. The right move depends on what access you still have.

If You Still Have Any Working Admin Login

1. Sign in with the working account — Use a user that authenticates successfully, often one created after the upgrade.
2. Confirm the failing user plugin — Run SELECT user, host, plugin FROM mysql.user WHERE user='YOUR_USER';.
3. Decide on the fix path — Pick “Switch the user” for the long-term route, or “Enable the plugin” for a short bridge.

If No Account Can Log In

On a server you control, you can start MySQL with a safe recovery mode so you can adjust users, then restart normally. The safest approach is still to follow your platform’s official docs for your OS or managed service.

1. Stop the MySQL service — Use your init system or container stop command so the server is fully down.
2. Start in grant-bypass mode — Launch with --skip-grant-tables only long enough to repair users.
3. Open a local session — Connect on the same host, then fix the user’s plugin method.
4. Restart in normal mode — Shut down the grant-bypass instance, then start MySQL the standard way.

Grant-bypass mode is a sharp tool. Run it only on a locked-down host, keep the window short, and restart as soon as you’ve repaired access.

Fix Option A Switch Users To Caching_sha2_password

This is the path that ages well. MySQL client programs in 8.4 and later use caching_sha2_password by default. That means fewer surprises when you patch, rotate images, or change driver versions.

Switch One User Cleanly

1. Pick the exact account row — Identify the 'user'@'host' entry that your app actually uses.
2. Set the auth plugin — Run ALTER USER 'user'@'host' IDENTIFIED WITH caching_sha2_password BY 'new_password';.
3. Flush privileges when needed — If your setup is old or you just repaired tables, run FLUSH PRIVILEGES;.
4. Test from the app host — Connect from the same machine or network path your app uses, not only from localhost.

Use a fresh password when you switch plugins. It avoids edge cases with stale hashes and makes auditing easier.

Switch Many Users With A Safe Checklist

• Inventory accounts — Export user, host, and plugin so you know the blast radius.
• Stage changes — Convert a non-prod copy first, then repeat on prod once logins are verified.
• Update app drivers — Confirm your connector works with caching_sha2_password and TLS settings match.
• Rotate secrets — Update the app config, secret store, or CI variables right after the user change.

Fix Option B Enable Mysql_native_password As A Short Bridge

Sometimes you can’t switch right away. Maybe a vendor app ships an old connector. Maybe a legacy tool is hard-coded. In those cases, enabling the server-side plugin can buy you time, as long as you treat it as a temporary measure.

On MySQL 8.4, the manual documents a startup option that enables the plugin. Many admins set it in the MySQL config file so it survives restarts.

Enable The Plugin At Startup

1. Find the server config file — Common paths include /etc/my.cnf, /etc/mysql/my.cnf, or a container-mounted config.
2. Add the enable switch — Under the [mysqld] section, set the option MySQL documents for enabling native auth.
3. Restart the server — Restart MySQL so the plugin state is applied.
4. Confirm plugin availability — Run SHOW PLUGINS; and verify mysql_native_password is active.

Know When This Stops Working

MySQL 9.0 removes the server-side mysql_native_password plugin. At that point, config switches that try to enable it can fail at startup. If you’re planning a major version jump, treat this bridge as a short window, not a plan.

Common Traps That Keep The Error Coming Back

You can “fix” 1524 once and still get hit again after the next rebuild. These are the traps that cause repeat outages.

Users Created Long Ago With Old Plugin Defaults

If an account was created years back, the plugin field may still point at mysql_native_password. When you upgrade to MySQL 8.4, that field becomes a time bomb. Switching the user is cleaner than trying to keep the plugin enabled forever.

Client Flags That Force The Wrong Plugin

Some tools pass a default-auth flag or connector setting that forces mysql_native_password even when the server expects caching_sha2_password. Check your connection string, DSN, or GUI advanced settings. If you see a forced plugin setting, remove it and retest.

Container Images That Reset Your Config

In Docker and similar setups, your config may live inside the image. A rebuild can drop your [mysqld] settings and bring the error back on the next restart. Mount the config as a volume, or bake it into a managed image you control.

Broken User Rows After Downgrades Or Incomplete Upgrades

On older migrations, the mysql.user table can end up with values in the wrong columns. That can lead to 1524 even on versions where the plugin exists. Running the server’s upgrade tool and repairing system tables is often the quickest way out.

Hardening Steps So You Don’t Revisit This Next Month

Once logins work, spend ten minutes to lock in the win. These steps reduce the odds of a repeat page at 2 a.m.

1. Standardize on one auth method — Pick caching_sha2_password for new users, then migrate old accounts in batches.
2. Pin and test client libraries — Track your MySQL connector versions the same way you track app dependencies.
3. Store a recovery account — Keep one admin user tested after each upgrade, with a secret stored in your vault.
4. Record the server’s auth policy — Document the intended defaults in your repo so rebuilds match reality.
5. Run a post-upgrade login check — After patching, test logins from the app host and from a DBA host.

If you’re writing internal runbooks, include the exact SQL you ran, the server version, and the plugin state you observed. That small note speeds up the next incident.

When You See “1524 plugin mysql_native_password is not loaded” In Apps

The same server problem shows up in different wrappers. PDO might report SQLSTATE 1524. MySQL Workbench may show a login failure. PhpMyAdmin may throw an auth error. The fix is still at the server and user level, not in the UI.

Work through these app-side checks after you repair the server:

• Update the connector — Newer drivers tend to handle caching_sha2_password better, especially with TLS.
• Verify TLS mode — If your connector needs RSA certificate handshake, TLS can remove that friction.
• Remove forced plugin settings — Strip any option that pins mysql_native_password unless you truly need it.
• Re-test with a fresh user — Create a new account using the server defaults, then test your app against it.

If a vendor app can’t handle modern auth, keep the bridge short and track an upgrade plan. Each MySQL release makes mysql_native_password a less safe bet.

Most teams fix this once by switching users, then never see it again. If you prefer the fast bridge, set a calendar reminder to remove it after your client updates land. The quiet servers are the ones that keep their auth settings boring.

If you manage multiple servers, run the user-plugin query on each one and keep the output in version control. It turns guesswork into a quick, repeatable check for audits.

Send us your feedbackTell us what you thought about this post

Name * Email *

Your comment *

Quick check — what is …? *

Send feedback