SAML certificates do not need CA trust for federation security

At a glance

What this is: This is an analysis of why SAML federation usually relies on self-signed certificates and explicit partner trust rather than CA-backed web trust.

Why it matters: It matters because IAM, PAM, and lifecycle teams need to govern federation trust, certificate rotation, and audit expectations without assuming SAML behaves like HTTPS.

👉 Read WorkOS's analysis of CA-signed versus self-signed SAML certificates

Context

SAML certificate trust is a federation problem, not a browser trust problem. In SAML, the identity provider signs assertions and the service provider verifies them with the shared public certificate, so security depends on the configured trust relationship between the two parties.

That difference matters for IAM programmes because certificate decisions in federation are often driven by governance, compliance, and lifecycle process, not by public certificate authority requirements. Teams that treat SAML like TLS often introduce unnecessary operational overhead without improving the actual trust model.

Key questions

Q: How should security teams choose between self-signed and CA-signed SAML certificates?

A: Choose self-signed certificates by default if the goal is standard SAML federation security. Use CA-signed certificates only when policy, audit, or enterprise PKI tooling explicitly requires them. The security control is the pinned trust relationship between IdP and SP, not public certificate authority validation.

Q: Why do SAML certificates not need the same trust model as HTTPS certificates?

A: SAML certificates secure assertion signing and verification between two known parties. HTTPS certificates prove a site to any browser on the public internet, so they depend on global CA trust. SAML does not need that model because trust is established directly between the identity provider and service provider.

Q: What breaks when SAML certificate lifecycle management is weak?

A: Weak lifecycle management creates expired certificates, failed federation logins, and risky fallback behaviour when teams scramble to restore access. It can also leave stale trust in place after a relationship changes. The main failure is not cryptography, but operational drift in a controlled identity dependency.

Q: When should organisations require CA-signed certificates for SAML?

A: Require CA-signed certificates only when a formal policy, audit expectation, or internal PKI standard makes them necessary. They are not a SAML security requirement. If the organisation does not need that extra governance layer, self-signed certificates are usually the cleaner and equally secure choice.

Technical breakdown

How SAML signature trust differs from TLS trust

SAML uses certificates for cryptographic signing and verification, not for proving a website to the public internet. The identity provider signs the assertion with its private key, and the service provider checks that signature with the IdP’s public certificate. That means the security boundary is the relationship between two configured parties, not a global certificate authority chain. The certificate can be self-signed because the service provider is trusting a known key, not the public PKI ecosystem.

Practical implication: validate that the IdP certificate is distributed and pinned through a controlled federation process, not through assumptions borrowed from web TLS.

Why self-signed certificates are the normal SAML choice

Self-signed certificates are common in SAML because they satisfy the actual trust requirement: both sides agree on the same public key. A CA adds an external trust chain that SAML does not need for assertion integrity or origin validation. In practice, the important control is key management, including secure generation, exchange, storage, and replacement of the certificate when it changes. The certificate authority is optional unless an organization’s internal policy demands it.

Practical implication: focus certificate governance on secure exchange, rotation, and validation, rather than on buying CA-backed trust that SAML does not require.

When CA-signed certificates still make sense

A CA-signed certificate can still be useful where policy, audit expectations, or existing PKI tooling create a governance requirement. That does not change the SAML security model, but it can simplify alignment with enterprise certificate lifecycle processes. The real question is whether the CA is solving a federation trust problem or just satisfying a broader control framework. If it is the latter, the value is administrative consistency, not stronger SAML assurance.

Practical implication: use CA-signed certificates only when policy or tooling requires them, and avoid treating them as a security prerequisite for SAML federation.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

SAML does not inherit the web PKI trust model. The federation relationship is explicit and bilateral, which means the security property comes from the configured trust between the identity provider and service provider, not from a public certificate chain. That is the core reason self-signed certificates are standard in SAML and why CA semantics are often misapplied by teams coming from HTTPS thinking. Practitioners should separate federation assurance from browser trust assumptions.

