Password Management
Passwork
EU-Made Report an error0–5 in half steps. 5 means the rubric's top anchor is met on the evidence.
by Passwork Europe S.L. · passwork.pro
Report an error on this page Is this your product? →
Link to this page
Add ?theme=dark to the image address for dark backgrounds.
The badge shows the category and the month of the latest evaluation, and EU-Made where
that is the product’s provenance. It never shows a score.
Passwork at a glance
- Vendor
- Passwork Europe S.L.
- Headquarters
- Not stated on the vendor’s pages as of 13 Oct 2026
- Data hosting
- Not stated on the vendor’s pages as of 13 Oct 2026
- Free plan
- Not stated on the vendor’s pages as of 13 Oct 2026
- Panel verdict
- The AI panel rates Passwork 2/5, the mean of 6 judges. Passwork, a password manager named in the imprint as Passwork Europe S.L. how scores are made
- As of
- Vendor pages captured 13 Oct 2026; evaluated by the panel 15 Oct 2026. all sources
Read this page as one judge. Each weighs the same scores by what they care about.
The panel's verdict
Passwork, a password manager named in the imprint as Passwork Europe S.L. of Barcelona, earns its best marks in sharing and access control: custom roles beside Owner, Administrator and Member, per-recipient read or read-and-edit sends, tracked and revocable access, single-use links that expire three minutes after opening, and emergency recovery via a corporate administrator attached to every vault plus a blocked service account whose master password sits offline. Its published cryptography is candid — AES-256-CBC client-side, AES-256-CFB server-side, RSA-OAEP key wrapping, a per-field table, a threat model — while zero-knowledge covers passwords and secrets, not the searchable name, login and URL fields. Weakest are pricing transparency, with the captured pricing page yielding no per-user rate, tier, seat minimum or term, and sovereignty, where the transparency statement records rights previously held by Passwork FZ-LLC (UAE) until the 2024 acquisition and the captured pages confirm neither hosting location nor subprocessors. Every other criterion sits at 4, except deployment and portability at 4-5; sovereignty is the only criterion spanning more than a point.
Speaks for it
- Sharing and access control scored 5-6: custom roles beside Owner, Administrator and Member, per-recipient read or read-and-edit on sent passwords, tracked revocable access, and single-use links expiring three minutes after opening.
- Emergency recovery is documented — a corporate administrator automatically added to every vault of a type, plus a blocked service account with its master password held in a physically secure offline location.
- The published encryption scope names AES-256-CBC client-side, AES-256-CFB server-side and RSA-OAEP vault-key wrapping, with a threat model covering database leak, server compromise and traffic interception.
- SAML single sign-on is documented in depth for Microsoft Entra ID, AD FS and Keycloak, down to attribute mapping, endpoints and Kerberos/SPNEGO seamless login.
- Self-hosting is a documented edition, with a CLI that injects secrets at runtime and a JSON export that preserves vault and folder structure.
Held against it
- Pricing transparency scored 0-1: the captured pricing page yields no per-user rate, tier contents, seat minimum, term or self-hosted licence price.
- Sovereignty scored 1-3: the captured pages confirm neither where vault data and metadata are hosted nor any subprocessor, and the transparency statement records rights previously held by Passwork FZ-LLC (UAE) until the 2024 acquisition.
- We found no public information on an independent audit with a named auditor and date, on a bug bounty, or on disclosed incident history.
- We found no public information on SCIM or directory sync for joiners and leavers, on how the vault key is released under single sign-on, or on FIDO2 hardware keys and passkeys; the only second factor evidenced is the vendor's own authenticator app.
- We found no public information on enforceable master-password or MFA policies, password-health or breach reports, or audit-log retention; the only retention figure captured is 90 days for IP addresses.
Best for
- You need a self-hosted password manager — the on-premises edition states that passwords never leave your infrastructure — with activity logs routed via syslog or stdout into your own monitoring stack.
- Your team's daily work is governed credential sharing: per-recipient edit rights, expiring external links and a documented emergency-recovery path.
- You want encryption internals published — algorithms, per-field scope, a threat model — as a condition of trust, even absent third-party verification.
- You use Microsoft Entra ID, AD FS or Keycloak and want single sign-on documented down to endpoints, attribute mapping and Kerberos seamless login.
Avoid if
- You must price the purchase before talking to sales — the captured pricing page yields no per-user rate, tier, seat minimum, term or self-hosted licence price.
- You must document where hosted vault data and metadata reside and which subprocessors can touch them — unconfirmed on the captured pages, with the transparency statement recording rights previously held by a UAE entity until the 2024 acquisition.
- Your procurement requires third-party verification — we found no public information on an audit with a named auditor and date, a bug bounty or disclosed incident history.
- Your joiner-leaver process depends on directory sync — we found no public information on SCIM or automated deprovisioning, and how the vault key is released under single sign-on is undocumented.
The scores
| Criterion | Panel median |
|---|---|
| Encryption model & independent audits | 2 of 5 |
| Sharing, roles & recovery | 3 of 5 |
| SSO, directory sync & provisioning | 2 of 5 |
| Audit logs, policies & reporting | 2 of 5 |
| Hosting choice, offline access & export | 2 of 5 |
| European sovereignty | 1 of 5 |
| Pricing transparency | 0.5 of 5 |
Encryption model & independent audits
Show reasoningHide reasoning
How this is scored
What the vendor can prove about its security design: end-to-end encryption with named algorithms and key derivation, which fields are encrypted on the device and which are not, independent audits and penetration tests with published results, a bug bounty, and incident history disclosed.
0 — Security described in adjectives ("bank-grade", "military encryption") with no architecture, no audit and no statement of what the vendor can read.
3 — Encryption algorithms named and "zero knowledge" claimed, but no whitepaper, no statement of which fields stay unencrypted, and audits mentioned without dates, auditors or results.
5 — A published security whitepaper naming algorithms, key derivation and the client-side encryption model, a stated list of what is and is not encrypted (including URLs and metadata), and a named independent audit or certification (ISO 27001, SOC 2) with its date.
8 — Recurring independent penetration tests or code audits with reports or summaries published, a public bug bounty or vulnerability disclosure policy, past security incidents documented with their impact, and open-source clients or cryptography that can be reviewed.
10 — The design is verifiable end to end: full source or cryptographic design public, every field encrypted client-side including metadata, audits by named firms repeated yearly with full reports, a threat model that states what a compromise of the vendor's servers would expose, and incident post-mortems published.
The CISO
The published cryptography documentation does what I ask for first: it names AES-256-CBC client-side encryption with RSA-OAEP key wrapping, states that name, login, URL, description and tags stay protected only by server-side encryption to enable search, and lays out a threat model for database leak, server compromise and traffic interception. After that it goes quiet where I need it loudest — we found no public information on independent audits by named firms with dates, a bug bounty, or a disclosed incident history. 6 7
The Identity Engineer
The encryption scope page is close to whitepaper grade: named algorithms (AES-256-CBC client-side, AES-256-CFB server-side, RSA-OAEP for key wrapping), a field-by-field table of what is encrypted where including the search metadata that stays server-side, and a threat model covering database leak, server compromise and traffic interception. What holds it down is that the captured audits page yields no named auditor, date or result, and we found no public information on a bug bounty, incident history, or reviewable client source. 6 7
The Compliance Auditor
The encryption scope page is unusually candit for an audit file: AES-256-CBC client-side with RSA-OAEP vault keys, AES-256-CFB server-side, a per-field table showing which data the server can still index (name, login, URL, description, tags), and a threat model covering database leak, server compromise and traffic interception. What I cannot put in the file is independent verification: the captured audits page yielded no named auditor, date or result, and we found no public information on bug bounties, disclosed incidents or reviewable client code. 6 7
The SME Owner
The published encryption-scope page is the real thing: named algorithms (client-side AES-256-CBC, server-side AES-256-CFB, RSA-OAEP wrapping of vault keys), a field-by-field statement that passwords, TOTP secrets and files are client-encrypted while names, logins and URLs stay server-side only so search works, and even a threat model covering database leak, server compromise and traffic interception. What holds it back is that I found no public information on an independent audit with a named firm and date, a bug bounty, or any disclosed incident history, so nothing third-party confirms the design. 6
The DevOps Engineer
The encryption-scope documentation is what I want to read before trusting a server: AES-256-CBC on the client, AES-256-CFB on the server, RSA-OAEP vault-key wrapping, a field-by-field table of which fields stay only server-encrypted for search, and a threat model covering database leak and server compromise. I found no public information on an independent audit with a named auditor and date, a bug bounty, past incidents, or reviewable client source, so none of the design is verifiable beyond the vendor's own pages. 6 7
The Skeptic
The encryption documentation is unusually candid — AES-256-CBC in the client, AES-256-CFB on the server, RSA-OAEP for vault keys, a field-by-field table and a threat model stating that names, logins, URLs, descriptions and tags stay server-side so the server can index them for search — so zero knowledge covers passwords and secrets but not the metadata, and the client-side layer applies only when it is enabled. Beyond an audits page in the sitemap, we found no public information on any named audit, auditor, date or published report, no bug bounty or vulnerability disclosure policy, and no incident history. 6 7
Sharing, roles & recovery
Show reasoningHide reasoning
How this is scored
How credentials are shared and governed across a company: shared vaults or collections, role-based permissions, view-only and time-limited access, admin account recovery, emergency access, and what happens to shared items when an employee leaves.
0 — Personal vaults only, or sharing by sending a password to another user with no permissions and no record.
3 — Shared folders with all-or-nothing access, no roles, and no stated process for recovering an account or reclaiming credentials from a departing employee.
5 — Shared vaults or collections with read, edit and manage permissions, groups and admin roles, an admin recovery mechanism documented with its key model, and offboarding that transfers a leaver's shared items.
8 — Granular permissions down to hiding the password while allowing autofill, time-limited and one-time sharing with external parties, emergency access with a waiting period, delegated administration per team or location, and approval workflows for sensitive items.
10 — Access is governed and provable: least-privilege defaults, recovery and emergency access designed so the vendor never holds a key and stated so, periodic access reviews supported in the product, and every grant, change and revocation attributable to a person.
The CISO
Governance is documented in concrete terms: three built-in roles plus custom roles, per-recipient read and edit access on sent passwords with edits applying to the original, one-time external links with expiration down to three minutes after opening, and a corporate administrator automatically attached to every vault for emergency recovery with the master password held in a physically secure offline location. We found no public information on offboarding a leaver's shared items, approval workflows for sensitive credentials, or hiding a password while still allowing autofill. 8 9
The Identity Engineer
Sharing is genuinely governed: per-recipient read versus read-and-edit where edits land on the original record, tracked sends with revocable access, external links with expiry and single-use behaviour, three built-in roles plus custom roles, and emergency vault recovery via a blocked service account whose master password is documented as held in a physically secure offline location. We found no public information on hiding a password while allowing autofill, approval workflows for sensitive items, or a stated offboarding transfer for a leaver's shared items. 8 9
The Compliance Auditor
Roles are real — Owner, Administrator, Member plus custom roles, per-recipient read versus read-and-edit on sent passwords, single-use and expiring external links whose record copy is encrypted with a link key, and share tracking with revocation. Emergency vault recovery is documented through a blocked service account whose master password sits in a physically secure offline location, and an Access tab shows every vault a user can reach. We found no public information on groups, on offboarding transfer of a leaver's shared items, or on hiding a password while keeping autofill. 6 8 9
The SME Owner
This is close to what I need to replace our Excel file: shared vaults with shortcuts into other folders, sending a password with read or read-and-edit access per recipient, external one-time links that expire three minutes after opening or after an hour, a week, a month or unlimited, plus tracking of everything sent. Recovery is thought through — a corporate administrator is automatically added to every vault of a type and cannot be removed by vault owners, and a blocked service account with its master password in a physically secure offline location exists for emergency vault recovery. I found no public information on approval workflows, hiding a password while still allowing autofill, or a documented hand-over of a leaver's own items. 8 9
The DevOps Engineer
Permissions here are real: custom roles on top of Owner/Administrator/Member, per-recipient read-and-edit on sent passwords where edits land on the original, and single-use external links that expire three minutes after opening or up to a set lifetime, plus a documented emergency path — a corporate administrator auto-attached to every vault and a blocked service account whose master password is kept offline. I found no public information on hiding a password while still allowing its use, approval workflows, or a documented transfer of a leaver's items beyond a per-user access overview. 8 9
The Skeptic
Vault sharing with per-recipient read and read-and-edit access, trackable shares, and time-limited or single-use external links are documented alongside three built-in roles, custom roles, and a corporate administrator automatically added to every vault for emergency recovery, with the service-account master password held in a physically secure offline location — a recovery mechanism whose key model is actually stated. We found no public information on approval workflows, on hiding a password while still allowing autofill, on group-based assignment, or on a documented transfer of a leaver's shared items, and the corporate administrator's standing, owner-irremovable access to all vaults is exactly the kind of master key a buyer should interrogate. 8 9 6
SSO, directory sync & provisioning
Show reasoningHide reasoning
How this is scored
How the vault fits into the company's identity stack: SSO with Entra ID, Okta or Google, and the key model behind an SSO unlock; SCIM or directory sync for joiners and leavers; MFA options including hardware keys; and passkey support for users and the vault itself.
0 — Each user creates an account by email; no SSO, no directory sync and no MFA beyond an app code.
3 — SSO available only to sign in to the admin console or on the top tier with no description of how the vault is then decrypted, and users provisioned by CSV invite.
5 — SSO with named identity providers (Entra ID, Okta, Google) documented with how the vault key is derived or released, SCIM or directory sync for provisioning and deprovisioning, and MFA including FIDO2 or hardware keys.
8 — SSO unlock designed so the vendor cannot derive the vault key and stated so, group sync driving vault permissions, automated suspension on deprovisioning, conditional access or device policies, and passkeys stored and used across platforms.
10 — Identity is integrated without trust shortcuts: the SSO key model published and independently reviewed, deprovisioning that revokes vault access and shared items immediately with a log entry, passwordless vault unlock with passkeys, and support for the customer's own key-management or trusted-device approval.
The CISO
Single sign-on is documented properly for Entra ID, AD FS and Keycloak — endpoints, attribute mapping, authentication-context handling and Kerberos seamless login — with two-factor confirmation through the vendor's own authenticator app. Nothing captured explains how the vault key is released after an identity-provider login, and we found no public information on directory sync, automated deprovisioning of leavers, hardware security keys or passkeys. 10 11 1
The Identity Engineer
SAML single sign-on with Microsoft Entra ID is properly documented — endpoints, attribute mapping, even the requested authentication-context fix — with AD FS, Keycloak, Kerberos/SPNEGO and chained IdP logout also listed, which is more provider detail than most show. But the pages never say how the vault key is derived or released after a sign-on, and we found no public information on SCIM or directory sync, on automated suspension of a leaver's vault, or on FIDO2 hardware keys and passkeys for the vault itself — the only multi-factor option evidenced is the vendor's own authenticator app. 1 10 11
The Compliance Auditor
SAML SSO is genuinely documented — Entra ID, AD FS and Keycloak with endpoints, attribute mapping, Kerberos/SPNEGO and IdP-logout settings — and a Passwork authenticator app covers second-factor login. What matters most to an auditor is missing here: we found no public information on how the vault key is released under SSO, on SCIM or directory sync for joiners and leavers, or on FIDO2 hardware keys and passkeys. 1 10 11
The SME Owner
SSO is documented properly rather than as a checkbox: SAML configuration with Microsoft Entra ID plus AD FS and Keycloak, attribute mapping, Kerberos/SPNEGO and seamless Windows login, and making SSO the priority login method. But we found no public information on SCIM or any directory sync for joiners and leavers, on how the vault key is derived or released when a user signs in through SSO, or on FIDO2 hardware keys and passkeys — the only second factor evidenced is the vendor's own authenticator app. In a forty-person firm someone always forgets the master password, so that gap matters. 10 11 1
The DevOps Engineer
SAML SSO is documented properly for Entra ID, AD FS and Keycloak, down to attribute mapping, endpoints, Kerberos/SPNEGO seamless login and IdP logout chaining, with two-factor via their own authenticator app. I found no public information on how the vault key is derived or released after an SSO login, on SCIM or directory sync for joiners and leavers, or on FIDO2 hardware keys and passkeys. 1 10 11
The Skeptic
SAML single sign-on is documented in real depth for Microsoft Entra ID, AD FS and Keycloak — attribute mapping, endpoints, Kerberos/SPNEGO and seamless Windows login. But we found no public information on how the vault key is derived or released under single sign-on, on SCIM or directory sync for joiners and leavers, or on FIDO2 hardware keys and passkeys; the only second factor evidenced is the vendor's own authenticator app. 10 11 1
Audit logs, policies & reporting
Show reasoningHide reasoning
How this is scored
What an administrator and an auditor can see and enforce: event logs of access and changes, password health and breach reports, enforceable policies (master password, MFA, sharing, export), SIEM integration, and reports an ISO 27001 or NIS2 audit can use.
0 — No audit log and no admin policies; the administrator sees a user list.
3 — A basic activity list and a password-strength score, but no exportable log, no enforceable policies, and no record of who viewed or copied a shared credential.
5 — Event logs covering logins, item access, sharing and admin changes, exportable or available through an API, enforceable policies for master password and MFA, and password health and breach-monitoring reports.
8 — Native SIEM integration with named targets (Splunk, Microsoft Sentinel, Elastic or syslog), policies for sharing, export and browser-extension behaviour, log retention stated, and compliance reports aligned to ISO 27001, NIS2 or BSI IT-Grundschutz.
10 — Auditability is complete: every view, copy, autofill and permission change logged with user and device, logs tamper-evident and retained for a configurable period, alerting on anomalous access, and an auditor role that can read logs without access to secrets.
The CISO
An activity log exists under administration with a syslog output channel, syslog-based SIEM integration is advertised, and access to the action history is itself governed as a role permission. We found no public information on enforceable master-password or MFA policies, password health and breach reports, or a stated retention period for the logs; the vendor's own security course teaches retention standards, but the product documentation commits to none. 12 1 9 13
The Identity Engineer
An activity log exists under administration with a documented output switch to syslog or stdout, syslog-based SIEM integration is stated, and action-history visibility is a per-role permission — the privacy policy's 90 days for IP data is the only retention figure captured. We found no public information on enforceable master-password or MFA policies, password-health or breach-monitoring reports, audit-log retention, or compliance reporting an ISO 27001 or NIS2 audit could consume. 1 3 9 12
The Compliance Auditor
An activity log exists, its output channel is configurable to syslog or stdout, and the homepage advertises SIEM integration over syslog — that is the export path an ISO 27001 or NIS2 audit needs. The pages do not show whether the log records views and copies of a credential, only that it captures action events, and we found no public information on enforceable master-password or MFA policies, password-health and breach reports, or audit-log retention; the only retention figure published is 90 days for IP addresses. The security-logging material we did find is an educational course, not product reporting. 1 3 9 12 13
The SME Owner
There is an activity log covering actions, configurable to write to syslog or stdout, the vendor advertises SIEM integration over syslog, and action-history access can be revoked from ordinary members, which is enough to see who did what. But I found no public information on enforceable policies for master passwords, MFA, sharing or export, on password health or breach-monitoring reports, or on how long the audit trail is retained. 1 9 12
The DevOps Engineer
The activity log can be routed to syslog or stdout and the homepage sells SIEM integration over syslog, which is enough pipe to land events in my own stack, and user-level audit can be required by policy. I found no public information on enforceable master-password or MFA policies, password health or breach reports, or a stated retention period for the activity log. 1 9 12
The Skeptic
An activity log exists under administration and can be routed to syslog or stdout for SIEM consumption, with role-level control over who sees action history and whether API access is enabled. We found no public information on enforceable master-password or MFA policies, on password health or breach-monitoring reports, or on retention of the audit trail itself, and the vendor's own security-course pages walk through assembling open-source logging stacks rather than native product reporting. 9 12 1 13
Hosting choice, offline access & export
Show reasoningHide reasoning
How this is scored
Where and how the vault runs and how the data leaves it: cloud region choice, a self-hosted or on-premises option, offline access during a vendor outage, client coverage across operating systems and browsers, and a complete, documented export and import path.
0 — Cloud only in an unstated region, no offline access, and no export or an export that drops attachments and shared items.
3 — Cloud with a region named, apps for common platforms, and an export in CSV only that leaves out attachments, folders, TOTP seeds or custom fields.
5 — An EU region or self-hosted option, offline read access on desktop and mobile, clients for Windows, macOS, Linux, iOS, Android and the major browsers, and an export that covers all item types including attachments.
8 — Both EU cloud and self-hosted or on-premises deployment documented, a status page with incident history, encrypted full-fidelity export and import from named competitors, and vault access continuing during an outage of the vendor's service.
10 — The customer can run and leave the vault on their own terms: self-hosting with documented high availability and backup, an open or documented export format that preserves structure, permissions and history, and a stated procedure for continued access if the vendor ends the service.
The CISO
Self-hosting is stated plainly and repeatedly — the vendor's words are that passwords never leave your infrastructure — and export offers JSON preserving vault and folder structure alongside plain-text CSV, selectable per vault or folder. We found no public information on offline access during an outage, a named region for the hosted edition, or whether exports carry attachments, and the desktop application is listed without its operating systems. 1 3 14
The Identity Engineer
Self-hosting is real and loudly documented — passwords never leave your infrastructure — alongside desktop and mobile apps and four browser extensions, and the export offers CSV or JSON where JSON preserves the whole vault and folder structure and can be scoped to chosen vaults. We found no public information on an EU cloud region, offline access during an outage, whether exports carry attachments, or a status page with incident history. 1 3 6 14
The Compliance Auditor
Self-hosting is the strong card: a dedicated on-premise edition where 'your passwords never leave your infrastructure', server documentation deep enough to cover PHP-FPM logging, desktop and mobile apps plus extensions for Chrome, Firefox, Edge and Safari, and an export to CSV or JSON that preserves vault and folder structure. Against that, we found no public information on offline access during an outage, an EU cloud region, a status page, or whether the export carries attachments and TOTP seeds. 1 6 12 14 15
The SME Owner
Self-hosting is real and prominent — the vendor's words are that your passwords never leave your own infrastructure — alongside a desktop app, iOS and Android apps, extensions for Chrome, Firefox, Edge and Safari, and an export offering CSV plus a JSON that preserves vault and folder structure with selectable scope. What keeps it at this level: we found no public information on offline access, on which desktop operating systems are covered, on cloud regions, on a status page, or on whether exports carry attachments and TOTP seeds, and the CSV export stores raw data in plain text. 1 3 14
The DevOps Engineer
On-premises deployment, a CLI that injects secrets at runtime, a DevOps API and a JSON export that preserves vault and folder structure are my basics for running and leaving this on my own iron. I found no public information on high availability, backup or sizing for the self-hosted edition, on a status page, on offline access during an outage, or on whether the export carries attachments and TOTP seeds or imports from named competitors. 1 3 14 6
The Skeptic
Self-hosting is a first-class documented edition — passwords that never leave your infrastructure — with a desktop app, iOS and Android apps, extensions for Chrome, Firefox, Edge and Safari, and an export to CSV or JSON in which JSON preserves the vault and folder structure, though the vendor itself notes CSV stores raw data as plain text. We found no public information on offline access during a vendor outage, on whether export covers attachments and TOTP seeds, on a Linux client, on cloud region choice, or on a status page with incident history. 1 14 15 3
European sovereignty
panel opinion
Show reasoningHide reasoning
How this is scored
Who the contracting entity and the parent company are, where vault data and metadata are hosted, and who the subprocessors are. Independently sourced by the sovereignty pipeline; end-to-end encryption narrows what a foreign authority could compel, but metadata, logs and the update channel for the client software remain in the vendor's hands, so the chain still counts.
0 — Non-EU vendor and contracting entity, hosting unstated, and subprocessors unnamed.
3 — An EU data region offered while the contracting entity and parent are non-EU without a stated safeguard, or the subprocessor list is absent.
5 — EU hosting as standard or selectable and an EU contracting entity, but the parent company or parts of the chain (support, analytics, email, client distribution) are non-EU.
8 — EU hosting on named infrastructure, EU contracting entity, subprocessor list published with locations, a DPA covering vault metadata and logs, and a self-hosted option that removes the vendor from the data path.
10 — Sovereign end to end and evidenced: European ownership, entity, hosting and every subprocessor, certifications published (ISO 27001, BSI C5 or equivalent), and source code or builds verifiable so the client update channel is not a blind trust in the vendor.
The CISO
Credit for candour: the transparency statement discloses developers of Russian origin and rights held by a UAE company until the 2024 acquisition by the Barcelona entity. But we found no public information on where hosted vault data resides, which subprocessors touch it, or the jurisdiction of the contracting entity on the vendor's own captured pages, so I cannot tell the board who could be compelled to hand over what; the documented on-premises deployment is the one verifiable mitigation. 5 4 3
The Identity Engineer
The imprint names Passwork Europe S.L. of Barcelona as the contracting entity, and the transparency statement discloses that rights were previously held by a UAE entity and the product built by developers of Russian origin before the 2024 acquisition. Hosting location, data residency and subprocessors are unconfirmed on the captured pages, and we found no public information on a data-processing agreement covering vault metadata and logs; the self-hosted option at least removes the vendor from the data path. 1 4 5
The Compliance Auditor
The contracting entity is Passwork Europe S.L. in Barcelona and the transparency statement names the chain — developed from 2014 by developers of Russian origin, rights held by Passwork FZ-LLC (UAE), acquired by the Spanish company in 2024 — which is disclosure, but the rights holder sits outside the EU. The self-hosted edition removes the vendor from the data path, yet for cloud customers we found no public information on where vault data and metadata are hosted, on subprocessors and their locations, or on certifications such as ISO 27001. 1 4 5
The SME Owner
The legal notice names Passwork Europe S.L. in Barcelona and the transparency statement says the Spanish company acquired the product in 2024, though the same statement has the rights previously held by a UAE entity. Beyond that the picture goes dark: I found no public information on where vault data is hosted or who the subprocessors are, so for a company that cares where its password metadata sits, the chain is unverified from the servers onward. 4 5
The DevOps Engineer
The transparency statement itself lays out a chain of rights held by a UAE entity until a Spanish company's 2024 acquisition, with a Barcelona company named in the legal notice, but the captured pages confirm neither where vault data and metadata are hosted nor a single subprocessor. With hosting, subprocessors and the client update chain unevidenced, only the self-hosted edition would take the vendor out of the data path. 4 5
The Skeptic
The imprint names a Barcelona entity and a transparency statement describes rights held by a UAE company until a 2024 acquisition by the Spanish firm — and the visible chain ends there. We found no public information on where vault data or metadata are hosted, on the current parent's jurisdiction, on any subprocessor list, or on a data-processing agreement covering logs and metadata, so a buyer cannot assess what a foreign authority could compel. 4 5
Pricing transparency
Show reasoningHide reasoning
How this is scored
Whether a buyer can compute the real annual cost from public pages alone: price per user and tier, which features (SSO, SCIM, SIEM, self-hosting) sit in which tier, minimum seats, add-ons, and the minimum term.
0 — No public prices at all; every tier is a sales conversation.
3 — A starting price exists, but which business features (SSO, SCIM, audit logs) sit in which tier is unclear — the invoice is unknowable.
5 — Per-user tier prices public with the main features per tier, but at least one commonly needed piece (SSO, SIEM integration, self-hosting, minimum seats) is unpriced or "on request".
8 — Every tier priced publicly with its feature set and seat minimum, add-on prices listed, self-hosted licensing stated, minimum term and VAT treatment given.
10 — Complete price computability: annual invoice derivable for a given number of users, with every add-on, self-hosting licence, support level and renewal condition published.
The CISO
We found no public information on per-user prices, tier contents, seat minimums, add-ons or contract terms; the only pricing-adjacent statement captured is a marketing comparison about automation-API costs. A buyer cannot compute an annual invoice from these pages. 2 1
The Identity Engineer
We found no public price figures on any captured page: no per-user tier price, no seat minimum, no minimum term and no add-on pricing, and the captured pricing page itself yields no numbers. From this evidence a buyer cannot begin to compute the annual cost. 1 2
The Compliance Auditor
The captured pricing page yielded no per-user prices, tier features, seat minimums or terms, so a buyer cannot compute an annual cost from what we hold. We found no public information on which tier carries SSO, SIEM export or self-hosted licensing. 1 2
The SME Owner
I found no public information on prices — nothing on per-user rates, tier contents, seat minimums or terms; the captured pricing page yielded no figures, so I cannot compute what a year for forty people would cost. For a buyer like me who wants to see the invoice before the sales call, that alone settles it. 2 1
The DevOps Engineer
A pricing page appears in the captures, but I found no public price in it — no per-user rate, no tier feature boundaries, no seat minimum, no minimum term and no self-hosted licence price. The only cost statement anywhere is a marketing comparison of the automation API against HashiCorp's prices, so an annual invoice cannot be computed from public pages. 2 1
The Skeptic
We found no public information on prices — no per-user rate, tier structure, seat minimum, term or VAT treatment, and no statement of where single sign-on, SIEM integration or self-hosting sit — so the annual invoice is not computable from what was captured. 2
European sovereignty — proven facts
0 of 4 dimensions provenBuilt only from facts shown on the vendor's own pages. A dimension we could not prove is left open, not scored as zero.
| Legal entity | Not determined ⚠ unverified | — | uncited Report an error |
|---|---|---|---|
| Ownership | Not determined | — | uncited Report an error |
| Data residency | Not determined ⚠ unverified | — | uncited Report an error |
| Subprocessors | Not determined ⚠ unverified | — | uncited Report an error |
Questions about Passwork
Is Passwork European?
Yes. whats-best.ai classifies Passwork as EU-Made.
Where does Passwork store data?
Not stated on the vendor’s pages as of 13 Oct 2026.
Does Passwork have a free plan?
Not stated on the vendor’s pages as of 13 Oct 2026.
What are the best alternatives to Passwork?
As of 21 Oct 2026, the panel rates Password Depot (3.5/5), Keeper (3/5) and Passbolt (3/5) highest among the other 18 Password Management products evaluated. Ratings that look equal are rounded to half stars; the order uses the unrounded rating, then the name. The highest-rated European alternative is Password Depot (EU-Made). Ratings are the AI panel’s opinion, formed from public evidence: how scores are made. The full list, with European products first: Passwork alternatives.
Where this could be wrong
- Evidence ages. The oldest capture behind this page is from 13 Oct 2026. Vendors change pricing and policies without notice; every fact reflects its source as of the capture date shown in the registry.
- Weak sourcing — Data residency, Subprocessors, Legal entity. Not confirmed on the vendor’s own pages as captured.
- AI can misread a source. Extraction and judgement are automated; a citation guarantees traceability, not infallibility. If something here is wrong, say so — no account needed, every report is decided within 5 business days, and accepted corrections are published.
What we left out
A claim that does not survive our checks costs us the claim, not the page. This is what was taken off this one.
- 69 product facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 18 compliance facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 17 pricing facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 12 legal facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 7 integrations facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 5 hosting facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 2 support facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 1 data fact could not be confirmed on the vendor’s page as captured and was left out of this page and of the panel’s material. Know more? Tell us
- 3 sovereignty dimensions could not be confirmed on the vendor’s own pages and are shown as unknown. Know more? Tell us
- 6 of the readings below were written against an earlier fact sheet — a fact has been corrected, added or pulled since. Until the panel next runs on this product you are reading the older judgement. Know more? Tell us
Sources (15)
The pages every claim on this page was read from — each one checked, dated, and kept verifiable.
- 1 Vendor homepage passwork.pro Checked 13 Oct 2026 Details →
- 2 Pricing page passwork.pro Checked 13 Oct 2026 Details →
- 3 Privacy policy passwork.pro Checked 13 Oct 2026 Details →
- 4 Legal notice passwork.pro Checked 13 Oct 2026 Details →
- 5 Ownership statement passwork.pro Checked 13 Oct 2026 Details →
- 6 Encryption model & independent audits — found from sitemap passwork.pro Checked 13 Oct 2026 Details →
- 7 Encryption model & independent audits — found from sitemap passwork.pro Checked 13 Oct 2026 Details →
- 8 Sharing, roles & recovery — found from sitemap passwork.pro Checked 13 Oct 2026 Details →
- 9 Sharing, roles & recovery — found from sitemap passwork.pro Checked 13 Oct 2026 Details →
- 10 SSO, directory sync & provisioning — found from sitemap passwork.pro Checked 13 Oct 2026 Details →
- 11 SSO, directory sync & provisioning — found from sitemap passwork.pro Checked 13 Oct 2026 Details →
- 12 Audit logs, policies & reporting — found from sitemap passwork.pro Checked 13 Oct 2026 Details →
- 13 Audit logs, policies & reporting — found from sitemap passwork.pro Checked 13 Oct 2026 Details →
- 14 Hosting choice, offline access & export — found from sitemap passwork.pro Checked 13 Oct 2026 Details →
- 15 Hosting choice, offline access & export — found from sitemap passwork.pro Checked 13 Oct 2026 Details →