Centrify Outage History

Started May 11, 2026, 03:44 PM UTC· resolved May 12, 2026, 12:00 PM UTC

1. resolved May 11, 2026, 03:44 PM UTC

   Between approximately 7:47 PM and 10:48 PM EDT on Sunday, May 10, 2026, some US customers in East US region may have experienced timeout errors (including 504s) or delays when logging in to Platform. This was caused by a disruption at a US datacenter operated by our upstream network provider, which affected traffic routing in the region. The upstream issue has since been resolved and affected infrastructure has been restored. Platform login is now operating normally, and we are continuing to monitor. We apologize for any inconvenience this may have caused.

2. postmortem May 20, 2026, 03:15 AM UTC

   **Incident Overview** On May 10, 2026, between 23:47 UTC and 02:48 UTC \(the next day\), some US customers in the East US region experienced intermittent login errors, including 504 timeouts and slow response times. The issue originated at the Ashburn, VA location of our web application firewall \(WAF\) infrastructure, which handles traffic routing for East US region. Service was restored during the incident by rerouting traffic through alternate locations. The Ashburn site was returned to service at 12:00 UTC on May 11, 2026. **Root Cause** The outage was triggered by a hardware failure within the Ashburn WAF infrastructure. A faulty optical transceiver caused the primary network link between aggregation switches to become unstable, leading to repeated connection drops. A secondary link that should have served as a failover was already inactive at the time, a condition that had gone undetected due to a gap in infrastructure monitoring. With no functioning backup, the degradation of the primary link disrupted traffic flowing through the site, resulting in the login errors customers experienced. Two factors extended the duration of impact. First, the monitoring gap meant that the inactive backup link was not visible ahead of the incident. Second, there was a delay in executing the standard failover process \(deactivating the affected site and rerouting traffic\) once customer impact was identified. Both gaps have since been identified and remediated. **Preventive Actions** * The faulty optical transceivers on both the primary and secondary network links at the Ashburn location are being replaced, with a spare unit kept on-site to support faster response if needed in the future. * The monitoring gap that failed to surface the inactive secondary link is being addressed, ensuring both active and backup links are visible to the network operations team going forward. * Response procedures are being reviewed and reinforced to ensure the site deactivation and traffic rerouting process is initiated promptly whenever significant customer impact is detected.

Read the full incident report →

Started May 11, 2026, 03:28 PM UTC· resolved May 12, 2026, 02:17 AM UTC

1. monitoring May 11, 2026, 03:28 PM UTC

   As of 13:37 UTC, the degraded performance affecting Secret Server Cloud in the EU region has been resolved. Customers who experienced failures launching secrets or intermittent API errors should no longer be impacted. Our team is conducting a root cause analysis. We will post a follow-up update once findings are available. We apologize for any disruption this caused. ----------------------------------------------------------------------------------------------------------------------- Investigating — May 11, 2026, 07:57 UTC We are investigating reports of degraded performance affecting Secret Server Cloud in the EU region. Some users may be unable to launch secrets. We will provide an update as soon as more information is available.

2. resolved May 12, 2026, 02:17 AM UTC

   As of 13:37 UTC on May 11, 2026, the Intermittent failures launching Secrets in the EU region has been resolved. Our preliminary investigation determined that the root cause was an outage impacting a cloud infrastructure service used by Secret Server Cloud. Normal service has been confirmed restored. We are continuing to work with our cloud provider to obtain full root cause details and identify preventative actions. We apologize for the impact to your experience and appreciate your patience while we investigated.

3. postmortem May 20, 2026, 06:09 AM UTC

   **Incident Overview** On May 12, 2026, starting at 07:53 UTC, Secret Server Cloud customers in the EU region experienced intermittent failures when launching secrets, initiating proxied RDP/SSH sessions, and making API calls requiring distributed engine communication. The incident was traced to a degradation in the underlying cloud messaging infrastructure in the West Central Europe region. At 13:37 UTC, the degraded performance affecting our services was fully resolved and normal operations were restored. The impact was limited to SSC customers with Distributed Engines. Secret viewing, management, and Web UI availability remained unaffected. **Root Cause** A degradation in the cloud messaging infrastructure in the West Central Europe region caused message subscription management operations to return HTTP 504 Gateway Timeout errors, preventing Distributed Engines from completing initialization and taking them offline. This resulted in timeouts across all distributed engine-routed operations, most visibly secret launches and proxied session initiations. The failure was isolated to the control plane layer of the messaging infrastructure. TCP-level connectivity remained healthy throughout the incident, and the issue was not attributed to any network or configuration change on our side. The issue was mitigated by our Cloud provider rolling back a recent release on the messaging infrastructure that had contributed to the control plane failures. **Preventive Actions** * Expand monitoring coverage for cloud messaging exception rates and Distributed Engine subscription failure patterns to enable proactive detection ahead of customer impact. * Review integration of Cloud provider health notifications into our on-call alerting pipeline to improve visibility into infrastructure events affecting Secret Server Cloud regions. * Assess improvements to Distributed Engine startup and reconnection logic to introduce retry handling with exponential back-off on transient messaging failures, reducing the risk of short-lived disruptions escalating into sustained engine outages. **Lessons Learned** The duration of customer impact during this incident was extended by gaps in our operational response. Specifically: * Limited visibility into cloud provider health events delayed our awareness of the underlying infrastructure degradation, and we did not follow our standard operating procedure to escalate with our vendor in a timely manner. * Acknowledgment of the incident on our status page was delayed, deviating from our standard incident communication process. * This incident reinforced the importance of continual improvements in both our monitoring and situational awareness of our infrastructure, as well as in our engineer training and development. We apologize for the extended impact our handling of this incident had on our customers and on their operations. We continue to take our responsibilities to our customers seriously, and have taken lessons from the handling of this incident to strengthen our processes going forward.

Read the full incident report →

Started Apr 26, 2026, 06:21 AM UTC· resolved Apr 27, 2026, 02:14 PM UTC

1. investigating Apr 26, 2026, 06:21 AM UTC

   We are investigating reports of degraded performance affecting Privileged Access Service / Cloud Suite Pod34. Some users may experience slower than normal response times. Users may encounter slow page loads, increased latency, or timeouts. Our team is actively investigating.

