Notifications
Clear all
Topic starter
06/07/2026 9:38 am
TL;DR: Identity data management pages outline how to connect user credentials, sessions and tokens to SQL and NoSQL sources, plus schema upgrade reliability for the Curity Identity Server, according to Curity. The practical issue is not connectivity alone, but whether identity data sources remain governable as systems, regions, and tenancy models change.
NHIMG editorial — based on content published by Curity: Data management guidance for identity data, user accounts, sessions, and tokens
Questions worth separating out
Q: How should IAM teams govern identity data across SQL and NoSQL back ends?
A: They should assign clear ownership for each identity object, define the source of truth for writes, and validate that login, token, and session behaviour remains consistent across every back end.
Q: When does identity schema change become an operational risk?
A: It becomes an operational risk when a schema change can affect authentication, session persistence, or revocation behaviour without being tested in advance.
Q: What do security teams get wrong about identity data integration?
A: They often treat identity data integration as a back-end implementation detail instead of a security decision.
Practitioner guidance
- Define the identity source of truth by data type Document which system owns users, credentials, sessions, and tokens before connecting additional SQL or NoSQL sources.
- Test schema upgrades as part of release validation Run upgrade and rollback tests against realistic identity data before production change windows.
- Match storage model to assurance requirements Use relational stores where integrity and transactional consistency matter most, and use document or key-value models only when the identity behaviour they support is well understood.
What's in the full article
Curity's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step connection guidance for identity schema and data sources in the Curity Identity Server
- Practical coverage of SQL and NoSQL integration choices for identity storage
- Schema upgrade reliability features and how to keep the identity server aligned with current data structures
- Architecture examples for multi-tenant and multi-region identity deployments
👉 Read Curity's data management guidance for the Curity Identity Server →
Identity data management in Curity: what IAM teams should notice?
Explore further
06/07/2026 9:52 am
Identity data management is really control-plane governance, not database administration. When credentials, sessions, and tokens are distributed across multiple data sources, the practical risk is that identity state becomes harder to reason about than the application that consumes it. That shifts the governance question from storage choice to operational trust in the identity layer. Practitioners should treat data source design as part of identity control design, not a separate infrastructure concern.
A few things that frame the scale:
- From our research: 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
- From our research: Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
A question worth separating out:
Q: What should teams check before connecting a new identity data source?
A: They should verify ownership, schema compatibility, rollback behaviour, and how the new source affects session and token reliability. If the team cannot explain what happens to live identity state during an outage or upgrade, the data source is not ready for production use.
👉 Read our full editorial: Curity’s data management guidance for identity stores and schemas
