Data sovereignty and password management: Keeping credentials where they belong

Illustration of a house with a built-in data server room, connected by a glowing line to a lock icon and a key icon, symbolizing data sovereignty and password management.

Data sovereignty is the ability to determine, physically, legally, and cryptographically, who can access a piece of data and under which jurisdiction. A company can be fully GDPR-compliant on paper and still have no real control over where its passwords live. For corporate credentials, that gap between "compliant" and "in control" is where breaches, subpoenas, and failed audits start.

The General Data Protection Regulation (GDPR) sets the baseline most organizations use to judge their data practices: it governs how personal data is collected, stored, and transferred, and under Article 3 its territorial scope extends to any company processing EU residents' data, regardless of where that company is headquartered.

Passwords and secrets are not ordinary data, which is why password management needs its own sovereignty model, separate from general file storage. They open access to everything else, they move between employees constantly, and they rarely pass through the data loss prevention (DLP) or classification tools that watch over contracts and customer records. A credential stored on the wrong server, in the wrong country, under someone else's encryption keys, is a liability that most compliance checklists don't catch.

This article breaks down what sovereignty actually means at three levels: physical location, encryption, and access governance. It compares on-premise, air-gapped, and EU cloud models, and shows where a self-hosted, zero-knowledge password manager like Passwork fits into that decision.

Key takeaways

Sovereignty requires three controls: location, encryption, and access governance. A gap in one breaks the others.
Credentials need their own security model. They're high-value, move constantly, and slip past standard DLP tools.
GDPR compliance doesn't address who holds the encryption keys. A compliant vendor can still access customer data through subprocessors or legal requests.
Zero-knowledge architecture determines whether cloud encryption actually protects you. If the vendor holds the keys, server location matters less.
On-premise and air-gapped deployment maximize control but add operational load. Patching, backups, and uptime become your team's responsibility.
EU cloud hosting closes the sovereignty gap only with client-side encryption. Residency covers jurisdiction; encryption covers who holds the keys.
Vendor sovereignty claims need third-party verification. ISO/IEC 27001, NIS2 readiness, and public penetration testing give procurement a starting point.
Deployment choice depends on four factors: air-gap needs, EU hosting requirements, team size, and self-hosting policy. Different workflows can use different models.

What data sovereignty actually means for credentials

Data sovereignty is the combination of three separate controls: where data physically sits, who holds the encryption keys, and who governs access to it. Losing any one of the three breaks sovereignty, even if the other two are solid. Most vendors advertise only the first.

Physical location answers where the servers are. A password manager hosted in Frankfurt still falls under GDPR's territorial scope, but so does one hosted in Virginia if it processes EU residents' data. Location matters for jurisdiction, not automatically for legal exposure.
Encryption control answers who can decrypt the data. If the vendor holds the keys, a government request, an insider, or a breach at the vendor's infrastructure can expose your credentials regardless of server location.
Access governance answers who inside your organization can see what. Role-based access control (RBAC) and audit logs determine whether a departing employee's access is revoked in minutes or discovered six months later.

True data sovereignty requires all three elements. Omitting any component reduces the architecture to a formal compliance checklist.

Why credentials are a distinct data class

Credentials deserve separate handling because they are high-value, high-circulation, and largely invisible to standard data governance tools. A leaked customer record exposes one dataset. A leaked admin password exposes every system that admin can reach, and it keeps working until someone rotates it.

Verizon's 2026 Data Breach Investigations Report found stolen credentials accounted for 13% of initial access vectors, but that figure tripled (39%) across the full breach progression. Passwords also move constantly: shared during onboarding, copied into tickets, pasted into chat threads, forwarded when a project changes hands. DLP tools built to catch document exfiltration rarely flag a password dropped into a Slack message.

That combination of high impact and low visibility is why credential storage needs its own sovereignty model instead of inheriting whatever policy covers general file storage.

Dive deeper into the numbers

For a full breakdown of the Verizon 2026 DBIR (including breach vectors, ransomware trends, and third-party risk) check out our analysis of the report.

