Passbolt’s CSPN submission and what it means for credential governance

At a glance

What this is: PassBolt’s CSPN submission is a certification milestone that shifts the discussion from product claims to independent review of its credential governance, cryptography, documentation, and attack resistance.

Why it matters: For IAM and NHI practitioners, this matters because security-critical credential tooling needs assurance over lifecycle, assumptions, and operating model, not just feature lists.

Context

Credential governance is not only about storing passwords or secrets. It also depends on whether a product can prove how it handles cryptographic design, installation assumptions, documentation, and attack resistance under independent review.

PassBolt says its CSPN application has moved forward after a pre-evaluation with Quarkslab, which means the product is now in a certification process led by ANSSI. For security teams, the important question is not the label itself but what the assessment forces the vendor to document and defend.

That distinction matters because assurance frameworks are most useful when they expose hidden assumptions about deployment, operator guidance, and security boundaries rather than simply validating that controls exist.

Key questions

Q: What should teams look for in a credential governance certification review?

A: Teams should look for evidence that the review covers cryptographic design, installation procedures, documentation, threat assumptions, and the scope of the security guarantees. The value of certification lies in whether the product can defend its claims under realistic conditions, not whether it simply includes security features on a checklist.

Q: Why is an independent assessment more useful than a feature list for credential tools?

A: A feature list says what a product can do, but an independent assessment shows whether those claims hold under defined assumptions and realistic attack scenarios. That matters for credential tools because deployment choices, operator behaviour, and documentation quality can all weaken security after purchase.

Q: How should organisations evaluate security assumptions in credential platforms?

A: They should identify the assumptions that underpin the product’s guarantees, then test whether those assumptions are still true in their environment. If a tool only works securely under narrow conditions that are not documented or enforced, governance risk shifts to the operator.

Q: What does certification tell buyers about deployment readiness?

A: Certification can indicate that the product has been examined against a defined security target and realistic attack scenarios, but it does not remove the need for local validation. Buyers still need to confirm that their own installation, administration, and integration model matches the assumptions used in the evaluation.

Technical breakdown

What CSPN evaluates in a credential governance product

CSPN, or Certification de Sécurité de Premier Niveau, is an independent security certification scheme operated by ANSSI. In this process, evaluators do not just check whether a product has security features. They review source code, cryptographic mechanisms, documentation, installation procedures, security assumptions, and the product’s resistance to realistic attack scenarios. For credential governance tools, that is important because assurance depends on how the product behaves when deployed, not only how it is described in marketing or manuals. The evaluation also forces clear statements about what guarantees the product provides, under which assumptions, and against which threats.

Practical implication: Treat certification readiness as a documentation and assurance exercise, not just a technical hardening task.

Why cryptographic design and operational guidance are part of the same risk surface

Credential governance products often fail at the seam between cryptography and operations. A strong design can still be weakened by poor installation guidance, unclear trust assumptions, or ambiguous administrative procedures. That is why CSPN looks at the whole package: cryptographic design, technical documentation, installation steps, and administration guidance all shape the real security outcome. In practice, the assurance question is whether the product can be deployed and operated without hidden dependencies that erode its guarantees. This is especially relevant where credentials, secrets, or password workflows support critical internal access.

Practical implication: Review cryptographic claims together with deployment and administration guidance, because that is where assurance is won or lost.

How certification differs from a penetration test

A penetration test can find exploitable weaknesses in a point-in-time configuration, but it does not usually establish the scope of the product’s intended security guarantees. CSPN goes further by testing the assumptions behind the design and by requiring evidence that the product resists realistic attack scenarios under defined conditions. That makes it more useful for buyers who need assurance about how a security-critical product is meant to behave over time. For credential management, the distinction matters because governance teams must know not only that attacks were considered, but also what remains true after deployment, integration, and operational change.

Practical implication: Use certification evidence to validate security claims, and use penetration testing to expose environment-specific weaknesses.

