Centrify outage history

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.

Starting approximately 12:32 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.

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, SEA, UK and AU regions 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.

We are investigating reports of slow logins and intermittent login failures for Delinea Platform customers in the EU, UK, Southeast Asia, and Australia regions. Starting at approximately 23:20 UTC on September 28, 2026, some users may take much longer than usual to sign in. Some sign-in attempts may fail with a timeout or HTTP 504 error. Users who are already signed in may also see slower responses when their session is validated. Our engineering team is actively engaged and has identified a degraded dependency affecting the authentication service in these regions. We are working on mitigation now. If a sign-in fails, please retry. We will post another update within 30 minutes, or sooner if we have new information.

We have applied a fix for customers in the EU and Australia regions. Sign-in performance and error rates in these regions have returned to normal as of approximately 01:05 UTC on September 29, 2026. We are monitoring to confirm the recovery holds.

We have applied a fix for all affected regions: EU, UK, Southeast Asia, and Australia. Sign-in performance and error rates have returned to normal as of approximately 01:10 UTC on September 29, 2026. We are monitoring to confirm the recovery holds. If you still have trouble signing in, please refresh your browser and try again. If the problem continues, contact Delinea Support.

This incident has been resolved.

## Incident Overview  Delinea Platform users in the EU, UK, Southeast Asia, and Australia regions experienced very slow logins and intermittent login failures. Affected functionality included Entra ID single sign-on, local account authentication, and Privileged Remote Access \(PRA\) session establishment.  * Start: September 28, 2026, approximately 11:20 PM UTC  * End: September 29, 2026, approximately 01:10 AM UTC   ## Root Cause and Remediation  A scheduled deployment introduced the use of regional cache replicas to improve authentication performance. Pre-release validation confirmed the replicas were active, but a firewall configuration error prevented data synchronization between the primary cache and the regional replicas. The cloud provider's standard health reporting continued to show the replicas as healthy and available, so the issue was not surfaced before or during the release.   When the authentication service attempted to read from these replicas, requests stalled and timed out, resulting in login failures. Internal monitoring detected the elevated error rates, and the engineering team identified the root cause and rolled back the change. The rollback returned all affected regions to the primary cache and restored normal authentication. Regional cache replicas will remain disabled for the EU, UK, Southeast Asia, and Australia regions while we evaluate alternative architectures. We assessed private network connectivity between caches and determined it does not meet our reliability requirements.  ## Preventive Actions  * We are making significant improvements to how the authentication service recovers from cache connectivity problems. The goal is that a degraded cache connection no longer causes stalled or failed logins.  * We have added alternate monitoring for connection failures, giving earlier detection of cache related issues that are not reflected in the cloud provider's health reporting.  We apologize for the disruption and are committed to preventing recurrence through these measures.

We are investigating intermittent reports of issues with the Delinea Mobile App's Authenticator functionality working as expected post 26.2 Deployment. If you are experiencing this issue, please use other MFA options until we are able to resolve this issue. Our team is actively investigating and will provide an update when one is available.

The issue has been identified and a fix is being worked on. The fix will require a new deployment during a weekend maintenance window. In the meantime, please refer to the below KB Article for details on the issue and ways to workaround it. https://support.delinea.com/s/article/1790702420275 Thanks for your patience. If you have any questions or experience any issues, please open a case at https://support.delinea.com or call our support line at +1 202-991-0540.

We’re pleased to inform you that the incident affecting the service(s) listed below 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 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) 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 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.

We are investigating an issue affecting login and access to Secret Server Cloud for a subset of customers across the US, EU, and UAE regions. Our engineering team is actively investigating the issue and working to resolve it as quickly as possible.

We are continuing to monitor for any further issues

This incident has been resolved.

We are investigating an issue affecting login and access to the Delinea Platform in the US region. Some users may be unable to log in or may experience slow performance when accessing their tenants. Our engineering team is actively engaged. We will provide an update as soon as more information is available.

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.

This incident has been resolved.