2. monitoring Apr 26, 2026, 02:09 PM UTC

   We wanted to provide you with an update on the incident affecting the service(s) listed below. We have implemented a mitigation and are monitoring the situation. For any questions or concerns, please reach out to our support team at https://support.delinea.com.

3. resolved Apr 27, 2026, 02:14 PM UTC

   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.

Read the full incident report →

Started Apr 25, 2026, 09:25 PM UTC· resolved Apr 26, 2026, 12:51 PM UTC

1. identified Apr 25, 2026, 09:25 PM UTC

   We have identified an issue in the recently rolled out Cloud Suite 26.1 release where custom authorization profiles containing wildcard or regex characters (e.g., "*") may return HTTP 401 errors. Built-in authorization profiles are not affected. A workaround is available. Please refer to the following knowledge base article for details: https://support.delinea.com/s/article/1777148833588 A fix is actively in progress, and is expected to be available shortly. We will post an update as events warrant. We apologize for any inconvenience this may cause.

2. resolved Apr 26, 2026, 12:51 PM UTC

   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.

Read the full incident report →

Started Apr 24, 2026, 05:58 PM UTC· resolved Apr 25, 2026, 08:56 PM UTC

1. identified Apr 24, 2026, 05:58 PM UTC

   We have identified the cause of the current issues impacting Secret Server Cloud in the US region. An ongoing cloud provider incident is affecting an availability zone hosting workloads in our US East region. Customers may encounter HTTP 500 errors when accessing the Secret Server UI, with messages similar to the following: "Http failure response for https://.secretservercloud.com/... : 500 OK" To restore service, we are failing over traffic to our secondary region. Customers may experience brief connectivity errors during the failover. We will continue to provide updates as the failover progresses. We apologize for the disruption and thank you for your patience.

2. monitoring Apr 24, 2026, 07:06 PM UTC

   After further investigation, we determined that a failover to our secondary region was not required. We have moved the affected resources to a different availability zone within the primary region and are observing improvement in service health. Application errors are no longer being reported. We will continue to monitor the environment closely and post a further update once the incident is fully resolved. We apologize for the disruption and thank you for your patience.

3. monitoring Apr 24, 2026, 11:06 PM UTC

   We are continuing to monitor for any further issues. We are not seeing any Application errors since 15:31PM Eastern.

4. resolved Apr 25, 2026, 08:56 PM UTC

   This incident has been resolved.

5. postmortem May 01, 2026, 01:35 PM UTC

   **Incident Overview** On April 24, 2026, a subset of Secret Server Cloud customers in the US region experienced intermittent errors or connectivity issues when accessing their tenants. The disruption was caused by an outage in our cloud infrastructure provider at the East US data center. The issue originated in a single part of the data center but spread to additional areas as traffic was automatically redistributed, extending the scope and duration of the incident. Full-service recovery was confirmed at 00:15 UTC on April 25, 2026. **Root Cause** The outage impacted internal networking components that our platform depends on, disrupting connectivity across the environment. These failures contributed to the intermittent HTTP 500 errors experienced by some Delinea customers during the incident window. The issue originated in one of the Availability zones in East US data center and expanded to other zones as traffic was automatically redistributed, broadening the impact. Our team responded promptly, identifying the root cause at our cloud infrastructure provider and redistributing traffic to other zones. As a precautionary measure, our team initiated a failover to a secondary region, but later determined it was no longer needed and safely rolled back with no additional impact. Service was fully restored after our infrastructure team redirected traffic away from the affected nodes within the primary environment, with full recovery confirmed at approximately 00:15 UTC on April 25, 2026. **Preventive Actions** * Evaluate multi-availability-zone node pool configurations to improve platform resilience and reduce the impact of localized data center failures. * Establish clear thresholds and decision criteria for triggering regional failover versus in-region mitigation to improve response speed during incidents.

Read the full incident report →

Started Apr 03, 2026, 10:00 PM UTC· resolved Apr 03, 2026, 10:00 PM UTC

1. resolved Apr 10, 2026, 04:11 AM UTC

   This incident has been resolved. SAML/Federation authentication has been fully restored for all affected tenants. A platform update deployed earlier today introduced a change that caused login failures for tenants with non-default SAML issuer settings. We apologize for the disruption and will be publishing a full post-incident review. Investigating We have received reports of SAML/Federation users being unable to log in to their Delinea Platform tenants. We are actively investigating the issue and will provide updates as more information becomes available. Tenants using username/password authentication are not affected at this time.

2. postmortem Apr 10, 2026, 04:47 AM UTC

   ### Incident Overview On Friday, April 3rd, 2026, a subset of SAML/Federation users were unable to authenticate to their Delinea Platform tenants. The issue was first reported at approximately 5:01 PM ET and was fully resolved by 8:38 PM ET following a rollback of a recent platform update. Tenants using the default SAML issuer configuration were not impacted. Customers with local \(non-SAML\) accounts retained access throughout the incident via breakglass or local admin credentials. ### Root Cause A platform update deployed at approximately 4:20 PM ET introduced a code change that inadvertently caused custom SAML authentication configurations to not be correctly applied for affected tenants. This resulted in authentication failures for tenants that relied on a custom SAML issuer, while tenants using default settings were unaffected. A contributing factor was insufficient test coverage for this specific authentication scenario prior to the global rollout of the update. ### Preventive Actions * A code fix is being implemented to ensure custom SAML authentication configurations are correctly applied in all cases going forward. * Automated test coverage is being expanded to include SAML authentication scenarios with custom configurations to prevent similar issues in future releases.

Read the full incident report →

Started Mar 16, 2026, 10:00 AM UTC· resolved Mar 16, 2026, 10:57 AM UTC

1. resolved Mar 16, 2026, 12:32 PM UTC

   We are investigating reports from a subset of customers experiencing "Access Denied" errors, intermittent blocking, or unexpected captcha challenges when accessing Secret Server Cloud. Our cloud Web Application Firewall (WAF) provider detected an anomalously high request rate and activated DDoS mitigation, which resulted in these access issues. Upon investigation, we verified that the increased request count was legitimate and worked with our WAF provider to disable mitigation for this event. We will continue to collaborate with our vendor to improve anomaly detection and reduce the likelihood of false-positive events in the future. We apologize for any inconvenience this may have caused and appreciate your patience as we work to ensure reliable access. For assistance or further updates, please contact our support team at https://support.delinea.com.