Where standard cloud storage introduces legal friction

Standard cloud password managers introduce legal exposure through subprocessor chains, cross-border data transfers, and vendor staff access, even when the vendor is fully GDPR-compliant. Encryption at rest does not remove these risks if the vendor, not the customer, holds the decryption keys.

Three specific friction points show up repeatedly during procurement reviews:

Subprocessors. Most cloud vendors rely on subcontracted infrastructure, monitoring, or support providers. Each subprocessor is a separate entity with its own access surface. GDPR Article 28(2) requires that the processor shall not engage another processor (subprocessor) without prior specific or general written authorisation of the controller.
Third-country transfers. GDPR Chapter V governs transfers of personal data outside the EU/EEA. Article 44 sets the general principle that any transfer must not undermine the level of protection guaranteed by the regulation, and Article 46 requires appropriate safeguards, such as Standard Contractual Clauses, when no adequacy decision applies. Credential vaults hosted in a third country, or replicated to one for backup purposes, fall squarely under this chapter.
Vendor staff access and legal requests. If the vendor can technically decrypt customer data, that data is subject to legal process in the vendor's jurisdiction. A subpoena, warrant, or foreign disclosure order can compel access regardless of where your company is registered.

NIS2 adds a fourth angle: Article 21(2)(d) requires essential and important entities to assess supply chain security, including the vendors and tools they use to manage access credentials. A password vault sitting with a third-party subprocessor you haven't vetted falls squarely into that requirement.

None of this makes cloud storage non-compliant by default. It means "GDPR-compliant" is a necessary condition for credential sovereignty.

Case in point: Jurisdictional exposure

A cloud password manager hosted in US data centers is subject to American legislation. Under the CLOUD Act, US law enforcement agencies can compel service providers to hand over customer data. Furthermore, FISA Section 702 permits intelligence agencies to request data from US-based service providers. If the vendor controls the decryption keys, they must comply with these federal orders. The customer’s EU registration or internal security policies cannot override this legal obligation.

Mapping the three layers to deployment models

A gap in any single layer reopens the exposure the other two were meant to close. The table below applies the three controls from the first section, location, decryption, and access, to the models organizations actually choose between.

Layer	On-premise	Air-gapped	EU cloud region
Where data sits	Customer's own infrastructure	Isolated network, no internet path	Vendor's EU-based data center
Who can decrypt	Customer only, zero-knowledge architecture	Customer only, zero-knowledge architecture, no external connectivity	Depends on encryption model; secure only with client-side encryption
Who governs access	Customer's RBAC and audit logs	Customer's RBAC, manually maintained	Customer's RBAC, vendor manages infrastructure layer

Air-gapped describes infrastructure with no network path to the internet at all, the strictest form of physical isolation.
Zero-knowledge means the vendor can never read your data, under any circumstances.
Client-side encryption is the mechanism that produces that guarantee: encryption and decryption happen on the user's device, using a master password the vendor never receives or stores, so the server only ever holds and transmits ciphertext.

A poorly implemented client-side encryption scheme, one with a recoverable master password or a weak key derivation function, doesn't automatically deliver a true zero-knowledge guarantee. This distinction determines whether "encrypted in the cloud" actually means anything for sovereignty.

On-premise and air-gapped: Complete isolation, at the cost of operational load

On-premise deployment gives an organization complete physical and cryptographic control over its credential vault, because the data never leaves infrastructure the organization owns and administers. Air-gapping takes this a step further: the infrastructure has no network path to the internet at all, which is the only setup that removes external network dependency entirely.

Isolation from the provider: zero-knowledge encryption

Passwork runs entirely inside the corporate perimeter, on infrastructure the organization controls end to end. The password and secrets manager encrypts and decrypts data entirely on the client side, using a key derived from the user's master password. The server never receives or stores plaintext at any point, it holds only encrypted blobs and has no key capable of decrypting them. For organizations with air-gap requirements and strict segmentation policies, this is often the only architecture that satisfies internal security policy.

