Hidden lock-in: how vendor secrecy around password hashing hurts customers

When organizations choose a software solution, they do so with the expectation that they can move on if their needs change. However, some vendors actively create migration barriers. One of the most damaging is refusing to share password hashing algorithms when organizations seek to transition to a new provider – a practice that has serious consequences and leaves organizations trapped in ways they never anticipated.

The problem: a black box approach to authentication

Many customer identity and access management (CIAM) vendors store user credentials in a hashed format to ensure security. However, when an organization decides to move to a new CIAM solution, some vendors refuse to disclose the hashing algorithm and parameters used. This creates an unnecessary roadblock to completing a secure user migration.

Without access to these details, organizations face two major issues:

1. User friction and poor experience – If passwords can’t be securely migrated, the only option is to require every user to reset their password on the new platform. This is a disruptive and frustrating experience, leading to higher abandonment rates and increased help desk burden and costs.
   
   
2. Security risks – Users reusing passwords across services may inadvertently introduce security vulnerabilities when forced to reset. Attackers can use this opportunity to exploit predictable password behavior, increasing the risk of credential stuffing attacks.

Why vendors withhold this information

While some identity vendors claim security concerns as the reason for withholding password hashing details, this justification falls apart under scrutiny. Securely sharing hash details with organizations looking to migrate should not expose plaintext passwords—it simply enables a structured and secure transition. 

If a vendor claims this process exposes an attack surface to their other customer passwords, then one should question why the vendor doesn’t prioritize addressing this vulnerability in their product.

In reality, withholding this information is often a strategic move to create lock-in. By making migration difficult, vendors push organizations into renewing contracts out of necessity rather than value.

How customers can mitigate this risk

To protect against vendor lock-in due to withheld password hashes, you can take proactive steps, including:

• Conduct early due diligence – Before signing a contract, ask vendors about their migration policies, exit strategies, and migration support and ensure vendors have clear, documented procedures for securely transitioning user authentication data.
• Demand contractual protections – When negotiating terms and conditions,  include clauses that mandate vendors provide hashing algorithm details and migration support upon contract termination.
• Deploy backup authentication methods – Use alternative authentication methods, such as federated identity systems (e.g., SSO or OAuth), that can reduce reliance on vendor-managed password storage.
• Take advantage of legal and compliance leverage – Depending on industry regulations, check if you have legal grounds to demand password portability, especially in sectors with data sovereignty and user control requirements.

Vendors should recognize that ethical business practices and customer trust are more valuable than forced retention tactics. Organizations should demand that their vendors document their password hashing approaches and make them available upon request when offboarding. Organizations should also advocate for standardized migration frameworks that allow seamless user authentication transitions.

Breaking free from unfair lock-in

Vendors that withhold password hashing details are prioritizing retention over customer success, making it difficult for organizations to migrate when needed. Organizations must push back against these practices, ensuring that they retain control over their own user authentication systems. By demanding transparency and planning for migration from the outset, organizations can protect themselves from the hidden dangers of vendor lock-in.

By design, Strivacity recognizes that password hashes belong to our customers, not us. We operate with transparency and provide our customers with the necessary authentication details upon request, ensuring a smooth and secure transition. This approach not only fosters trust but also demonstrates our commitment to customer empowerment. Because true customer success isn’t about forcing dependence–it’s about enabling choice. 

Ready to break free from restrictive vendors? See how Strivacity stacks up against vendors like Okta and Ping Identity and why switching doesn’t have to be painful.