2. postmortem Mar 26, 2026, 05:25 AM UTC

   ## Incident Overview On Monday, March 16, 2026, customers hosted on the Delinea Secret Server Cloud \(SSC\) UK cluster experienced a service disruption that prevented access to the SecretServer endpoint. The Delinea WAF blocked inbound traffic to the affected endpoint as an automated protective response after regional traffic volumes exceeded predefined DDoS threshold limits. * Start Time: February 16, 2026 – 10:03 UTC * End Time: February 16, 2026 – 10:57 UTC ## Root Cause The incident was caused by abnormally high traffic generated by a single customer Secret Server engine, which exceeded predefined DDoS protection threshold limits in the UK region. Key contributing factor: * Engine request spike:` `Traffic from secret-server-engines increased dramatically from a typical baseline of fewer than 100 calls to approximately 27,000 calls, triggering automated DDoS protection mechanisms. ## Preventive Actions * The UK site DDoS threshold was temporarily increased to 4500, allowing legitimate but abnormal traffic patterns to be handled while ensuring continued regional protection. * Enhance monitoring to identify sharp, customer-specific engine call spikes.

Read the full incident report →

Started Mar 12, 2026, 01:49 AM UTC· resolved Mar 12, 2026, 02:38 PM UTC

1. investigating Mar 12, 2026, 01:49 AM UTC

   We are currently investigating an issue affecting SSO authentication for some customers. Impacted users are encountering Federation Error 102 during login. Our team is actively investigating.

2. investigating Mar 12, 2026, 02:57 AM UTC

   We are continuing to investigate this issue.

3. identified Mar 12, 2026, 04:59 AM UTC

   We have identified that affected customers have their "Map federated user to existing directory user" setting configured as Disabled, which is not the default setting. The default value for this setting is Optional. 1. From the left navigation, click Settings, then select Federation Providers. 2. Click the name of your federation provider. 3. On the Settings tab, click Edit. 4. Under User Mappings, locate the "Map federated user to existing directory user" option. 5. Change the value from Disabled to Optional. 6. Click Save. We are currently working on a remediation and will provide an update once it is complete.

4. identified Mar 12, 2026, 06:15 AM UTC

   We have verified a fix for this issue and will be deploying a hotfix at the earliest opportunity. Once the hotfix is applied, affected customers who applied the workaround will be able to revert their "Map federated user to existing directory user" setting back to Disabled. We will provide an update once the hotfix has been successfully deployed.

5. identified Mar 12, 2026, 11:16 AM UTC

   We are aware that some customers are unable to apply the previously communicated workaround due to the error: "Entra Tenant Id is already in use." We are currently working to deploy a permanent fix that will resolve this issue without requiring customers to apply the workaround. We will provide a further update once the fix has been successfully deployed. We apologize for the inconvenience and thank you for your patience.

6. monitoring Mar 12, 2026, 01:47 PM UTC

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

7. resolved Mar 12, 2026, 02:38 PM UTC

   This incident has been resolved.

8. postmortem Mar 26, 2026, 05:27 AM UTC

   ## Incident Overview On March 12, 2026, a subset of customers in Australia \(AU\) and the United States \(US\) regions began experiencing Federation configuration error. The issue rooted from a planned software update that prevented some users from logging in to Platform. This was caused by the user session becoming corrupted or inconsistent. Start Time: March 12, 2026 – 01:33 UTC End Time: March 12, 2026 – 14:43 UTC At the time of the incident only AU and US were marked as impacted, but later investigations identified that it impacted subset of clients globally. ## Root Cause The incident was caused by a defect introduced in the Identity API release that corrupted user authentication state for federated users. This error persisted even after the deployment was rolled back, requiring a targeted fix to repair affected tenants. Key contributing factors included: A defect in the new Identity API release caused user accounts to enter a broken state upon authentication. Automated background session refreshed affected users who were not actively logged in, extending the scope of the impact beyond those actively using the platform. The sequence of multiple coordinated releases made it more difficult to isolate the faulty component quickly ## Preventive Actions * A targeted new build was developed and deployed to handle users who entered the bad state, fully resolving the incident. * We are adding additional pre-release testing for federated authentication flows: All releases that touch authentication, Identity, or federation service will have dedicated test coverage. * Cross-service release dependency review: We are confirming that the combination of releases has been tested together in lower silos, not just each service in isolation.

Read the full incident report →

Started Mar 08, 2026, 03:53 PM UTC· resolved Mar 09, 2026, 03:57 PM UTC

1. investigating Mar 08, 2026, 03:53 PM UTC

   We are receiving reports of a small subset of customers experiencing difficulties connecting to PAS/Cloud Suite due to Delinea rotating the wildcard.my.centrify.net certificate yesterday (March 7th). Sectigo certificates require a new root and intermediate certificates that can be manually downloaded from Sectigo for those systems that are not automatically updated. Our team is actively working on a KB article for this issue. Most systems have already pulled this updated certificate. While the KB Article is being created, in the meantime if you need to install the cert for your system, you can download it via the links below. Root Cert from Sectigo: https://crt.sh/?d=4256644734 Intermediate Cert from Sectigo: https://crt.sh/?d=4267304690 Information from Sectigo on the Root Cert rotation: https://www.sectigo.com/sectigo-public-root-cas-migration

2. identified Mar 08, 2026, 05:24 PM UTC

   The issue has been identified. Please see the links below to resolve. If you need to install the new root certs for your system, you can download it via the links below. Root Cert from Sectigo: https://crt.sh/?d=4256644734 Intermediate Cert from Sectigo: https://crt.sh/?d=4267304690 Information from Sectigo on the Root Cert rotation: https://www.sectigo.com/sectigo-public-root-cas-migration

3. identified Mar 08, 2026, 08:31 PM UTC

   We are continuing to work on a fix for this issue.

4. resolved Mar 09, 2026, 03:57 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Feb 09, 2026, 08:31 PM UTC· resolved Feb 09, 2026, 09:12 PM UTC