A claim like that shouldn't be taken on faith. Passwork's source code is open for the organization's own security team to audit directly, line by line, instead of relying on the vendor's description of how encryption is implemented.

The operational trade-off

That level of isolation comes with a bill, paid in operational effort. On-premise shifts server maintenance, patching, backup management, and uptime responsibility from the vendor to your own IT team. Someone has to apply updates, monitor disk space, manage TLS certificates, and handle disaster recovery. For a small IT team already stretched across other priorities, that's a real cost. Organizations choosing self-hosting need either a dedicated sysadmin resource or a managed internal process for keeping the deployment current.

Passwork's zero-knowledge encryption keeps your data unreadable to anyone but your own users. Review the architecture in the user guides before committing infrastructure, or test the full deployment free to see it running on your own servers.

EU cloud hosting: Viable, but only with client-side encryption

EU cloud hosting can satisfy jurisdictional requirements for smaller teams without dedicated infrastructure staff, but only if the vendor implements mandatory client-side encryption (CSE). Without CSE, an EU-hosted vault still leaves the vendor capable of decrypting customer data, which reopens the same exposure that hosting in the EU was supposed to close.

Under a proper CSE model, the master password never leaves the user's device, and the vendor's servers process and store only ciphertext. Even with full physical access to the server, the vendor cannot read the vault's contents. This is a meaningfully different guarantee than "our data centers are in the EU," which addresses jurisdiction but says nothing about who holds the keys.

EU cloud hosting with CSE narrows legal exposure and satisfies data residency requirements for many compliance frameworks, but it isn't the same guarantee as full on-premise sovereignty. The infrastructure, network layer, and physical hardware remain outside the customer's direct control. For organizations with air-gap mandates or strict self-hosting policies, EU cloud is not a substitute, regardless of encryption strength.

On-premise without zero-knowledge still trusts local admins with plaintext access. EU cloud without it still trusts the vendor's infrastructure staff. Either way, the guarantee only holds when the master password never leaves the user's device.

Verifying vendor claims: What procurement should check

Sovereignty claims are only as credible as the third-party evidence behind them. This check applies regardless of which deployment model you choose: a certificate doesn't tell you where data sits, but it does tell you whether a vendor's other claims hold up. Procurement teams should base a self-hosting decision on internal admin capacity and policy requirements, then validate the shortlisted vendor through independent certification, own audit, and public security testing.

Four checks matter in practice:

ISO/IEC 27001 certification confirms an information security management system has been independently audited against the international standard. Passwork holds ISO/IEC 27001:2022 certification, issued by MSECB and verifiable through the IAF CertSearch database.
NIS2 and GDPR readiness matters for any organization that falls under either regulation's scope. NIS2 Article 21's supply chain requirements extend to the tools essential and important entities use to manage access credentials, while GDPR Article 32 requires "appropriate technical and organisational measures," including encryption, for any system handling personal data. Organizations evaluating vendors against these requirements can review Passwork's approach to NIS2 compliance as one reference point.
Source code audit rights confirm that a zero-knowledge claim is actually true rather than marketing language. In a genuine zero-knowledge design, the vendor cannot recover an individual user's master password under any circumstance, not through a backend reset, not through a support ticket, not under legal pressure. If a user forgets it, the data behind it is gone by design, because the vendor never held the key in the first place. Passwork opens its source code to customers' own security teams for exactly this reason: it's the way to confirm the encryption implementation matches the architecture the vendor describes.
Public penetration testing provides evidence beyond self-reported security posture. Passwork has completed an independent penetration test through HackerOne, covering secure data handling, the OWASP Top 10 and SANS Top 25, authentication, and API access control.

Choosing a deployment model: A decision framework

The right deployment model depends on five practical factors:

Air-gap requirements
Mandatory EU hosting
Admin team size
Internal self-hosting policy
Infrastructure control requirements

Matching these factors against deployment options avoids the common mistake of choosing based on price or brand recognition alone. Use this credential residency decision matrix to map organizational constraints to a deployment model:

