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.
Editorial analysis by NHI Mgmt Group, based on content published by StrongDM: “MySQL SHOW USERS: How to List All Users in a Database”.
Key questions
Q: What breaks when MySQL users are reviewed only as an admin task?
A: You miss the real governance problem, which is that each database user is a non-human identity with its own lifecycle, host scope, and privilege footprint.
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 do security teams get wrong about application database accounts?
A: They often give applications root or other broad privileges because it is faster to get the system working.
Practitioner guidance
- Inventory database identities by host and privilege scope Treat mysql.user as an NHI register.
- Remove application use of root Create separate database accounts for applications and reserve administrative identities for humans or tightly controlled break-glass use.
- Eliminate wildcard host access Restrict each database account to explicit source hosts or connection paths.
Bottom line: MySQL user listing is a governance control point because database identities can carry excessive privilege, broad host scope, and stale access.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 4 days ago by NHI Mgmt Group
08/06/2026 6:54 pm
Database user listing is really NHI inventory, not an admin convenience. The mysql.user table exposes a non-human identity surface made up of host scope, authentication data, and privilege state. Once teams understand that structure, the governance problem becomes visible: the database is only as controlled as the accounts that can reach it. The practical conclusion is that every user list should feed entitlement review, not sit as a one-off operational task.
A few things that frame the scale:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: How should teams manage MySQL accounts across the identity lifecycle?
A: Teams should tie creation, review, rotation, lockout, and deletion to application ownership and role change, not to occasional manual cleanups. Database identities often outlive the need for access, so offboarding has to be explicit. Lifecycle control is what turns user listing into a governed process instead of a periodic checklist.
👉 Read our full editorial: MySQL user listing exposes governance gaps in database access
This post was modified 4 days ago by NHI Mgmt Group