Notifications
Clear all
Topic starter
08/06/2026 4:23 pm
TL;DR: MySQL user creation, privilege assignment, revocation, and audit checks still depend on repetitive manual steps in self-managed environments, especially across dozens or hundreds of instances, according to StrongDM. The operational lesson is that access governance becomes a scaling problem long before it becomes a database administration problem.
NHIMG editorial — based on content published by StrongDM: How to Create a MySQL User (Step-by-Step Tutorial)
Questions worth separating out
Q: How should security teams govern MySQL user access across many instances?
A: They should centralise identity, standardise roles, and verify privileges at the database layer rather than relying on ad hoc admin commands.
Q: What breaks when MySQL privileges are managed manually?
A: Manual privilege management breaks consistency, revocation confidence, and auditability.
Q: When should organisations replace per-instance MySQL administration with centralised access control?
A: They should make the shift when repeated user creation, grant changes, and revocation tasks start consuming operational time across multiple servers.
Practitioner guidance
- Inventory database accounts by host and privilege scope Catalogue every MySQL account, the host patterns attached to it, and the database or object-level privileges it carries.
- Treat privilege revocation as a verified change After every REVOKE or password change, confirm the resulting state with SHOW GRANTS and a direct privilege check.
- Move recurring MySQL access to federated control Use a central policy layer for authentication and role assignment where database counts are growing.
What's in the full article
StrongDM's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step SQL commands for creating users, granting permissions, revoking access, and changing passwords in MySQL.
- Examples of host-scoped account definitions, including localhost and subnet-based access patterns.
- Command output patterns for SHOW GRANTS and INFORMATION_SCHEMA checks that help validate effective permissions.
- Guidance on using a centralised control plane with SSO and role-based access workflows.
👉 Read StrongDM's tutorial on creating MySQL users and managing privileges →
MySQL access governance: why manual user management stops scaling?
Explore further
08/06/2026 6:00 pm
Manual database account administration is an identity governance control, not an engineering convenience. The tutorial shows that the core work is creating users, assigning privileges, revoking access, and checking effective grants. That is the same lifecycle pattern IAM teams manage for service accounts and privileged users. When it is done by hand across many databases, the governance model degrades into local practice rather than enterprise control. Practitioners should treat database access as governed identity, not as a set of isolated SQL commands.
A few things that frame the scale:
- 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
A question worth separating out:
Q: How do teams know whether MySQL access governance is actually working?
A: They should be able to show current grants, recent revocations, and clear account ownership for every database user. If access cannot be explained from identity source to database entitlement, governance is not working. The strongest signal is that privilege state and operational intent match without manual reconstruction.
👉 Read our full editorial: MySQL user creation shows why manual access governance breaks at scale
