
Business password managers often advertise AES-256 encryption and servers that never see plaintext passwords. But cipher strength alone does not tell you how much data one compromised key or misplaced group membership can expose.
That exposure depends on the encryption boundary: whether a key unlocks an organization, a vault, a shared folder, or an individual secret. This comparison examines where Passwork, Bitwarden, Passbolt, 1Password, and Keeper draw that boundary, and what their designs mean for permissions, directory login, automation, and deployment.
The question that reveals the encryption boundary
Imagine a self-hosted password manager. A sysadmin responsible for backups has a database dump and joins the corporate organization to access one shared password. What else could they decrypt using the keys available to their account?
Bitwarden encrypts corporate items with per-item keys wrapped by one organization symmetric key, according to its security white paper. Organization members receive usable access to that key, while collections control normal server-delivered access and permissions rather than creating separate cryptographic boundaries. In a self-hosted threat model, an attacker who obtains the relevant database ciphertexts and a member’s usable organization key could decrypt organization items outside that member’s assigned collections.
Passwork, with client-side encryption enabled, uses a separate key for each vault. Item keys sit under vault keys, and users receive a wrapped vault key only for vaults they can access. Under this zero-knowledge encryption model, the same sysadmin can decrypt their assigned vaults, but not unrelated Finance or Infrastructure vaults.
Passbolt encrypts each secret separately for each recipient using OpenPGP, as described in its security documentation (Pro v5.4, August 2025). There is no shared container key. Users can decrypt only secrets encrypted for them, although adding recipients requires more work.
1Password isolates data by vault, where permissions are also defined. Keeper uses record keys and shared-folder keys rather than one organization-wide key. Neither offers a self-hosted vault database for this particular test.
| Aspect | Passwork | Bitwarden | Passbolt | 1Password | Keeper |
|---|---|---|---|---|---|
| Encryption boundary | Vault | Organization | Individual secret | Vault | Shared folder and record |
| Database plus member key unlocks | Assigned vaults | Corporate records under the organization key | Secrets shared with that member | Not applicable: cloud vault | Not applicable: cloud vault |
| Exposure from one compromised member with database access | Assigned vaults | Organization | Assigned secrets | Not directly comparable | Not directly comparable |
Passwork and Passbolt limit what a database dump plus one member's keys can reveal. Bitwarden simplifies key distribution but makes the organization key a broader cryptographic boundary. The cloud-only products avoid this specific database-access scenario, though their key architecture still matters.
Start a free Passwork trial to test how your vault structure limits access after an account compromise.
Vault types: governance above individual vaults
In Passwork, a vault type defines who may create vaults in a class and which administrators are automatically assigned to new vaults of that type. With client-side encryption enabled, those administrators also receive wrapped copies of the new vault keys. The result is a repeatable policy for departments and projects.
For example, a Finance type can automatically assign the CFO to each new finance vault. A DevOps type can keep infrastructure administrators separate from sales. When a department head leaves, the company can reassign the type administrator and review grants within that area instead of auditing a sprawling global admin role. This becomes useful as teams and vault counts grow. See Passwork's vault policies.
Two built-in types avoid corporate administrators. A personal vault belongs to one user. A private shared vault lets that user invite others. By default, even the organization's Owner or Admin cannot read their contents. Administrators can configure who is allowed to create these vault types and share information from them, including disabling unmanaged personal vault creation.
There are two limits: assigning a type does not retroactively grant access to existing vaults, and types form cryptographic boundaries only when client-side encryption is enabled. Otherwise they remain governance rules.
The competitors offer related features, but not the same policy layer. Bitwarden enterprise policies govern matters such as authentication, recovery, and organization membership rather than automatically assigning administrators by vault class. Passbolt has no vault container to classify. 1Password provides vault-level isolation and personal vaults, but no equivalent class-wide rule for newly created vaults. Keeper's shared folders and teams manage access without typed vault creation policies.
| Capability | Passwork | Bitwarden | Passbolt | 1Password | Keeper |
|---|---|---|---|---|---|
| Vault classes with assigned administrators | Yes | No | No | No | No |
| Automatically attach admins to new vaults of a class | Yes | No | No | No | No |
| Control who creates a class | Per type | Partly, via organization policy | No | No | No |
| Personal space without a corporate admin | Personal and private shared vaults | My Items | Per-secret sharing | Personal vault | Personal folder |
| Control sharing from personal vaults by class | Yes | No equivalent | No equivalent | No equivalent | No equivalent |
Vault types reduce the chance that newly created departmental vaults receive inconsistent administration. They add a policy decision upfront, but reduce repeated manual configuration later.
Folder permissions: Inheritance or templates?
A folder tree is useful only if its permissions behave as administrators expect. Similar-looking interfaces can enforce very different rules.
Passwork offers five permission levels—read, write, manage, admin, and forbidden—for users and groups at vault or folder level. Vault access flows into nested folders, while folder rules can narrow access. Admin and forbidden rights cannot be overridden further down. When multiple rules apply, the higher-priority level wins. Importantly, a folder is not a separate encryption boundary: access to its contents still relies on the vault key. This sits alongside Passwork's role-based access control model.
Bitwarden grants permissions through collections. Nested collections are organizational labels; they do not inherit their parent's items or rights. Personal folders have no sharing permissions. Individual member permissions override group permissions.
Passbolt uses folders as permission templates. When an item is created, moved, or shared, the folder's permissions are applied, but the item's own permissions determine subsequent access. A creator can become the owner of a password and restrict access even when someone else owns the folder. In a July 2026 community discussion about extension v5.14.2, Passbolt confirmed this behavior follows its permission model and said a UI change was planned to prevent non-owners editing permissions during creation.
1Password has no permission-bearing folders inside a vault; tags organize items without changing access. Sharing a subset of items permanently therefore requires another vault. Nested identity-provider groups are not supported for vault membership, according to a September 2026 community response.
Keeper supports nested shared folders and record-level permissions. Explicit record assignments override inherited folder rights. Its nested-folder model has a five-level depth limit and was behind a feature flag in vault release 18.0.0.
| Aspect | Passwork | Bitwarden | Passbolt | 1Password | Keeper |
|---|---|---|---|---|---|
| Internal structure | Folder tree | Collections | Permission-template folders | Tags | Nested shared folders |
| Inherited rights | Yes, with restrictions | No | No; permissions applied at creation or move | Not applicable | Yes, five levels, feature flag |
| Permission levels | Read, write, manage, admin, forbidden | View, hidden, edit, manage | Read, update, owner | View, create, edit, archive, delete, manage | Folder and record permissions |
| Individual record sharing | Shortcuts and inbox | Item in multiple collections | Direct item grant | No permanent item-level grant | Yes |
Passwork's tree supports departmental structures and exceptions. Bitwarden and 1Password are simpler to administer but less flexible for deeply nested access. Passbolt's template behavior requires special attention because folder and item permissions can diverge.
Groups: what changes when someone joins?
With Passwork client-side encryption, adding someone to a group does not automatically give them every vault key associated with that group. It creates a pending request for each relevant vault. A key holder must approve the request before the new member can decrypt its contents.
This separates directory provisioning from cryptographic access. LDAP synchronization can place a new employee into groups, but access to sensitive vaults still requires approval. The distinction matters during onboarding and offboarding.
For teams that need less manual approval, Passwork offers another pattern: put the department's data in one vault and organize it into folders. Approve the user's vault key once; folder permissions then determine access within that vault as group membership changes. The trade-off is a wider shared cryptographic boundary than several separate vaults.
Passbolt cannot use this shortcut. Because each secret is encrypted for each recipient, adding a group member requires someone with access to re-encrypt the relevant secrets for that user. Directory synchronization notifies a group manager and waits for this step. The work scales with the number of secrets rather than the number of vaults.
Bitwarden already distributes the organization key to members, so collection assignments do not require new encryption keys. In 1Password, assigned vault keys follow group access. Keeper distributes access through assigned shared folders.
| Aspect | Passwork | Passbolt | Bitwarden | 1Password | Keeper |
|---|---|---|---|---|---|
| Group membership automatically supplies new decryption keys | No; per-vault approval | No; re-encrypt per secret | Organization key already held | Assigned vault keys | Assigned shared-folder keys |
| Directory sync completes access without human intervention | No, for new vault keys | No | Yes | Yes | Yes |
| Main cost of adding a member | Wrapped key per vault | Re-encryption per secret | Membership update | Keys for assigned vaults | Keys for assigned folders |
| Container-level approval | Yes | No | Organization membership | Vault | Shared folder |
The choice is between tighter approval checkpoints and smoother provisioning. Passwork lets organizations choose different balances for different departments; Passbolt provides fine-grained per-secret access at a higher sharing cost.
What domain login actually does
A domain password authenticates a user; it does not decrypt vault data in any of these products. Their differences lie in how directory authentication and provisioning work.
Passwork self-hosted authenticates directly against LDAP or Active Directory, including environments with multiple domain controllers. Users sign in with domain credentials; directory groups can map to Passwork groups. With client-side encryption enabled, the domain password authenticates the session while separate cryptographic keys protect vault contents.
Passwork Cloud did not yet offer LDAP at the time of this comparison; it was on the roadmap, along with SCIM provisioning. Both Passwork deployments support SAML 2.0 SSO.
Bitwarden Directory Connector synchronizes users and groups but does not authenticate them against LDAP, as its documentation explains. Domain-based sign-in requires Enterprise SSO through SAML or OIDC. Users ordinarily still unlock their vault with a master password, unless trusted devices or Key Connector are configured.
Passbolt also separates LDAP synchronization from login. Users authenticate using a private key and passphrase or SSO, and adding synced users to groups with existing secrets requires re-encryption.
1Password and Keeper use cloud-based vault services with SSO integration. Keeper's SSO Connect On-Prem can keep certain identity components on company hardware, but its encrypted vault backend remains in Keeper's cloud. Keeper lists supported local components in its deployment documentation.
| Aspect | Passwork | Bitwarden | Passbolt | 1Password | Keeper |
|---|---|---|---|---|---|
| Direct domain-password login | Self-hosted LDAP/AD | No; SSO | No; key/passphrase or SSO | SSO | SSO |
| Multiple domain controllers | Yes | Sync only | Sync only | Not applicable | AD Bridge |
| Documented SSO protocol | SAML 2.0 | SAML 2.0 or OIDC | OpenID Connect (OIDC) | OpenID Connect (OIDC) | SAML 2.0 |
| SCIM provisioning | Planned | Yes | Yes | Yes | Yes |
| Domain password decrypts records | No | No | No | No | No |
Passwork's direct LDAP login can simplify self-hosted deployments without a separate identity provider. Cloud-first competitors currently offer more mature automated identity provisioning; planned Passwork features should not be treated as available today.
One API for passwords and machine secrets
Passwork manages employee credentials and machine secrets through the same instance, permission model, audit log, and REST API. Teams can support CI/CD workflows without licensing a separate secrets product.
Its web, desktop, browser, and mobile clients use the same API at /api/v1. An official CLI and open-source Python connector support DevOps workflows. The CLI provides get and update for records, api for direct endpoint calls, and exec to retrieve and decrypt a secret, expose values as environment variables, and run a command. Service accounts are users with API tokens created by an administrator. Generating a new personal token revokes the user's previous API sessions.
This unified model has limitations: the API is pull-based, with no outbound webhooks, and /v1/batch supports read aggregation only, up to 25 GET subrequests. Event-driven integrations must poll or consume syslog exports.
Competitors take different approaches. Bitwarden Secrets Manager is a separate paid add-on with machine accounts and project-based access, rather than access through Password Manager collections. Keeper Secrets Manager is another product line with SDKs and a cloud-connected gateway. 1Password service accounts work with defined vaults and permissions, but their scope is fixed when a token is created; changing it requires a new token. Passbolt exposes an API and automation tooling while retaining its per-secret sharing model.
| Aspect | Passwork | Bitwarden | Passbolt | 1Password | Keeper |
|---|---|---|---|---|---|
| Employee and machine secrets | One instance | Password Manager plus Secrets Manager | One product | Vaults plus service accounts | Vault plus Secrets Manager |
| Automation interface | REST API, CLI, Python connector | Management API and Secrets Manager CLI/SDKs | REST API, admin CLI | CLI, SDKs, Connect | SDKs, Commander |
| Machine identity | Service account with token | Project-scoped machine account | User with private key | Fixed-scope service account | Secrets Manager application |
| Main limitation | No webhooks; read-only batch | Separate secrets subscription | Per-secret sharing overhead | Token scope immutable | Separate secrets product |
Passwork favors a single operational system for people and automation. Specialized secrets products can offer dedicated integrations, but introduce additional licensing and management surfaces.
Where the vault runs
Deployment can eliminate products from a shortlist before any feature comparison. Passwork, Bitwarden, and Passbolt allow organizations to host the vault itself. 1Password and Keeper keep the vault backend in their cloud services.
Passwork supports on-premise deployment on Linux, Windows Server, or Docker, giving organizations control over their infrastructure and backups. Its EU-hosted cloud offering uses a separate database and tenant for each customer, rather than storing all customers' records in one shared schema. These options are discussed in Passwork's deployment models guide.
Bitwarden also offers genuine self-hosting, although its Enterprise license remains tied to an active cloud subscription. Passbolt supports self-hosting and a hosted service. Keeper's locally deployable SSO and integration components do not change the location of its vault backend.
| Aspect | Passwork | Bitwarden | Passbolt | 1Password | Keeper |
|---|---|---|---|---|---|
| Self-hosted vault | Yes | Yes | Yes | No | No |
| Vendor cloud | EU | Yes | Yes | Yes | Yes |
| Cloud tenant model | Separate database per tenant | Multi-tenant | Dedicated per subscription | Multi-tenant | Multi-tenant |
Self-hosting gives organizations control over data location but also responsibility for updates, backups, and availability. Cloud-only products reduce that workload where policy permits external hosting.
Optional client-side encryption and metadata
Passwork Cloud always uses client-side encryption. Self-hosted Passwork lets administrators disable it. The other four products in this comparison do not offer an equivalent switch.
Server-side encryption can suit a small team with trusted administrators that prioritizes immediate access grants and simpler recovery. Disabling client-side encryption removes per-vault cryptographic isolation: vault types still control creation and administration, but no longer form separate encryption boundaries.
Even when client-side encryption is enabled, Passwork's server can read item names, logins, descriptions, and URLs to support server-side search. Password values remain encrypted on the client and outside the search index. Bitwarden and Keeper encrypt these metadata fields too, keeping them hidden from the server at the cost of client-side decryption for search. Passbolt v5 leaves folder names and tags unencrypted.
| Aspect | Passwork | Bitwarden | Passbolt | 1Password | Keeper |
|---|---|---|---|---|---|
| Disable client-side encryption | Self-hosted only | No | No | No | No |
| Metadata visible to server with client-side encryption | Name, login, description, URL | None of these fields | Folder names and tags | None of these fields | None of these fields |
| Search | Server | Client | Client | Client | Client |
This is a real security and usability trade-off. Buyers should evaluate both password confidentiality and metadata exposure, especially when records contain sensitive system names or account identifiers.
What it costs
These are published list prices per user per month on annual billing, as of October 2026. Vendors use different currencies and packaging, so the comparison is directional.
Passwork Standard costs €3 and Advanced €4.50 per user per month. Advanced includes secrets management and enterprise identity features. Self-hosted customers can also choose a one-time lifetime license. Bitwarden Teams costs $4 and Enterprise $6, with Secrets Manager priced separately at $6 and $12, respectively. Keeper Business starts at $4 and Enterprise at $6, while KeeperPAM is priced separately. 1Password Business costs $8.99. Passbolt Pro self-hosted costs €4.50 with a ten-user minimum.
| Product | Price/user/month | Relevant condition |
|---|---|---|
| Passwork Standard | €3 | Cloud or self-hosted |
| Passwork Advanced | €4.50 | SSO, LDAP mapping, secrets, clustering; self-hosted lifetime option |
| Bitwarden Teams | $4 | Password Manager |
| Bitwarden Enterprise | $6 | SSO, policies, self-hosting; Secrets Manager extra |
| Keeper Business | €4 | Some reporting and monitoring require higher tier |
| Keeper Enterprise | €6 | PAM sold separately |
| 1Password Business | $8.99 | Cloud vault |
| Passbolt Pro | €4.50 | Self-hosted; ten-user minimum |
Bitwarden Secrets Manager costs $6 per user per month on Teams or $12 on Enterprise, billed separately from Password Manager. Organizations using both products should compare combined licensing costs based on the number of users in each. Passwork Advanced includes password and secrets management in one subscription. Passbolt's per-secret encryption model adds administrative work when sharing secrets or adding group members, a cost that subscription prices alone cannot capture.
Where competitors have the advantage
Passbolt provides direct per-secret sharing and revocation. Each recipient gets a ciphertext encrypted with their public key. Revocation removes that recipient's encrypted copy from the service. This supports fine-grained control, but every additional recipient requires encryption and storage work. As with other password managers, revocation cannot erase plaintext or copies a recipient previously saved.
Passwork stores one shared ciphertext and distributes wrapped keys rather than duplicating every secret for each recipient. Removing a permanent vault or folder grant removes the relevant key access. Its inbox works differently: a direct user handoff wraps an item's key for the recipient, and an accepted item becomes a copy in the recipient's vault. Group inbox delivery uses a non-client-side-encryption path. Inbox is therefore a transfer, not a permanently revocable grant.
| Aspect | Passwork | Passbolt |
|---|---|---|
| Data stored per recipient | One shared ciphertext, wrapped keys | Ciphertext per recipient |
| Share | Wrap a key | Re-encrypt the secret |
| Revoke ongoing access | Remove wrapped-key access | Remove recipient's ciphertext copy |
| One-off handoff | Inbox creates recipient-owned copy on acceptance | Direct item sharing |
Bitwarden and Keeper protect metadata that Passwork exposes for server-side search. Keeper also offers record shortcuts and direct per-record permissions in shared folders, plus a broader privileged-access platform. 1Password has fewer inheritance rules and exceptions, making it easier to configure for teams that do not need complex folder permissions. Bitwarden combines low entry pricing, self-hosting, and established clients.
These are substantive advantages. Passwork's flexibility helps organizations with complex access structures, but also creates more policies to design and maintain.
How to choose: Start with the boundary
Begin with the failure scenario, not the encryption algorithm. If an account is compromised, what records can its keys decrypt? What changes if the attacker also obtains a database backup? Then check whether your permission model mirrors departmental boundaries and whether onboarding can accidentally expand access.
Passwork is suited to organizations that need separate departmental vaults, inherited folder permissions, direct LDAP authentication on-premise, and employee and machine credentials in one system. Passbolt favors per-secret control where the administrative cost of sharing is acceptable. Bitwarden offers straightforward organization-wide key distribution and self-hosting. 1Password minimizes configuration complexity in a cloud-first model. Keeper combines shared-folder controls with a wider privileged-access offering.
If Finance, HR, and Infrastructure are separate operational units, decide whether they should also have separate cryptographic boundaries. That decision determines the potential exposure of one compromised key more directly than an AES-256 label.
Test Passwork in your infrastructure and compare what one compromised account could decrypt in each candidate system.
Frequently asked questions
What is an encryption boundary in a password manager?
It is the amount of data accessible with a particular key or set of keys: an organization, vault, shared folder, or individual secret. Key hierarchy and sharing determine that scope.
Does AES-256 guarantee a small blast radius?
No. Cipher strength does not determine how broadly keys are shared. Products using strong encryption can expose different amounts of data when an account or key is compromised.
Can a self-hosted administrator read every password in a database?
That depends on the key design and the administrator's keys. In Bitwarden, an organization member with the organization key and database access can decrypt corporate records. In Passwork with client-side encryption enabled, a member's keys unlock only assigned vaults.
Does LDAP group membership automatically grant vault access?
In Passwork with client-side encryption, new vault keys require approval from a key holder. Other products may provision relevant keys automatically or, in Passbolt, require per-secret re-encryption.
Can one tool manage employee passwords and DevOps secrets?
Yes. Passwork supports both through one instance, REST API, CLI, and permission model. Other products may use separate secrets-management offerings or distinct automation interfaces.
Does a domain password decrypt vault data?
No. It authenticates the user directly against LDAP/AD in self-hosted Passwork or through SSO in other products. Decryption relies on separate cryptographic keys.



Table of contents
- The question that reveals the encryption boundary
- Vault types: governance above individual vaults
- Folder permissions: Inheritance or templates?
- Groups: what changes when someone joins?
- What domain login actually does
- One API for passwords and machine secrets
- Where the vault runs
- Optional client-side encryption and metadata
- What it costs
- Where competitors have the advantage
- How to choose: Start with the boundary
- Frequently asked questions
Table of contents
- The question that reveals the encryption boundary
- Vault types: governance above individual vaults
- Folder permissions: Inheritance or templates?
- Groups: what changes when someone joins?
- What domain login actually does
- One API for passwords and machine secrets
- Where the vault runs
- Optional client-side encryption and metadata
- What it costs
- Where competitors have the advantage
- How to choose: Start with the boundary
- Frequently asked questions
Self-hosted password manager for business
Passwork provides an advantage of effective teamwork with corporate passwords in a totally safe environment. Double encryption and zero-knowledge architecture ensure your passwords never leave your infrastructure.
Learn more