Requirement	Recommended model
Air-gap mandate (ICS, classified environments)	On-premise, fully isolated network
Mandatory EU data residency, no air-gap requirement	On-premise or EU cloud with client-side encryption (choice depends on infrastructure control requirements)
Small IT/admin team, limited infrastructure capacity	EU cloud with client-side encryption
Strict internal self-hosting policy (regulatory or contractual)	On-premise, customer-managed infrastructure

None of these rows are mutually exclusive in practice. A financial institution might run on-premise for its core vault while accepting cloud-based tools for lower-sensitivity workflows. The matrix is a starting point for the conversation with security and compliance stakeholders.

How Passwork's architecture maps to these layers

Passwork's self-hosted deployment addresses the sovereignty gap described throughout this article by combining physical isolation, zero-knowledge encryption, and customer-controlled access governance in one architecture. The vault deploys on infrastructure the customer owns, whether that's a single Linux server, a Windows Server environment, or a Docker container inside an air-gapped network.

Encryption uses AES-256 with a zero-knowledge design, meaning the infrastructure, if it were ever compromised, holds only ciphertext. Access is governed through role-based permissions and a full audit log, so administrators can see who accessed which credential and when, and revoke access immediately when someone changes roles or leaves. Integration with AD/LDAP and SAML SSO lets access governance plug into existing identity infrastructure rather than running as a separate silo.

This is deliberately not a claim that self-hosting is right for everyone. Organizations without air-gap requirements or strict self-hosting mandates may find a cloud option with proper client-side encryption sufficient. The point is that when full sovereignty is the requirement, the architecture needs to support it structurally.

Data sovereignty in password management: How to apply it to your evaluation

Sovereignty is an ongoing alignment between where data sits, who holds the keys, and who governs access, and that alignment needs revisiting whenever your infrastructure, vendor contracts, or regulatory scope changes.

Start by mapping your own organization against the four factors in the decision matrix: air-gap requirement, mandatory EU hosting, admin team size, and internal self-hosting policy. That mapping will tell you more about the right deployment model than any vendor's marketing page.

The only way to confirm a self-hosted architecture fits your infrastructure is to run it there. Passwork offers a free trial you can deploy on your own servers, with full functionality and no data ever leaving your environment.

Frequently Asked Questions

What is data sovereignty in the context of password management?

Data sovereignty in password management means the organization, not a third-party vendor, controls where credential data physically resides, who holds the encryption keys, and who can access it. GDPR compliance alone does not guarantee sovereignty if the vendor can technically decrypt the data or is subject to a foreign jurisdiction's legal requests.

Is GDPR compliance enough to guarantee credential sovereignty?

No. GDPR compliance addresses broad data processing obligations, and Chapter V specifically governs cross-border transfers, but neither addresses who holds the encryption keys. A GDPR-compliant vendor can still technically decrypt customer data unless the architecture uses zero-knowledge or client-side encryption.

What's the difference between on-premise and air-gapped deployment?

On-premise means the software runs on infrastructure the organization owns, which may still have internet connectivity. Air-gapped means that infrastructure has no network path to the internet at all. Air-gapping is a stricter subset of on-premise, typically required in defense, industrial control, or classified environments.

Does EU cloud hosting satisfy data sovereignty requirements?

EU cloud hosting satisfies jurisdictional and data residency requirements only when combined with client-side encryption, where the vendor never holds decryption keys. Without it, EU hosting addresses location but not who can access the data, which leaves a meaningful sovereignty gap for organizations with strict requirements.

What does zero-knowledge architecture actually protect against?

Zero-knowledge architecture protects against server-side compromise, insider access at the vendor, and legal requests for data, because the server only ever stores encrypted ciphertext. The master password stays on the user's device and is never transmitted to or stored by the vendor's infrastructure.

How does NIS2 affect password manager vendor selection?

NIS2 Article 21(2)(d) requires essential and important entities to manage supply chain security risk, which extends to vendors handling access credentials. Organizations under NIS2 scope should evaluate password manager vendors' certifications and security testing as part of their own compliance obligations.