1. identified Feb 09, 2026, 08:31 PM UTC

   We are currently investigating an issue where some platform users are receiving the error message: "Cannot access 't' before initialization" This occurs when navigating between the following sections: User Management Network At this time, we are not aware of any functional impact beyond the display of this error message. We have identified the issue as being related to a recent release and are actively rolling back the change to restore normal behavior. We will provide an update once the rollback is complete.

2. monitoring Feb 09, 2026, 08:42 PM UTC

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

3. monitoring Feb 09, 2026, 08:46 PM UTC

   We are continuing to monitor for any further issues.

4. resolved Feb 09, 2026, 09:12 PM UTC

   This incident has been resolved.

5. postmortem Feb 19, 2026, 02:38 PM UTC

   **Incident Overview** Between 2:20 PM and 3:34 PM EST on February 9, 2026, Platform users experienced red banner errors, “Cannot access ‘t’ before initialization”, when clicking on the Discovery link in the left-hand navigation. These errors occurred due to client-side bundle incompatibility introduced during a recent Platform update. * Start of Impact: February 9, 2026, at 19:20 UTC * End of Impact: February 9, 2026, at 20:34 UTC **Resolution** We resolved the incident by pinning our build tooling back to the previous compatible version of webpack, which restored correct bundle generation and eliminated the errors. Normal service was confirmed to be restored by 3:34 PM EST. **Root cause** The incident was caused by a minor Angular framework update that indirectly upgraded the webpack to a newer version - a change that was not explicitly requested or anticipated. This newer version of webpack generated application bundles in a format that was incompatible with our existing module federation setup, which is the mechanism we use to load different sections of the platform as separate, independently deployable units. When the incompatible bundle was loaded, it caused client-side errors that surfaced to users as red banner messages. **Preventative Actions** We are taking the following steps to reduce the risk of similar incidents occurring in the future: * As a longer-term improvement, we are planning a migration away from our current module federation setup to native federation, which will eliminate the dependency on webpack and reduce the risk of similar issues in the future.

Read the full incident report →

Started Jan 23, 2026, 11:38 PM UTC· resolved Jan 24, 2026, 12:47 AM UTC

1. identified Jan 23, 2026, 11:38 PM UTC

   We are currently investigating an issue impacting RDP and SSH connections initiated through Secret Server Cloud, specifically when connections are made via the Connection Manager / RDP proxy. Some customers may experience: # Failures when launching RDP or SSH sessions # Black screens during connection attempts # Inability to connect through the RDP proxy, while direct RDP may continue to work We have identified the underlying cause and are actively implementing a fix. Additional updates will be shared as progress is made.

2. identified Jan 23, 2026, 11:55 PM UTC

   We have confirmed the root cause of this issue to be resource contention impacting the RDP/SSH proxy services. To mitigate the issue, we have added additional resources to increase capacity and reduce connection failures. We are continuing to monitor the environment closely to ensure stability and will provide further updates as needed.

3. monitoring Jan 24, 2026, 12:07 AM UTC

   A fix has been implemented to address the resource contention impacting RDP and SSH connections. We are actively monitoring the service, and results indicate that RDP and SSH connections are functioning normally without disconnections.

4. resolved Jan 24, 2026, 12:47 AM UTC

   This incident has been resolved.

5. postmortem Jan 27, 2026, 04:39 PM UTC

   ## Incident Overview Customers in the US region experienced intermittent failures when initiating RDP and SSH sessions through Secret Server Cloud, specifically via the Connection Manager / RDP proxy. Start Time: January 23, 2026, 5:45 PM ET End Time: January 23, 2026, 6:45 PM ET Some customers observed: * Failures when launching RDP or SSH sessions * Black screens during connection attempts * Inability to connect via the RDP proxy, while direct RDP access may have continued to work Other regions were not impacted. ## Detection The issue was initially identified through customer support tickets. Internal alerts were received later due to alert thresholds being set too high to detect the early stages of the degradation. ## Root Cause As part of a [planned maintenance](https://status.delinea.com/incidents/r8wkgt5ghcqx) activity in the US region on January 23, customer-facing Azure Service Bus resources were migrated to new hostnames, along with updates to email services and domains. The maintenance completed at 4:30 PM ET. To avoid data loss and disruption to active customer sessions during the maintenance: * A replica set of compute nodes continued to point to the legacy Service Bus * A new set of compute nodes were provisioned to use the new Service Bus hostnames This temporary configuration required approximately double the normal compute capacity, which is not a typical operating condition. As a result: * Some compute nodes remained in a provisioning state longer than expected due to resource constraints in the node pool * Over the following hour, insufficient available capacity existed to process incoming connection requests * This led to RDP and SSH session failures and disconnections via the Connection Manager Once the issue was identified, capacity was increased by: * Expanding the compute node pool * Rebalancing resources away from the replica nodes pointing to the legacy Service Bus These actions allowed the backlog of requests to be processed and restored normal service behavior. This behavior was not observed in lower silos or in other regions during earlier phases of the maintenance period. ## Preventive Actions To prevent recurrence and improve detection during atypical load conditions, the following actions are being implemented: * Lower alert thresholds for message queue depth and processing delays to enable faster detection and response * Reduce alert lookback periods to surface emerging issues sooner during rapid load changes * Introduce a new monitor tracking the percentage of compute pods in an unhealthy state due to resource constraints in the node pool

Read the full incident report →

Started Jan 22, 2026, 09:40 PM UTC· resolved Jan 23, 2026, 08:00 AM UTC

1. identified Jan 22, 2026, 09:40 PM UTC

   We are currently experiencing intermittent email delivery failures when sending messages to certain external email providers. Our platform is receiving “451 4.3.2 temporary server issue” responses when attempting to deliver email to affected mailboxes. This indicates a temporary issue within the recipient email provider’s infrastructure, which may result in delayed or failed email delivery. Customer Guidance: Customers experiencing email delivery issues are encouraged to check with their email service provider for any ongoing service advisories or disruptions. Next Update: We will continue to monitor the situation and provide updates as more information becomes available.

