Notifications
Clear all
Topic starter
08/06/2026 5:07 pm
TL;DR: Identity data buried in SQL tables can block IAM and IGA programmes when legacy and custom apps lack APIs, according to ConductorOne’s Baton-SQL post. The practical issue is not database access alone, but the need to centralise users, roles, entitlements, and grants without custom connector sprawl.
NHIMG editorial — based on content published by ConductorOne: Managing Identity for SQL-Powered Apps: No APIs Necessary
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- NHIs outnumber human identities by 25x to 50x in modern enterprises.
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
Questions worth separating out
Q: How should security teams govern applications whose identity data only exists in SQL tables?
A: Security teams should treat SQL tables as authoritative identity sources when no API exists, then ingest those records into the IGA or IAM control plane through a controlled connector.
Q: What breaks when legacy applications cannot expose access data through APIs?
A: Visibility, certification, and lifecycle control break first.
Q: When is read-only database ingestion better than enabling provisioning?
A: Read-only ingestion is better when the team is still establishing trust in the data model, ownership, and mappings.
Practitioner guidance
- Map SQL-backed systems to governance scope Inventory every internal application whose authoritative access data lives in a relational database, then classify whether it feeds certification, provisioning, or both.
- Treat connector configuration as controlled identity logic Review YAML and CEL mappings the same way you would review access policy changes.
- Start read-only, then expand scope deliberately Use read-only extraction for initial visibility and only enable provisioning after ownership, rollback, and approval paths are defined.
What's in the full article
ConductorOne's full blog covers the operational detail this post intentionally leaves for the source:
- Sample Baton-SQL configuration patterns for common SQL-backed applications
- Query mapping examples that show how resource, entitlement, and grant data are transformed
- Supported database coverage across Oracle, MySQL and MariaDB, SQL Server, and PostgreSQL
- GitHub repository details for teams that want to inspect the connector implementation
👉 Read ConductorOne's post on managing SQL-powered app identity data without APIs →
SQL-powered app identity governance without APIs: are your controls ready?
Explore further
08/06/2026 7:08 pm
SQL-only identity sources create a governance blind spot, not just an integration inconvenience. When identity and access records live in relational databases without APIs, IGA tools can miss authoritative entitlement data entirely. That breaks visibility, certification, and offboarding workflows at the source. The practical conclusion is that any app outside the ingestion layer is also outside the governance layer.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
A question worth separating out:
Q: How do SQL-backed apps affect non-human identity governance?
A: They often store service-account roles, application tokens, and machine-facing grants in the same database structures as human access data. That means NHI governance can fail even when the identity platform is mature, because the authoritative record is still outside the control plane. Teams need ingestion coverage, not just policy coverage.
👉 Read our full editorial: SQL-powered app identity governance without APIs: what changes