## Incident Overview On September 16, 2026, Delinea Platform customers in the US region experienced login failures and severe slowness when signing in or accessing their tenants. Affected users may have seen "upstream request timeout" errors on the sign-in screen or experienced long delays when loading their tenant. * **Start:** September 16, 2026 approximately 11:40 AM EDT \(UTC-4\) * **End:** September 16, 2026 approximately 1:02 PM EDT \(UTC-4\) ## Root Cause and Remediation The Delinea Platform relies on a caching service to support login, authentication, and other identity-related operations. Over the preceding weeks, demand on this service in the US region had grown steadily with increasing platform usage, leaving limited operating headroom. In addition, authentication services were holding connections to the caching service open over time rather than releasing them, which gradually consumed its available capacity. A configuration that distributes read traffic across an additional caching resource, which would have provided extra headroom, was not active at the time. On September 16, normal traffic volumes pushed the caching service beyond its operating capacity, causing slow and failed requests for login and identity operations across the US region. This incident involved the same caching infrastructure as the [August 28, 2026 incident](https://status.delinea.com/incidents/1s7gw9kyjwyq). That incident was triggered by an unusually large volume of synchronization activity and was addressed by increasing the caching service's memory capacity. This incident occurred under normal traffic conditions, which showed that compute capacity and connection handling also needed to be addressed. Our engineering team restarted the affected authentication services, which released the accumulated connections and restored login functionality. The caching service was also scaled to a higher tier that doubles its compute capacity, and we continued to monitor the service until full recovery was confirmed. Since the incident, caching service utilization has remained within normal operating thresholds, and read traffic is now distributed across an additional caching resource. ## Preventative Actions Following the August 28, 2026 incident, we committed to several improvements to this caching infrastructure. Below is the progress on each, along with additional actions identified from this incident. Work on all items is ongoing. **Progress on actions from the August 28 incident** * **Increase the capacity and resiliency of our caching infrastructure.** The US caching service has been scaled to a higher tier that doubles its compute capacity. Read traffic is now distributed across an additional caching resource. We are continuing this work by moving token-related operations to dedicated caching infrastructure for further headroom. * **Correct monitoring thresholds to detect capacity pressure proactively.** During this incident, our monitoring did identify capacity pressure ahead of customer impact, but the alerts were not actioned in time. We are continuing this work by removing non-actionable alerts for core authentication services and requiring immediate engineering engagement on the first alert. * **Limit connection-recovery retries.** This work has been expanded to cover how authentication services manage caching connections overall, including connection release and timeout settings, so capacity is not gradually consumed over time. * **Apply rate limiting to large synchronization jobs.** Rate limiting is being implemented. We are also reducing unnecessary high-volume requests from integrated services to the caching layer. **Additional actions from this incident** * Implement scheduled, automated rolling restarts of authentication services as an interim safeguard until the connection handling improvements are deployed. We recognize this is not the first sign-in disruption on the Delinea Platform in recent weeks, and we are not treating it lightly. Beyond the actions above, Delinea leadership has made our Platform reliability an executive-sponsored priority, ahead of feature work where the two compete. That includes better detection of issues affecting critical workflows such as sign-in, and planning capacity ahead of growth. We sincerely apologize for the disruption this caused to your operations and will continue to share our progress.

