Keeper Security EU Alternative 2026: The Government Password Manager That Can't Protect Your EU Data

Post #4 in the sota.io EU Password Manager Compliance Series

Keeper Security's marketing leads with government. FedRAMP-authorised. Trusted by the US Department of Defense. Zero-knowledge encryption. The most audited password manager in enterprise security circles.

For a CISO at a US federal agency, Keeper's credentials are unimpeachable.

For a Data Protection Officer at a German Mittelstand company or a French healthcare group, those same credentials raise an uncomfortable question: the very features that make Keeper trustworthy to the US government are precisely what makes it legally problematic under EU data protection law.

FedRAMP authorization means Keeper has passed rigorous US government security review. It also means Keeper routinely operates under US federal jurisdiction, US federal contracts, and US federal legal obligations — including, critically, the CLOUD Act.

This guide explains the structural conflict, what Keeper's corporate architecture means under GDPR Article 44, and which alternatives provide verifiable EU jurisdiction for password vault data.

Who Is Keeper Security, Inc.?

Keeper Security was founded in 2011 by Craig Lurey and Darren Guccione in Chicago, Illinois. It remains headquartered in Chicago.

The entity that holds the Keeper vault product, the encryption keys, and the US government contracts is Keeper Security, Inc. — incorporated in Delaware, operating from Illinois.

Keeper also operates a European subsidiary: Keeper Security International Limited, registered in Ireland. This entity processes EU customer data under GDPR and handles EU commercial relationships.

At first glance, this structure looks like a clean separation: EU customers are with the Irish entity, therefore outside CLOUD Act reach.

The separation is real in accounting terms. In legal terms under CLOUD Act analysis, it is considerably more fragile than Keeper's marketing implies.

The CLOUD Act and Why FedRAMP Makes It Worse

The Clarifying Lawful Overseas Use of Data Act (18 U.S.C. § 2713), enacted in 2018, gives US federal agencies the legal authority to demand data from US-incorporated companies — regardless of where that data is physically stored.

The critical clause: "A provider of electronic communication service or remote computing service shall comply with the obligations of this chapter to preserve, backup, or disclose the contents of a wire or electronic communication and any record or other information pertaining to a customer or subscriber within such provider's control, regardless of whether such communication, record, or other information is located within or outside of the United States."

For Keeper Security, Inc. (Delaware), CLOUD Act orders are legally enforceable against the parent. The question for EU customers is whether Keeper Security International Limited (Ireland) can functionally insulate their data from that parent.

Why FedRAMP Increases CLOUD Act Risk

FedRAMP — the Federal Risk and Authorization Management Program — is a US government-wide compliance framework for cloud services used by federal agencies. Keeper holds FedRAMP Authorized status, meaning Keeper operates cloud infrastructure that processes US government data under federal contracts.

This creates two CLOUD Act risk amplifiers that pure commercial SaaS vendors do not face:

1. Active federal relationship: Keeper has existing contractual and operational relationships with US federal agencies. Agencies under pressure to investigate supply-chain threats or insider risks have an established legal channel to Keeper — not just a theoretical CLOUD Act warrant pathway, but an active governmental relationship with an entity that already operates under government oversight.

2. Security review creates disclosure precedents: FedRAMP's Continuous Monitoring (ConMon) requirements mean Keeper regularly discloses security incidents, access logs, and system configurations to federal reviewers. While this is security data, not user vault data, it establishes an operational pattern of government access to Keeper infrastructure that has no EU equivalent.

This does not mean Keeper is automatically handing EU data to US agencies. It means the structural proximity between Keeper and the US federal government is substantially greater than with commercial SaaS vendors like Dashlane or 1Password — whose CLOUD Act risk we covered in earlier posts in this series.

Keeper's Zero-Knowledge Architecture: What It Protects and What It Doesn't

Keeper is genuinely zero-knowledge in the cryptographic sense. The master password never leaves the device. Vault contents are encrypted client-side using AES-256 before transmission. Keeper's servers store ciphertext, not plaintext passwords.

This architecture provides strong protection against one threat model: a database breach. If Keeper's servers are compromised, attackers get encrypted blobs they cannot decrypt without the user's master password.

Zero-knowledge does not protect against CLOUD Act warrants in the following scenarios:

Scenario 1: Encryption Key Escrow via PBKDF2

