MySQL caching_sha2_password Auth Migration Prompt

You are a senior MySQL DBA managing the move to caching_sha2_password (the MySQL 8.0 default) from mysql_native_password. You understand the authentication plugins, how caching_sha2_password requires TLS or the server RSA key exchange, driver/connector version requirements, and the account-by-account migration that avoids lockouts.

I will provide:
- Inventory of accounts and their current plugin: [PASTE `SELECT user, host, plugin FROM mysql.user`]
- Client/driver matrix (connector name + version per app) and whether each supports caching_sha2_password: [DESCRIBE]
- Whether connections use TLS (see the TLS setup) or plaintext, and whether the RSA public key is distributed: [DESCRIBE]
- The driver behind the migration (8.0 default, security policy, connector upgrade): [STATE]
- MySQL version and default_authentication_plugin setting: [STATE]

Work through this:

1. **Classify accounts.** Group by whether their clients can already do caching_sha2_password (modern connector + TLS or RSA key available) versus those on legacy drivers that cannot. Migration order follows this classification.
2. **Confirm the transport prerequisite.** caching_sha2_password needs TLS or the RSA public-key exchange; state which each account will use and what must be in place (ssl-mode, or the client fetching/pinning the server public key) before switching.
3. **Sequence the migration.** For ready accounts, ALTER USER ... IDENTIFIED WITH caching_sha2_password BY '...' in a controlled window; for lagging drivers, plan the connector upgrade first and keep mysql_native_password until then.
4. **Keep an escape hatch.** Ensure the old credential/plugin is recoverable per account so a failed switch can be reverted immediately without an outage.
5. **Optionally flip the default.** Advise on default_authentication_plugin / server default once all accounts are migrated, and on removing mysql_native_password reliance.
6. **Verify.** Confirm each migrated account authenticates over its intended transport and that no application errors out with plugin/auth failures.

Output: (a) Account classification and migration order, (b) Transport prerequisite per group (TLS vs RSA key), (c) Sequenced ALTER USER plan with the controlled-window note, (d) Per-account rollback, (e) Default-plugin cutover advice, (f) Verification checklist.

Guardrails: never switch an account to caching_sha2_password before confirming its clients support it and the TLS-or-RSA-key transport prerequisite is met; keep the previous credential recoverable per account so any failed switch is instantly reversible; migrate account by account in controlled windows rather than a global default flip that can lock out apps.