2. resolved Jan 23, 2026, 08:00 AM UTC

   We’re pleased to inform you that the incident affecting outbound email delivery to certain external email providers has been resolved. Our monitoring confirms that the affected provider has addressed the underlying issue that was causing intermittent “451 4.3.2 temporary server issue” responses. Email delivery to impacted mailboxes has since stabilized and is now functioning 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.

Read the full incident report →

Started Jan 09, 2026, 03:54 AM UTC· resolved Jan 09, 2026, 04:21 AM UTC

1. identified Jan 09, 2026, 03:54 AM UTC

   We will be undergoing emergency maintenance on pod34 backend storage that will cause a temporary service disruption lasting less than five minutes. We apologize for any inconvenience this may cause and appreciate your patience as we work to restore normal service. For any questions or concerns, please reach out to our support team at https://support.delinea.com.

2. monitoring Jan 09, 2026, 04:14 AM UTC

   Maintenance is complete and we are monitoring the results

3. resolved Jan 09, 2026, 04:21 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Jan 09, 2026, 03:00 AM UTC· resolved Jan 09, 2026, 04:01 AM UTC

1. investigating Jan 09, 2026, 03:00 AM UTC

   We are currently experiencing a service disruption where customers encountering "Unexpected Error" when launching new remote sessions. We’re reaching out to inform you about an ongoing incident affecting the service(s) listed below. Our team is working to identify the root cause and implement a solution. We apologize for any inconvenience this may cause and appreciate your patience as we work to restore normal service. For any questions or concerns, please reach out to our support team at https://support.delinea.com.

2. investigating Jan 09, 2026, 03:09 AM UTC

   We are continuing to investigate this issue.

3. identified Jan 09, 2026, 03:24 AM UTC

   Our investigation has identified the issue as being caused by a bug introduced in the latest release. We are actively rolling back the affected release to restore full functionality. This issue only affects new PRA sessions configured to launch using a hostname. Active sessions and new PRA sessions launched using FQDN, IP address, or from inventory are working as expected. We will continue to provide updates as mitigation progresses. Thank you for your patience while we work to resolve this issue.

4. monitoring Jan 09, 2026, 03:34 AM UTC

   The rollback of the affected release has been successfully completed. PRA session launches using hostnames have been restored, and we are monitoring the service to ensure continued stability. Active sessions and new PRA sessions launched using hostname, FQDN, IP address, or from inventory are all functioning as expected.

5. monitoring Jan 09, 2026, 03:36 AM UTC

   We are continuing to monitor for any further issues.

6. resolved Jan 09, 2026, 04:01 AM UTC

   This incident has been resolved.

