MySQL 8.4 Authentication Errors: mysql_native_password and caching_sha2_password Fixes

You upgraded to MySQL 8.4 LTS, and a deploy script now stops with ERROR 1524 (HY000): Plugin 'mysql_native_password' is not loaded. Or an application that worked for years fails with Authentication plugin 'caching_sha2_password' reported error: Authentication requires secure connection, but only after a restart. Both come from one change. MySQL 8.4 ships with the old mysql_native_password plugin turned off, and MySQL 9.0 removed it from the server. Every account, connector, proxy, and replication channel now has to speak caching_sha2_password, which needs TLS or an RSA key exchange the first time an account authenticates. This guide maps each error string to its cause, shows how to find the affected accounts, and gives a migration runbook to finish before you move to the 9.7 LTS series.

Scope and review date: November 2026. This post covers MySQL Community Server 8.0, 8.4 LTS, and the 9.x series up to 9.7.4 LTS, with notes for Amazon Aurora MySQL 8.4. Commands, error strings, and version numbers were checked against MySQL, connector, and proxy documentation on 9 November 2026. They were not run in a lab, so rehearse them on staging first.

What changed in MySQL 8.4 and 9.x authentication?

MySQL 8.0 made caching_sha2_password the default plugin for new accounts but left existing accounts alone. Many teams upgraded from 5.7 and kept every application user on mysql_native_password. That was fine until 8.4.

The MySQL 8.4 manual states it plainly: the plugin "is deprecated as of MySQL 8.0.34, disabled by default in MySQL 8.4, and removed as of MySQL 9.0.0." The 8.4 "What Is New" page also removes the default_authentication_plugin variable, so a 5.7-era my.cnf line that set it now stops the server from starting. The replacement is authentication_policy; when its first element is *, new accounts get caching_sha2_password.

Start by checking which plugin your current session and the server default use:

-- Which plugin did this session's account use?
SELECT CURRENT_USER(), plugin
FROM mysql.user
WHERE CONCAT(user, '@', host) = CURRENT_USER();

-- What will new accounts get?
SELECT @@GLOBAL.authentication_policy;

Interpretation: if the first element of authentication_policy is * or names caching_sha2_password, new accounts are created on the new plugin. Old accounts keep whatever plugin they had when they were created, which is why the problem hides until an upgrade.

MySQL 9.7 is the next LTS series after 8.4 (9.7.0 shipped on 21 April 2026, and 9.7.4 on 20 October 2026, per the 9.7 release notes). The release model page says you can go from 8.4 LTS to 9.7 LTS but cannot skip an LTS series, so every 8.4 estate meets this change on its next major upgrade.

Why does MySQL 8.4 say "Plugin 'mysql_native_password' is not loaded"?

Because the plugin is built into the 8.4 server but switched off. With it off, two things fail. Accounts that authenticate with it cannot log in: the manual shows the client getting a plain ERROR 1045 (28000): Access denied while the server writes the reason to its error log. And any CREATE USER or ALTER USER that names the plugin fails with error 1524. Provisioning scripts, Ansible roles, and Terraform modules written for 5.7 hit the second case first.

The temporary bridge: --mysql-native-password=ON

If you need old accounts working today, 8.4 accepts a startup option, added in 8.4.0. It is a bridge for the 8.4 series only: the option itself is removed in 9.0.0.

# /etc/my.cnf on MySQL 8.4 only. Remove before any 9.x upgrade.
[mysqld]
mysql_native_password=ON

Interpretation: after a restart, existing native accounts log in again and CREATE USER ... IDENTIFIED WITH mysql_native_password works. Treat this line as a dated exception in your change log, and set a date to remove it. To keep the plugin off, omit the option; OFF also works but is not required.

How do I fix "Authentication requires secure connection"?

This is error 2061, and it only affects caching_sha2_password accounts. The plugin keeps an in-memory cache of accounts that have logged in. A cache hit uses a challenge-response exchange that, in the manual's words, "does not use cleartext password transmission and does not require a secure connection." A cache miss needs full authentication. The client must then send the password over a secure channel or encrypt it with the server's RSA public key. If it can do neither, you get 2061.

