Notifications
Clear all
Topic starter
08/06/2026 3:58 pm
TL;DR: SAML signatures use explicit trust between the identity provider and service provider, so self-signed certificates are normally secure and standard, while CA-signed certificates matter mainly when policy, audit, or existing PKI tooling require them, according to WorkOS. The practical issue is certificate governance, not internet-facing trust chains.
NHIMG editorial — based on content published by WorkOS: Are CA-signed certificates necessary for SAML security?
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- How the IdP and SP exchange and trust the public certificate during SAML setup
- Which enterprise policy and compliance scenarios make CA-signed certificates attractive from a governance perspective
- How certificate rotation and renewal behave in real federation environments
- Why auditors may prefer CA-backed certificates even when the SAML security model does not require them
👉 Read WorkOS's analysis of CA-signed versus self-signed SAML certificates →
SAML certificates and federation trust: what IAM teams need to know?
Explore further
08/06/2026 5:19 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: SAML certificates do not need CA trust for federation security