This incident has been resolved. We apologize for the disruption this caused. Investigating We are investigating reports of Delinea Platform tenants displaying a frozen tenant message, preventing users from signing in and accessing their environment. The condition began at approximately 4:49 PM EDT due to an incorrect configuration change, preventing certain customers from accessing their tenants. Engineering identified the cause, ran a revert job beginning at approximately 5:08 PM EDT, and all affected tenants were confirmed unfrozen by 5:55 PM EDT. 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 This report covers two related occurrences that affected Delinea customer tenants. The second occurrence, September 19-20, 2026, was a direct consequence of incomplete recovery from the first occurrence on September 4, 2026, and both are documented together under this incident. #### Occurrence 1: September 4, 2026 A subset of Delinea Platform tenants entered a frozen state, displaying a tenant frozen message that prevented users from signing in and accessing Delinea Platform and Secret Server Cloud. **Start:** September 4, 2026, 4:15 PM EDT \(20:15 UTC\) **End:** September 4, 2026, 5:55 PM EDT \(21:55 UTC\) #### Occurrence 2: September 19-20, 2026 A subset of Secret Server Cloud tenants displayed a scheduled for deletion notice that prevented users from signing in to Secret Server Cloud. Sign-in to Delinea Platform itself remained available. **Start:** September 19, 2026, 10:28 PM EDT \(September 20, 02:28 UTC\) **End:** September 20, 2026, 1:50 PM EDT \(17:50 UTC\) ## Root Cause and Remediation #### Occurrence 1: September 4, 2026 Delinea deprovisions tenants that are no longer under an active subscription. The tenant list for this cycle was built using selection criteria that evaluated only the original subscription expiration date and did not account for subsequent renewals. As a result, tenants that had renewed and remained fully entitled were treated as expired and were included in the list alongside legitimate deprovisioning tenants. Our deprovisioning workflow includes a customer-facing advance notification stage, which displays an in-application notice to tenant administrators ahead of any deletion activity. That notice serves both as a customer warning and as an internal verification step, because any active customer receiving it would have surfaced the error well before execution. This stage was not applied for this cycle; the frozen state was applied directly instead, so the error in the selection criteria went undetected until the job ran. When the scheduled job executed at 4:15 PM EDT, the frozen tenant state was applied to the affected active tenants. Following the first customer report at 4:49 PM EDT, Engineering identified the cause and initiated a revert job at 5:08 PM EDT. The revert completed at 5:55 PM EDT and sign-in access was confirmed restored across all affected tenants. However, the September 4 change had also set the subscription end date for affected Secret Server Cloud tenants to August 20, 2026. The revert restored tenant access but did not return those end dates to their correct values, and post-recovery verification confirmed sign-in access only, not the accuracy of the underlying subscription records. This condition remained undetected and led directly to Occurrence 2. #### Occurrence 2: September 19-20, 2026 Secret Server Cloud includes a standard automated lifecycle process that restricts sign-in and schedules a tenant for deletion 30 days after its subscription end date. On September 19, 2026, 30 days after the incorrect August 20, 2026 end date, this process identified the affected tenants as expired and applied the scheduled for deletion state. The lifecycle process behaved as designed; the fault was the incorrect subscription data left in place after Occurrence 1. Delinea Support began restoring access for individual tenants starting at 12:09 AM EDT on September 20. Engineering identified every tenant carrying the incorrect end date then extended the subscription end date for all affected tenants as a temporary measure, and access was restored across the full set by 1:50 PM EDT on September 20. Between September 21 and September 23, 2026, Delinea reviewed each affected tenant individually against its active entitlements and replaced the temporary end date with the correct value. During this period, some customers may have observed an inaccurate subscription end date or license detail in their account information; this did not affect access. If your organization observes a subscription end date or license detail that does not match your current entitlement, please contact our [Support team](https://support.delinea.com/s/). No tenant was deleted, and no customer data was deleted, modified, or otherwise affected in either occurrence. The impact was limited to tenant access. ## Preventative Actions * Bulk tenant deprovisioning has been retired. All bulk tenant lifecycle actions are paused, and deprovisioning will be processed individually. * Automate the tenant lifecycle end to end from current subscription records, including renewals and subscription changes, replacing the manual multi-step process. Each tenant will be validated against active subscription records before any state change is applied. * Make every lifecycle stage mandatory and non-skippable, beginning with an advance notice period during which tenant administrators see an in-application notice and all functionality continues to operate normally. * Ensure frozen tenants remain recoverable for a defined retention period before any permanent deletion, with restoration driven directly from corrected subscription records. * Strengthen incident recovery procedures so that any restoration of tenant state also restores and reconciles the associated subscription records, and recovery is verified against the system of record, not sign-in access alone, before an incident is closed. * Add internal monitoring and alerting for abnormal volumes of tenant freeze or scheduled for deletion events, and for anomalous patterns in subscription data, so that issues of this type are detected by Delinea before customers are affected. We sincerely apologize for the disruption caused by both occurrences. We recognize that the second occurrence resulted from our incomplete recovery from the first, which extended the impact on your operations. Restoring access was our immediate priority in each case, and the actions above are being tracked to completion to ensure this does not recur.

