Why a self-hosted password manager for EU data sovereignty starts with the server
A regulated EU organization that must show where credentials and their metadata live, and who can reach them, should start with the server, not the client. A self-hosted vault keeps ciphertext and the hosting under EU control, but the choice between Passbolt and self-hosted Bitwarden depends on two things: what the server can see, and which license covers the edition you actually need. Passbolt's documentation says the server only receives and stores ciphertext, with names, URLs and descriptions encrypted only in the v5 format and only when the organization enables metadata encryption. Bitwarden's main server code is AGPL 3.0, but the bitwarden_license directory, including SSO integration modules, falls under a source-available license that requires a paid subscription for production use. Confirm both points against the current documentation before you write a requirement.
This is where a password manager page for EU sovereignty differs from a generic one. Under GDPR Article 44, every transfer of personal data to a third country, including onward transfers, must meet Chapter V conditions, and EDPB Guidelines 05/2021 treat remote access from a third country, even only displaying data on a screen for support, as a transfer. Your support contract therefore matters as much as your hosting: ask where support engineers sit, whether they can view decrypted data during troubleshooting, and which sub-processors touch backups, telemetry or update channels. Schrems II, the Data Privacy Framework adequacy decision and the pending appeal in Case C-703/25 P all bear on US-linked vendors, so treat their status as a live question for counsel.
A workable starting point is a self-hosted Passbolt Community Edition or Pro deployment on EU infrastructure you control, with a written support scope that names the vendor's access paths. Passbolt's Pro features, including LDAP provisioning, account recovery, SSO and syslog activity logs, are listed as paid, so confirm which ones your audit evidence depends on before you choose the edition. If the Bitwarden license file must match your installation's data region, confirm that before buying. Use the answers to draw the data flow diagram first, then pick the product.
Which EU transfer and access rules shape the vault design
This table maps each EU transfer, access and switching rule to a concrete decision for a self-hosted vault: where it runs, who can reach it, who holds keys and how data leaves. Read each row as a question to settle before hosting or buying support, since the Data Privacy Framework row explains why the design should not depend on it.
| Rule | What it asks for in the vault design | Build decision and what to confirm |
|---|---|---|
| GDPR Article 44 (transfers to third countries) | Every transfer of personal data to a third country, including onward transfers, must meet Chapter V conditions. Vault metadata such as entry names and URLs can be personal data. | Keep the vault, backups and logs in EU-controlled infrastructure. Confirm that the hosting provider's sub-processors do not move data outside the EEA. |
| EDPB Guidelines 05/2021 (remote access) | Remote access from a third country, even only displaying data on screen for support, counts as a transfer. Storage in a cloud outside the EEA also counts. | Restrict vendor support sessions to EU-located staff or approved access paths, and log each session. Ask the partner where its engineers sit when they connect. |
| GDPR Article 48 and third-country orders | A third-country court or authority order to disclose personal data is enforceable in the EU only under an international agreement such as a mutual legal assistance treaty. | Document how the organization would respond to a foreign order received by a provider. Ask the vendor and partner for their contractual process for handling such requests. |
| US CLOUD Act (18 U.S.C. 2713) | Providers subject to US jurisdiction must preserve or disclose data in their possession, custody or control, wherever it is located. | A US-parented vendor cloud or US-controlled support channel can reach vault data even when hosted in the EU. Ask who controls the hosting account and the support tooling. |
| EDPB Recommendations 01/2020 (supplementary measures) | Where a provider needs data in the clear and foreign authority powers exceed what is necessary and proportionate, no effective technical supplementary measure is envisioned. | Favor designs where the server stores only ciphertext. In Passbolt, confirm metadata encryption is enabled with the v5 format. In Bitwarden, note that vault item names and URLs are server-visible unless you confirm otherwise for your version. |
| Data Privacy Framework adequacy (Decision (EU) 2023/1795, Case C-703/25 P) | Adequacy covers only US organizations on the Data Privacy Framework List, and an appeal against the General Court's September 2025 judgment is pending. | Do not make the design depend on this framework. Prefer EU hosting and EU-controlled support so the outcome of the appeal does not change your architecture. |
| EU Data Act Article 32 (third-country access to non-personal data) | Providers must take technical, organizational and legal measures to prevent third-country governmental access to non-personal data held in the Union where it conflicts with EU or national law. | Ask the provider for written evidence of these measures for any hosted or support component. Keep configuration and audit logs under your own control. |
| Data Act switching rights (Articles 25, 29 and 50) | Customers may switch to another provider or to on-premises infrastructure, with a maximum two-month notice period, a 30-day transition, and no switching charges from 12 January 2027. | Choose a self-hosted edition so export does not depend on a vendor cloud. Test an export and re-import into a second instance before go-live and write exit steps into the support contract. |
| Export and exit controls (Passbolt docs) | Since Passbolt 5.10, cleartext CSV exports are disabled by default, and encrypted KeePass KDBX formats are offered unless an administrator allows CSV again. | Keep cleartext export disabled, define who may change export policy, and record the setting in your change log. Confirm the same control set for the Bitwarden version you deploy. |
What the server sees in Passbolt and in self-hosted Bitwarden
Both products are designed so that the password, username field, notes and attachments of a vault item are encrypted on the client before they reach the server. Passbolt uses end-to-end encryption based on the OpenPGP standard, and encryption and decryption happen in the browser extension or mobile app rather than on the server. The server receives and stores ciphertext for the secret. Bitwarden clients also encrypt vault data locally before sync, using the account's keys, so the self-hosted server stores encrypted vault data. Confirm how each client handles attachments and custom fields in your version, because coverage of these fields has changed between releases.
- Passbolt secret handling: each user holds a key pair, and each user with access to a shared resource receives their own copy encrypted with their public key.
- Passbolt browser signing: the browser extension is cryptographically signed, so verify the signature of the build you deploy.
- Bitwarden client encryption: the clients encrypt vault items locally, and the self-hosted server holds ciphertext for item contents.
- Attachments and custom fields: test whether each field type is encrypted before sync in the release you run.
- Master password exposure: neither product sends the master password to the server in clear text, but confirm the login and key derivation flow in your own environment.
Check these points by creating a test item, then inspecting the stored database row and the network traffic with a proxy you control.
Metadata is the category most often overlooked in sovereignty reviews. Passbolt's documentation states that metadata such as names, URLs and descriptions is encrypted only with the v5 format and only when the organization enables metadata encryption. Without that setting, these fields may be readable to the server and to anyone with database access. Bitwarden's position differs by item type and version, so treat it as an open question for your deployment and verify it directly rather than assuming parity with Passbolt.
- Passbolt v5 format: metadata encryption requires the v5 resource format and the organization setting to be enabled.
- Passbolt legacy resources: resources created before enabling the setting may keep unencrypted names, URLs and descriptions.
- Bitwarden item names and URIs: confirm in your release whether item names, folder names and URIs are encrypted before they reach the database.
- Search and indexing: check whether the server or client builds search indexes from metadata, since this affects what the server can infer.
- Migration effects: imported entries may arrive in a different format from entries created in the product.
Run a database query on a test organization with metadata encryption on and off, then compare which columns hold readable text.
Sharing is a relationship problem, and the server sees it even when it cannot read the secret. In Passbolt, the server must know which users and groups have access to which resources so it can distribute the correctly encrypted copies, which means access relationships are visible to the server. Bitwarden organizations use collections, groups and member records that the server stores to enforce access, so the server knows who can reach which collection. Neither product hides the sharing graph from the operator of the server.
- Passbolt access graph: resource permissions and group membership are stored server-side to route encrypted copies.
- Bitwarden collections: collection assignments and group memberships are server records used for policy enforcement.
- Operator visibility: the people who administer the database can see which accounts share which items.
- Revocation behavior: confirm how each product removes a user's encrypted copies when access is revoked, and whether previously shared copies can be read by the revoked user.
- Group sync: directory-synced groups add more identity relationships to the server, so review them as personal data.
Test revocation on a sample shared item, then check the server records and the revoked user's cached data.
User identity data is personal data that sits on the server regardless of encryption. Both products store account identifiers such as email addresses, account status, roles and authentication settings. Passbolt's Pro and Enterprise editions add LDAP and SSO integrations, which means directory attributes and identity provider mappings flow into the server. Bitwarden self-hosting also requires an installation ID and installation key tied to an email address, and paid features add license records. These records fall under data protection obligations even though the vault contents are encrypted.
- Account records: email addresses, display names, roles and status are stored in the database in readable form.
- Directory sync: LDAP, Active Directory or identity provider attributes copied into the server expand the personal data set.
- Installation and license records: the Bitwarden installation ID and license file identify the deployment and its owner.
- Authentication data: confirm where MFA secrets, login sessions and recovery material are stored and whether they are encrypted at rest.
- Support access: any vendor or partner account used for support may create additional identity records in your environment.
List every identity attribute in the database schema of your test deployment and classify each one under your records of processing.
Activity logs are where the server sees the most behavioral detail. Logs record who accessed or changed which item and when, and they are generally plaintext because log consumers need to read them. Passbolt lists syslog activity logs as a Pro feature that is not part of the Community Edition, so forwarding and retention depend on the edition you choose. Bitwarden event logs are available in its paid organization features and are stored on the server. In both cases, the log content is personal data about your staff, and it may reveal sensitive business activity even when secrets are encrypted.
- Passbolt logging: syslog activity logs are a Pro edition feature, so confirm the export path and format for your edition.
- Bitwarden event records: confirm which events are logged, how long they are retained and where they are stored in your release.
- Log content: logs may contain item identifiers, user identifiers and IP addresses, which are personal data.
- Log destination: if logs leave the EU through a SIEM or hosted tool, the transfer analysis applies to them too.
- Retention settings: set retention and deletion rules in the database and in any forwarding system.
Generate a set of test actions, then confirm the events appear, the fields they contain and where copies are stored. Repeat the check after each upgrade.
Which platforms fit an EU data sovereignty requirement and why
The three platforms differ less in features than in license terms, what the server stores, and who can sell you support. Each card below names one decision that affects where credentials and their metadata end up and what you must verify before signing a contract.
Passbolt Community and API licensing
The Passbolt API server is licensed under AGPL-3.0, and the official Docker and Helm chart repositories share that license. Community Edition is free to self-host with unlimited users, so the data path stays in your infrastructure. Check that the AGPL terms work for your internal use and any modifications you plan, and confirm with counsel whether your sector requires a supported edition in writing.
Passbolt Pro features for regulated teams
Several controls that auditors often ask about sit behind the Pro edition: LDAP user and group provisioning, account recovery, SSO with Microsoft, Google, OpenID and AD FS, MFA policies, syslog activity logs, and SCIM. Confirm each feature against the current comparison page before procurement, because an unlicensed Community deployment may lack the recovery and logging evidence your examiners expect. Pro is priced per user, so ask for a quote tied to your user count.
Passbolt hosting in your own infrastructure
Passbolt documents installation on several Linux distributions, plus Docker, a Kubernetes Helm chart, an AWS AMI and Ansible, with a virtual appliance for Pro only. The hosting choice decides which legal entity runs the server and where backups sit, so confirm the chosen cloud region or data center location in writing. Confirm also whether the Helm chart and Ansible roles meet your change-management rules.
Self-hosted Bitwarden license split
The Bitwarden server core is under AGPL 3.0, but the bitwarden_license directory, including SSO integration modules, falls under the Bitwarden License, which is source-available and not open source under the OSI definition. Production use of that code needs a paid subscription. Have counsel review whether your procurement treats the SSO module as open source before you commit to the design.
Bitwarden license file and data region
Paid features on a self-hosted Bitwarden server need a license file downloaded from the cloud admin console and tied to the installation ID. That installation ID is retrieved with a valid email address from bitwarden.com/host, and the data region of the installation must match the cloud organization's region. Confirm the region with the vendor before install, because a mismatch blocks the paid features and a later migration must redo attachments, invitations, policies and SSO.
Vaultwarden for business use
Vaultwarden is a community reimplementation of the Bitwarden server API, not a vendor product, so it carries no vendor support contract or published license file in the sources supplied here. Confirm its license terms, release cadence and security advisory process directly from its repository before using it for shared business credentials. Ask a partner whether it can support Vaultwarden in production and how it handles that compatibility risk.
How the EU-hosted vault rollout runs, phase by phase
The sequence moves from a documented data residency position to a hosted, tested and handed-over vault, with each phase closing on a named record so the decision to keep credentials in EU-controlled infrastructure can be checked later. Each phase has an output that a DPO, security lead or auditor can review.
Map data and assess transfer exposure
The organization lists what the vault will hold: user accounts, shared resources, folders, groups, logs and backups, along with the people and systems that can reach each one. Legal or privacy staff, with the security lead, record every point where a non-EU party could access data, including support sessions, remote administration, telemetry and backup copies. The output is a data map and a transfer assessment that states whether any transfer under Chapter V of the GDPR is expected. The step closes when the data map has been signed off by the data protection owner.
Record the hosting decision inside EU infrastructure
The team chooses the hosting location, operator and support model, then documents them in a hosting decision record. The record covers which EU data center or cloud region runs the server and database, who holds administrative access, where backups are stored, and whether any vendor support would reach the system from outside the EEA. It also identifies the supported Passbolt install targets or Bitwarden deployment method that fits the chosen infrastructure. The step closes when the record is approved and the infrastructure owner confirms it matches the data map.
Design identity, SSO and directory sync
The team defines how users sign in, how groups are created from the directory, and how leavers lose access. This phase decides which login methods apply, whether MFA is enforced by the identity provider or by the vault, and which SSO and provisioning features need a paid edition, which the vendor documentation should confirm. The output is an identity design document with a group model and an offboarding flow. The step closes when a test group of accounts signs in and loses access through the agreed path.
Validate client-side encryption and metadata settings
Before any credential is stored, the team confirms how the chosen product encrypts data and which fields the server can read. For Passbolt, this means checking the encryption model, the v5 format, and whether metadata encryption is enabled for the organization. For Bitwarden, it means checking which vault items are encrypted and what the server still records. An administrator then runs test items through the client and inspects what the database holds. The output is a short validation report that lists what the server can and cannot see, and the step closes when the report is accepted by the security lead.
Import under export and policy controls
The team moves existing entries from the current tool using the importers the product supports, after first setting export and password policies. Passbolt has disabled cleartext CSV exports by default since version 5.10, and administrators should keep that default unless a documented need exists. Imported data is checked by sampling records against the source, and the source export file is deleted from working locations under a recorded procedure. The output is an import log with counts, exceptions and the deletion record. The step closes when the sample check passes and the log is filed.
Run a pilot with a defined group
A small group of users, including at least one administrator and one owner of shared accounts, uses the vault for real work for a set period agreed in advance. The pilot tests sharing, recovery requests, browser extension and mobile clients, and the restore of one backup into a separate environment. Support contacts and escalation routes are exercised during the pilot. The output is a pilot report listing defects, workarounds and decisions for the rollout. The step closes when the report is approved and the open defects are either fixed or accepted by the owner.
Migrate users and decommission the previous tool
Remaining users are moved in waves, with the previous tool kept read-only until the final cutover. Shared accounts have their passwords rotated after the move where the old tool held the only copy, and the old vault is exported or retired under the decommissioning record. Access to the previous tool and its backups is removed on a set date. The output is a decommissioning record that lists retired accounts, rotated credentials and where the old exports and backups are now held. The step closes when the old system no longer grants access and the record is signed.
Hand over runbooks, restores and support terms
The team hands the platform to the operations owner with runbooks for upgrades, backup and restore, incident response and user offboarding. A restore is tested again on the production configuration, and the support contract is checked against the data map, including who can access the environment during support and where logs are held. The output is a handover pack with the hosting decision record, validation report, restore test result and contact list. The step closes when the operations owner accepts the pack in writing and the support terms match the transfer assessment.
Hosting patterns that keep credentials inside EU control
The hosting pattern decides who can reach the server, the database and the backups, and that decides whether credentials stay inside EU control. The cards below cover the common patterns and the support access questions that most often undo them.
EU cloud account run by the organization
The organization deploys the vault into its own cloud subscription in an EU region, with its own identity provider, network controls and key management. Choose the region for the database, the backups and any logs, because each one can hold metadata. Confirm that the cloud provider's own staff access and any support tickets stay within the terms you negotiated, and that snapshots are not replicated outside the EEA by default.
On-premises or EU data center install
A Passbolt or Bitwarden server runs on hardware the organization owns or rents in an EU facility, with no dependency on a vendor-hosted control plane. This pattern gives the clearest answer to where ciphertext and metadata live. Check the physical access list, the out-of-band update path and how the server reaches the internet for licensing or updates, because each outbound path is a data flow to document.
Kubernetes with official Helm charts
Passbolt publishes a Helm chart in its charts-passbolt repository, and Bitwarden publishes official charts in its helm-charts repository, both under AGPL-3.0. Pin chart and image versions, keep the cluster in an EU region, and confirm that managed Kubernetes control planes, logging sinks and image registries are also in the EU. A chart that works is not the same as a deployment that has been reviewed for data location.
Hosting versus vendor support access
Hosting the vault in the EU does not settle the question if the vendor or a partner can view data during troubleshooting. EDPB Guidelines 05/2021 treat remote access from a third country, even only displaying data on a screen for support, as a transfer. Require a written support access procedure that names who connects, from where, for which ticket, with the customer approving each session and every session recorded in the customer's own logs.
Support sessions restricted and logged
Put support access behind the organization's own jump host or privileged access tooling, with time-limited accounts, MFA and a session recording kept in EU storage. Ask the vendor to confirm which personnel locations can view screens or database extracts. Store the approval record with the ticket so an auditor can match each session to a business reason and an end time.
Backups and restore location
Backups hold the same ciphertext and metadata as the live database, so they fall under the same location rules. Keep backup copies, offsite replicas and restore test environments in EU storage, and confirm that the restore procedure does not require a support engineer outside the EEA. Test a restore into an EU environment at least once to confirm the path works.
Evidence EU regulators and auditors ask for from the vault
This table lists the records a regulator or auditor is likely to ask for about a self-hosted vault holding EU personal data, and which component or party produces each one. Read it as a preparation checklist: DeployOpen prepares this evidence, but independent auditors and certification bodies issue any audit reports or certifications.
| Evidence item | What it shows | Component or party that produces it |
|---|---|---|
| Transfer impact records | Whether any third-country access to vault data is possible and what supplementary measures apply | Controller legal and privacy team, informed by vendor and hosting documentation |
| Data map for the vault | Which personal data sits in vault fields, metadata, logs and backups, and where each copy lives | Controller with DeployOpen input from the deployed configuration |
| Processor and sub-processor contracts | Who processes data for the support vendor, which sub-processors exist and where they operate | Contracts agreed with the support provider and any hosting provider |
| Hosting location records | Physical and cloud regions for the Passbolt or Bitwarden server, database, backups and mail relays | Infrastructure team and DeployOpen deployment documentation |
| Admin and access logs | Who administered the vault, who accessed shared resources and when, with exports to the SIEM | Passbolt Pro syslog activity logs; Bitwarden event logs on the self-hosted server, confirmed per edition |
| Backup and restore test records | That encrypted backups stay in the EU and that a restore has been tested with dated results | Backup tooling run by the operator, with DeployOpen runbooks and test reports |
| Key recovery procedures | How a user regains access after losing their key, and who can approve recovery | Passbolt account recovery (Pro) or Bitwarden account recovery policy, documented by the controller |
| Vendor and licensing records | Which edition and license are in use, and that paid features are covered for production | Bitwarden license file tied to the installation ID; Passbolt subscription records |
What EU buyers ask before a self-hosted vault goes live
How much does a self-hosted password manager cost compared with Passbolt Pro?
The software cost depends on the edition, and the largest costs are usually people and infrastructure. Passbolt's Community Edition is free to self-host with unlimited users, while Pro is listed at $4.9 per user per month billed annually with a 10-user minimum, according to Passbolt's published pricing. Enterprise pricing is custom. Recurring costs include the subscription, server and backup hosting, and the staff who patch and monitor the system. One-time costs include the implementation, migration and training. Ask any vendor or partner for a quote that separates these items and states which features need a paid edition, such as LDAP provisioning, account recovery, SSO and SCIM.
Does Bitwarden self-hosting need a paid subscription?
Yes, for business production use with paid features. Bitwarden's server code under the Bitwarden License, which includes the Commercial.Core and SSO modules, requires a paid subscription for production use, according to Bitwarden's license FAQ. Paid features need a license file downloaded from the cloud admin console and tied to your installation ID, and that cloud organization's data region must match the self-hosted installation. The self-hosted release itself is free to download, but you should confirm with Bitwarden exactly which features your team needs and what subscription that requires before you commit to a design.
How long does a self-hosted password manager rollout take?
The duration depends on the number of users, the directory and SSO integration, and how much of the existing password data must be migrated. No standard timeline applies to every organization. Plan for separate phases: hosting build, HTTPS and backup setup, identity integration, pilot migration, and staged rollout to browsers and mobile apps. Bitwarden notes that attachments, member invitations, enterprise policies and SSO must be redone when moving from cloud to self-hosted, so that work adds time. Ask any implementation partner for a fixed-scope schedule with named milestones before work starts.
What must our organization supply before a vault project starts?
The project depends on decisions and access that only your organization can provide. You will need an owner for data classification and sharing rules, an identity provider or directory such as Active Directory, OpenLDAP or an SSO service, and a hosting environment with the right region, network access, TLS certificates and backup storage. You also need a list of existing password sources to import and named staff to approve folder and group design, recovery procedures and offboarding rules. Confirm these items in the statement of work so that delays in your environment are not treated as scope changes.
Can our own IT team run the vault after go-live?
Yes, if the team has the skills and time to operate it. Passbolt supports installation on several Linux distributions, Docker, a Kubernetes Helm chart and Ansible, and Bitwarden publishes Docker-based self-hosting and official Helm charts. Operating the vault means applying updates, watching the database size and storage, testing restores, managing certificates and handling user lifecycle work. Bitwarden's Linux guide also requires Docker Engine 26 or later and ships an MSSQL Express image with a 10 GB database limit. Decide whether your team will own these tasks or buy a retainer for upgrades, backup testing and support.
Is switching to another provider protected under the EU Data Act?
Yes, the Data Act gives customers of data processing services a right to switch, and the switching-charge ban applies from 12 January 2027. Under the Act, which has applied since 12 September 2025, customers may switch to another provider or to on-premises ICT infrastructure, with a maximum two-month notice period and a 30-day transition, according to Articles 25, 29 and 50 of Regulation (EU) 2023/2854. Switching charges are banned from 12 January 2027. Whether a self-hosted password manager or a support contract falls within the Act's definition of a data processing service depends on the specific contract, so have counsel confirm it with your supplier.
What should a contract for vault support say about data location?
The contract should name where the vault data is stored, who can access it, and what happens when a support engineer needs remote access. The EDPB Guidelines 05/2021 state that remote access from a third country, even only displaying data on screen, is a transfer under GDPR Chapter V. Ask the supplier to commit to remote-access locations, subprocessors, support staff nationality where relevant, and notice before any change. Also confirm backup location, incident notification terms and deletion on exit. Have legal review these terms against your transfer assessment before signing.
Does DeployOpen run the password manager inside our infrastructure?
DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including cloud accounts, data centers and air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support and upgrades are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications.
Contract and support questions to ask an implementation partner
Start with the people who can reach the vault, because support access is where data sovereignty most often leaks. Ask the partner in writing where its engineers and support staff sit when they log in to your environment, which tools they use for remote sessions, and whether any remote view of your systems, screens or logs occurs from outside the EEA. The EDPB guidelines treat even displaying data on a screen from a third country as a transfer, so a support session that looks harmless can count. Ask for the list of named roles with production access and a commitment to notify you before that list changes. Request a written answer on whether follow-the-sun support is delivered from outside the EEA, and ask who approves exceptions.
Next, ask for the sub-processor list with the location of each entity and the processing it performs, including hosting, backup storage, email delivery and ticketing systems that may receive credential-related metadata. Ask which law governs the support contract, which jurisdiction hears disputes, and whether the partner or any sub-processor is subject to third-country laws with extraterritorial reach such as the US CLOUD Act. Ask how the partner will respond to a third-country authority request: whether it commits to challenge the request, to notify you where legally allowed, and to disclose the minimum necessary data. Confirm these terms with counsel, because the answer shapes the transfer assessment you must document.
Finally, confirm key and backup custody and exit terms. Ask who holds the server secrets, the database and the encryption keys for any backup, and whether the partner can ever read a vault's contents. For paid Passbolt or Bitwarden features, ask the partner to show the license or subscription that covers each feature in production and the installation ID it is bound to. Ask for the data return format, such as encrypted KDBX export, the time allowed to return data after termination, and confirmation that backups and copies are deleted with a certificate of deletion. The Data Act sets switching rights for data processing services, so confirm with your legal team whether those rights apply to the partner's contract.
Primary sources for EU vault decisions
Where does the GDPR say a credential vault hosted outside the EU becomes a transfer?
Article 44 of the GDPR applies to every transfer of personal data to a third country, including onward transfers, so a vault that holds personal data and is hosted or administered from outside the EEA falls under Chapter V. Read the GDPR text on EUR-Lex for the article itself. Credential records often contain employee names, email addresses and account identifiers, which is personal data even when the passwords are encrypted. Confirm with your data protection officer which vault fields are personal data in your setup.
What do the EDPB Guidelines 05/2021 treat as a transfer for remote support?
The EDPB Guidelines 05/2021 (version 2.0) state that remote access from a third country is a transfer, even when the person only displays data on a screen for support or administration. They also say that storage in a cloud outside the EEA is a transfer. Support engineers who log in to your vault from outside the EEA therefore need to be part of your transfer assessment. Read the EDPB Guidelines 05/2021 and ask every support vendor where its staff access customer systems from.
Does an EU processor under non-EU law create a transfer risk for a vault?
The EDPB Guidelines 05/2021 (Example 12) say that using an EU processor subject to third-country law with extraterritorial effect is not itself a transfer. Complying with a request from a third-country authority would be a transfer, so controllers should assess that exposure before they engage the processor. For a password vault, this means asking whether the vendor or its parent can be compelled to disclose data it holds. The EDPB Recommendations 01/2020 explain how to assess supplementary measures when the provider needs data in the clear. Where the vault stores only ciphertext, the answer depends on whether the server holds keys or metadata that identify people and systems.
What do the EDPB Recommendations 01/2020 say about cloud access to data in the clear?
The EDPB Recommendations 01/2020 state that when a cloud provider needs access to data in the clear, and the destination's public authority powers go beyond what is necessary and proportionate, the EDPB cannot envision an effective technical supplementary measure. A self-hosted vault changes this picture because your organization controls the server and the database. Passbolt and Bitwarden both state that the server stores ciphertext, but metadata such as names and URLs may be visible depending on the edition and configuration. Use the EDPB Recommendations 01/2020 to structure the question for each vendor: what the server can read, and who else can reach the database.
What does the EU Data Act require about switching providers and government access?
The Data Act, applicable since 12 September 2025, gives customers the right to switch from a data processing service to another provider or to on-premises ICT infrastructure, with a maximum two-month notice period and a 30-day transition. It bans switching charges from 12 January 2027, and Article 32 requires providers to take measures against third-country governmental access to non-personal data held in the Union where it conflicts with Union or national law. Read the Data Act on EUR-Lex and ask any hosted vault provider how these switching terms appear in its contract. Your exit plan should still include a tested export.
Which Passbolt pages should an engineer read before hosting it in our own data center?
Start with the Passbolt API server repository, which is licensed under AGPL-3.0, along with the Docker and Helm chart repositories. The Passbolt hosting install guide lists supported operating systems, Docker, a Kubernetes Helm chart, an AWS AMI and Ansible, and a virtual appliance for Pro only. Read the how Passbolt secures your data page to confirm what the server receives and which metadata is encrypted. Check the Passbolt pricing page for which features, such as LDAP provisioning, account recovery and SSO, need the Pro edition.
What should we check in the Bitwarden license terms before self-hosting?
Bitwarden's server code is AGPL 3.0, but files in the bitwarden_license directory, including Commercial.Core and SSO integration modules, fall under the Bitwarden License, which is source-available and not open source under the OSI definition. The Bitwarden server license FAQ states that production use of that code requires a paid subscription. Paid features also need a license file tied to your installation ID and data region, which you download from the cloud web app. Ask your Bitwarden contact to confirm which features your edition requires and how the license is renewed.
How do we move a Bitwarden cloud organization to a self-hosted server?
Bitwarden documents a migration in which the organization exports its data, downloads its license, creates a self-hosted account with the same email and imports the data. The Bitwarden migration guide notes that attachments, member invitations, enterprise policies and SSO must be redone after import. The licensing help page explains the installation ID and region match needed for paid features. Plan the cutover as a project with a freeze window, test the import on a copy, and confirm with the vendor what the data region means for your organization before you export anything.
How DeployOpen scopes and runs an EU-hosted password manager
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For an EU-hosted password manager, we start by agreeing in writing where the server, its database and its backups will run, and what the vendor and support contract can and cannot change.
How we scope
- Written scope names the hosting location, cloud accounts or data centers, and every region where backups and logs are stored.
- We map which fields the server can see in your chosen edition, including whether metadata encryption is enabled.
- We confirm which features need a paid edition, such as SSO, SCIM, account recovery and MFA policies, before work starts.
- Scope records who can administer the vault, who holds the server keys, and which support contracts apply.
How we build
- We install the chosen platform, such as Passbolt or self-hosted Bitwarden, on EU-controlled servers, containers or Kubernetes.
- We configure HTTPS, database access, backup encryption and network restrictions to match the agreed data residency design.
- We test import from your current tool, directory sync, and browser extension deployment against the written acceptance criteria.
- We test the vault against the security controls in scope, including access restrictions and audit log export.
How we hand over
- Handover documents cover hosting topology, data flows, key and backup locations, and the administrator runbook.
- We deliver a register of third-country access paths, such as remote support sessions or vendor telemetry, for your legal and privacy review.
- Operators are trained on user onboarding, offboarding, export policy settings and restore procedures before go-live.
- Restore from backup is demonstrated in the agreed environment so your team can repeat it without us.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped to your release and patch policy.
- We can prepare systems and evidence for compliance assessments, but independent auditors issue any audit reports or certifications.
- Before buying vendor support, confirm the support tier, the data location of any support access, and the upgrade commitments in writing.