Keeper generates vault encryption keys derived from the master password via PBKDF2 (Password-Based Key Derivation Function 2). The derived key never leaves the client in normal operation.

However, in enterprise deployments using Keeper's Admin Console, administrators can perform account recovery operations. This requires the enterprise to hold key escrow material — typically secured by the enterprise's own key, not Keeper's. But it means vault keys exist in recoverable form somewhere, and the escrow mechanism creates a surface that legal process can target.

A CLOUD Act order directed at an enterprise Keeper account could seek the escrow material held by the enterprise, not Keeper directly. If the enterprise is a US entity (a US subsidiary of a German group, for example), this becomes legally complex.

Scenario 2: Metadata is Not Zero-Knowledge

Zero-knowledge applies to vault contents. Metadata — which users access which accounts, connection timestamps, device IDs, IP addresses, billing records — is not zero-knowledge.

Under GDPR, metadata is personal data. Under CLOUD Act, metadata is the most common target of federal demands (subscriber records, usage logs). A CLOUD Act order to Keeper Security, Inc. for metadata about EU users falls within the scope of what the CLOUD Act authorises and what zero-knowledge encryption does not protect.

Scenario 3: The US-Parent Structural Problem

Keeper Security International Limited (Ireland) does not independently control the encryption infrastructure, the key management system, or the software stack. These are maintained by Keeper Security, Inc. (Delaware).

The Irish entity is a data controller for EU customer relationships in the commercial sense. It is not an independent vault operator. A CLOUD Act order to the Delaware parent affects systems that the Irish entity depends upon, regardless of the commercial separation.

GDPR Article 44 requires transfers to third countries to have an adequate legal basis. When a US parent company has effective technical control over EU data infrastructure, CJEU case law (Schrems I, Schrems II) establishes that legal separation without operational independence is insufficient protection.

Keeper's GDPR Compliance Claims: What They Cover

Keeper publishes a detailed GDPR compliance page. Their claims:

• EU-US Data Privacy Framework participant: Keeper is listed as a DPF participant for HR data
• Standard Contractual Clauses: Keeper offers SCCs for data transfers from EEA to the US
• EU data residency option: Enterprise customers can configure data storage in AWS Frankfurt
• ISO 27001 certification: Keeper Security International Limited holds ISO 27001
• SOC 2 Type II: Annual audit covering security, availability, confidentiality

These are real compliance measures. The DPF participation and SCC framework represent genuine legal mechanisms for data transfer.

The DPF Problem: NOYB Challenge

The EU-US Data Privacy Framework, adopted in July 2023 (Commission Decision 2023/1795), replaced Privacy Shield as the legal basis for EU-US data transfers. NOYB (None of Your Business), Max Schrems' privacy advocacy organisation, filed a challenge to the DPF before the CJEU on 25 September 2023 (Case C-446/23).

The challenge mirrors the arguments that invalidated Privacy Shield in Schrems II. The core issue: US surveillance law (FISA 702, EO 12333) has not fundamentally changed. The DPF's "redress mechanism" — a Data Protection Review Court within the US executive branch — does not meet CJEU standards for judicial independence.

A timeline for the CJEU ruling is unclear but legal observers expect a decision by 2025-2026. If the CJEU invalidates DPF (as it did Privacy Shield in 2020), companies relying on DPF as their transfer basis — including Keeper — would need to revert to SCCs immediately.

The SCC Problem: Contractual vs. Technical Protection

Standard Contractual Clauses (SCCs) create contractual obligations that Keeper must not comply with unlawful government requests, must notify EU customers of government demands where legally permitted, and must provide equivalent protection to EU data.

SCCs do not create technical impossibility for CLOUD Act compliance. If a US federal judge issues a CLOUD Act order to Keeper Security, Inc., the order is legally binding regardless of what SCCs say. Keeper would face a choice between violating the court order and violating the SCCs. US courts take precedence.

The European Data Protection Board's Schrems II guidelines acknowledge that SCCs require supplementary technical measures to be effective in high-risk contexts. For a FedRAMP-authorized government vendor, the risk profile is higher than average commercial SaaS.

EU Data Residency: What It Actually Means

Keeper offers data residency in AWS Frankfurt (EU-WEST-1) for enterprise customers. Data-at-rest resides in Germany. Backups stay in EU.