We are investigating an issue affecting login and access to the Delinea Platform in the US region. Some users may be unable to log in or may experience slow performance when accessing their tenants. In most cases, retrying the login attempt allows users to successfully access their tenant. Our engineering team is actively engaged. We will provide an update as soon as more information is available.

We are continuing to investigate login and access issues affecting the Delinea Platform in the US region. Affected users may see an "upstream request timeout" error message when attempting to sign in, or may experience slow performance when accessing their tenant. Our engineering team is fully engaged and treating this as a top priority. We will provide an update as soon as more information is available.

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

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

This incident has been resolved. Login and access to the Delinea Platform in the US region have returned to normal, and users should no longer encounter errors or degraded performance when signing in. We are continuing our investigation into the underlying cause and will share a root cause analysis once that investigation is complete. We apologize for the disruption this caused.

## Incident Overview On August 28, 2026, Delinea Platform customers in the US region experienced intermittent login failures and slow performance when signing in or accessing their tenants, including error or timeout pages on the sign-in screen for some users. In some cases, retrying the login attempt allowed users to successfully access their tenant.   * Start: August 28, 2026 approximately 17:29 UTC  * End: August 28, 2026 approximately 19:19 UTC  ## Root Cause and Remediation  A caching related code change that was made on Aug 27, combined with an unusually large volume of background synchronization activity on Aug 28, exceeded the normal operating capacity of our caching infrastructure supporting login and authentication services. Connections to it began failing and other dependent services attempted to recover those connections repeatedly rather than cleanly, preventing the caching infrastructure from stabilizing on its own. This led to slow or failed login attempts and delays in identity-related operations across the US region.  Our engineering team rolled back the caching change and restarted the affected services, which cleared the failed connections and began restoring functionality, though performance remained degraded. The caching resource was scaled up to restore normal performance. We continued to closely monitor the service until full recovery was confirmed.  ## Preventative Actions * Increase the capacity and resiliency of our caching infrastructure by distributing workloads across additional resources.  * Correct monitoring thresholds to ensure capacity pressure is detected proactively before it impacts platform performance.   * Limit connection-recovery retries to prevent recovering connections from compounding system load during a stress event.  * Apply rate limiting to large synchronization jobs to prevent any single job from negatively impacting platform-wide performance.  We sincerely apologize for the disruption this caused and the inconvenience to your operations. We are committed to preventing recurrence through the above actions.

This incident has been resolved. We apologize for the disruption this caused. Investigating We are investigating an issue where users in non-US regions are unable to establish new remote sessions. Affected users receive an "Engine unavailable" message when launching a session. Impact is limited to customers in non-US regions. Tenants hosted in the US region are not affected. We will provide an update as soon as we have more information. 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 in non-US regions were unable to launch new PRA sessions and received an "Engine unavailable" error. Existing running sessions were unaffected. * Start: August 14, 2026, 09:46 UTC * End: August 14, 2026, 10:45 UTC ## Root Cause and Remediation A new version of the PRA service was deployed to production on August 14, 2026 at 09:46 UTC. The new version did not correctly apply a required configuration value in the production environment, which prevented the service from locating the session engine for non-US regions. Affected customers were consequently unable to launch new sessions and received an "Engine unavailable" error. Following an increase in backend error rates during post-deployment monitoring, correlated with incoming customer reports, the deployment was rolled back to the previous stable version. Rollback completed at 10:45 UTC. Resolution was verified through backend logs and by confirming that impacted customers could successfully launch new sessions. ## Preventative Actions * Review the deployment process to determine why the configuration issue was not detected prior to production release. * Implement a staged rollout model so that new service versions are released to a single region and validated before wider deployment. * Introduce automated post-deployment health checks, including a synthetic session launch per region, that gate promotion and trigger rollback on failure. We sincerely apologize for the disruption this caused and appreciate your patience while we worked to resolve it.

