They have.
I can provide all the proof if you wish, but it might be flagged since itâs already mentioned and linked above.
All their Audits specially by cure 53 are public and so are their certifications:
ISO 27001, ISO 27017, ISO 27018, ISO 27701, SOC 1, SOC 2, SOC 3, and PCI DSS and SOC 2 Type II audit
Feel free to link the audits (not copying all the texts). Happy to have a look.
Very much wondering what was found on zero knowledge and the usage of PGP in the security model given what is mentioned above.
Passbolt v5, Encrypted Resource Metadata/Pentest-Report Passbolt Browser Addon & API 04.-05.2025:
Auditâs conclusion
Cure53 is happy to report that the overall server-side design is quite strong, with no major issues identified within it. This is largely due to the fact that very little sensitive information is actually visible to the server. In other words, much of the handling of critical data is taking place on the client instead. All vulnerabilities on the server-side found were caused by the use of unvalidated user input. This means they can be easily fixed by adding input validation already present in the other parts of the application. Regarding the addon, no issues undermining confidentiality could be spotted. From an end-to-end encryption standpoint, this is a praiseworthy result. Moreover, the server cannot access encrypted data, and only the user holds the necessary credentials. However, the lack of signature validation meant that users would not have the way to detect data tampering. As such, this issue signified an integrity compromise and should be addressed urgently to ensure full E2E encryption protections.
Cure53 would like to thank Cedric Alfonsi and Remy Bertot from the Passbolt SA team for their excellent project coordination, support and assistance, both before and during this assignment.
1 Like
The rest can be found at the bottom here:
Under Audit Reports:
Cure 53 Review-Report Passbolt Crypto Features 07.2022:
Cure 53 Review Report Passbolt Security White Paper 02.2021:
Okay, so if I understand all the above and linked materials, Passbolt encrypts secrets with pgp, but the server still logs who can decrypt each item and publicâkey fingerprints. This metadata seems like a privacy concern, even without breaking the encryption. Because the private PGP key is the master secret, losing or compromising that key exposes all of their past and future secrets, and revoking a key requires reâencrypting every secret. I believe the industry standard is to use keyâderivation to mitigate this which seems to be lacking. I am very much wondering why they went with such unconventional design. Usually the recommendation is donât create your own crypto(implementations). If there is no good explanation of that I would stay far away from the solution. I would really like to hear why they thought this is a better idea.
Besides this the lacking real random generator (mentioned in the audit) seems rather concerning for a password manager.
1 Like
ISO 27001 is more about your organizationâs security program (policies and procedures) not the security of the architecture of products you develop. It is not relevant here.
ISO 27017 is about your cloud security controls and I donât think the topic at hand is relevant to its scope.
ISO 27018 is about privacy and data controls, also likely not relevant.
ISO 27701 is an extension to ISO 27001 to add elements of privacy and data controls. Also unlikely to be relevant.
SOC 1 is a financial audit lol
Anyone and their dog can âpassâ a SOC 2 audit, because thereâs no such thing as failing a SOC 2 audit lol. The auditor gives you a final report which describes controls they were able to verify and any areas you fell short or they found issues. The point is you are supposed to distribute the report to potential clients for review, it is not a pass/fail system, and you need to see the report to understand the risks of doing business with the auditee. Businesses typically (in my experience) wonât give out their report unless you are a prospective B2B client and sign an NDA.
SOC 3 is basically the same as SOC 2 but the final report removes most of the details so companies feel safe releasing it for public consumption. Itâs kind of just a marketing pamphlet, IMO.
SOC 2 Type II is redundant, you already mentioned SOC 2. Usually when people say SOC 2 they mean Type II as the only difference between Type I and II is Type I is point in time at a single moment whereas Type II is continuous where controls are evaluated over a period of time.
Iâm guessing youâve never had the joy of reading a SOC 2 audit report, or even better, working with a SOC 2 auditor, which is fine, I wouldnât expect most to know this and thatâs why companies like to parade them out like a magic word that means their products are perfectly secure.
Cure53 audits are better, but they really only validate there are no vulnerabilities that they could identify during the audit period, which might be short, and either way they generally wonât speak to your architectureâs overall competence or evaluate higher level design decisions. No one is saying there is a clear vulnerability right now, the issue is their design decisions indicate they donât really know what theyâre doing.
3 Likes
I would contact them. But I canât email their email support it is only for paying users. You are able to talk through their community forum. But that is all is given if you arenât paying.
i mean that seems reason enough to not recommend it to our audience ngl.
1 Like
Understandable maybe in the future. If they explain more personally for you. Or one of their team come on here to explain. I do know they have a YouTube channel. Iâll try to see if they explain anything there. If not thanks for looking and taking an âhonestâ review.
Well, KeePassXC also doesnât have email support. 
I did find this:
Description of the zero knowledge mode for metadata:
Then this about encrypting metadata that is still cleartext:
Passbolt 5.5 made encrypted resource metadata the default for new Cloud workspaces and introduced zero-knowledge mode. Existing Cloud instances created before Sep 23, 2025 can now enable it using the steps above.
Shared metadata key rotation
Shared metadata key rotation allows administrators to rotate the organisationâs metadata key from the settings. Rotation supports policy requirements and limits access for former members by ensuring new metadata is encrypted under a new key.
Zero-knowledge mode for metadata
Zero-knowledge mode prevents the server from accessing resource metadata. Administrators explicitly share the metadata key with users when appropriate, which strengthens confidentiality for organisations that prioritise privacy over server-side inspection. Until a user receives the key, actions that require shared metadata remain intentionally restricted.
I have spent 2 hours going through some of the documentation to understand how Passbolt works. So, here:
The concerns raised are understandable and were indeed more valid a couple of years ago, but most of them have been addressed or are inherent to the OpenPGP-based architecture that Passbolt deliberately chose. A quick summary of where things stand today (v5.x, 2025):
- Metadata privacy Resource names, URIs, descriptions and folders are now end-to-end encrypted (personal metadata with the userâs own key, shared metadata with a rotatable organization recovery key). The only data that remains in cleartext is the minimal operational metadata required for the application to function (user IDs, group membership, permission flags). With Passbolt 5.1, metadata encryption was introduced as an opt-in feature, and by v5.5, it became the default for new installations, especially on Passbolt Cloud. This is major improvements over pre-v5 versions.
- âPGP key is the master secretâ Thatâs correct and by design. Itâs the same model used in any OpenPGP workflow (encrypted/signed e-mail). Losing or compromising the private key does give an attacker access to everything that was ever encrypted for that key exactly the same risk profile you have with any asymmetric system and, in practice, with the master-password-derived symmetric vault key used by Bitwarden, 1Password, etc.
- Revocation and re-encryption Revoking access to individual resources is instantaneous (the encrypted blob for that user is simply deleted). Full key revocation does require re-sharing or re-encrypting items with a new key pair, which is again standard OpenPGP behavior. Passbolt offers an optional encrypted key escrow (protected by a rotatable organization recovery key) to make recovery/re-rotation less painful for teams.
- Key derivation The private key itself is protected with OpenPGPâs iterated and salted S2K specifier (essentially PBKDF2-like), so a stolen private key file is still resistant to brute force if a strong passphrase is used. The design simply avoids the âsingle derived symmetric vault keyâ pattern because it would break per-user encryption and granular sharing.
- Random-number issue The 2018 finding about Math.random() in the password generator was fixed shortly after the audit. The most recent penetration test and code review (2025) only identified a few non-cryptographic uses of weak RNG (UI shuffling, etc.), which are being replaced but do not affect key material or password generation.
In short, Passboltâs model is intentionally built around the OpenPGP standard rather than the more common âencrypted vault blob + master keyâ approach. That gives stronger interoperability, true per-recipient encryption, and no single master secret that could decrypt everything if compromised, at the cost of more manual work when a key is lost or revoked.
For individual users who prefer maximum simplicity, tools like Bitwarden or KeePassXC are ofabetter fit.
Hope that provided some answers to your questions?
Iâve just had a read of the security whitepaper. Itâs seems that they are having to add layers and layers of additional security, in order to deal with the issues associated with using PGP. Especially around authentication and secret sharing.
@Italicize2242 you keep stating that some of the things they do are âstandard OpenPGP behaviorâ etc. But this just reiterates the fact that OpenPGP was a bad choice.
1 Like
Hey, I get where youâre coming from. The Passbolt whitepaper, blogs, and audits does talk about a bunch of extra mechanisms (GPGAuth, server side nonces, the whole verify then decrypt flow), and I would say it is fair to say âwow, theyâre really having to add a lot of stuff on top of OpenPGP.â
The thing is, almost all of that extra work isnât there because OpenPGP is broken itâs there because OpenPGP was never designed for browser-based, multi-user password sharing in the first place. Turning a 30 year old encryption standard into a secure web authentication and sharing system naturally requires some careful engineering on top.
Passbolt basically took the hardest route which I think pays off:
- User own their private keys (the server literally canât read anything that is encrypted with these keys. They can also be rotated if compromised). While most data is end-to-end encrypted, some metadata which is stated to become encrypted in the future like (folder structure, user permissions) may be stored server-side in older versions. Newer versions (5.5+) support encrypted resource metadata, audited and enabled by default, closing some of this gap.
- Secrets are encrypted directly to each recipientâs public key (true multi-user E2EE).
- Everything is interoperable with any standard OpenPGP tool.
Thatâs why you end up with GPGAuth and the extra signature check theyâre the price of staying zero knowledge and standards based instead of going the easier âjust use one master symmetric key like most password managersâ route.
Itâs totally valid to prefer something simpler (Bitwarden, or 1Password) Theyâre smoother for most teams. But calling OpenPGP a âbad choiceâ for Passbolt is like saying âsteel is a bad choice for a bridge because you have to add all these rivets and cables to keep it stable and secure.â The extra engineering is exactly what you sign up for when you want that level of independence and auditability.
Anyway, no hard feelings reasonable people can land on different sides here. I just think Passboltâs approach makes sense once you accept their core constraint the server must never be able to decrypt anything that is encrypted, ever. OpenPGP is still one of the few practical ways to pull that off at scale with real teams for easy sharing.
I think it is a better teams password manager compared to Psono which is recommended by privacy guides. IMO
Which is why it shouldnât be used for it. Anything else is a real stretch.
Except other password managers donât do that for password sharing. They also use public key cryptography.
1 Like
The 2025 audit from Cure 53 proved that the PGP and itâs zero knowledge is secure:
The most noteworthy from the conclusion of the audit:
From an end-to-end encryption standpoint, this is a praiseworthy result. Moreover, the server cannot access encrypted data, and only the user holds the necessary credentials.
The Full Auditâs Conclusion with a Vulnerability Finding:
Cure53 is happy to report that the overall server-side design is quite strong, with no major issues identified within it. This is largely due to the fact that very little sensitive information is actually visible to the server. In other words, much of the handling of critical data is taking place on the client instead. All vulnerabilities on the server-side found were caused by the use of unvalidated user input. This means they can be easily fixed by adding input validation already present in the other parts of the application. Regarding the addon, no issues undermining confidentiality could be spotted. From an end-to-end encryption standpoint, this is a praiseworthy result. Moreover, the server cannot access encrypted data, and only the user holds the necessary credentials. However, the lack of signature validation meant that users would not have the way to detect data tampering. As such, this issue signified an integrity compromise and should be addressed urgently to ensure full E2E encryption protections.
Cure53 would like to thank Cedric Alfonsi and Remy Bertot from the Passbolt SA team for their excellent project coordination, support and assistance, both before and during this assignment.
True, but Passbolt doesnât rely on a master password or derived symmetric key at all instead, it uses PGP keypairs for access. This removes risks tied to weak passwords or bypassing key derivation, but it does makes setup a bit more involved.
Passbolt embraces the PGP complexity on purpose because it values user control, transparency, and open standards. Yes, itâs less convenient, but thatâs a conscious trade off, not a flaw. Like I said your previous criticism isnât wrong, but it misses the point of what Passbolt is trying to achieve. Which is decentralization and transparency of the security and who actually owns the data.
And how are these PGP keypairs protected?
With the exception of 1Password the recommendations on PG are open source. And Bitwarden at least can be self-hosted. There claims arenât anything new or revolutionary.
1 Like
Finally.
What they are trying to achieve is meaningless if they implement it poorly.
Are you saying they donât encrypt the PGP private keys? Does the server store them in plaintext then?
This does not logically follow.
Correct! Thatâs why they shouldnât be using it, and has been the entire point this whole time.
PGP isnât required for these properties.
Well, to be clear, you yourself already admitted PGP wasnât designed for this. And itâs more like saying âmud is a bad choice for a bridge because you need to build a steel frame around it to keep it from washing away anyway, so just use steelâ
No, theyâre the price of not knowing how to build any better zero knowledge and standards based systems.
Except the private key, of course. Minor detail.
Why not just use that directly on the vault data then?
No.
Which should be everyone. Complexity is the enemy of security.
At least we can agree on one thing.
1 Like