You trust it with everything. Your banking passwords. Your work credentials. Your private messages. Every digital skeleton key you own, locked away in a vault marketed as European, secure, and sovereign.
Except the vault was built by someone else. Someone you’d never let in the door.
An investigation by the OCCRP has revealed that a password manager proudly bearing the ‘Made in EU’ label shares its actual codebase β the DNA of the software β with a Russian state-certified firm. Not inspired by. Not similar to. The same code, maintained in lockstep, updated in parallel. This isn’t a branding problem. This is a structural security paradox hiding behind a compliance certificate.
Let’s break down why this matters more than any data breach headline you’ve read this year.
When you pick a European password manager, you’re not just choosing software. You’re choosing a geopolitical promise. The promise that your data lives under GDPR, under EU courts, under democratic oversight. The ‘Made in EU’ sticker isn’t marketing fluff β it’s the entire reason you pay for the product instead of using a free alternative. You’re buying trust.
But here’s what no one in the compliance department will tell you: a supply chain vulnerability doesn’t care where the label was printed.
The shared codebase means that any backdoor, any vulnerability, any ‘accidental’ weakness introduced into the Russian-certified version could β by design or by disaster β propagate directly into the EU product. The two aren’t siblings who went their separate ways. They’re conjoined twins sharing a nervous system. When one twitches, the other feels it.
Think about what ‘state-certified’ means in the Russian context. It means the software has been reviewed and approved by FSB-adjacent entities under Russia’s SORM framework β the same surveillance architecture that gives the state near-total visibility into domestic digital life. Certification in that environment isn’t a seal of quality. It’s a negotiation. And you don’t get certified without answering questions you’d rather not answer.
The label says Brussels. The codebase says Moscow. And your passwords are caught in the middle.
Now, the company will tell you this is fine. They’ll point to local data storage. They’ll show you their EU servers. They’ll flash their ISO certifications and their GDPR compliance audits. And all of it will be true β and none of it will matter.
Because the vulnerability isn’t in where your data sleeps. It’s in the walls of the house. If the codebase itself is shared with an entity operating under adversarial state oversight, then no amount of European server hosting changes the fundamental attack surface. You can move your safe into a Swiss bank vault, but if the locksmith who built the safe also builds safes for someone who wants to rob you, you have a problem that geography can’t solve.
This mirrors a pattern we’ve seen before in dual-use technology transfer. It’s the telecom equipment debate. It’s the Kaspersky antivirus conversation. It’s the semiconductor supply chain reckoning. Each time, the industry says ‘trust us, the code is clean.’ Each time, we discover that trust is not a substitute for structural independence.
Compliance is not security. A certificate is not a guarantee. And a label is not a firewall.
If you’re using this password manager β or any product whose ‘European’ identity rests on a shared codebase with a non-allied entity β you need to ask yourself a hard question: What does ‘security’ actually mean to you?
If it means ‘my data is stored in an EU data center,’ then you’re fine. Technically. On paper.
If it means ‘no adversarial state actor has a potential structural pathway to my credentials,’ then you have a problem that switching servers won’t fix. You need to switch software.
The uncomfortable truth of globalized tech is that sovereignty is increasingly a story we tell ourselves. Your app was designed in one country, coded in another, maintained in a third, hosted in a fourth, and certified by a fifth. The ‘Made in EU’ label is the last chapter of a much longer book β and if you only read the last page, you’ll miss the plot twist that determines how the story ends.
In the age of supply chain warfare, the most dangerous vulnerability isn’t a zero-day exploit. It’s the lie that proximity equals safety.
Check your password manager. Ask where the code comes from β not where the company is registered, not where the servers sit, but where the actual codebase is born and maintained. If the answer makes you uncomfortable, that discomfort is the correct response.
Because trust isn’t something you buy. It’s something you verify. And right now, millions of people are paying for a promise that the architecture can’t keep.
FAQ
Q: Couldn't the EU company just fork the codebase and go independent?
A: Technically possible, practically meaningless. A shared codebase means shared architecture, shared vulnerabilities, and shared update pipelines. Forking after years of parallel development doesn't erase the structural exposure β it just gives you a copy of a compromised foundation. You'd need a ground-up rewrite, which no company will admit is necessary.
Q: Does this mean I should stop using password managers entirely?
A: No. It means you should stop assuming that a 'Made in EU' label equals structural independence. Audit the actual supply chain: where is the code maintained, who contributes, and is there any shared development with entities operating under adversarial state oversight? If the company won't answer transparently, leave.
Q: Isn't this just Cold War paranoia applied to software?
A: Tell that to the victims of SolarWinds. Supply chain attacks are the defining cybersecurity threat of this decade. When a codebase is shared with a firm certified under Russia's SORM surveillance framework, questioning that dependency isn't paranoia β it's basic risk assessment. The paranoid position is assuming everything is fine because the label looks European.