We are investigating reports of degraded performance affecting Secret Server. Some users may be unable to access the Vault UI. Users may encounter the error: [Federation Runtime]: remoteEntryExports is undefined, which can prevent access to secrets. Our team is actively investigating the cause and working to restore normal service. We will provide updates as more information becomes available.

After further investigation, we have determined that this issue is isolated to Secret Server on-premises deployments and does not affect Secret Server Cloud (SSC). No impact to SSC has been identified in the US, EU, or SEA regions. This incident is now resolved.

We identified an issue affecting Secret Server Cloud for a subset of customers in the Singapore region due to increased load on backend infrastructure. Affected users experienced slow response times or difficulty accessing their instance. This was a performance issue only. This issue has been resolved and normal performance has been restored. We apologize for any inconvenience this may have caused. 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  On July 29, 2026, a subset of Secret Server Cloud customers in the Singapore region experienced a performance issue due to increased load on backend infrastructure. Affected users experienced slow response times or difficulty accessing their instance.  Start of Impact: July 29, 1:41AM UTC  End of Impact: July 29, 2:32AM UTC  ### Root Cause  During the affected period, a shared backend resource supporting the Singapore region experienced a spike in utilization that pushed it to its maximum capacity. An automated process responsible for scaling resources to handle the increased load failed to execute as expected, resulting in increased response times for a subset of customers in that region.  ### Preventative Actions  To prevent recurrence, the following measures are being implemented:  * Enhancing our automated scaling process to reduce the risk of similar issues occurring in the future.  We sincerely apologize for the disruption this caused and the inconvenience to your operations. We are committed to preventing recurrence through the above actions.

We are investigating reports that some Secret Server Cloud users are unable to sign in and are being redirected to an error page. We are actively working to resolve the issue and will provide another update soon.

We have identified the root cause of the issue. A configuration change prevented affected tenants from connecting to the database, causing the application to fail to load and display error pages. Our engineering team has applied a corrective change and is validating the fix. We will provide another update soon.

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

This issue has been resolved, and services are operating normally. We will continue to monitor to ensure stability.

## Incident Overview  On July 28, 2026, a small subset of Secret Server Cloud tenants were unable to sign in or encountered errors when navigating between pages.  Affected tenants could not establish a connection to their database, which caused the application to fail to load.  * Start: July 28, 2026, approximately 03:11 AM UTC  * End: July 28, 2026, approximately 04:05 PM UTC  * Regions impacted: Very small subset of tenants across multiple regions ## Root Cause and Remediation  During an internal release step, a supporting service was rebuilt and deployed at a version that did not match the version running in Secret Server Cloud production. The two versions format database connection settings differently, and the newer format included a setting the production application did not recognize.  That value was written to an internal cache and served to tenants as their cached entries were refreshed. Because refresh timing varies by tenant, tenants became affected at different points rather than all at once, which is why impact was limited to a subset rather than the full region.  Our Engineering team identified the root cause, redeployed the supporting service at the version matching production, and cleared the affected cache entries. Access was restored as corrected values propagated, and each affected tenant was validated individually before the incident was closed. ## Preventative Actions  * Add automated compatibility testing and deployment validation checks to catch configuration and version mismatches before code reaches production.  * Improve detection of tenant-level database connection failures so this class of issue is identified through internal monitoring rather than customer reports.  * Strengthen internal review processes for cache and configuration management to reduce the risk and impact of similar issues in the future. We sincerely apologize for the disruption this caused and the inconvenience to your operations. We are committed to preventing recurrence through the above actions.

We have identified an issue preventing some customers from connecting via RDP or changing passwords remotely. We are actively working to resolve the issue and will provide another update soon.

