Platform Tenants Unexpectedly Frozen

Update timeline

1. resolved Sep 04, 2026, 10:02 PM UTC

   Multiple Delinea Platform tenants were unexpectedly frozen due to an erroneous bulk configuration change, preventing customers from accessing their tenants. Engineering identified the cause, ran a revert job beginning at approximately 2:20 PM PDT, and all affected tenants were confirmed unfrozen by 2:49 PM PDT.

2. postmortem Sep 25, 2026, 05:05 AM UTC

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