A secure vault is the starting point
Strong, correctly implemented encryption protects stored credentials from being read without the right key. It is essential for the vault on your device and for every backup you keep.
But a password has to leave that protected state to be used. The vault unlocks. A credential appears in memory. A browser fills a sign-in page. Each step needs its own controls.
When evaluating a credential tool, look at the whole journey: storage, access, use and recovery. The encryption algorithm is one part of that design.
A password can be stolen without opening your vault
- A convincing fake sign-in page. You type a password into a phishing site. The attacker receives it without ever touching your vault.
- One password used in several places. A password exposed by one service can give an attacker access to other accounts where you reused it.
- A copy you forgot about. An export, a temporary spreadsheet or a browser profile on a shared computer creates another place where credentials can be exposed.
- A vault left unlocked. An unattended computer or a password left on the clipboard can make a secret accessible after it has been decrypted.
- A weaker recovery route. A strong master passphrase can be undermined by an access-restoration process that relies on guessable answers or a phone number you no longer control.
- Someone pretending to be support. A request to reveal a passphrase or recovery key can be an attempt to obtain the secrets that unlock your data.
These risks call for clear access rules, careful handling and informed decisions about where you use your credentials.
The controls that matter beyond encryption
Know where every copy lives
Your vault, backups and exports all deserve protection. Extra copies can improve availability and protect against device loss, but they also create more locations to secure. Ask where each copy is stored, who can access it and how it is protected. Keep backups deliberately, and avoid unnecessary exports.
Lock when access is no longer needed
Automatic locking reduces the time your vault remains accessible. Useful triggers include inactivity, a locked screen, closing the application and removing a device. Ask what happens to decrypted secrets when the vault locks: clearing them from the application's memory matters as well as closing the interface.
Make guessing expensive, and trusted access revocable
A strong passphrase and a properly configured key-derivation function help resist guessing against a copied encrypted vault. Key derivation makes each guess require computational work. The protection depends on the passphrase, the derivation settings and the attacker's resources.
Delays after failed attempts add protection at an application or device interface where they are enforced. They do not necessarily constrain an attacker testing a copied vault outside that interface. These are different controls, and a product should explain what each protects.
If a trusted computer can unlock without your passphrase, the conditions should be clear. You should know which computers are trusted and how to revoke that access.
Fill only when you choose, on the intended site
Autofill is a security decision: it releases a password into a web page. It should require your action, check that the page uses HTTPS and match the intended site. Embedded frames need their own checks; the address of the surrounding page is not enough.
Leaving the final sign-in action to you gives you another opportunity to check the destination. It does not make a filled password inaccessible: scripts on the page may be able to read it before you submit. HTTPS protects the connection, but it does not prove that a site is trustworthy.
Keep recovery under your control
Recovery should be explained as clearly as unlocking. Who can restore access? What secret or proof do they need? A recovery key you hold yourself provides an independent way back in, but anyone who obtains it may be able to use that route too. Protect it separately from your vault.
Read what a recovery key is and how to keep it for a practical recovery plan.
Understand what leaves your computer
Ask what the vault software sends over the network, including sync data, telemetry and crash reports. Limiting what is collected and transmitted reduces opportunities for exposure. Clear statements about network behaviour should be backed by evidence you can inspect.
Keep the scope clear: vault software that makes no internet connections is different from a browser that connects to websites when you sign in.
Know what support will never ask for
A product should clearly identify the secrets its support team will never request. Your passphrase, recovery key and stored passwords should not become proof of identity in a support conversation. Clear guidance helps you recognise a request that could expose your vault.
Ask for specifics before you trust a credential tool
- Where are my vault and backups stored, and who can access each copy?
- When does the vault lock, and what happens to decrypted secrets in memory?
- What protects against guessing at the unlock interface and against a copied vault?
- Which computers can unlock without my passphrase, and how do I revoke that access?
- What checks happen before autofill, including for embedded frames?
- Does autofill require my action, and does the tool submit the form?
- If I forget my passphrase, who can restore access and what do they need?
- What does the software send over the network, and how can I verify that?
- Which secrets will support never ask me to share?
Specific, documented answers give you something to evaluate. A reassuring label alone does not.
Look beyond the word “encrypted”
Look for a clear explanation of how your passwords are protected in storage, during access and when you use them. Know where your backups live, keep recovery secrets safe and understand the limits of autofill.
Those are the details that turn an encryption claim into a security design you can assess.