You are about to hand a single company the keys to your entire digital life. Every bank login, every email account, every work system, every recovery code. That is what a password manager is: a vault holding the credentials that protect everything else you own online. And yet most people choose one based on a review headline, a monthly price, or a slick onboarding animation. Almost nobody asks the question that actually matters: who owns this thing, and can I trust them?
Here is a fact that should unsettle you. In 2022, LastPass suffered a breach where attackers exfiltrated encrypted customer vaults along with unencrypted metadata like website URLs. The company had roughly 25 million users at the time. The vaults were only as safe as each user's master password, which meant millions of people were suddenly in a race against attackers who had all the time in the world to brute-force weak passwords offline. Ownership, corporate structure, and how a company handles disclosure turned out to matter enormously.
This article walks you through how to vet a password manager's ownership before you trust it with your secrets. You will learn what to look for in corporate registration and history, how to read a threat model, how to compare popular options on the criteria that actually predict safety, and a repeatable checklist you can run in under an hour.
Key Takeaways
- Ownership determines incentives. Who profits, who is legally accountable, and where they are based all shape how a product behaves under pressure.
- Zero-knowledge architecture is non-negotiable. The vendor should be mathematically unable to read your vault, and they should prove it, not just claim it.
- Independent audits beat marketing. Look for published third-party security audits with dates, scope, and fixes, not vague "bank-grade encryption" language.
- Corporate history is a signal. Acquisitions, private-equity ownership, and past breaches change the risk profile of a tool you already use.
- Open source raises the ceiling on trust but does not automatically make a product safe. You still need to verify who maintains and builds it.
- Have an exit plan. Before you commit, confirm you can export your data in a standard format if the owner changes or the company folds.
Why Ownership Matters More Than Features
Feature lists are easy to fake and easy to copy. A polished landing page tells you nothing about what happens when a government subpoena arrives, when a venture fund demands growth at any cost, or when the founding security team quietly leaves after an acquisition.
Password managers are a special case because the trust is total and the switching cost is high. Once you have 200 credentials in a vault, moving is painful, so vendors know you are locked in. That dynamic rewards companies that behave well early and can tempt owners to cut corners once you are captured.
Three ownership factors do most of the predictive work:
- Legal entity and jurisdiction. The country a company is incorporated in determines what data it can be compelled to hand over and under what legal process.
- Funding and profit model. A bootstrapped company selling a paid product has different incentives than one burning venture money and monetizing later.
- Continuity and track record. How long has the entity existed, who runs it, and how have they handled past incidents?
This same logic applies to any tool that touches your secrets. We have written about it before in the context of vetting a screen recorder for privacy and auditing browser extension permissions. Password managers just raise the stakes to the maximum.
How to Investigate Who Actually Owns the Company
You would be surprised how much you can learn in 30 minutes with public records and a skeptical eye. Here is the process I run before recommending or trusting any credential tool.
1. Find the legal entity, not the brand
The consumer brand name is rarely the legal entity. Scroll to the footer of the vendor's website, open the Terms of Service, and the Privacy Policy. Look for the exact registered company name and address. If a product does not name its legal owner anywhere, treat that as a serious red flag.
For example, when you look at a listing on a marketplace, ownership should be explicit. On LionScripts, products are published by eDarpan Tech Private Limited, and the About page names the operating company plainly. That transparency is the baseline, not a bonus.
2. Check corporate registration
Once you have the entity name, verify it against a public business registry. In the US that might be a state Secretary of State database, in the UK it is Companies House, in India the Ministry of Corporate Affairs. Confirm the company exists, is active, and roughly matches the age the marketing implies.
3. Trace the funding and acquisition history
Search for the company on Crunchbase and in news coverage. Ask:
- Is it independent, venture-backed, or owned by private equity?
- Has it been acquired? By whom, and when?
- Did key security or founding staff leave after the deal?
Private-equity ownership is not automatically bad, but it correlates with cost-cutting and aggressive monetization. When a password manager gets acquired, read the announcement carefully and watch the product for the next 12 months.
4. Read the incident history
Search [product name] breach, [product name] vulnerability, and [product name] disclosure. A company that has never had an incident is either very young or not looking hard. What matters is how they responded: fast disclosure, clear scope, concrete fixes, and no blaming the users.
Reading the Threat Model and Encryption Claims
Ownership tells you about incentives. Architecture tells you what those incentives can actually reach. The two questions that matter most:
Is it zero-knowledge?
Zero-knowledge means the vendor never has access to your unencrypted vault or the key that unlocks it. Encryption and decryption happen on your device using a key derived from your master password, which never leaves your machine. If the company is breached, attackers get ciphertext, not your passwords.
Verify this in the documentation, not the homepage. Look for specifics: the encryption algorithm (AES-256 or XChaCha20 are standard), the key derivation function (PBKDF2 or Argon2), and iteration counts. If a vendor cannot tell you how many PBKDF2 iterations they use, they have not thought hard enough about your security.
Where does trust actually live?
Even zero-knowledge tools ship code to your browser or device, and that code is delivered by the vendor. So the vendor could, in theory, push a malicious update. This is why open-source clients and reproducible builds matter, and why some of the same discipline we describe in verifying open source packages before adding them to a project applies here too.
A Worked Example: Vetting Before You Migrate 47 Passwords
Let's make this concrete. Say you currently keep 47 passwords across 12 services in your browser's built-in manager, and you have decided that is not good enough. You have three candidates and one weekend. Here is how the hour of vetting plays out.
- Minute 0 to 10: Open each vendor's Privacy Policy and Terms. Record the legal entity name, country of incorporation, and whether they name a parent company. Candidate A names a Swiss entity. Candidate B names a US LLC owned by a PE firm. Candidate C names no legal entity at all. Candidate C is already out.
- Minute 10 to 25: Look up A and B in business registries and on Crunchbase. A is independent and profitable from subscriptions. B was acquired 18 months ago and had a breach the year before that.
- Minute 25 to 40: Find the security audit pages. A has two published audits from named firms in the last two years, with a scope section and remediation notes. B links to a single audit that is four years old.
- Minute 40 to 55: Confirm each supports encrypted export to a standard format so you are not trapped. A exports to encrypted JSON and CSV. B exports to CSV only.
- Minute 55 to 60: Decision. You choose A, enable a strong master password with a passphrase of at least five random words, turn on multi-factor authentication, and print your recovery kit.
Notice that not one minute of this went to comparing autofill animations. The features were roughly equal. The ownership and architecture made the decision.
Comparing Password Manager Trust Signals Side by Side
Here is a simple framework for scoring candidates. Replace the example tools with your own shortlist and fill in what you find. The point is the criteria, not my scores.
| Trust Signal | Cloud SaaS (typical) | Open-Source Self-Hosted | Local-Only Vault | Browser Built-In |
|---|---|---|---|---|
| Named legal owner | Usually yes | Yes (project + maintainers) | Varies | Yes (major vendor) |
| Zero-knowledge by design | Common, verify claims | Yes, and inspectable | Yes (data never leaves device) | Partial, tied to account |
| Independent audits published | Best vendors yes | Sometimes, community-driven | Rare | Rarely product-specific |
| Breach blast radius | High (central store) | You control the server | Local only | Tied to your account provider |
| Data export / exit | Usually standard formats | Full control | Full control | Limited |
| Ongoing maintenance burden | Low | High (you patch it) | Medium | Low |
No single column wins for everyone. A journalist protecting sources may accept the maintenance burden of self-hosting. A small business may want managed SaaS with published audits. What matters is that you match the model to your actual threat model rather than to a marketing tagline.
Where Password Managers Fit in a Broader Security Setup
A vetted password manager is one layer, not a complete defense. The credentials it protects still guard systems that need their own hardening, and the ownership scrutiny you apply to your vault should extend to the rest of your stack.
If you run websites, the same discipline shows up in how you evaluate protective tooling. On the marketplace side, our Cover image: Software value feedback loop by jakuza, licensed under BY-SA 2.0 via Openverse.