We have identified the issue preventing some customers from connecting via proxy or changing passwords remotely. During this incident, some customers also experienced errors when creating folders. Our engineering team has isolated the root cause and is actively implementing a fix to restore normal service. We will provide another update as progress continues.

We have applied mitigation measures to restore service availability and are actively monitoring the environment to ensure continued stability. We apologize for any inconvenience this may have caused and appreciate your patience.

The issues affecting our Secret Server Cloud customers has been resolved. We apologize for any inconvenience this may have caused.

## Incident Overview On July 27, 2026, Secret Server Cloud \(US region\) customers experienced widespread failures with RDP sessions, remote password rotation, and folder creation. The root cause was a critical internal caching layer that filled up to capacity because session entries were being stored in it without expiration. As the cache filled, it began rejecting write operations, causing a backend processing service to fail. Messages continually accumulated in an internal message queue which degraded performance for all affected tenants. * Start: July 27, 2026, approximately 2:00 PM EDT * End: July 27, 2026, approximately 4:10 PM EDT * Region impacted: US ## Root Cause and Remediation The internal caching layer had been accumulating session data with no expiration for over 20 days. At the time of investigation, approximately 86% of cache entries had no expiration set. The root cause is a code-level bug that was not setting expirations properly on session entries. Once the cache reached capacity, new writes were rejected, breaking the log pipeline and cascading into broader service failures across tenants. To remediate, the caching layer was manually flushed at approximately 4:04 PM EDT, restoring write capacity and allowing the message queue to drain. A code fix to add TTL \(time-to-live\) to the affected keys has been identified and is in progress. ## Preventative Actions * Apply a code fix to add TTL to session entries and other unbounded growth keys in the caching layer, preventing recurrence regardless of deployment cadence. * Add memory utilization alerting for the caching layer at defined thresholds, so memory pressure is detected proactively before capacity is reached. * We are looking into adding a post-release action for flushing the cache as a standard step in the deployment process We sincerely apologize for the disruption this caused and the inconvenience to your operations. We are committed to preventing recurrence through the above actions.

We are aware of reports from several customers experiencing Connector connectivity issues in the US region. We have identified the cause as the network infrastructure supporting Connector traffic and have mitigated the impact. Connectivity should now be restored. Further investigation and infrastructure changes are planned for next week to prevent recurrence. 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  On July 24, 2026, customers in the US region experienced Connector connectivity issues affecting authentication through the Delinea Platform. Some Connectors intermittently went offline while others in the same environment continued operating normally, with no consistent pattern distinguishing affected from unaffected Connectors. Restarting or re-registering an affected Connector did not restore connectivity.  * Start: July 24, 2026, approximately 4:50 PM ET \(8:50 PM UTC\)  * End: July 24, 2026, approximately 8:00 PM ET \(July 25, 12:00 AM UTC\)  ## Root Cause and Remediation  The root cause was overload on backend relay services that route Connector traffic to the Delinea Platform. Because impacted and unimpacted Connectors were sometimes present in the same customer environment, initial investigation focused on individual Connector configuration and network paths. Further investigation identified the issue on TCP relays in the US-West region; one affected relay was temporarily removed from the relay pool for isolation and diagnosis. This confirmed the underlying issue was load on the affected relays rather than a defect in the relay software or hardware itself.  To remediate, our team investigated and stabilized the affected relay services as they were identified, restoring Connector connectivity. Connectivity was confirmed restored the evening of July 24, and the incident was resolved by approximately 8:00 PM ET. No action was required from customers, and no customer data was lost.  ## Preventative Actions  * Added new relays in US-West and US-East to increase capacity and reduce the likelihood of relay overload recurring.  * Improve tooling for the backend relay services to make them more resilient and self-recovering under load.  * We are implementing additional monitoring of the relay services to detect this specific condition and connectivity degradation before customers are impacted.  We sincerely apologize for the disruption this caused and the inconvenience to your operations. We are committed to preventing recurrence through the above actions.

We wanted to provide you with an update on the incident affecting the service(s) listed below. Our team has been working diligently to address the issue, and we have made significant progress. We appreciate your continued patience and support as we work to fully restore normal service. For any questions or concerns, please reach out to our support team at https://support.delinea.com.

