Thycotic kesinti geçmişi

We are aware of an issue affecting the Delinea Platform in the US region. Some users may be experiencing difficulty logging in or accessing the platform, including unresponsive login attempts and unavailable resources after signing in. Our team is actively investigating. We will provide an update as soon as we have more information.

We have identified the cause of this incident. A connectivity issue with an upstream network provider affecting our New York point of presence is impacting access to the Delinea Platform for some US region users. Mitigation has been applied, with traffic being rerouted through an alternate point of presence to restore service. We are monitoring the situation closely and will provide a further update as events warrant

Traffic has been fully rerouted through alternate points of presence and service has been restored for affected US region users. We are monitoring the platform to confirm full stability.

This incident has been resolved.

We are currently investigating reports of Distributed Engines being unable to connect to Secret Server Cloud. Customers may experience issues accessing secrets that rely on Distributed Engines, including remote session launches through Connection Manager and proxied secret operations. Our engineering team is actively investigating the root cause and working to restore full functionality. We will provide an update as soon as we have more information. We apologize for any inconvenience this may be causing.

We are continuing to investigate this issue.

We have identified the cause of the Distributed Engine connectivity issue. A compatibility mismatch between the Distributed Engine and a backend service is preventing connections from being established. Our engineering team is deploying a fix to the impacted regions (US, UK and CA) to resolve the issue. We will continue to provide updates as the deployment progresses. We apologize for any inconvenience this may be causing.

The fix has been deployed to the UK and Canada regions. Distributed Engines in those regions will automatically re-establish connectivity. Deployment to the US region is still in progress. We will provide another update once the US deployment is complete. We apologize for any inconvenience this may be causing.

The fix has been successfully deployed to all regions. We have confirmed that Distributed Engine connectivity has been re-established across UK, Canada, and US regions. We are continuing to monitor the environment to ensure stability. We apologize for any inconvenience this has caused.

This incident has been resolved.

## Incident Overview On May 20, 2026, a subset of customers in the US, UK, and Canada regions experienced Distributed Engines going offline, which prevented access to secrets that depend on Distributed Engines. Affected customers were unable to launch remote sessions through Connection Manager and could not perform other proxied secret operations during the impact window. * **Start:** May 20, 2026, 11:30 AM Central \(4:30 PM UTC\) * **End:** May 20, 2026, 2:35 PM Central \(7:35 PM UTC\) ## Root Cause and Remediation During the recent patch of Secret Server, the Distributed Engines in US, CA, and UK were not functioning for a brief period due to an incompatibility issue between the new Distributed Engine and the prior Secret Server version. The new Distributed Engine expected a configuration value that the older Secret Server version was not yet providing, which prevented the Distributed Engine from starting up cleanly. The affected Distributed Engines entered a retry loop and could not self-recover until the compatibility issue was corrected. To remediate, the latest Secret Server backend was deployed to the impacted regions, restoring compatibility with the new Distributed Engine. The deployment was completed first in the UK and Canada regions, followed by the US region. Distributed Engines in all affected regions automatically re-established connectivity once the deployment was completed, requiring no customer action. Connectivity was confirmed restored across all three regions at 2:35 PM Central. ## Preventative Actions * Implement forward-compatibility testing for Distributed Engine releases, including a response-mocking harness that simulates a Secret Server omitting newly introduced configuration keys, and a per-PR checklist to ensure new configuration reads are covered by the harness. * Update the Distributed Engine release pipeline to support region-specific deployments, enabling controlled rollout sequencing and tighter regional containment during multi-component releases. * Strengthen automated testing to verify Secret Server compatibility with both the prior and current Distributed Engine versions. We sincerely apologize for the disruption this caused and the inconvenience to your operations. We are committed to preventing recurrence through the above actions.

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

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

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.

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.

**Incident Overview** On May 11, 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.

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.

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.

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.

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.

We’re pleased to inform you that the incident affecting the service(s) listed below has been resolved. The load causing the issue has resolved. 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.

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.

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.

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.

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.

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

This incident has been resolved.

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

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.

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

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.

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

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.

We are continuing to investigate this issue.

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.

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.

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.

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

This incident has been resolved.

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

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

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

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

This incident has been resolved.

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.

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

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.

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.

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.

This incident has been resolved.

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

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.

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.

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.

Maintenance is complete and we are monitoring the results

This incident has been resolved.

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.

We are continuing to investigate this issue.

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.

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.

We are continuing to monitor for any further issues.

This incident has been resolved.

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

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.

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.

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.

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.

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

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.

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.

This incident has been resolved.

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

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.

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.

This incident has been resolved.

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