Data residency does not change corporate jurisdiction. Keeper Security, Inc. (Delaware) remains the technical operator. AWS Frankfurt runs on AWS infrastructure, and AWS, Inc. is itself a Delaware C-Corp. CLOUD Act orders run through the corporate parent, not the geographic location of servers.

A CLOUD Act order to Keeper Security, Inc. or Amazon.com, Inc. can compel production of EU-resident data stored in Frankfurt. EU data residency is a useful compliance feature for GDPR data localisation requirements; it is not a CLOUD Act defence.

What Keeper Costs vs. EU Alternatives

Before moving to alternatives, a fair cost comparison:

For large enterprises (500+ seats), Keeper's pricing can be negotiated down significantly. For SMEs comparing EU alternatives, the price gap is minimal — typically under €1/user/month.

EU Alternatives to Keeper Security

1. Passbolt — Luxembourg, Open-Source, EU-Native

Jurisdiction: Passbolt SA is incorporated in Luxembourg (Grand-Duchy of Luxembourg), an EU member state. Data processing stays within EU legal infrastructure.

Architecture: Passbolt uses OpenPGP end-to-end encryption. Vault contents are encrypted with users' PGP keys. Passbolt's servers never see decrypted data. This is functionally equivalent to Keeper's zero-knowledge model.

Key differentiators:

• Open-source core (AGPL v3): The Community Edition is free and fully auditable. No black-box encryption to trust.
• Self-hostable: EU organisations can run Passbolt on their own infrastructure (on-premises or EU cloud), eliminating vendor cloud dependency entirely.
• Git-based audit trail: Every password access and modification creates an immutable audit log — stronger for compliance than Keeper's proprietary audit logs.
• Team-oriented UX: Passbolt was built for DevOps and IT teams sharing credentials, not enterprise hierarchy management. Less polished than Keeper for executive users, stronger for technical teams.

GDPR verdict: Clean EU jurisdiction. No US parent, no CLOUD Act exposure, self-hosted option eliminates third-party cloud risk entirely.

When Passbolt is the right choice: Technical teams in EU companies that want auditability, open-source transparency, and the option to self-host. Financial services and healthcare organisations that require on-premises deployment.

2. Proton Pass — Geneva, Switzerland

Jurisdiction: Proton AG is incorporated in Geneva, Switzerland, operating under Swiss law (Federal Act on Data Protection, revised 2023) and subject to GDPR as a processor of EU personal data. Switzerland is not an EU member but holds an EU adequacy decision (Decision 2000/518/EC).

Architecture: Proton Pass uses end-to-end encryption built on Proton's existing mail and drive infrastructure. Vault contents are encrypted client-side. Proton operates under Swiss judicial procedure, which requires dual criminality for international law enforcement cooperation — providing stronger protection than US legal mechanisms.

Key differentiators:

• CERN academic heritage: Proton was founded by CERN researchers in 2014. The organisation retains a non-profit foundation structure (Proton Foundation) that constrains commercial acquisition and investor pressure.
• Integrated privacy suite: Proton Pass integrates with Proton Mail, Proton Drive, and Proton VPN. For organisations already in the Proton ecosystem, Pass adds vault management without adding a new vendor.
• Hide-my-email aliases: Proton Pass generates email aliases per site, reducing credential stuffing risk beyond what standard password managers provide.
• No browser extension telemetry: Proton's browser extension does not collect usage analytics, unlike Keeper's enterprise analytics features.

Considerations:

• Swiss adequacy decision has been stable since 2000 but is subject to review. If the Commission reassesses (unlikely in the short term), SCCs would be required.
• Proton Pass Business lacks some enterprise features Keeper offers: no Active Directory / LDAP integration in the base tier, limited SIEM integration.
• Switzerland's IMSI catcher case (2023) showed that Swiss authorities can and do compel Proton to provide IP logs under domestic law — though vault contents remain cryptographically inaccessible.

GDPR verdict: Strong. Swiss adequacy + end-to-end encryption + non-commercial foundation structure. Not zero-risk (IMSI case is real), but materially stronger than Delaware C-Corp jurisdiction.

When Proton Pass is the right choice: Privacy-conscious organisations that want a commercial SaaS product with EU-proximate jurisdiction and integrated privacy suite. Works best for teams already using Proton Mail.

