Passbolt security audit 2021 shows specification gaps in cryptography

At a glance

What this is: Passbolt’s audit review found cryptographic specification gaps, including insecure TLS guidance and nonce handling concerns, rather than immediate implementation failure.

Why it matters: For IAM and NHI practitioners, this is a reminder that identity security depends on precise protocol behaviour, not just feature intent, especially where authentication and secret access are involved.

By the numbers:

• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read Passbolt's security audit findings on cryptographic specification gaps

Context

Passbolt’s audit write-up is really about the gap between cryptographic design intent and the precision needed to operate it safely. In identity security terms, that matters because authentication protocols, TLS requirements, and challenge handling are part of the control surface, not implementation footnotes.

The article focuses on audit findings that point to undefined behaviour in the specification, especially around secure transport and nonce correctness. For teams running secrets platforms, service-account tooling, or privileged collaboration systems, the lesson is that weakly specified identity behaviour creates avoidable risk long before an attacker arrives.

Key questions

Q: What breaks when secure transport is left to administrators in an identity system?

A: Security breaks at the trust boundary. If HTTPS, cipher selection, and transport hardening are left to local configuration alone, credentials and authentication exchanges can be exposed to inconsistent deployment choices. The result is not just weaker confidentiality, but a control model that varies from one environment to the next and is difficult to govern consistently.

Q: Why do nonce requirements matter in challenge-based authentication?

A: Nonce requirements matter because the challenge must be unique and used once to preserve authentication integrity. If a system allows reuse, replay, or ambiguous token behaviour, the protocol no longer guarantees the property it was designed to provide. In practice, that turns a cryptographic assurance into a documentation assumption.

Q: How can security teams tell whether a specification is secure enough to implement?

A: They should look for unambiguous, testable statements about transport security, challenge handling, expiry, and access removal. If a control can be interpreted multiple ways, implementers will make different assumptions and security behaviour will drift. A good specification removes that ambiguity before code reaches production.

Q: Who is accountable when insecure protocol choices are left open in a secrets platform?

A: Accountability is shared, but it should be explicit. Product teams must define the security behaviour, and operators must enforce the deployment baseline. When the specification leaves room for insecure transport or unclear challenge semantics, the organisation owns the risk because the control was never made deterministic enough to govern reliably.

Technical breakdown

Transport-layer encryption is part of the identity trust boundary

The audit notes that Passbolt did not enforce HTTPS by default and left protocol hardening guidance to administrators. That is not just a transport concern. In an identity system, TLS defines whether credentials, challenges, and session material remain protected in transit. If the deployment accepts insecure cipher choices or plain HTTP, the trust boundary between client and server becomes a policy decision rather than a product-enforced control. For systems used to store or exchange secrets, that is a material architectural issue because confidentiality and integrity both depend on the transport layer behaving predictably.

Practical implication: treat enforced TLS and approved cipher baselines as part of identity control design, not optional deployment hygiene.

Nonce correctness prevents replay and challenge reuse

The audit highlights GpgAuth challenge handling, where the specification expected a nonce but the implementation used UUID-based tokens. A nonce is supposed to be used once and only once, which prevents replay and reduces the chance that a captured challenge can be reused. Even if collision risk is low, the control objective is stronger than statistical improbability. In authentication design, especially for systems handling secret access, correctness means the protocol must be unambiguous enough that implementers cannot drift into behaviour that weakens uniqueness guarantees.

Practical implication: require protocol documentation that makes one-time challenge behaviour explicit and testable across implementations.

Specification clarity is a security control, not just documentation

Several findings were described as having limited practical impact on the current software but still reflected missing or incomplete definitions in the specification. That distinction matters. When an identity or cryptography system leaves room for interpretation, downstream implementers may make different security choices, and those choices can accumulate into inconsistent trust behaviour across components. This is especially relevant for secrets platforms, where transport, challenge validation, expiry handling, and access removal all depend on the same governance quality: the specification must remove ambiguity before it reaches production.

Practical implication: audit specifications for ambiguous security language and treat unresolved behaviour as an implementation risk to be closed before rollout.

NHI Mgmt Group analysis

Specification ambiguity is a control failure, not a cosmetic issue. The audit shows that undefined behaviour in cryptographic and authentication specifications can create security drift even when the code path is not immediately exploitable. That matters because implementers and operators make different assumptions when the documentation is incomplete. In identity systems, ambiguous behaviour is itself a governance defect, not just a documentation gap. The practitioner conclusion is that precise security semantics belong in the control design, not in post-hoc interpretation.

Secure transport must be enforced at the identity layer, not delegated to deployment discipline alone. Passbolt’s write-up makes clear that HTTPS enforcement and cipher-suite guidance were left partly to administrators. That is a familiar pattern in identity tooling: the product assumes the operator will close the gap, while the operator assumes the product will surface the risk early enough to prevent misconfiguration. The result is a trust boundary that depends on local excellence rather than systemic enforcement. Practitioners should treat this as a design pattern to challenge, not a deployment footnote.