7. postmortem Jan 13, 2026, 04:28 AM UTC

   **Incident overview** On January 09, 2026, A subset of Platform customers were unable to launch new PRA sessions when the target machine hostname used a single-label format \(e.g., webserver1\). Sessions with machine names using FQDN \([webserver1.example.com](http://webserver1.example.com)\) and IP address as formats, functioned as expected. * Impact Start Time: January 9, 2026, 1:00 AM UTC * Impact End Time: January 9, 2026, 3:35 AM UTC **Root Cause** On January 9, 2026, at 12:00 AM UTC, a new version of the PRA service was deployed. This release introduced a regression in the hostname validation logic, causing single‑label hostnames \(e.g., webserver1\) to be incorrectly flagged as invalid and preventing session launches for customers using this format. After correlating the deployment with the customer reports, we initiated an immediate rollback to the previous stable version. Post‑rollback validation, including a review of backend traces and logs, confirmed that the issue was fully resolved and that affected customers were once again able to launch sessions using single‑label hostnames. **Prevention and Follow-up Actions** * Review deployment process to identify why this regression was not caught in pre-production testing. * Expand test automation coverage to include single-label hostname validation scenarios. * Enhance observability by adding telemetry and alerts for hostname‑related validation failures.

Read the full incident report →

Started Dec 30, 2025, 09:50 PM UTC· resolved Jan 05, 2026, 11:55 PM UTC

1. investigating Dec 30, 2025, 09:50 PM UTC

   We are investigating failures accessing Secret Server Cloud (SSC) Service Portal when connecting through the Chicago, IL data center. Customers in other US regions are not impacted. Our initial findings indicate the issue is caused by an upstream network Point of Presence (PoP) failure. We are actively working with our network vendors to remediate the problem. Workaround: If available, customers may temporarily switch to an alternate ISP or use a VPN to change the network routing to access SSC Service Portal. We will provide further updates as more information becomes available.

2. monitoring Dec 30, 2025, 11:39 PM UTC

   A fix has been implemented by our upstream network partner. We are continuing to monitor to ensure that there is no disruption in connectivity to our services.

3. monitoring Dec 31, 2025, 06:58 AM UTC

   To mitigate the impact of the upstream PoP issue, our network partner has rerouted traffic through alternate Point of Presence (PoP) locations. As a result, Secret Server Cloud tenants in US region may resolve to a different IP address. If you have implemented IP address allow-listing on outbound firewall rules, please ensure that all IP ranges listed in our documentation are permitted to maintain connectivity to the SSC Service Portal. The list is documented as "ipRanges" here. https://docs.delinea.com/online-help/delinea-platform/getting-started/firewall-requirements/index.htm#WebApplicationFirewall We apologize for any inconvenience this may cause and appreciate your patience and cooperation while we continue to monitor the situation.

4. resolved Jan 05, 2026, 11:55 PM UTC

   We have not received any additional reports since the mitigation was implemented on December 30, 2025 at 18:39 EST. A permanent fix has been implemented by our network partner, and traffic has been restored to the previously impacted Point of Presence (PoP) in the Chicago data center. We are currently completing a Root Cause Analysis (RCA) and will share it on this status page next week.

5. postmortem Jan 14, 2026, 04:32 PM UTC

   ## Incident Overview Between December 29 and December 30, 2025, a subset of Secret Server Cloud \(SSC\) customers in the US region experienced failures accessing the SSC Service Portal when traffic was routed through the Chicago, IL data center Point of Presence \(PoP\). Customers connecting through other US regions were not impacted. The issue manifested as intermittent portal inaccessibility, increased latency, and reduced application availability. Standard network diagnostics \(e.g., ICMP, MTR\) often appeared normal, making the issue difficult to detect from a customer perspective. ### Impact Windows \(EST\) * December 29, 2025: 13:32 – 18:17 * December 30, 2025: 13:17 – 14:29 * December 30, 2025: 16:50 – 18:39 ### Affected * SSC tenants in the US region whose traffic was routed via the Chicago PoP * Customers using outbound IP allow-listing experienced additional connectivity challenges after traffic rerouting ### Unaffected * SSC customers routed through non-Chicago PoPs * Customers accessing services through alternate network paths or regions The incident was fully mitigated on December 30, 2025 at 18:39 EST ## Root Cause The root cause was a software defect within the network vendor’s Chicago \(CHI\) Point of Presence \(PoP\). Between December 29 and December 30, 2025, the network vendor identified an issue where, under specific conditions, a subset of TCP connection attempts failed to complete. While initial packets were sent, connection establishment was not consistently acknowledged by backend systems. This resulted in sporadic application-level failures despite network-level health checks appearing normal. As mitigation, the network vendor bypassed the affected Chicago PoP and rerouted traffic through alternate PoP locations, restoring service stability. A permanent fix was subsequently implemented by the network vendor, and the environment has remained stable since. ## Preventive Actions ### Actions Implemented by Network Vendor * A permanent software fix has been deployed by the network vendor to address the underlying defect that could prevent successful TCP connection establishment under certain conditions. * Enhanced monitoring and alerting have been implemented at the PoP level to enable earlier detection of similar intermittent TCP handshake failures. * Updated the runbooks for the Network Operations Center to ensure rapid rerouting can be performed if required in the future. ### Customer Resiliency Recommendations * SSC Customers using outbound IP allow-listing on their network should ensure that all documented IP ranges are permitted to prevent connectivity issues during traffic rerouting or failover events. While outbound requests to SSC primarily resolve to six IP addresses in 45.60.x.x CIDR range, we recommend that the [expanded list documented here](https://docs.delinea.com/online-help/secret-server/networking/general/secret-server-ports/index.htm#web-application-firewall-waf-for-traffic-to-secret-server-cloud) is allowed on your firewall, as the SSC tenant may resolve to a different IP address during failover events. * SSC customers are encouraged to deploy Distributed Engine in a secondary region to improve resilience and disaster recovery capabilities. * SSC Customers are advised to maintain a secondary ISP or alternate network path that can be used during upstream network disruptions.

Read the full incident report →

Started Dec 29, 2025, 06:32 PM UTC· resolved Dec 30, 2025, 02:24 AM UTC

1. identified Dec 29, 2025, 06:32 PM UTC

   We are investigating reports of Delinea customers in the United States experiencing failures accessing the Platform and SSC websites when connecting through the Chicago, IL and Los Angeles, CA data centers. Customer in other US regions are not impacted. Our initial findings indicate the issue is caused by an upstream network Point of Presence (PoP) failure. We are actively working with our network vendors to remediate the problem. Workaround: If available, customers may temporarily switch to an alternate ISP or use a VPN to change the network routing to access the Platform and SSC websites. We will provide further updates as more information becomes available.

2. monitoring Dec 29, 2025, 11:17 PM UTC

   A fix has been implemented by our upstream network partner. We are continuing to monitor in order to ensure that there is no disruption in connectivity to our services.

3. resolved Dec 30, 2025, 02:24 AM UTC

   This incident has been resolved.

4. postmortem Jan 14, 2026, 04:45 PM UTC

   Root cause analysis is available [here](https://status.delinea.com/incidents/s1yv495d5w4k)

Read the full incident report →

Started Dec 16, 2025, 02:58 PM UTC· resolved Dec 16, 2025, 04:15 PM UTC

1. investigating Dec 16, 2025, 02:58 PM UTC

   We are currently experiencing an issue causing service degredation in Australia for Platform users. Our team is working to identify the root cause and implement a solution. We apologize for any inconvenience this may cause and appreciate your patience as we work to restore normal service. For any questions or concerns, please reach out to our support team at https://support.delinea.com.

2. monitoring Dec 16, 2025, 03:35 PM UTC

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

3. resolved Dec 16, 2025, 04:15 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Dec 14, 2025, 03:58 PM UTC· resolved Dec 14, 2025, 08:51 PM UTC

1. investigating Dec 14, 2025, 03:58 PM UTC

   We are experiencing pending Remote Password Changing (RPC) tasks in US region. Our engineering team has identified the root cause and working on restoring normal functionality as quickly as possible. We apologize for the inconvenience and appreciate your patience while we work to resolve the issue. If you have any questions or need assistance, please contact our support team: https://support.delinea.com

2. identified Dec 14, 2025, 03:59 PM UTC

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

3. monitoring Dec 14, 2025, 07:08 PM UTC

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

4. resolved Dec 14, 2025, 08:51 PM UTC

   This incident has been resolved.

5. postmortem Dec 26, 2025, 03:37 PM UTC

   Postmortem details for this incident are [posted here](https://status.delinea.com/incidents/yhtbqczx9hn5)

Read the full incident report →

Started Dec 06, 2025, 11:03 PM UTC· resolved Dec 07, 2025, 07:43 AM UTC

1. investigating Dec 06, 2025, 11:03 PM UTC

   We are currently investigating reports of customers experiencing pending Remote Password Changing (RPC) tasks and Heartbeat failures. Our engineering team is actively working to identify the root cause and restore normal functionality as quickly as possible. We apologize for the inconvenience and appreciate your patience while we work to resolve the issue. If you have any questions or need assistance, please contact our support team: https://support.delinea.com

2. identified Dec 07, 2025, 12:46 AM UTC

   The issue has been identified. Rollback of the latest release is in progress. Thank you for your patience.

3. monitoring Dec 07, 2025, 02:23 AM UTC

   Rollback is complete. We are seeing successful Remote Password Changing (RPC) tasks and Heartbeats. We will continue to monitor the results.

4. identified Dec 07, 2025, 05:26 AM UTC

   We are experiencing pending Remote Password Changing (RPC) tasks and Heartbeat failures in US and UK regions

5. monitoring Dec 07, 2025, 07:35 AM UTC

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

6. resolved Dec 07, 2025, 07:43 AM UTC

   This incident has been resolved.

7. postmortem Dec 26, 2025, 03:35 PM UTC

   ## Incident Overview ### Summary Secret Server Cloud customers using Distributed Engine \(DE\) for Remote Password Changing \(RPC\) operations experienced RPC requests remaining in a “Pending” state. In some cases, RPC functionality was partially restored before full service was recovered. A follow-on regression occurred during remediation, temporarily impacting a subset of customers again. ### First Occurrence * Start Time: December 6, 2025, 5:44 PM ET * End Time: December 7, 2025, 2:35 AM ET ### Second Occurrence \(Follow-on Regression\) * Start Time: December 14, 2025, 10:53 AM ET * End Time: December 14, 2025, 12:00 PM ET ### Impact * RPC operations initiated through Distributed Engine remained in a pending state and did not complete successfully. * Other Secret Server Cloud functionality was not impacted. ## Root Cause The issue was caused by enhancements introduced as part of the RPC pre-run validation feature, which is tightly integrated with the RPC execution flow. The enhancement required changes to how RPC requests are structured and processed. These changes introduced compatibility issues between the updated Secret Server Cloud service and certain previously installed Distributed Engine versions, preventing RPC requests from being processed correctly. During the initial rollback, additional infrastructure changes included in the same release prevented an automatic rollback from fully completing, which extended the time required to restore full functionality. During the subsequent remediation rollout on Dec 13, 2025, a configuration issue related to message routing caused a temporary regression, impacting a subset of Distributed Engines until the configuration was corrected. ## Preventive Actions To prevent recurrence, we have taken and are taking the following actions: * Improved QA validation to explicitly test upgrades across all supported Distributed Engine versions, not just incremental or phase-based upgrades. * Ensured large, foundational features such as RPC pre-run validation are integrated into QA environments earlier in the release cycle to better reflect production conditions. * Added broader cross-team technical reviews for complex, highly integrated features before release. * Implemented backward compatibility safeguards to ensure newer Secret Server Cloud releases can safely interoperate with older Distributed Engine versions. * Enhanced deployment validation and monitoring to more quickly detect configuration regressions during remediation rollouts.

Read the full incident report →

Started Nov 17, 2025, 10:30 AM UTC· resolved Nov 17, 2025, 10:30 AM UTC

1. resolved Nov 21, 2025, 05:02 PM UTC

   We are investigating reports from a subset of customers getting Access Denied errors when attempting to create or update secrets. We identified that the issue is caused due to a bug introduced in the latest SSC release. Our engineering teams are working to revert the changes to a previous stable release. We apologize for any inconvenience this may cause and appreciate your patience during this time. For assistance or updates, please contact our support team at https://support.delinea.com.

2. postmortem Nov 21, 2025, 05:03 PM UTC

   ### Incident Overview Users attempting to update or create secrets through specific API endpoints encountered “Access Denied” errors. This impacted the following scenarios: * Uploading a file to a secret field * Assigning a list to a field * General secret create/update operations when LauncherConnectAsSecretId was configured Affected Endpoints: * POST /api/v1/secrets/ * PUT /api/v1/secrets/\{id\}/ * PUT /api/v1/secrets/\{id\}/fields/\{slug\}/listdetails * PUT /api/v1/secrets/\{id\}/fields/\{slug\}/ The first two endpoints are used primarily by integrations and automation scripts. The latter two are used by the UI for list assignments and file attachments. Start Time: November 15, 2025 6:00 PM Eastern End Time: November 17, 2025 9:35 PM Eastern ### Root Cause In the latest SSC release, a bug fix was deployed introducing new logic intended to correctly apply the LauncherConnectAsSecretId parameter in cases where a privileged secret lacked a PuTTY launcher. While the intended scenario was resolved, the updated logic unintentionally caused Access Denied failures across the four endpoints listed above. This issue was partially identified and corrected during QA; however, not all affected paths were detected. A relevant integration test existed, but the test selection logic used during merge-time impact analysis did not include that test. As a result, the problematic code path was not validated before deployment, allowing a narrower version of the issue to reach production. The issue was resolved by reverting the affected code and redeploying the previous stable implementation. ### Preventive Actions * Expand the impact-analysis logic used during code merges to ensure a broader set of integration tests is always executed, particularly those related to authorization logic. * Review and refine automated test coverage for LauncherConnectAsSecretId and related authorization flows. * Add targeted regression tests for all endpoints impacted in this incident to prevent similar authorization side effects.

Read the full incident report →

Started Nov 11, 2025, 04:31 AM UTC· resolved Nov 11, 2025, 06:41 AM UTC

1. investigating Nov 11, 2025, 04:31 AM UTC

   We are currently investigating service disruption in US region for Privilege Manager Cloud tenants. Our engineering teams are fully engaged and working to restore normal service as quickly as possible. We apologize for the inconvenience and appreciate your patience while we investigate.

2. identified Nov 11, 2025, 05:37 AM UTC

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

3. monitoring Nov 11, 2025, 05:54 AM UTC

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

4. resolved Nov 11, 2025, 06:41 AM UTC

   We are pleased to inform you that the incident affecting the US region for Privilege Manager Cloud 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.

5. postmortem Dec 05, 2025, 07:15 AM UTC

   **Incident Overview** On November 11, 2025, customers in the US region experienced service disruption when accessing Privilege Manager Cloud \(PMC\). Affected users encountered error messages or unexpected sign-in prompts when attempting to access their accounts. The impact occurred during the following time window: * November 11, 2025, from 03:11–05:49 UTC **Root Cause** The issue was caused by a disruption in our database infrastructure that stores customer information. Our application services were unable to connect to the database, preventing users from accessing their accounts. The disruption occurred due to: * Unplanned maintenance activities that created an overload on our system * A timing issue in our internal load management process that caused it to stop responding * The system became stuck in an unhealthy state and required a manual reset to recover Our monitoring systems detected the database connectivity issues shortly after they began. Standard recovery procedures such as increasing system capacity and restarting services did not resolve the problem, indicating a deeper issue with the database infrastructure. **Resolution** Our team performed a system failover to restore service availability. Normal operations resumed once the database connections were re-established and all services returned to a healthy state. **Preventive Actions** To strengthen reliability and minimize future impact, we are implementing the following measures: * Fixing the underlying issue to prevent our system from becoming stuck during high-load situations * Adding safeguards to ensure our load management process handles stress conditions more gracefully * Enhancing our monitoring and alerting systems to detect database connectivity problems more quickly

Read the full incident report →

Started Oct 29, 2025, 04:36 PM UTC· resolved Oct 30, 2025, 12:26 AM UTC

1. investigating Oct 29, 2025, 04:36 PM UTC

   We are currently experiencing degraded performance affecting certain UI features in the Platform, specifically within the Engine Pool and Marketplace sections. Our engineering teams are fully engaged and working to restore normal service as quickly as possible. We apologize for the inconvenience and appreciate your patience while we investigate.

2. identified Oct 29, 2025, 05:45 PM UTC

   We have identified that the issues impacting UI functionality in Engine Pool and Marketplace are caused by DNS routing issues from our Cloud Provider. Our engineering teams are investigating options to update the network route so that connections from on-prem environments can resume to the Platform. At this time, creating new engines or upgrading existing ones is not possible, and engine listings may not appear in the Platform UI. However, existing sessions and new sessions through the Engine Pool remain unaffected.

3. monitoring Oct 29, 2025, 07:25 PM UTC

   A fix has been applied, and the UI elements for Engine Pool are now functional. Users should also be able to download from the Marketplace. Our engineering teams continue to monitor the service to ensure full recovery and will provide additional updates as more information becomes available.

4. resolved Oct 30, 2025, 12:26 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Oct 23, 2025, 02:01 PM UTC· resolved Oct 23, 2025, 03:11 PM UTC

1. resolved Oct 23, 2025, 11:07 PM UTC

   [Resolved] - This incident has been resolved. We are investigating reports that some customers are unable to access their tenant. Affected users may see the message: “Access Denied. Error 16. The request was blocked by our security service.” We have identified the issue as an invalid Web Application Firewall (WAF) policy that is unintentionally blocking traffic from certain regions. Our teams are working to revert the policy to restore access.

2. postmortem Oct 23, 2025, 11:07 PM UTC

   **Incident Overview** Platform and Secret Server Cloud services in certain regions were inaccessible to customers who encountered the following error: “Access Denied. Error 16. The request was blocked by our security service.” Start Time: October 23, 2025, 14:01 UTC End Time: October 23, 2025, 15:28 UTC The issue affected traffic originating from the Netherlands, Belarus, Pakistan, Kazakhstan, Iran, and most countries in Africa. Customers from other regions were not impacted. **Root Cause** An invalid Web Application Firewall \(WAF\) policy was inadvertently deployed to the production environment. The policy was intended for a test website but was mistakenly applied to the Platform WAF configuration, resulting in legitimate traffic from multiple regions being blocked. The invalid policy was identified and reverted at 15:11 UTC, restoring normal access. **Preventive Actions** * Strengthen the change control process with an additional verification step to prevent test policies from being deployed to production. * Reinforce environment-specific deployment training for internal teams. * Update operational playbooks to ensure teams can quickly validate and roll back WAF configuration changes.

Read the full incident report →

Started Oct 22, 2025, 10:08 PM UTC· resolved Oct 23, 2025, 09:18 PM UTC

1. investigating Oct 22, 2025, 10:08 PM UTC

   We’re currently conducting maintenance on the Thycotic One service. Our team is actively working to complete the necessary updates and improvements. If you have any questions or concerns regarding this maintenance, please do not hesitate to contact us at https://support.delinea.com. Thank you for your patience and understanding as we work to enhance our services.

2. resolved Oct 23, 2025, 09:18 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Oct 20, 2025, 05:25 PM UTC· resolved Oct 21, 2025, 03:16 AM UTC

1. investigating Oct 20, 2025, 05:25 PM UTC

   We are currently investigating intermittent login failures while accessing the tenant. Users would see Http failure response with a 504 error code. This issue is occurring due to failure of MFA code via email. Our engineering teams are fully engaged and working to restore normal service as quickly as possible. We apologize for any inconvenience this may cause and appreciate your patience during this time.

2. identified Oct 20, 2025, 05:45 PM UTC

   We are investigating intermittent login failures where users may see an HTTP 504 error. The issue is related to MFA codes failing to deliver via email. Users with email-based MFA are affected. As a workaround, please use other available MFA methods (e.g., authenticator app or SMS). Our engineering teams are actively working to restore the email-based MFA service. We appreciate your patience and will provide an update as soon as more information becomes available.

3. monitoring Oct 20, 2025, 06:15 PM UTC

   We are seeing improvements in the delivery of MFA codes via email. Login functionality is recovering for users who use email as their MFA option. Our engineering teams continue to monitor the service to ensure full recovery. We will provide additional updates as more information becomes available.

4. resolved Oct 21, 2025, 03:16 AM UTC

   This incident has been resolved.

5. postmortem Oct 28, 2025, 03:29 PM UTC

   ### Incident Overview On October 20, 2025, some users experienced intermittent login failures when accessing the tenant. Impacted users saw an HTTP 504 error caused by delays in receiving MFA codes via email. Users utilizing email-based MFA were affected, while those using other authentication methods such as authenticator app or SMS were able to log in successfully. The impact occurred during the following time windows: * First Window: Oct 20, 2025, from 07:00–09:10 UTC * Second Window: Oct 20, 2025, from 15:34–18:20 UTC ### Root Cause The issue was caused by a service disruption at our cloud provider in the US East region, which affected downstream email delivery services. This disruption led to email queuing delays and retries, resulting in intermittent failures when sending MFA codes via email. As a result, users depending on email-based MFA were unable to complete login attempts intermittently during the impacted periods. Normal service was restored once the cloud provider mitigated the regional disruption and email delivery performance stabilized. ### Preventive Actions To strengthen reliability and minimize future impact, we are implementing the following measures: * Transitioning to global email delivery endpoints across multiple regions to improve redundancy and resilience. * Evaluating a secondary email delivery provider to provide automatic failover in the event of a regional or provider-wide outage. * Enhancing monitoring and alerting for email delivery performance to enable faster detection and response to similar issues.

Read the full incident report →