Secret Server Cloud: Multiple Regions - Connectivity Issues from Some Customer Networks

Update timeline

1. resolved Sep 30, 2026, 08:07 AM UTC

   Between approximately 4:10 AM EDT and 6:45 AM EDT on September 28, 2026, some customers were unable to connect to Secret Server Cloud from certain corporate networks. Affected users saw connection reset or timeout errors when accessing their tenant. Access from other networks was not affected. Customers who restrict tenant access to specific IP addresses were unable to log in during this period. The issue was caused by a connectivity problem at a third-party edge network provider that affected traffic from some customer networks in the region. Traffic was routed through alternate locations, and connectivity was restored for affected customers by approximately 6:45 AM EDT. We apologize for the inconvenience this has caused and appreciate your patience as we worked to restore normal service. For any questions about this incident, please reach out to our support team at https://support.delinea.com. Affected Components: Secret Server Cloud - Europe, United Kingdom, United States, Asia Pacific (Singapore)

2. postmortem Sep 30, 2026, 08:48 AM UTC

   ## Incident Overview Beginning at 07:10 UTC on September 28, 2026, a subset of Secret Server Cloud tenants in the Europe, UK, US, and APAC \(Singapore\) regions experienced connectivity failures. Customers on certain corporate networks encounter connection timeouts or reset errors when attempting to reach their tenants. Customers with tenant access restrictions enabled had no alternate path available and were unable to access Secret Server Cloud for the duration of the incident. * Start: September 28, 2026, 07:10 UTC * End: September 28, 2026, 10:45 UTC ## Root Cause and Remediation The Secret Server Cloud edge network experienced two separate issues that prevented traffic from some customer networks from reaching their tenants. The first was due to a defect in a software update that our edge network provider deployed. Under a specific production condition that was not identified in the provider’s pre-deployment testing, the defect caused traffic processing components to restart at several of its network locations. These components recovered automatically, and service at the affected locations was restored between 07:47 and 08:20 UTC. The second was due to an upstream internet carrier issue affecting our edge network in London caused packet loss and connection timeouts. As a result, customer networks whose traffic was routed through London continued to be affected after the first issue had cleared. Connectivity was fully restored at 10:45 UTC after traffic was rerouted away from the affected carrier. ## Preventive Actions * The provider has deployed a fix for the software defect and is strengthening its pre-deployment validation, the resilience of its infrastructure across locations, and its automated recovery mechanisms. We are tracking these commitments through to completion. * We are conducting a full review of the London carrier issue with our provider, including why traffic was not rerouted sooner, and reducing failover time so future carrier disruptions are isolated quickly. We sincerely apologize for the disruption this caused and the inconvenience to your operations. We are committed to preventing recurrence through the above actions.