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.
At a glance
What this is: This guide explains how to list MySQL users and check their privileges, while showing that the real security issue is governance over database identities, not the query itself.
Why it matters: IAM, PAM, and NHI teams should treat database user inventory as an access control control point because host scope, privilege scope, and account lifecycle determine exposure.
Context
MySQL user listing is a way to inspect who can authenticate to a database and what that identity can do. In governance terms, it is an inventory and review step for NHI access, because each database account is a non-human identity with a host scope, credentials, and privileges that can outlive the need for access.
The control gap is rarely the SQL command itself. The risk sits in manual review, broad host patterns such as wildcard access, application use of root, and stale accounts that remain active after the original need has ended.
That makes the topic relevant to both database administrators and identity teams. Listing users becomes useful only when it feeds privilege review, offboarding, logging, and short-lived access rather than acting as a one-time administrative check.
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. A simple user list does not show whether access is appropriate, stale, or overbroad. Teams need to connect review to entitlement, logging, and revocation, or the list becomes a snapshot with no control value.
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. Together, they increase the blast radius of compromise and make misuse harder to contain. The safer pattern is host-specific, least-privilege access tied to a clear operational purpose.
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. That shortcut removes least privilege, makes grant review less meaningful, and increases the blast radius if the app or its credentials are compromised. The safer pattern is to issue narrowly scoped database accounts for each workload.
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.
Technical breakdown
How MySQL stores user identity and privilege data
MySQL commonly stores account records in the mysql.user table, which contains the user name, host, authentication string, privilege data, and plugin information. That combination matters because MySQL does not treat a database account as just a name. Identity is bound to where the account may connect from, how it authenticates, and what global privileges it carries. In practice, a single row can represent both an access path and a control failure if the host is broad or the privileges are overextended. Reviewing this table is therefore an inventory exercise for non-human identities, not a mere configuration query.
Practical implication: review mysql.user as an access inventory and validate host scope, authentication method, and privilege breadth together.
Why wildcard hosts and root-for-apps expand exposure
A wildcard host lets the same database account connect from many locations, which weakens the trust boundary around the identity. Pair that with root use for applications and the database loses the separation between administrative power and application need. This is a classic privilege design problem: the account becomes portable, reusable, and easy to abuse if credentials leak or are shared across environments. For NHI governance, the issue is not only who can log in, but where that identity is allowed to appear and whether its privilege level matches the workload’s actual task.
Practical implication: replace wildcard host access and application root usage with narrowly scoped database accounts tied to specific connection paths.
How privilege review and session logging close the gap
Privilege review answers what an account can do, while session logging answers what it actually did. Those are different controls and both matter because a user list alone cannot tell you whether access was appropriate, used, or abandoned. MySQL audit practices become much stronger when they connect account inventory to grant review, failed-login detection, and session replay. That is the difference between a static admin list and a governed identity lifecycle. Without logs, offboarding and privilege correction are reactive; with logs, teams can prove access scope and investigate misuse quickly.
Practical implication: combine grant review with session logging so every account has both a defined entitlement and an observable history.
Threat narrative
Attacker objective: The objective is to turn legitimate-looking database access into durable control over data and administrative actions.
- Entry occurs through broadly scoped MySQL accounts, especially where wildcard hosts or reused credentials let connections come from more places than intended.
- Credential abuse follows when overprivileged or stale accounts are available for application use, making takeover or misuse easier once access is obtained.
- Impact comes from database access that persists beyond business need, allowing unauthorized queries, administrative actions, or hidden persistence in the account layer.
Breaches seen in the wild
- Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
- BeyondTrust breach 2024: A stolen BeyondTrust Remote Support API key let a China state-sponsored actor reset accounts and reach US Treasury workstations in 2024.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Wildcard host access is an identity-design flaw, not a harmless shortcut. Broad host patterns weaken the trust boundary around a database account because they let the same credential operate from too many places. That creates unnecessary exposure in both cloud and on-prem environments, especially when application accounts are reused across services. The practical conclusion is to treat host scope as part of privilege design, not as a networking detail.
Application root usage collapses least privilege at the point of issuance. The moment root is assigned to an app, the database has no meaningful separation between administrative capability and workload need. That is not just excessive privilege; it is a governance failure that turns review into an after-the-fact exercise. The practical conclusion is that database access should be issued at the narrowest task scope possible, with administrative power isolated from runtime access.
Stale database accounts create offboarding debt that standard IAM programs often miss. Database identities do not always follow the same lifecycle controls as human accounts, so they survive role changes, project endings, and application decommissions. That makes lifecycle management the real control gap behind many database access issues. The practical conclusion is to align account review and revocation with application ownership and operational change, not with ad hoc cleanup cycles.
Centralized access control turns MySQL listing into enforceable governance. When access is brokered through a trusted identity layer, the database user list stops being the only source of truth and becomes one input to a broader control model. That shifts the programme from manual checking to continuous visibility across who connected, what they could do, and when access ended. The practical conclusion is to connect database entitlements to lifecycle and audit controls that can actually be enforced.
From our research library:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
- Read next: Ultimate Guide to NHIs — Key Challenges and Risks
What this signals
Identity review has to move closer to issuance time: MySQL access lists are only useful when they feed a decision about host scope, privilege scope, and account lifecycle. If review happens after accounts have already been reused across environments, the control is mostly documentary rather than preventative.
The practical shift is from manual user auditing to governed database access, with session logging and short-lived access providing the evidence trail that static account lists cannot. That matters because database identities often persist longer than the application need that created them.
Access review processes assume a privilege remains stable long enough to be examined. Database accounts that are shared, broad, or stale break that assumption, so the programme has to treat MySQL user management as a lifecycle control, not an occasional hygiene check.
For practitioners
- Inventory database identities by host and privilege scope Treat mysql.user as an NHI register. Review every account for host pattern, authentication method, and global privilege breadth, then flag any entry that is broader than the workload needs.
- Remove application use of root Create separate database accounts for applications and reserve administrative identities for humans or tightly controlled break-glass use. Match each workload to the minimum command and schema scope it actually needs.
- Eliminate wildcard host access Restrict each database account to explicit source hosts or connection paths. Wildcard hosts should be treated as an exposure multiplier because they weaken the database trust boundary.
- Pair privilege reviews with session logs Use grant review and connection replay together so that entitlements and behaviour can be checked in the same governance cycle. That is the cleanest way to prove who connected and what they did.
- Automate offboarding of stale accounts Tie database account removal to application retirement, role change, and project closure so credentials are revoked when they are no longer needed. Manual cleanup is too slow for reliable lifecycle control.
Key takeaways
- MySQL user listing is a governance control point because database identities can carry excessive privilege, broad host scope, and stale access.
- The real risk is not the query itself but the gap between account inventory, privilege review, and revocation.
- Teams reduce exposure by narrowing host scope, removing application root access, and tying database accounts to lifecycle and session logging.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The article centers on excessive MySQL privileges and root use for applications. |
| NHI-01 — Improper Offboarding | The article warns that stale MySQL accounts persist after business need ends. | |
| NHI-07 — Long-Lived Secrets | The article recommends rotation and short-lived access rather than persistent credentials. | |
| Recommendation — Review database accounts for privilege creep and remove administrative rights from application identities. Tie database account revocation to role change and application retirement. Replace durable database credentials with short-lived access and rotate secrets on a defined schedule. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Overprivileged or stale database accounts can be abused for access expansion and movement. |
| Recommendation — Map exposed database accounts to credential access and lateral movement paths in threat hunting. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article focuses on password rotation, account locking, and credential lifecycle for MySQL users. |
| Recommendation — Apply authenticator management to rotate, expire, and revoke database credentials on schedule. | ||
Key terms
- Database Identity: A database identity is a named account used to authenticate to a database and perform actions within it. In practice, it includes the user name, host scope, credentials, and assigned privileges, making it a governed non-human identity rather than just a login string.
- Device Scope: Device scope is the part of a BYOD policy that states which devices, operating systems, and supporting tools are allowed. It also clarifies practical boundaries such as app restrictions, training requirements, and whether rooted or jailbroken devices are prohibited before access to company resources is granted.
- Privilege Review: Privilege review is the process of checking whether an identity still needs the access it has. It is used to find standing access, excessive permissions, and orphaned credentials before they become an incident path. Effective reviews are repeatable, evidence-based, and tied to ownership and remediation workflows.
- Off-boarding: Off-boarding is the process of removing a departing user’s access, credentials, and related entitlements from the environment. In mature IAM programmes, it also includes reviewing sessions, shared secrets, delegated roles, and linked non-human identities so that exit events do not leave behind hidden access paths.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 8, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org