Is Green Security down?

We are investigating an issue with SSO SAML configurations returning 500 errors.

We have identified the issue and are rolling out a fix right now.

This incident has been resolved.

We are currently investigating an issue where an increased number of timeout responses to API calls.

We have identified and mitigated the issue. All requests are returning to normal now.

This incident has been resolved.

We are currently investigating an issue where the patient search integration with Epic/Cerner through the FHIR interface is experiencing an increase in `invalid_client` errors.

We have identified the issue and are working through a fix.

We have identified the issue as a rotated JWK Set key that was not picked up by Epic. Your CSM will reach out with a new per-tenant JWK Set URL (newly required best practice from Epic) to re-fetch the newest keys for your instance. These URLs properly handle key rotations.

We have restored the previous keys yesterday and via monitoring have found that all patient search functionality is working as it has previously. We encourage all customers to reach out to their CSM to plan for a migration to a tenant specific JWK Set URL.

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.

# 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.