Notifications
Clear all
Topic starter
08/06/2026 4:59 pm
TL;DR: Listing MySQL users is an access-control checkpoint, not a housekeeping task: wildcard hosts, root-for-apps, stale accounts, and missing session logs can expose databases to avoidable risk, according to StrongDM. The security issue is that identity review, privilege scope, and offboarding still happen too late and too manually for reliable governance.
NHIMG editorial — based on content published by StrongDM: MySQL SHOW USERS: How to List All Users in a Database
By the numbers:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
Questions worth separating out
Q: How should security teams govern MySQL user accounts in production databases?
A: Treat MySQL users as governed identities, not just local administrative records.
Q: Why do wildcard hosts and root accounts increase MySQL risk?
A: Wildcard hosts remove a key boundary around where a credential can be used, and root accounts remove the privilege boundary around what that credential can do.
Q: What breaks when MySQL access reviews are done only after incidents?
A: Post-incident reviews miss the accounts that should never have existed in the first place, especially stale users and overprivileged database identities.
Practitioner guidance
- Inventory database identities by host and privilege scope Export mysql.user and SHOW GRANTS results into an access review workflow, then flag accounts with wildcard hosts, root-level permissions, or unexplained authentication plugins.
- Remove application dependence on root-style database access Replace shared administrative accounts with narrowly scoped identities for applications, maintenance jobs, and support workflows, and restrict each account to the exact host it must use.
- Attach database offboarding to lifecycle events Trigger account disablement, password expiry, and privilege removal when a user changes role, leaves a team, or a workload is retired so stale users do not persist in mysql.user.
What's in the full article
StrongDM's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step SQL examples for listing users, filtering by host, and generating grant statements
- GUI walkthroughs for MySQL Workbench, phpMyAdmin, and dbForge Studio for MySQL
- Concrete command syntax for creating, locking, unlocking, and expiring database accounts
- Implementation detail on StrongDM's centralized access, session logging, and just-in-time access model
👉 Read StrongDM's guide to listing MySQL users and checking privileges →
MySQL user audits and access controls: where teams still slip?
Explore further
08/06/2026 6:54 pm
MySQL user listing is a governance control, not an admin convenience. The article shows that user tables, grants, and host bindings expose the real security state of a database. That matters because access review is only useful if the underlying identities are visible, attributable, and scoped. The practitioner conclusion is simple: treat database user enumeration as part of NHI governance, not an after-the-fact audit task.
A few things that frame the scale:
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which is why database user enumeration should be tied to governance rather than ad hoc troubleshooting.
A question worth separating out:
Q: How do you know if database JIT access is actually working?
A: JIT access is working when privileged database access is time-bound, session-linked, and automatically revoked after the task ends. You should be able to show who requested access, what was granted, when it expired, and what actions occurred during the session. If those facts are missing, JIT is only a label.
👉 Read our full editorial: MySQL user listing exposes governance gaps in database access
