Notifications
Clear all
Topic starter
11/08/2026 3:25 pm
TL;DR: SAML certificate changes remain a predictable operational risk when ownership is fragmented across IAM, IT, app teams, and third parties, and manual rollover can disrupt service, according to Redblock’s analysis and Microsoft guidance. The core problem is not expiry detection but synchronized execution across systems that do not share one workflow.
NHIMG editorial — based on content published by Redblock: Identity Security The Last-Mile Problem in SAML Certificate Rotation
By the numbers:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
Questions worth separating out
Q: How should security teams handle SAML certificate rotation in fragmented application estates?
A: They should inventory every application that relies on the trust certificate, assign a clear owner, and make validation part of the change itself.
Q: Why do manual certificate rollover processes create identity risk?
A: Manual processes create risk because they depend on people to synchronise changes across multiple consoles, owners, and vendors.
Q: What do IAM teams get wrong about SAML certificate expiry?
A: They often treat expiry as the real problem when the real problem is distributed execution.
Practitioner guidance
- Map every SAML trust dependency Build an inventory of each service provider, owner, admin path, and validation step before the next certificate rollover.
- Convert rollover into a governed workflow Replace ticket-driven coordination with a repeatable process that applies the new certificate, verifies acceptance, and records completion state for every application.
- Add validation to the identity control itself Treat post-change sign-in testing as part of the control, not as optional QA.
What's in the full article
Redblock's full blog covers the operational detail this post intentionally leaves for the source:
- Pipeline-level walkthrough of SAML certificate rotation across disconnected applications
- Step-by-step handling of certificate retrieval, application update, vault storage, and post-change verification
- Demo of the automated workflow Redblock describes for keeping SSO working during trust changes
- Operational detail on how the process reduces manual coordination across app owners and vendors
👉 Read Redblock's analysis of SAML certificate rotation across disconnected apps →
SAML certificate rotation in fragmented app estates: are controls keeping up?
Explore further
11/08/2026 3:34 pm
Manual certificate rollover is a governance failure, not a maintenance inconvenience. The article shows that expiry is predictable but execution is not, because ownership, validation, and trust changes are split across teams and systems. That means the real control gap is lifecycle orchestration across disconnected applications. Practitioners should treat rollover as an identity governance process, not an admin chore.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
A question worth separating out:
Q: Who is accountable when a certificate rollover breaks SSO?
A: Accountability should sit with the identity owner who governs the trust relationship, not with the last person who touched a ticket. In practice, IAM, application, and vendor teams may all be involved, but one owner must be responsible for completion, validation, and escalation.
👉 Read our full editorial: SAML certificate rotation across disconnected apps is still brittle