That last point explains a common report: the application fails after a restart, an engineer logs in with the mysql client to investigate, and the application starts working. The engineer's login over a Unix socket counted as secure, filled the cache, and the application then took the fast path. Nothing was fixed. The next restart or FLUSH PRIVILEGES brings the failure back.

There are three real fixes, in order of preference:

1. Use TLS. Encrypted TCP, Unix socket files, and shared memory all count as secure, so no RSA key is needed.
2. Give the client a trusted copy of the public key (--server-public-key-path, or the connector's equivalent).
3. Let the client request the key (--get-server-public-key). The manual calls this more convenient but less secure than a local copy, and says it "may be acceptable in secure network environments."

# Prefer TLS: fail rather than fall back to plain text
mysql --ssl-mode=REQUIRED -h db-01 -u app_user -p

# No TLS: use a trusted local copy of the server's public key
mysql --ssl-mode=DISABLED -h db-01 -u app_user -p \
  --server-public-key-path=/etc/mysql/keys/db-01_public_key.pem

Interpretation: if the first command succeeds after a fresh restart, the account and client are ready for full authentication. If only the socket login works, the TCP path has no TLS and no key, and the application will fail on its next cold cache.

-- On the server: is an RSA key loaded, and is this session encrypted?
SHOW STATUS LIKE 'Caching_sha2_password_rsa_public_key';
SHOW SESSION STATUS LIKE 'Ssl_cipher';

Interpretation: an empty Caching_sha2_password_rsa_public_key value means the server found a problem with its key files; the manual says to check the error log. An empty Ssl_cipher means the current session is not using TLS.

What does "Authentication plugin cannot be loaded" mean?

Error 2059 is raised by the client, not the server. The client was asked to use a plugin it does not have. The MySQL 8.0 upgrade notes list the forms it takes with old client libraries:

• Authentication plugin 'caching_sha2_password' is not supported
• Authentication plugin 'caching_sha2_password' cannot be loaded: dlopen(.../caching_sha2_password.so, 2): image not found
• From PHP: The server requested authentication method unknown to the client [caching_sha2_password]

The same notes explain a trap: an old client can fail "even to use accounts that do not authenticate with caching_sha2_password", because the server names its default plugin in the handshake. Upgrading the client library is the only lasting fix.

The reverse error, Authentication plugin 'mysql_native_password' cannot be loaded, now appears with 9.x client tools. The 9.0.0 release notes say the client-side native plugin was "converted into a dynamically loadable plugin". A 9.x client that connects to a native-password account on an older server needs that plugin file in its plugin directory, and some packages do not ship it. Migrating the account fixes it from the server side.

# Which client library and plugin directory is this client using?
mysql --version
mysql_config --plugindir 2>/dev/null
ls "$(mysql_config --plugindir 2>/dev/null)" | grep -i native

Interpretation: a 9.x client with no mysql_native_password file in its plugin directory cannot log in to native accounts. Either install the client plugins package for your platform or move the account to caching_sha2_password.

Which connector versions support caching_sha2_password?

Before you change any account, upgrade every client that uses it. These are the first versions that support caching_sha2_password, from each project's own documentation. Treat them as floors, not targets: run a current release.

Two error strings tell you which row you are in. The Node.js mysql package reports server error 1251, ER_NOT_SUPPORTED_AUTH_MODE: "Client does not support authentication protocol requested by server; consider upgrading MySQL client". The fix is to move to mysql2. Connector/J reports Public Key Retrieval is not allowed when it reaches full authentication without TLS. Its allowPublicKeyRetrieval property defaults to false.

# Spring Boot: prefer TLS over allowPublicKeyRetrieval=true
spring.datasource.url=jdbc:mysql://db-01:3306/app?sslMode=REQUIRED
# If TLS is not possible, pin the key instead of fetching it:
# jdbc:mysql://db-01:3306/app?sslMode=DISABLED&serverRSAPublicKeyFile=/etc/app/db-01.pem

Interpretation: Connector/J's sslMode already defaults to PREFERRED. Setting REQUIRED makes a missing certificate fail loudly instead of falling back to the RSA path. allowPublicKeyRetrieval=true works too, but it trusts whatever key the server sends.

# Find the driver versions your services actually ship
npm ls mysql mysql2
pip show pymysql mysql-connector-python mysqlclient 2>/dev/null | grep -E '^(Name|Version)'
go list -m all | grep go-sql-driver
mvn dependency:tree | grep -E 'mysql-connector-(j|java)'

Interpretation: compare each result with the table, and include batch jobs, BI tools, CDC connectors, and backup scripts. Those are the clients that usually still run an old driver.

How do I find accounts still on mysql_native_password?

The plugin is stored per account in mysql.user. Run this on every primary and every replica you might promote; account lists drift.

SELECT user, host, plugin, password_last_changed, account_locked
FROM mysql.user
WHERE plugin IN ('mysql_native_password', 'sha256_password')
ORDER BY user, host;

Interpretation: every row is an account to migrate. sha256_password is also deprecated, so move those accounts in the same pass. Locked accounts, and system accounts such as mysql.sys that use other plugins, need no action.

-- Which of those accounts are actually connecting, and from where?
SELECT u.user, u.host AS account_host, p.HOST AS client_host,
       p.CURRENT_CONNECTIONS, p.TOTAL_CONNECTIONS
FROM mysql.user u
JOIN performance_schema.accounts p ON p.USER = u.user
WHERE u.plugin = 'mysql_native_password'
ORDER BY p.TOTAL_CONNECTIONS DESC;

Interpretation: performance_schema.accounts counts connections since the last restart, by user and client host. Accounts with zero connections over a full business cycle are candidates to lock or drop rather than migrate. The client hosts tell you which teams to contact about driver versions.

The MySQL Shell upgrade checker runs the same review before a version change. Its documented checks include authMethodUsage, deprecatedDefaultAuth, and deprecatedRouterAuthMethod for MySQL Router's internal accounts.

# MySQL Shell 9.7 can target any server release up to 9.7
mysqlsh -- util checkForServerUpgrade admin@db-01:3306 \
  --target-version=9.7.4 --output-format=JSON \
  --config-path=/etc/my.cnf

Interpretation: the target version cannot be newer than the Shell you run, so use a 9.7 Shell to check a 9.7 upgrade. Treat any authentication finding reported as an error as a blocker, and migrate that account first.

On Amazon Aurora MySQL 8.4

Managed services behave differently. The Aurora MySQL 8.4 security notes say existing mysql_native_password users keep working after the upgrade, and that authentication_policy defaults to *:caching_sha2_password. They also say require_secure_transport is ON by default in Aurora MySQL 8.4, so clients without TLS fail there for a different reason. AWS still recommends moving users to caching_sha2_password. For RDS for MySQL 8.4, check your parameter group before you assume either behavior.

Do ProxySQL, MaxScale, and MySQL Router handle caching_sha2_password?

A proxy authenticates twice: the client to the proxy (frontend) and the proxy to MySQL (backend). Both sides must support the plugin, or migrating a backend account breaks every pooled connection the next time the proxy reconnects.

ProxySQL. Its authentication methods page lists full frontend and backend support from v2.6.0. Versions 2.0.2 to 2.5.x support it on the frontend only with cleartext passwords in mysql_users. The same page warns that switching authentication methods during the handshake "presents challenges", so set the default plugin to match your accounts.

-- ProxySQL admin interface (port 6032), ProxySQL 2.6 or later
SELECT username, default_hostgroup, active FROM mysql_users;
SET mysql-default_authentication_plugin = 'caching_sha2_password';
LOAD MYSQL VARIABLES TO RUNTIME;
SAVE MYSQL VARIABLES TO DISK;

Interpretation: every username listed must exist on MySQL with the same password. Change the ProxySQL default only after the backend accounts are migrated and the ProxySQL version is 2.6 or later. Our ProxySQL guide covers the rest of the configuration.

MariaDB MaxScale. As of November 2026, the MaxScale MariaDB/MySQL authenticator page documents mysql_native_password and does not mention caching_sha2_password. If MaxScale fronts MySQL 8.4, confirm support for your MaxScale version with MariaDB before you migrate the accounts it uses or proxies.

MySQL Router. Router creates internal accounts when it is bootstrapped. The upgrade checker's deprecatedRouterAuthMethod check reports those accounts if they use a deprecated plugin.

How do replication users authenticate with caching_sha2_password?

A replica's receiver thread is just another client. If the replication user is on caching_sha2_password and the channel has no TLS, the CHANGE REPLICATION SOURCE TO reference says you "must specify either" GET_SOURCE_PUBLIC_KEY=1 or SOURCE_PUBLIC_KEY_PATH. Without one of them, the channel works until the source restarts, then fails on the cold cache with the 2061 message in Last_IO_Error.

-- On the replica. Prefer TLS; SOURCE_SSL=1 never falls back to plain text.
STOP REPLICA;
CHANGE REPLICATION SOURCE TO
  SOURCE_SSL = 1
  FOR CHANNEL '';
START REPLICA;

-- Without TLS, request the source's RSA public key instead:
-- CHANGE REPLICATION SOURCE TO GET_SOURCE_PUBLIC_KEY = 1 FOR CHANNEL '';

Interpretation: with several channels, every statement must name its channel. On 8.4, the old GET_MASTER_PUBLIC_KEY and MASTER_PUBLIC_KEY_PATH keywords are removed, so update automation that still uses them.

-- Confirm the channel survives a cold cache: run FLUSH PRIVILEGES on the source,
-- restart the receiver on the replica, then check:
SELECT CHANNEL_NAME, SERVICE_STATE, LAST_ERROR_NUMBER, LAST_ERROR_MESSAGE
FROM performance_schema.replication_connection_status;

Interpretation: SERVICE_STATE should be ON with LAST_ERROR_NUMBER 0. Error 2061 here means the channel has neither TLS nor the key.

Group Replication's distributed recovery uses the same rules through its own variables. Set them on every member that may join or rejoin:

SET PERSIST group_replication_recovery_use_ssl = ON;
-- or, without TLS:
SET PERSIST group_replication_recovery_get_public_key = ON;

Interpretation: a member that rejoins after a restart runs distributed recovery with a cold cache on the donor, so this setting decides whether rejoin works. The MySQL 8.4 GTID replication guide shows the full channel setup.

How do I migrate accounts safely before 9.x?

The migration itself is one statement per account. The work is making sure every client can complete full authentication before that statement runs. Changing the plugin discards any secondary password, and the password management page says RETAIN CURRENT PASSWORD combined with a plugin change fails. Dual passwords cannot soften this cutover.

If you do not know an account's password, you cannot keep it: MySQL stores only a hash, and the native hash cannot be converted. Generate a new one, and roll it out the way you would rotate any credential.

-- Unknown password: let MySQL generate one, then update the client's secret store
ALTER USER 'report'@'%'
  IDENTIFIED WITH caching_sha2_password BY RANDOM PASSWORD;

-- When the list is empty, the estate is ready for 9.x
SELECT plugin, COUNT(*) AS accounts
FROM mysql.user
GROUP BY plugin;

Interpretation: BY RANDOM PASSWORD returns the new password once, in the result set, so capture it straight into your secret manager. The final query should show no mysql_native_password rows. For a shared account, a safer pattern is to create a second account on caching_sha2_password, move clients to it one by one, and drop the old account at the end.

Frequently asked questions

Key takeaways

Plan your MySQL authentication migration with JusDB

JusDB's MySQL upgrade team can review your accounts, connector versions, proxies, and replication channels against the 8.4 and 9.7 authentication changes. We can then plan a staged move from mysql_native_password to caching_sha2_password, with a rollback point for each step.

Bring your mysql.user plugin inventory, your driver and proxy versions, and your planned upgrade window. Your team approves every production change.

Related reading

• MySQL 8.0 is EOL: upgrade checklist for 8.4 LTS
• MySQL "Communications link failure": fixing wait_timeout and the timeout variables
• Securing MySQL connections with SSL/TLS
• MySQL 8.4 Reference Manual: Caching SHA-2 Pluggable Authentication