3. Vaultwarden — Self-Hosted Bitwarden-Compatible

What is Vaultwarden? Vaultwarden is an unofficial, community-maintained, AGPL v3 reimplementation of the Bitwarden server API. It is written in Rust, runs on a single Docker container, and is fully compatible with all official Bitwarden browser extensions and mobile apps.

Jurisdiction: Self-hosted means your jurisdiction. Data lives on your servers, in your EU cloud provider, or your on-premises infrastructure. No Vaultwarden Inc. to serve CLOUD Act warrants to.

Architecture: Vault data is encrypted client-side in the Bitwarden application before transmission to the Vaultwarden server. The server stores ciphertext. Even the server operator cannot read vault contents without the user's master key.

Key differentiators:

• Zero vendor risk: No SaaS subscription, no vendor lock-in, no third-party cloud. You control the infrastructure lifecycle.
• Full Bitwarden API compatibility: Users keep Bitwarden browser extensions and mobile apps — no retraining required if migrating from Keeper (which requires switching UX).
• Minimal resource requirements: Vaultwarden runs on a €5/month VPS, Raspberry Pi, or NAS device. For a 50-person company, infrastructure costs are negligible.
• AGPL transparency: The entire server codebase is public and auditable.

Operational requirements:

• Someone on your team must manage updates, backups, and uptime. Vaultwarden requires a weekly ~1-hour maintenance commitment for a well-run deployment.
• No built-in SSO in the free version (SSO requires the Vaultwarden SSO fork or premium Bitwarden).
• Compliance certifications (SOC 2, ISO 27001) belong to you, not a vendor. This can be a feature (you control the audit) or a burden (you must conduct it).

GDPR verdict: Zero third-party exposure. All GDPR obligations (Art. 24-26, data processing agreements) are entirely internal to your organisation.

When Vaultwarden is the right choice: EU organisations with DevOps capability, regulated industries requiring data sovereignty, teams that want zero vendor dependency, SMEs where infrastructure cost outweighs SaaS convenience.

4. KeePassXC — Local, Offline, No Network

What is KeePassXC? KeePassXC is an open-source, cross-platform password manager that stores the vault as an encrypted local file (.kdbx format). There is no cloud component. No sync server. No vendor.

Jurisdiction: Local files have no cloud jurisdiction. KeePassXC is maintained by volunteer contributors under AGPL v3.

Architecture: Vault files are encrypted with AES-256 or ChaCha20 + Argon2 key derivation. The vault file can be synced via any EU file storage (Nextcloud, Seafile, your NAS) at your discretion.

Key differentiators:

• Absolute sovereignty: No network dependency means no legal attack surface. The vault file is an encrypted blob with no vendor who can be compelled.
• No subscription cost ever: The application is free.
• Browser integration: KeePassXC-Browser extension works with Chrome, Firefox, Edge, Brave.

Limitations:

• No team sharing built-in. Sharing secrets between team members requires file distribution or a shared Nextcloud folder — not a managed secrets management workflow.
• No mobile sync out-of-the-box (KeePassium on iOS, Keepass2Android on Android handle sync via cloud storage).
• No enterprise audit logs, access controls, or provisioning.

When KeePassXC is the right choice: Individual users, freelancers, or very small teams (2-5 people) who prioritise simplicity and absolute local control over collaboration features.

5. Padloc — German-Made, GDPR-Designed

What is Padloc? Padloc is a password manager developed by Padloc GmbH, incorporated in Germany (Düsseldorf). The product is end-to-end encrypted and FOSS (GPL v3).

Jurisdiction: Padloc GmbH is a German limited liability company under German law (GmbH). German data protection is enforced by the Bundesdatenschutzbeauftragter (BfDI) and 16 Landesdatenschutzbehörden. No CLOUD Act exposure.

Architecture: Vault contents are encrypted client-side with PBES2 + AES-256-GCM before hitting Padloc's servers. Keys derive from the master password via PBKDF2.

Key differentiators:

• Fully open-source (GPL v3): Padloc's server and client are both public.
• Self-hostable: Docker-based deployment; Padloc Premium can be self-hosted.
• Simple UX: Padloc targets individuals and small teams. Less enterprise feature overhead than Keeper or Passbolt.

Limitations:

