What zero-knowledge encryption does not protect
Zero-knowledge is a meaningful architecture, not a force field. Understanding its boundary is essential before placing high-consequence records in any encrypted vault.
What zero-knowledge does protect
In a zero-knowledge vault, encryption and decryption happen on the user's device with a key the provider is not given. IronVault encrypts vault contents with AES-256-GCM and derives the key from the master password with PBKDF2 using 600,000 iterations. Optional cloud sync moves encrypted vault data. The server does not receive the vault master password or derived key.
That design reduces the consequence of a storage-server disclosure because the stored vault content is ciphertext. It also prevents ordinary support access to plaintext vault records. These are concrete properties described in the security model, not a prediction that every device, browser and person will behave safely.
What zero-knowledge does not protect
An already-compromised device
The vault must decrypt data somewhere for the owner to use it. Malware with sufficient control of that device may capture keystrokes, screenshots, clipboard data or values after unlock. Client-side encryption protects data before and during storage; it cannot turn a hostile endpoint into a trusted one.
Phishing and mistaken approval
Encryption cannot decide whether a person intended to reveal a password to a convincing lookalike site. Restrained domain-aware autofill may provide a useful signal, but users still need to inspect destinations and unexpected prompts. Hardware-backed phishing-resistant factors can add protection for accounts that support them.
An exposed unlocked session
Auto-lock, biometric gates and reveal confirmation reduce casual exposure, but someone holding an unlocked device may see what the owner can see. Set an appropriate lock timeout, secure the device passcode and avoid unlocking sensitive records where screen observation is likely.
Metadata outside the encrypted payload
A service may need account email, authentication records, subscription state, encrypted-blob revision data and support messages a user chooses to send. App stores and network providers observe ordinary purchase or connection metadata. Zero-knowledge describes vault-content confidentiality; it does not mean the service knows nothing about an account. The privacy policy should be read with that distinction in mind.
Loss of the only recovery path
If support can silently reconstruct a vault key, the provider is part of the decryption boundary. IronVault intentionally cannot recover a forgotten vault master password. That protects the architecture but creates responsibility: the owner needs a strong master password, a safe offline recovery record and tested access on the devices that matter.
Unsafe plaintext exports
A CSV or JSON export may be readable outside the vault. Once exported, the file is protected by the operating system and the owner's handling, not by the original encrypted database. Create exports only when necessary, keep them local, validate the import and remove all copies. The migration checklist covers this high-risk window.
Availability and service failure
Encryption does not promise that a server, app store, network or device will always be available. Local access, encrypted backups and documented recovery reduce dependence, but users should decide how much redundancy high-consequence records require.
A practical threat-and-control map
| Threat | Helpful control | Remaining boundary |
|---|
| Server storage disclosure | Client-side encrypted vault data | Weak master passwords still deserve strong derivation and user care |
| Password reuse | Generated unique passwords | Recovery accounts and sessions still need review |
| Password-only login | TOTP, passkey or hardware key | Phishing and weak account recovery may remain |
| Lost device | Device lock, biometrics, auto-lock, encrypted sync | An unlocked or infected device changes the risk |
| Family emergency | Documented continuity and digital legacy plan | Legal authority and provider succession rules remain external |
Questions to ask any vault provider
- Where do encryption and decryption happen?
- Does the master password or derived key leave the device?
- What can support recover, and what can it read?
- Which metadata remains visible?
- How are browser-extension permissions and domain matching constrained?
- What happens to plaintext exports and clipboard values?
- Which independent assessments are published, with what scope and date?
IronVault has not yet completed an independent third-party security audit. That gap should be weighed honestly, especially by organisations or high-risk users who require recurring published assessments. Read the security claims IronVault refuses to make for the evidence standard the product is adopting.
Layer the controls
Use the vault with an updated operating system, a strong device passcode, limited extensions, unique account passwords, appropriate second factors and an offline recovery plan. For a broader inventory and setup sequence, use the encrypted life vault guide. Security improves when each layer has a defined job and its failure does not silently collapse every other layer.
Back to IronVault home · What Zero-Knowledge Encryption Does Not Protect