Security claims we refuse to make
Trust in a security product should come from specific architecture, testable behavior and honest limits. Bold adjectives are not evidence, so here is what IronVault will and will not claim.
Security is a system, not a slogan
A password manager sits between a person and many of their most important accounts. That makes vague promises especially dangerous. No responsible team can remove every risk created by devices, browsers, operating systems, extensions, user choices, dependencies and future vulnerabilities.
Our job is to reduce defined risks, explain how, test the controls and say where the boundaries remain. If a statement cannot be tied to architecture, code, a reproducible test or an independent assessment, it should not be the reason someone trusts a vault.
We do not promise perfection
We will not describe IronVault as impossible to compromise. A device already controlled by malware may capture information after a user unlocks it. A malicious browser extension may inspect a page. A convincing phishing site may trick a person into approving the wrong action. Client-side encryption is important, but it does not turn an infected endpoint into a trusted one.
What we can state precisely is that IronVault encrypts vault contents on the client with AES-256-GCM and derives the vault key from the master password using PBKDF2 with 600,000 iterations. The master password and derived vault key are not sent to the server. Cloud sync moves encrypted vault data rather than plaintext records. Those are architectural properties, not predictions about every possible attack.
We do not use an algorithm name as the whole argument
AES-256-GCM is a well-established authenticated-encryption primitive, but naming it does not prove that an application uses nonces safely, handles keys correctly, protects decrypted state or avoids leaking data through another path. PBKDF2 iteration count matters, but so do password quality, device performance and migration behavior.
That is why our security work includes the surrounding flows: keys remain device-side, vault sync uses encrypted envelopes, sensitive values are not written to logs, and display code treats imported legacy data as untrusted. The security page describes the model in more detail.
We do not claim that zero-knowledge removes metadata
Zero-knowledge describes the confidentiality of vault contents. IronVault still needs limited account and operational data to provide a service, such as an account email, authentication records, subscription state, encrypted blob metadata and support messages a user chooses to send. Network providers and app stores may also observe ordinary connection or purchase metadata.
The meaningful boundary is that the server does not receive the master password or a key that can decrypt the vault. That does not mean the service knows nothing about the existence of an account or a sync request. Privacy documentation should separate those categories instead of blending them into one broad promise.
We do not pretend recovery has no trade-off
If a provider can silently recover a vault's decryption key, the provider is part of the trust boundary. IronVault's vault master password is intentionally not recoverable by support. This protects the zero-knowledge model, but it also means the owner must keep a strong master password and recovery material safe.
That can be inconvenient, and it should be explained before a person stores important data. A recovery flow that sounds effortless may be appropriate for another product, but users deserve to know who can reconstruct the key and under what conditions.
We do not turn biometrics into a cryptographic superpower
Face ID, Touch ID and Android biometrics can make local unlock safer and more convenient when implemented through platform key storage. They do not replace the master password's role in deriving the vault key, and their assurance depends on the device, enrollment settings and operating-system security.
We describe biometrics as a device-level access control, not proof that every other layer is protected. High-risk users should also secure the device passcode, keep the operating system current and use hardware-backed second factors where available.
We do not hide the audit gap
Independent security reviews can provide valuable evidence, and mature competitors that publish recurring audits deserve credit for it. IronVault does not yet claim a recurring published independent-audit program. Internal tests, code review and security fixes are useful, but they are not a substitute for an independent assessment.
As external assessments are completed, the right approach is to publish scope, date, assessor, meaningful findings and remediation status. A badge without scope or a report too vague to evaluate does not help users make a real decision.
We do not attack competitors to look safer
Every password manager makes different choices around platforms, recovery, extensions, pricing and security controls. A past incident can teach useful lessons, but fear-based comparisons and selective facts do not improve anyone's vault. Our comparison pages should acknowledge where established products lead, including longer track records, broader native support or published audits.
Evidence we want users to ask for
- Where does encryption and decryption happen?
- Does the master password or derived key leave the device?
- What exactly is stored by the server?
- What happens when the master password is forgotten?
- Which metadata remains visible?
- How are extension permissions limited and explained?
- Which security assessments are public, and what was their scope?
- How quickly are supported versions updated after a serious issue?
These questions are more useful than any adjective. They also give a product team concrete commitments that can be tested release after release.
What trust should look like
Trust is not asking users to believe that nothing can go wrong. It is giving them enough accurate information to understand what is protected, what remains their responsibility and how the product responds when a weakness is found. Read how zero-knowledge encryption works, review IronVault's privacy policy, and choose the product whose trade-offs match your threat model.
Back to IronVault home · Security Claims We Refuse to Make - And What We Show Instead