Nonce handling illustrates how authentication correctness can fail without an obvious breach. The important issue is not whether a UUID collision is likely in practice. The issue is that challenge-based authentication relies on one-time uniqueness as a property, and any deviation from that property weakens assurance. This is a classic NHI governance lesson: security claims about authentication need to survive implementation details, because operational shortcuts can erode control quality before any attacker pressure is visible. The practitioner implication is to verify that protocol intent and runtime behaviour are identical.

Passbolt’s audit reinforces that secret-management systems inherit identity governance obligations. Tools used to protect credentials are themselves part of the identity stack, which means they need the same discipline around lifecycle, transport security, and access semantics. The fact that the report also references password expiry and permission removal shows that governance does not end at secret storage. It extends to how access is withdrawn and how resource state changes when users or groups change. The practitioner conclusion is to evaluate secrets platforms as identity systems, not just vaults.

Cryptographic assurance depends on implementation clarity as much as algorithm choice. The report’s broader message is that a well-designed protocol can still leave room for operational weakness if the specification is not exact enough. That is especially relevant in NHI environments, where service accounts, authentication tokens, and secret exchanges often span multiple components and teams. The governance implication is straightforward: ambiguous security requirements should be treated as defects with ownership, review, and closure criteria. The practitioner conclusion is to demand explicit security behaviour before certification or broad deployment.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to the Ultimate Guide to NHIs.
• For the lifecycle side of this problem, the NHI Lifecycle Management Guide shows how rotation, offboarding, and visibility need to work together rather than in isolation.

What this signals

Specification quality is becoming a governance requirement for identity platforms. Teams that treat authentication and transport details as implementation trivia will miss where risk is actually introduced. For identity programmes, the operational question is whether protocol behaviour is precise enough to survive handoff from design to deployment to audit.

The broader signal is that secrets platforms now sit inside the same governance expectations as IAM and PAM systems. That means controlled transport, explicit challenge semantics, and formalised access removal are no longer optional design preferences. Practitioners should expect auditors to ask whether the platform enforces the policy itself or merely documents it.

Control ambiguity creates trust debt: every unclear security statement becomes future operational variance. The practical response is to close specification gaps before they are translated differently by implementers, because those differences are what eventually show up as incidents, exceptions, and audit findings.

For practitioners

• Enforce TLS at the platform boundary Require HTTPS by default for any secret or authentication flow and block insecure cipher suites in the deployment baseline. Validate the server configuration during installation and health checks so the operator cannot accidentally deploy an identity trust path without transport protection.
• Specify one-time challenge behaviour explicitly Document nonce usage as a hard protocol requirement, then test for single-use challenge semantics in every implementation that participates in authentication. Any challenge mechanism that can be reused, replayed, or interpreted inconsistently should be treated as a design defect, not a low-risk quirk.
• Review security specifications for ambiguous control language Trace every statement about encryption, authentication, expiry, and permission removal back to a testable requirement. Where the wording allows two reasonable interpretations, force a decision before release so implementers do not inherit undefined behaviour in production.
• Treat permission removal as a lifecycle event When users or groups are removed from access paths, ensure the associated resources are marked expired and no longer usable in downstream workflows. Tie that state change to access review and offboarding processes rather than leaving it as an informal operational step.

Key takeaways

• The audit found that Passbolt’s main risk was specification ambiguity around cryptographic behaviour, not an obvious implementation break.
• High-severity findings centred on transport-layer encryption and nonce handling, both of which shape the reliability of authentication flows.
• Identity and secrets platforms should be governed with explicit, testable security requirements so operators are not forced to infer critical behaviour.

Key terms

• Nonce: A nonce is a value used one time to protect an authentication or cryptographic exchange from reuse. In identity systems, it prevents replay and helps prove freshness, but only when the implementation strictly enforces single use and unambiguous handling.
• Transport-layer encryption: Transport-layer encryption protects data while it moves between client and server, usually through TLS. For identity and secrets systems, it is part of the trust boundary itself because it protects credentials, session material, and challenge data from interception or alteration in transit.
• Specification ambiguity: Specification ambiguity occurs when security requirements are written in a way that allows multiple valid interpretations. In identity governance, that creates implementation drift because different teams may build different behaviours from the same text, weakening control consistency and auditability.
• Challenge-based authentication: Challenge-based authentication proves that a client can respond to a server-issued challenge before access is granted. It is only reliable when the challenge is unique, time-bound, and handled consistently across implementations, otherwise replay and misuse risks increase.

What's in the full article

Passbolt's full audit write-up covers the operational detail this post intentionally leaves for the source:

• The full breakdown of the cryptographic findings, including the exact wording of the high-severity issues and the related implementation recommendations.
• The audit context around GpgAuth challenge handling, nonce expectations, and why the specification language matters to implementers.
• The additional suggestions around password expiry flags and passphrase generation that were not explored in depth here.
• The closing notes on future audit parts and the broader security whitepaper context for the platform.

👉 The full Passbolt post covers the audit conclusions, nonce guidance, and related specification suggestions.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.