NHI Mgmt Group analysis

Certification shifts credential governance from assertion to evidence: In security-critical identity tooling, claims about protection are only useful when they survive independent review. CSPN forces the vendor to prove how cryptography, deployment, documentation, and assumptions fit together. That changes procurement from trust in product messaging to trust in verifiable assurance.

Credential governance is a lifecycle problem, not a feature checklist: The important questions are how secrets are protected, how guidance constrains operators, and what assumptions must stay true after installation. If those elements are not explicit, the product may appear secure while still relying on fragile operational conditions. Practitioners should read certification evidence as a statement about lifecycle resilience, not just product capability.

Assurance packages must expose the security boundary, not hide it: CSPN requires vendors to document what guarantees exist, under which assumptions, and against which threats. That is the right model for security-critical credential platforms because it turns vague confidence into a bounded promise. Teams buying such tooling should expect that level of clarity before they operationalise it.

Passbolt’s submission illustrates where European certification is heading: Buyers increasingly need assurance artefacts that connect product design, cryptographic choices, and deployment practice. That direction strengthens governance because it makes reviewable evidence part of the procurement conversation. The practical implication is that credential platforms will be judged less by claims and more by the quality of their assurance case.

Security-critical software must be defensible in use, not only in theory: The CSPN model is valuable because it evaluates how a product behaves in conditions close to real deployment. That matters for credential governance, where operational drift often undermines the original design. Practitioners should demand evidence that survives contact with actual administration, installation, and integration patterns.

What this signals

Assurance should be treated as a governance control, not a marketing signal: When credential platforms enter formal certification, the important output is a defensible assurance case. That gives IAM and security leaders a better basis for procurement, audit response, and control mapping than feature claims alone.

Assumption boundaries matter more than broad claims: A product that is secure only under narrow deployment conditions still creates operational risk if those conditions are not visible to the buyer. Certification helps surface those boundaries early, which is exactly where governance programmes need clarity.

For practitioners

• Map assurance claims to deployment assumptions Document which security guarantees depend on specific installation choices, operator behaviours, or trust boundaries before approving a credential platform.
• Review cryptography and operations together Ask for the cryptographic design, the administration guide, and the threat model as a single evidence set instead of treating them separately.
• Use certification evidence in procurement decisions Require vendors to show what the certification process actually tests, including realistic attack scenarios and the exact scope of review.
• Check whether guarantees survive integration Validate that connectors, hosting models, and administrative workflows do not quietly exceed the assumptions stated in the assurance materials.

Key takeaways

• Credential governance products need independent scrutiny because security claims only matter when they survive review of design, documentation, and deployment assumptions.
• The CSPN process forces a product to defend its cryptographic design and operational guidance against realistic attack scenarios.
• For practitioners, the practical lesson is to treat certification evidence as part of procurement and governance, not as a substitute for local validation.

Key terms

• Certification de Sécurité de Premier Niveau: Certification de Sécurité de Premier Niveau is an ANSSI certification scheme that assesses a product’s security posture against defined expectations and realistic attack scenarios. It is designed to provide independent assurance, not to replace operational governance or eliminate the need for internal control validation.
• Security Target: A Security Target is the formal statement of what a product claims to protect, how it is intended to be used, and which threats it is expected to resist. In certification contexts, it becomes the contract between the vendor, evaluator, and purchaser for understanding assurance scope and limitations.
• Assurance: A governance state where an organisation can verify what an AI agent is, what it is allowed to do, and who is accountable for it. For autonomous behaviour, assurance requires identity, policy, supervision, and revocation to work together at the moment of action.
• Cryptographic design: Cryptographic design is the way a product applies encryption, key handling, and related mechanisms to protect data and access. In certification contexts, it is evaluated alongside documentation and deployment assumptions because strong cryptography can still be weakened by poor operational boundaries.

Deepen your knowledge

NHI governance, identity lifecycle management, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or NHI governance programme, it is worth exploring.