Not always. A crypto library upgrade can change defaults, drop old algorithms or alter output formats, so data written last year may no longer verify or decrypt. Before merging, test that stored password hashes, ciphertext and signatures created by the old version still work with the new one, using real samples from a safe copy.
Why this upgrade is different
Most dependency fixes only change what happens from now on. A cryptography fix can also change how you read what already exists. Your database holds password hashes, encrypted fields and signed tokens created under old settings. If the new version refuses an old parameter, you lock users out or cannot decrypt records. If it silently accepts something weaker, you keep a risk you thought you removed.
What to inventory first
List every place the library touches stored or exchanged data.
| Data | Question to answer |
|---|---|
| Password hashes | Does the new version still verify the old algorithm and cost settings? |
| Encrypted fields | Does it decrypt ciphertext made with the old mode, key size and format? |
| Signed tokens or files | Do old signatures still validate, and for how long are they valid? |
| Key files and certificates | Does it parse the old encoding and key types? |
| Wire protocols | Do your partners still connect with the old cipher settings? |
Build a compatibility test from real samples
- Export small samples from a non-production copy. A handful of rows of each kind, with sensitive values removed or replaced with test data created by the old version.
- Write a test that reads them. Verify old hashes, decrypt old ciphertext, validate old signatures, all with the new library.
- Write a test that writes then reads. Confirm the new version round trips its own output.
- Test the oldest sample you have. The oldest data is the most likely to use a legacy setting.
- Test failure on purpose. A wrong password and a tampered ciphertext must fail with the new version too.
If old data needs to be upgraded
Fixing a library often goes hand in hand with moving off a weak algorithm. The OWASP Password Storage Cheat Sheet describes upgrading legacy hashes: when users enter their password, re-hash the input with the stronger algorithm. It also describes a second route, wrapping existing hashes inside the new algorithm, and notes that old hashes remain in the database until users log in unless you take one of those steps.
The same idea applies to encrypted data. Store a version marker with each record so the code can pick the right decryption path, and re-encrypt on read or in a background job. Do not do both the library upgrade and the data migration in one deploy. Ship the library with read support for old and new formats first, then migrate, then remove old support.
Plan the rollback
If the new version writes data in a format the old version cannot read, rolling back the code does not roll back the data. Decide before merging whether the new version will write the old format until the migration is done. This is the point where a rollback plan and a canary release earn their keep.
Safeguard can show which services use a given library through dependency scanning and SBOMs, which helps you find every place to test. You can run a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Open the inventory and find where a cryptography package appears, since every one of those places needs a compatibility test.
Quick check
Do I need real production data for the test?
No, and you should avoid it. Generate samples with the old version in a safe environment, using test values, so you cover the old formats without exposing real data.
Is it fine if the new library rejects an old weak algorithm?
Often yes, and sometimes that is the goal. Just make sure you have a migration path so legitimate users and records are not stranded.
Sources
Last reviewed: 19 October 2026.