We have identified the cause of the intermittent 504 / Gateway Timeout errors that some customers have experienced when accessing their Delinea Platform instances or when connector-based operations are in use. The issue stems from elevated response times in a backend service that handles connector connectivity, which is causing some requests to time out. Our engineering team has isolated the source and is actively applying corrective action to restore normal performance. Some customers may continue to see intermittent timeouts until the fix is fully in place. We will provide a further update as the situation changes.

The issue has been identified, and remediation efforts are currently underway. We will continue to provide updates as we make progress.

This incident has been resolved.

## Incident Overview  On July 24, 2026,  a subset of Delinea Platform customers in the US and AU regions experienced intermittent 504 Gateway Timeout errors, resulting in temporary service disruption while accessing Platform. On July 24, 2026, some Delinea Platform customers in US and AU regions experienced intermittent 504 Gateway Timeout errors, resulting in temporary service disruption while accessing the platform.  Start: July 24, 2026, 11:20 AM ET  End: July 24, 2026, 3:30 PM ET  ## Root Cause and Remediation  The incident was caused by an unexpected increase in request volume generated by a Secret Server Cloud synchronization process, which exceeded the processing capacity of The Platform service. As the service became overloaded, request latency increased and some requests exceeded the gateway timeout threshold, resulting in intermittent 504 Gateway Timeout errors for a subset of Platform customers.  Our engineering team applied immediate mitigations to reduce load while working to resolve the underlying capacity constraint, and is implementing a long-term solution to improve capacity handling and prevent similar incidents. Additional monitoring will also be added to detect and respond to this type of condition more quickly.  ## Preventative Actions  * Improve capacity handling: Enhance the backend capacity to better accommodate periods of elevated request volume without impacting customer traffic.  * Optimize Secret Server Cloud synchronization: Engineering has implemented mitigations to address the immediate issue and prevent recurrence in the short term. A long-term solution is being developed to further improve the handling of synchronization workloads.   * Expand monitoring and alerting: implement additional monitoring and alerting to detect elevated request volumes and performance degradation earlier, enabling faster response and mitigation.      We sincerely apologize for the disruption this caused and the inconvenience to your operations. We are committed to preventing recurrence through the above actions.

We are experiencing delays in audit event processing for customers in our US East region. Audit logs and audit activity may appear delayed or incomplete in the Delinea Platform and Secret Server Cloud interfaces. No audit events are being lost. All events are captured and will be processed. Core product functionality including secret access, authentication, and password management is not affected. Our engineering team has identified the root cause and has scaled database and processing resources to address the backlog. The backlog is actively draining.

The audit event processing backlog affecting customers in our US East region has been fully cleared. Audit logs are now current and up to date. No audit events were lost during this period. Thank you for your patience.

### Incident Overview  On July 20, 2026, a subset of Delinea Platform customers in the US region experienced delays in audit event processing, resulting in a lag between when actions occurred and when the corresponding audit events appeared in logs.  * Start: July 20, 2026, 10:54 AM UTC  * End: July 23, 2026, 3:58 PM UTC  ### Root Cause and Remediation  The incident was caused by an increase in audit event volume following a recent Secret Server release, which exceeded the processing capacity of the audit event pipeline in the US region. As volume grew, events were queued for processing rather than delivered in real time, causing a backlog and a corresponding delay in audit log availability. No audit events were lost during this incident.  Our engineering team scaled the underlying data processing capacity to work through the backlog while monitoring queue depth and processing rates. By July 23, 2026, all delayed events had been fully processed, audit logs were current, and normal operations had resumed.  ### Preventative Actions  * Improve automated scaling to the audit event pipeline so it can absorb increases in volume without creating a backlog or delaying log availability.  * Improve monitoring and alerting audit processing volume and queue depth to detect potential delays earlier and respond before customers are impacted. We sincerely apologize for the disruption this caused and the inconvenience to your operations. We are committed to preventing recurrence through the above actions.