Notifications
Clear all
Topic starter
07/06/2026 9:17 pm
TL;DR: Some CIAM vendors withhold password hashing algorithms and parameters during migration, forcing disruptive password resets, increasing help desk load, and raising credential stuffing risk, according to Strivacity. The real issue is not portability alone, but whether identity architecture allows customers to exit without losing authentication continuity.
NHIMG editorial — based on content published by Strivacity: password hash opacity and CIAM migration lock-in
Questions worth separating out
A: Security teams should treat withheld hash details as an exit risk, not a technical inconvenience.
Q: Why do withheld password hashes create both user friction and security risk?
A: Because the usual fallback is a mass password reset, and that breaks continuity for users while changing password behaviour at scale.
Q: What breaks when password hash portability is missing during CIAM offboarding?
A: The customer loses the ability to move authentication state in a controlled way.
Practitioner guidance
- Require hash portability in procurement Ask vendors to document the hashing algorithm, salt model, work factor, and migration support process before contract signature.
- Test offboarding before committing to a CIAM platform Run a simulated migration that includes user credential transition, fallback authentication, and support load estimates.
- Plan for federated fallback paths Reduce dependence on vendor-managed password storage by maintaining federated identity options such as SSO or OAuth where appropriate.
What's in the full article
Strivacity's full article covers the operational detail this post intentionally leaves for the source:
- Vendor-side explanations of why hash details are withheld during migration and how that affects offboarding planning.
- Practical guidance on contractual language that can require migration support and credential transition commitments.
- Detailed discussion of how SSO and OAuth can reduce dependence on vendor-managed password storage.
- Examples of how organisations can approach password portability without exposing plaintext credentials.
👉 Read Strivacity's analysis of password hash portability and CIAM migration lock-in →
Password hash opacity in CIAM: what it means for migration?
Explore further
08/06/2026 9:10 am
Password hash opacity is a lifecycle control failure, not a security feature. The customer cannot complete a controlled identity migration when the source platform refuses to disclose the information needed to re-establish authentication elsewhere. That turns offboarding into a vendor permission problem instead of a governance process. Practitioners should treat hash disclosure as part of lifecycle ownership, not as optional implementation detail.
A few things that frame the scale:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
A question worth separating out:
Q: Who is accountable when a CIAM vendor makes migration dependent on hidden hash details?
A: Accountability sits with the customer and the vendor together, but the customer must define the contract clearly enough that exit is possible. Security, procurement, and legal teams should require documented migration support, termination terms, and user transition obligations. If those obligations are absent, the organisation has accepted a lock-in risk it cannot later audit away.
👉 Read our full editorial: Password hash opacity creates CIAM migration lock-in
