# mysql_native_password Is Not Loaded: Fix ERROR 1524 on MySQL 8.4 and 9.7 Source: https://srvscripts.com/guides/mysql-native-password-not-loaded/ Updated: 2026-10-09 Publisher: srvScripts (https://srvscripts.com/) **Short answer:** `ERROR 1524 (HY000): Plugin 'mysql_native_password' is not loaded` means the account you log in with, or the account you are creating, uses the old `mysql_native_password` method, and this MySQL server does not load it. MySQL 8.4 ships with it switched off and MySQL 9.0 and later removed it. The quick fix on 8.4 is `mysql_native_password=ON` in the `[mysqld]` section of my.cnf and a restart. The lasting fix is to move each account to `caching_sha2_password` with `ALTER USER`, using the same password, before you ever upgrade to 9.x. We reproduced every error on this page on 9 October 2026 with the official MySQL 8.0.46, 8.4.11 and 9.7.2 server images on an AlmaLinux 9.8 lab host, upgrading one data directory from 8.0 to 8.4 and from 8.4 to 9.7, and connected with the MySQL command-line client and with PHP 8.3 (mysqli and PDO). The output blocks below are copied from those runs. ## Why the error appears after an upgrade MySQL deprecated `mysql_native_password` in 8.0.34, switched it off by default in 8.4 and removed it in 9.0. Accounts keep the plugin they were created with, so an application user made on MySQL 5.7 or 8.0 still points at it after an in-place upgrade. On 8.4 the server starts normally, but that user can no longer log in, and the client shows the error rather than a password failure: ``` $ mysql -h db -u wpuser -p wpdb ERROR 1524 (HY000): Plugin 'mysql_native_password' is not loaded ``` Creating or altering an account with the old method fails the same way, which is what breaks install scripts and control-panel tools that still ask for it: ``` mysql> CREATE USER 'newapp'@'%' IDENTIFIED WITH mysql_native_password BY '...'; ERROR 1524 (HY000) at line 1: Plugin 'mysql_native_password' is not loaded ``` This applies to Oracle MySQL and Percona Server. MariaDB is not affected: it keeps `mysql_native_password` as its normal method, and our cPanel and DirectAdmin lab servers on MariaDB 10.11 and 10.6 still use it for every account. ## Find the accounts that still use the old method Run this as root (or any user that can read `mysql.user`). Every row is an account that will fail on 8.4 without the plugin and on 9.x in any case: ``` mysql -u root -p -e "SELECT user, host, plugin FROM mysql.user WHERE plugin = 'mysql_native_password'" ``` ``` user host plugin wpuser % mysql_native_password ``` On a hosting server expect one or more rows per website database user. Note the host part: `wpuser@localhost` and `wpuser@%` are two accounts, and each needs its own fix. ## Quick fix on MySQL 8.4: turn the plugin back on Add one line to the `[mysqld]` section of the server configuration (`/etc/my.cnf` on AlmaLinux, Rocky and cPanel servers; often `/etc/mysql/mysql.conf.d/mysqld.cnf` on Ubuntu and Debian) and restart MySQL: ``` [mysqld] mysql_native_password=ON ``` ``` sudo systemctl restart mysqld # the service is called mysql on Ubuntu and Debian mysql -u root -p -e "SHOW PLUGINS" | grep native ``` ``` mysql_native_password ACTIVE AUTHENTICATION NULL GPL ``` In our test the old account logged in again straight away. The setting is a startup option, not a system variable, so `SELECT @@mysql_native_password` fails with ERROR 1193; check it with `SHOW PLUGINS` as above. cPanel’s own recovery steps for MySQL 8.4 also turn this option on, so on a cPanel server you may already have the line. Treat it as a bridge, not the fix: MySQL 9.x refuses to start while it is in the configuration (see below). ## Lasting fix: move each account to caching_sha2_password Change the account’s method and set the same password it already has, so the application’s configuration does not change. For a WordPress site the password is `DB_PASSWORD` in `wp-config.php`; other applications keep it in their own config file: ``` # Interactive client: the password is never on the command line, and the session is not saved to ~/.mysql_history MYSQL_HISTFILE=/dev/null mysql -u root -p ``` ``` mysql> ALTER USER 'wpuser'@'%' IDENTIFIED WITH caching_sha2_password BY 'the-current-password'; mysql> SELECT user, host, plugin FROM mysql.user WHERE user = 'wpuser'; mysql> exit ``` Type or paste the password only at the `mysql>` prompt. Putting it in `mysql -e "..."` would leave it in your shell history and, while the command runs, in the process list that other users on the server can read. `MYSQL_HISTFILE=/dev/null` stops the client from writing the session to its history file. MySQL 8.0 and later clients also skip lines containing `IDENTIFIED` or `PASSWORD` by default, but do not rely on that filter (other clients, such as older or MariaDB builds, may not apply it); the variable covers every client. The `SELECT` shows the result: ``` user host plugin wpuser % caching_sha2_password ``` MySQL stores only a hash, so it cannot convert the old hash for you: you must supply the password in the `ALTER USER` statement. If nobody knows it, set a new one and update the application’s config file at the same time. Repeat for every row the query above found, then remove `mysql_native_password=ON` from my.cnf and restart. In our test the account kept working after that restart. ## Error 2061 after the switch: “Authentication requires secure connection” `caching_sha2_password` never sends the password in clear text. Over TLS or a local socket that is automatic. Over a plain TCP connection, the first login after each server restart needs the server’s RSA public key, and clients built on the MySQL C library (the `mysql` command, Python mysqlclient, older Perl DBD::mysql and similar) refuse unless you allow that: ``` $ mysql -h db --ssl-mode=DISABLED -u wpuser -p wpdb ERROR 2061 (HY000): Authentication plugin 'caching_sha2_password' reported error: Authentication requires secure connection. ``` Any one of these fixes it. Our tests confirmed each: - **Use TLS.** MySQL 8.4 creates certificates on first start and clients use TLS by default; in our test the same login over the default connection worked (cipher TLS_AES_128_GCM_SHA256). Remove any `--ssl-mode=DISABLED` or `ssl=0` from the client settings. - **Fetch the public key.** Add `--get-server-public-key` on the command line, or `get-server-public-key` under `[client]` in the client’s option file. After one successful login the server caches the password and later logins work even without it, until the next restart. - **Use the local socket** (`localhost` instead of `127.0.0.1`) for applications on the same server. PHP is usually fine. PHP 8.3 with mysqlnd, both mysqli and PDO, logged in over plain TCP right after a server restart in our test, because mysqlnd fetches the key itself when the OpenSSL extension is present. That covers WordPress, Joomla, Drupal and most PHP applications on shared hosting. ## Before you upgrade to MySQL 9.7 MySQL 9.x has no `mysql_native_password` at all. If the line is still in my.cnf, the server does not start: ``` [ERROR] [MY-000067] [Server] unknown variable 'mysql-native-password=ON'. [ERROR] [MY-010119] [Server] Aborting ``` Once the line is removed, 9.7 starts, but every account still on the old method fails with ERROR 1524 until you run the `ALTER USER` fix above. There is no easy way back: after 9.7 has upgraded the data directory, starting MySQL 8.4 on it fails with `Invalid MySQL server downgrade: Cannot downgrade from 90702 to 80411`, so a rollback means restoring a dump or a snapshot. This is not theoretical. On 21 and 22 April 2026 a change in Oracle’s package repository let nightly updates install MySQL 9.7 on cPanel servers running 8.4, and many sites lost their database connections until administrators reverted. cPanel’s advice afterwards is to lock the packages so the system updater cannot change the major version: ``` sudo dnf install -y python3-dnf-plugin-versionlock sudo dnf versionlock add 'mysql-community-*' dnf versionlock list ``` Our checklist before any MySQL major upgrade: - Take a full dump (`mysqldump --all-databases --routines --events`) and, if you can, a snapshot of the server. - Run the account query above and move every account to `caching_sha2_password` while you are still on 8.4. - Remove `mysql_native_password`, `default-authentication-plugin` and other options the new version no longer accepts from my.cnf. - Test the application’s login, including cron jobs and scripts that use the `mysql` command over TCP. - Upgrade on a test copy first; there is no in-place downgrade. ## mysql_native_password is not loaded at a glance In short: Why MySQL 8.4 and 9.7 show ERROR 1524 Plugin 'mysql_native_password' is not loaded, the quick fix, the lasting fix with caching_sha2_password, and what breaks on 9.7. mysql_native_password is not loaded: what this guide covers. mysql_native_password is not loaded: the questions this guide answers. **Official documentation:** [MySQL 8.4: Native Pluggable Authentication](https://dev.mysql.com/doc/refman/8.4/en/native-pluggable-authentication.html), [MySQL 8.4: Caching SHA-2 Pluggable Authentication](https://dev.mysql.com/doc/refman/8.4/en/caching-sha2-pluggable-authentication.html), [cPanel: MySQL 8.4 upgraded to MySQL 9.7 during nightly updates](https://support.cpanel.net/hc/en-us/articles/39925555560471-MySQL8-4-upgraded-to-MySQL9-7-during-nightly-updates). **Related guides:** [MySQL 8.4 vs 9.7 LTS: what hosting admins need to know](https://srvscripts.com/guides/mysql-8-4-vs-9-7-lts/) · [MySQL 8.0 End of Life: Safe Move to 8.4 or MariaDB](https://srvscripts.com/guides/mysql-8-0-end-of-life/) · [caching_sha2_password MariaDB 12: Fix MySQL 8 Client Problems](https://srvscripts.com/guides/caching-sha2-password-mariadb-12/) · [MySQL/MariaDB won’t start: crash recovery runbook](https://srvscripts.com/guides/runbook-mysql-crashed/). ## Frequently asked questions ### Is it safe to turn mysql_native_password back on? Yes, as a short-term measure on MySQL 8.4. The method uses an older hash, so moving accounts to caching_sha2_password is better, and the option must be gone before any upgrade to MySQL 9.x, which will not start with it. ### Do I need to change the database password? No. ALTER USER … IDENTIFIED WITH caching_sha2_password BY can set the same password the application already uses. You do need to know it, because MySQL cannot convert the stored hash. ### Why does the error say the plugin is not loaded instead of access denied? The server knows which method the account uses and reports that the method is unavailable. In our tests on MySQL 8.4.11 and 9.7.2 the client received ERROR 1524 for an existing account, not ERROR 1045. ### Does MariaDB have the same problem? No. MariaDB still supports mysql_native_password and uses it by default. The issue appears when a MariaDB server is replaced by MySQL 8.4 or 9.x, or when an application moves to a MySQL server. ### Will WordPress still connect after the switch? In our tests PHP 8.3 with mysqlnd connected with both mysqli and PDO, over TLS and over plain TCP, right after a server restart. Command-line tools on the C library may need TLS or --get-server-public-key.