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

At a glance

What this is: Passbolt says its CSPN application has been submitted to ANSSI, signalling a formal independent security assessment of its product assumptions, cryptography, documentation, and operational guidance.

Why it matters: For IAM and NHI practitioners, this matters because certification pressure surfaces whether credential governance controls are actually evidenced, documented, and resistant to real attack conditions.

👉 Read Passbolt’s update on its CSPN certification submission

Context

Passbolt’s CSPN submission is about assurance, not feature release. In plain terms, CSPN is a French security certification process that checks whether a product’s claims hold up under independent review of code, cryptography, deployment guidance, and threat assumptions.

For identity teams, the relevance is wider than one vendor. Any credential platform that manages non-human identities, shared secrets, or collaborative access workflows has to prove its trust boundaries, operational assumptions, and attack resistance with more than marketing language.

Key questions

Q: How should security teams evaluate certification claims for credential management tools?

A: Treat certification as one evidence source, not as a buying decision by itself. Check what was evaluated, which deployment assumptions were in scope, and whether the product’s operational model matches your environment. If the assessment does not cover your identity workflow, the assurance value drops sharply. Use the certification to inform control design and procurement review.

Q: Why does independent evaluation matter for NHI and secret management platforms?

A: Because these platforms sit inside the trust path for service accounts, shared credentials, and operational access. Independent evaluation can expose weak assumptions in documentation, cryptography, and deployment guidance before they become production risk. For NHI governance, that matters because hidden assumptions often matter as much as technical features.

Q: What should organisations look for beyond a security certification badge?

A: Look for the evaluated scope, the documented assumptions, the residual risks, and whether your use case matches the certified operating model. A badge alone does not tell you how the product behaves in your environment or whether your admins, integrations, and access patterns fall inside the tested boundary.

Q: Who should own the decision to trust a credential platform after certification?

A: Ownership should sit with the teams responsible for IAM, PAM, and NHI governance, not only procurement. They need to decide whether the assurance evidence is sufficient for the access patterns and secret lifecycle in scope. Certification informs the decision, but the accountability for risk acceptance remains internal.

Technical breakdown

What CSPN evaluates in a credential security platform

CSPN is a product-security certification scheme operated by ANSSI. It examines source code, cryptographic mechanisms, documentation, installation procedures, and security assumptions, then tests resistance to realistic attack scenarios. That is materially different from a lightweight penetration test because the review asks what the product claims to protect, under what assumptions, and with what operational boundaries. For identity tooling, this matters because credential governance is not only about storage or sharing. It is about whether the system’s trust model can be defended in deployment and in use.

Practical implication: treat certification evidence as a governance input, not a substitute for your own control validation.

Why security assumptions matter more than feature lists

A certification process is only useful when it forces explicit assumptions into the open. For identity and secrets platforms, the critical questions are whether access paths are constrained, whether cryptographic handling is documented, and whether operational procedures match the intended threat model. If those assumptions are vague, teams can end up approving tools that look secure but depend on hidden conditions such as perfect administrator discipline or ideal deployment hygiene. That is where governance breaks down.

Practical implication: review the assumptions behind any credential platform before using it for high-trust workflows.

How independent evaluation changes procurement decisions

Independent evaluation changes the procurement conversation from ‘does it have the feature’ to ‘what evidence exists that the feature behaves as claimed under realistic conditions’. For NHI governance, that is especially important where shared vaults, collaborative administration, and secret handling create broad blast radius if controls fail. A certification framework does not eliminate risk, but it gives security teams a structured way to compare assurance claims against the actual operational model.

Practical implication: require vendors to show evaluation scope, tested assumptions, and residual risk before you treat certification as a buying signal.

NHI Mgmt Group analysis

Credential platforms are trust infrastructure, so their assurance model must be stronger than their feature set. A product that stores and distributes secrets sits inside the identity control plane, not beside it. When that product is used to govern shared access, the quality of its documentation, cryptography, and deployment model becomes part of the security boundary. Practitioners should judge the platform by the evidence behind its trust claims, not the presence of a vault UI.

