Is Centrify down?

We are investigating an issue affecting Inventory Service in the US region which is impacting the ability to add or make updates to Inventory. Core platform functionality remains operational. We are working to restore full functionality as soon as possible.

We’re pleased to inform you that the incident affecting the Inventory service has been resolved. Our team has implemented a fix, and all systems are now operating normally. We apologize for any inconvenience this incident may have caused, and we appreciate your understanding and support. For any questions or concerns, please reach out to our support team at https://support.delinea.com.

Between approximately 12:32 UTC and 14:11 UTC on October 13, 2026, some users signing in to the Delinea Platform with SAML single sign-on (SSO) were unable to complete login and received an "Access Denied – Error 15" message after authenticating with their identity provider. Users who were already signed in, and users signing in without SAML SSO, were not affected. The issue was caused by a security rule at a third-party edge network provider that incorrectly blocked SAML login responses. Our engineering team applied a configuration change at 14:11 UTC and SAML SSO logins have been succeeding normally since. If you continue to experience this error, please refresh your browser and try again. 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.

The issue has been identified and a fix is being implemented.

A fix has been implemented and we are monitoring the results.

We are continuing to monitor for any further issues.

We are continuing to monitor for any further issues.

This incident has been resolved.

At approximately 9:13 PM UTC on October 13, 2026, some customers experienced premature disconnections when launching PRA Remote Application sessions. The sessions terminated after approximately 2–3 minutes. Root Cause: A recent update to the FreeRDP library introduced a regression bug that omitted the RAIL (Remote Applications Integrated Locally) client handshake during Remote Application sessions. Without this handshake, the target host treated the session as inactive and terminated it after the configured idle timeout. Resolution: The PRA engine was patched to restore the RAIL client handshake for Remote Application connections. The fix was deployed and connectivity was restored for affected customers by approximately 12:34 PM UTC on October 14, 2026. Affected Components: Platform: Privileged Remote Access - US, APAC (Singapore) and AU Backfill Notice: This incident was added to our status page retrospectively to provide an accurate record of service impact. More information on backfill incidents is available here.

## Incident Overview   A subset of customers using Privileged Remote Access \(PRA\) Remote Application sessions experienced session disconnections approximately 2 to 3 minutes after launch. Reports were received from customers across the SEA, AU, UAE, CA, UK, and US regions.   * **Start:** October 13, 2026, 21:13 UTC  * **End:** October 14, 2026, 19:28 UTC  ## Root Cause and Remediation  A scheduled update was rolled out regionally to our remote session service as part of ongoing security compliance work. This update included a new version of a third-party remote desktop protocol component, which introduced a behavioral change that prevented a specific connection handshake from completing during session initialization. As a result, affected sessions were automatically logged off for approximately 2–3 minutes after connecting successfully.  Because these disconnections completed cleanly, without generating errors in system logs or traces, the issue was not detected by existing monitoring systems before the first customer report on October 13, 2026. A fix to restore the required connection handshake was identified and deployed across all affected regions by approximately 19:28 UTC on October 14, 2026.  ## Preventative Actions  * Expand our automated Remote Application test coverage to include extended duration sessions, so time-dependent issues are caught before release.   * Add monitoring for session duration anomalies, specifically tracking sessions that disconnect at consistent short intervals \(e.g., ~2 to 3 minutes\), even when the disconnection appears clean.   We sincerely apologize for the disruption this caused and appreciate your patience while we worked to resolve it.

Between approximately 12:32 UTC and 14:11 UTC on October 13, 2026, some users signing in to the Delinea Platform with SAML single sign-on (SSO) were unable to complete login and received an "Access Denied – Error 15" message after authenticating with their identity provider. Users who were already signed in, and users signing in without SAML SSO, were not affected. The issue was caused by a security rule at a third-party edge network provider that incorrectly blocked SAML login responses. Our engineering team applied a configuration change at 14:11 UTC and SAML SSO logins have been succeeding normally since. If you continue to experience this error, please refresh your browser and try again. 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: Delinea Platform - United States, Europe, United Kingdom, Canada, Australia, Southeast Asia, United Arab Emirates Backfill Notice: This incident was added to our status page retrospectively to provide an accurate record of service impact. More information on backfill incidents is available here.

We are currently investigating an ongoing issue in the EU region. We'll provide an update soon.

A fix has been implemented and we are monitoring the results.

This incident has been resolved.

## Incident Overview On October 1, 2026, customers in the EU region had problems using Secret Server Cloud \(SSC\). Users could not launch sessions from secrets, and pages for viewing secret details and audit history loaded slowly or failed. Scheduled background tasks such as heartbeats, password changes, discovery and notifications were delayed, and some Distributed Engines could not connect. * Start Time: October 1, 2026, 08:38 PM UTC * End Time: October 2, 2026, 12:30 AM UTC ## Root Cause and Remediation SSC uses a messaging service to pass work between its components. Examples include recording secret view activity for auditing, running scheduled tasks and preparing session launches. On September 30, 2026, the SSC service that processes these messages in the EU region began handling work at a much lower rate than normal. New activity kept arriving at the normal rate, so unprocessed messages built up in the queue. When the queue reached its capacity, the extra messages were moved to a holding area for undeliverable messages. Over the following hours this holding area kept growing until the messaging service hit its storage limit. Our engineering team increased the capacity of the messaging service, scaled up and restarted the SSC EU services, and cleared the backlog of undeliverable messages. Once the backlog drained, session launches, page loads and scheduled tasks returned to normal by October 2, 2026, 12:30 AM UTC. Delayed background tasks, including heartbeats, password changes and notifications, were processed automatically after service was restored. Customers did not need to take any action. Because the services were restored immediately to end customer impact, we did not capture the diagnostic data needed to determine why their throughput dropped, so the underlying trigger remains unknown. The queue growth should have been caught earlier. During a recent migration of our alerting tooling, a configuration change sent certain cloud metric alerts, including the messaging queue size alert, to the wrong destination. That alert triggered on the morning of October 1 but never notified our on-call team. Our automated remediation for other alert types was unaffected, which masked the gap. ## Preventative Actions 1. We corrected the alert routing on October 2, 2026, so these alerts now reach our on-call team, and we are adding canary and heartbeat alerts that notify us if alert delivery from our monitoring tools stops or drops unexpectedly. 2. We are strengthening how we change alerting, by testing each alert type end to end before and after any production deployment. 3. We are monitoring for a recurrence of the slowdown and will capture the diagnostic data needed to determine its cause if it happens again. 4. We are updating our deployment cycle with a safeguard that ensures the background services are refreshed even when a release is delayed, and we are adding this step to our release checklist.  We apologize for the disruption this caused and appreciate your patience while we resolved it.