• Smaller community than Passbolt or Bitwarden. Fewer enterprise integrations (no Active Directory, limited SIEM support).
• Team features are less mature than Passbolt Business.

When Padloc is the right choice: German SMEs or EU-conscious teams that want a German-incorporated SaaS option with EU hosting and open-source auditability, at lower operational complexity than Vaultwarden.

Migration from Keeper Security

Step 1: Export from Keeper

1. Open Keeper Desktop app or Web Vault
2. Navigate to Admin Console → Vault → Export
3. Choose CSV or JSON format (JSON preserves more metadata)
4. Export generates an unencrypted file — handle it carefully and delete after migration

Important: Keeper's export format does not include shared folder permissions, emergency access configurations, or SSO mappings. Document these manually before migration.

Step 2: Import into Your Chosen Alternative

Passbolt:

• Import via Passbolt's CSV importer (Admin → Import)
• Format: KeePass XML or Bitwarden JSON (convert Keeper JSON with a script)
• Assign to teams post-import

Proton Pass:

• Settings → Import → Bitwarden (Proton Pass accepts Bitwarden JSON format)
• Keeper JSON requires a one-step conversion (Keeper → Bitwarden JSON → Proton Pass)
• Proton publishes a migration tool for common sources

Vaultwarden (via Bitwarden client):

• Bitwarden → Tools → Import Data → Choose "Keeper (csv)"
• Bitwarden officially supports Keeper CSV import
• After import, your Vaultwarden self-hosted instance receives all records

Step 3: Enterprise Configuration

For enterprise deployments, plan for:

• SSO migration: Passbolt supports SAML/LDAP; Vaultwarden (with SSO fork) supports OIDC
• Emergency access: Reconfigure recovery workflows — Keeper's admin recovery model differs from Passbolt's team-based key escrow
• Browser extension update: Users switch from Keeper extension to target product's extension
• Mobile apps: Keeper mobile → Bitwarden mobile (for Vaultwarden) or Proton Pass mobile

Typical enterprise migration timeline: 2-4 weeks for a 100-seat deployment with proper testing.

Decision Matrix: Which Alternative for Which Organisation?

Choose Passbolt if: you need enterprise-grade team features, LDAP integration, and EU-incorporated SaaS with an open-source audit trail.

Choose Proton Pass if: you're already in the Proton ecosystem, want Swiss jurisdiction, and prioritise ease of deployment over self-hosting control.

Choose Vaultwarden if: you have DevOps capability, need absolute data sovereignty, and want Bitwarden's polished UX on your own infrastructure.

Choose KeePassXC if: you're an individual or very small team that needs local-only simplicity with no vendor dependency.

Choose Padloc if: you're a German SME wanting a domestic supplier with FOSS credentials and lower operational complexity than Vaultwarden.

The FedRAMP Paradox for EU Organisations

Keeper's government pedigree deserves a final note. FedRAMP authorization is a genuine security achievement — it requires penetration testing, continuous monitoring, and audit commitments that most commercial SaaS vendors never complete.

But FedRAMP was designed for US government security requirements, not EU data protection law. The program's entire framework assumes US legal jurisdiction, US oversight bodies, and US legal process. Keeper's compliance excellence within US federal law is structurally in tension with GDPR's requirement to limit data transfers to jurisdictions offering equivalent protection.

This isn't a criticism of Keeper's security engineering. It's a structural observation about legal geography. A password manager optimised for US government trust frameworks is optimised for a different legal environment than EU data protection law requires.

EU organisations choosing a credential management solution in 2026 should evaluate legal jurisdiction as a first-class requirement — not an afterthought. Passbolt (Luxembourg), Proton Pass (Switzerland), and self-hosted Vaultwarden all provide this. Keeper Security, Inc. (Delaware) does not, regardless of the quality of its encryption.

Summary

Keeper Security is a world-class product for US enterprise and government environments. For EU organisations operating under GDPR, the Delaware parent structure, FedRAMP relationship, and DPF dependency create legal risks that no amount of zero-knowledge encryption can fully mitigate.

The next post in this series examines NordPass — the password manager from Nord Security (Lithuania / Panama / Cyprus corporate structure) — and what its distributed ownership means for EU data protection compliance.

This post is part of the sota.io EU Password Manager Compliance Series, analysing the GDPR and CLOUD Act implications of widely used credential management tools.