Certificate governance in SAML is a lifecycle problem, not a reputation problem. The operational question is whether the IdP certificate is generated, exchanged, validated, rotated, and retired cleanly across the trust relationship. A CA can help with process consistency, but it does not replace the need for controlled federation onboarding and offboarding. Practitioners should treat SAML certificate handling as part of identity lifecycle governance.

CA-backed trust can reduce policy friction without changing the security model. Some organisations require CA-signed certificates for all cryptographic material because their control environment is built around enterprise PKI. That requirement is about audit alignment and operational standardisation, not about SAML needing third-party trust to function securely. Practitioners should decide based on governance fit, not on a false equivalence with TLS.

Federation trust should be managed as an explicit identity boundary. The right control question is not whether the certificate is publicly trusted, but whether the configured relationship between IdP and SP is tightly scoped, validated, and retired when no longer needed. That is where SAML assurance can degrade if lifecycle discipline is weak. Practitioners should review federation trust as a governed identity dependency, not a generic certificate task.

From our research:

• Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
• 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases.
• The governance lesson extends beyond SAML, as the Ultimate Guide to NHIs - Standards frames identity controls as explicit trust and lifecycle problems, not default platform assumptions.

What this signals

Certificate policy decisions in SAML should be anchored in identity governance, not in browser-era trust habits. Teams that standardise on one certificate model for every cryptographic use case often overcomplicate federation without improving assurance. The better signal is whether onboarding, rollover, and retirement are controlled end to end across the identity relationship.

Secrets and certificates behave like governed identity assets when their lifecycle is visible. Fragmented ownership turns federation metadata into operational debt, which is why control review should include certificate exchange paths, expiry monitoring, and offboarding hygiene. The Ultimate Guide to NHIs - What are Non-Human Identities is useful here because it frames certificates as part of the broader non-human identity surface.

SAML trust models will keep colliding with broader secrets governance programmes. As organisations consolidate identity controls, they need one view of how certificates, tokens, and service credentials are issued and retired. That convergence is where federation hygiene and NHI governance start to overlap, especially when a separate secrets control plane must track certificate rotation and provenance.

For practitioners

• Treat SAML certificates as federation keys, not web trust artifacts Document the exact IdP-to-SP trust relationship, including how the public certificate is exchanged, pinned, and replaced. Use the certificate as a controlled federation object, not as proof of internet identity.
• Align certificate choice to governance requirements Use self-signed certificates by default unless policy, audit, or existing PKI tooling explicitly requires a CA-signed certificate. Do not add CA dependency unless it solves a real control requirement.
• Build certificate rotation into federation lifecycle Test certificate replacement before expiry, validate rollover behaviour with the service provider, and confirm that old keys are removed after cutover. Rotation should be a planned federation event, not an emergency change.
• Review SAML offboarding as a trust-retirement process When an IdP, application, or federation relationship is retired, remove the corresponding trusted certificate and metadata so stale assertions cannot be accepted later.

Key takeaways

• SAML federation security depends on explicit trust between IdP and SP, not on the public CA trust model used by HTTPS.
• Self-signed certificates are the standard SAML choice because they satisfy the real security requirement, which is pinned signature verification between two known parties.
• Organisations should choose CA-signed certificates only when policy or tooling requires them, and should invest more attention in rotation, validation, and retirement.

Key terms

• Saml Federation Trust: SAML federation trust is the explicit agreement between an identity provider and a service provider to accept signed assertions from a specific partner. It is not public internet trust. The security property comes from configured key exchange, signature validation, and lifecycle management of the trusted certificate.
• Certificate Lifecycle Management: Certificate lifecycle management is the process of generating, distributing, rotating, validating, and retiring certificates before they create availability or trust problems. In identity systems, the important part is keeping the trust relationship current. Weak lifecycle discipline causes expired trust, failed logins, and stale access paths.
• Service Provider: A service provider is the application or platform that consumes SAML assertions after verifying the identity provider's signature. It does not need to trust the public internet certificate chain for the IdP. It needs a controlled, current trust relationship with the IdP certificate it has been configured to accept.

Deepen your knowledge

SAML certificate governance and federation trust are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are formalising lifecycle controls for certificates and related identity assets, it is a useful place to start.

This post draws on content published by WorkOS: Are CA-signed certificates necessary for SAML security? Read the original.