- Challenge
- Users could not authenticate through a federated identity path
- Assumption
- Renewal of a public CA certificate would be routine
- Decision
- Treat renewal and deployment as one controlled lifecycle
- Outcome
- Persistent validation and authorised rotation before expiry
A federated authentication design connected Microsoft identity services with Cisco Duo. The platforms were available, user accounts were valid and multi-factor authentication had not been deliberately disabled. Users still could not authenticate correctly.
The failure was a certificate in the federation path. A publicly issued certificate had reached its expiry date, trust validation failed and the authentication chain stopped working. One expired object had become an organisation-wide access outage.
Nothing about the date was unpredictable. Certificate expiry is declared when the certificate is issued. The operational failure was that renewal, recreation and deployment had remained a manual procedure understood by too few people.
Staff had changed since the original implementation. Their replacements could see that a certificate existed, but did not understand why it was required, how it had been created, where every relying component stored it or what would happen when it was replaced. The certificate was treated as static configuration even though it had always contained a deadline.
This failure pattern remains current. GitHub reported a five-hour Actions incident in July 2026 after an internal SSL certificate expired. A replacement had been generated, but its deployment still depended on a manual step that did not happen after the alert. GitHub responded by adding independent expiry monitoring and improving renewal automation. GitLab has documented a separate case where an expired TLS certificate, a lost certificate-authority key and incomplete operational knowledge placed hundreds of servers at risk when connections restarted.
The authentication vendors describe the same consequence. Cisco Duo documentation states that expired SAML signing or encryption certificates can block SSO access, and its 2026 certificate-authority field notice warns that applications configured to fail closed can block access when trust material is not updated.
Renewal therefore cannot mean obtaining another certificate and closing a ticket. The control must cover discovery, validation, authorisation, issuance, deployment to every participant in the trust relationship, end-to-end authentication testing and confirmation that the previous certificate can be retired safely.
The durable fix is persistent validation of every certificate in the authentication path, with alerts early enough to act and a documented owner authorised to renew or regenerate and apply it. Wherever the platform permits it, issuance and deployment should be automated together. Where a manual approval is necessary, the process should resume automatically after approval and prove that the new certificate is active.
Break-glass access and a tested recovery route must remain available outside the federation path. They do not replace lifecycle management; they prevent a missed renewal from also removing the means to repair it.
Certificates do not expire unexpectedly. Organisations are surprised only when a known deadline has no persistent owner, no complete deployment process and no test proving that the next certificate works.
Engineering lessons
- Certificate inventory must include every relying component, owner, expiry date and deployment location.
- Automated issuance without automated or controlled deployment still leaves a manual outage path.
- Renewal is complete only after end-to-end authentication has been tested with the new certificate.
- Staff changes must not remove the knowledge or authority required to rotate trust material.
- Break-glass access must not depend on the federation chain it is intended to recover.
References
- GitHub availability report: July 2026
- GitLab: The Consul outage that never happened
- Cisco Duo: SAML certificate expiration and renewal
- Cisco field notice: Duo certificate authority bundle expiration
Read the engineering principles behind this work →
Confidentiality: Engineering Notes are based on real engagements. Client identities, timelines and identifying details may be changed to protect confidentiality. The engineering decisions and lessons remain representative of the work undertaken.
