Elevated SSO Sign-in Errors

Update timeline

1. resolved Aug 11, 2026, 07:37 PM UTC

   Login via SSO showed an increase in failed logins for a subset of our users as a result of us upgrading our SSL library to the latest version. This caused a compatibility issue with some SSO configurations which were identified and fixed by 8:30ET.

2. postmortem Aug 11, 2026, 09:14 PM UTC

   # Incident Report: SSO Sign-On Failures — August 11, 2026 **Status:** Resolved **Impact window:** August 11, 2026, 12:00 AM – 8:30 AM ET **Affected:** A subset of users authenticating through certain single sign-on \(SSO\) configurations ## What happened During a scheduled maintenance release, we updated a core cryptography library used across our platform. The new version of that library changed some of its default security settings which caused conflicts with support for legacy SSL configurations some of our customers use. For most SSO configurations this had no effect, but for a subset using specific signature and protocol settings, those changes prevented sign-on from completing. Affected users were unable to log in. Users on other authentication methods were not affected, and the issue was limited to sign-on. No customer data was lost, altered, or exposed. ## Timeline \(ET\) | Time | Event | | --- | --- | | 12:00 AM | Scheduled release deployed, including the library update | | ~7:00 AM | Sign-on failure reports received from affected customers | | ~7:00–8:30 AM | Cause identified and fix prepared | | 8:30 AM | Update reverted; sign-on restored for all affected users | ## Why it took us until 7:00 AM to know The release went out overnight, and the failure was invisible to us until affected users began signing in that morning and told us. We do not have the capability to test SSO from client sites since that would require accounts at each of our clients. Once we knew, we identified the cause and restored service within 90 minutes. ## What we have done * Reverted the library update and confirmed sign-on was restored * Added automated testing that exercises the affected SSO flow so this specific regression cannot recur silently ## What we are changing * **Broader SSO test coverage.** We are expanding our pre-release test suite to cover the full range of SSO configurations our customers actually use, rather than a representative subset. * **Stricter handling of security-library updates.** Updates to cryptography and authentication components will now go through a dedicated compatibility review and a staged rollout instead of a standard batch release, so any incompatibility affects a small slice of traffic and is caught before it reaches everyone. * **Post-deployment verification.** Critical paths, including authentication, will be verified automatically after every deployment before it is considered complete. ## A note on our communication We published this report after the incident was already resolved rather than notifying customers while it was in progress. Our intent was to avoid alerting people to a problem that had already been fixed. In hindsight, customers who were locked out and had contacted us deserved to hear from us during the incident, not only after. In the future, we will have more timely updates to our status page to notify users of the incident in real-time.