Security certification is most useful when it exposes hidden operating assumptions. CSPN forces a vendor to specify what security guarantees are provided, under which assumptions, and against which threats. That is the right shape of question for NHI tooling, because secret handling failures often come from undeclared assumptions about admin behaviour, deployment hygiene, or threat scope. Practitioners should use the same lens in procurement and recertification.

Independent evaluation does not replace governance, but it changes the burden of proof. A platform can still be operationally misused even after certification, yet the evaluation narrows the space for untested claims. For teams managing shared credentials or collaborative secret access, that shifts attention to whether internal policy matches the product’s actual certified boundaries. The practitioner conclusion is simple: certification should inform control design, not end the review.

Certification pressure is a useful market signal for identity security maturity. As credential management becomes more central to cloud and NHI governance, vendors are being pushed to demonstrate assurance in ways that are auditable and comparable. That does not make certification a proxy for fit, but it does reward products that can survive scrutiny. Practitioners should expect more demand for evidence-led security narratives across the identity stack.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared with nearly 1 in 4 for securing human identities.
• That confidence gap is why practitioners should pair product assurance with lifecycle controls, as detailed in Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs.

What this signals

Credential assurance is becoming a governance signal, not just a product signal. When a platform manages shared secrets or delegated access, certification evidence should be read alongside lifecycle controls and access review design. The practical question is whether the product’s tested trust boundary matches the way your team actually provisions, rotates, and retires access.

The strongest programmes will treat independent assessment as one control layer inside a broader identity operating model. That model should connect procurement, access governance, and administrative oversight so that assurance claims do not drift away from production reality.

For practitioners

• Map certification scope to your actual use case Confirm whether the evaluated product scope covers the deployment model, secret types, and administration patterns you plan to use. A certification that excludes your operating mode should not be treated as evidence for that mode.
• Demand the assumptions behind the assurance claim Ask vendors to state which threat scenarios, installation patterns, and operational constraints were in scope for the assessment. Compare those assumptions with how your team will run the platform in production.
• Treat documentation quality as a security control Review installation guidance, administrative procedures, and cryptographic documentation as part of procurement. Weak or incomplete documentation often signals that the real control boundary is narrower than the product pitch suggests.
• Use independent evaluation as a control-design input Translate certification evidence into internal policy for vault access, shared credential handling, and platform administration. If the control can’t be expressed in your governance model, it is not ready for production use.
• Cross-check with framework requirements Align your review of credential platforms with NIST SP 800-53 Rev 5 Security and Privacy Controls and your internal identity governance standard before purchase approval. Use the certification to support, not replace, the framework mapping.

Key takeaways

• Passbolt’s CSPN submission is a reminder that identity tooling must prove its assumptions, not just describe its features.
• Independent certification is most valuable when it clarifies the product’s trust boundary, threat scope, and operational limits.
• For practitioners, the test is whether certification evidence maps cleanly to your own credential governance and lifecycle controls.

Key terms

• 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.
• 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.
• Assurance Boundary: An assurance boundary is the set of functions, assumptions, and deployment conditions that a security assessment actually covers. For identity platforms, this boundary matters because features outside the assessed scope may behave differently in real use, even if the product carries a certification badge.

What's in the full analysis

Passbolt's full article covers the operational detail this post intentionally leaves for the source:

• The pre-evaluation work completed with Quarkslab and the document set required for ANSSI review.
• The Security Target and the specific security guarantees Passbolt says the CSPN process will test.
• The formal review path, including the evaluation laboratory’s role and ANSSI’s certification decision process.
• The distinction Passbolt draws between certification, penetration testing, and overall product assurance.

👉 Passbolt’s full post covers the evaluation preparation, review steps, and what happens after ANSSI submission.

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 building or maturing an IAM programme, it is worth exploring.