TL;DR
On October 15, 2026, someone signed into customer Microsoft 365 tenants as the trusted ConnectWise Cloud Backup (formerly SkyKick) application. ConnectWise suspended the service, so archives were preserved but restores were unavailable. For IAM teams, a backup existing isn’t enough: the recovery copy must be isolated from the compromised administrator, reachable without the broken IdP, restored from a state you can explain and trust, and verified by real sign-ins.
The Recovery Trust Chain
| Stage | Principle |
|---|---|
| 01 Compromised state | Assume trusted credentials can be stolen. |
| 02 Preserved history | Keep earlier recovery copies isolated and immutable. |
| 03 Verified access | Restore selected identity state and test sign-in. |
The Incident / October 15–19, 2026
The Recovery Service Became Part of the Incident
When a backup provider suspends its integrations during a security investigation, customers may find their data safely archived but temporarily lose the ability to restore it.
That is the practical problem ConnectWise Cloud Backup, formerly SkyKick, brought into view. On October 15, someone authenticated to customer Microsoft 365 environments as the trusted Cloud Backup application. Huntress found Microsoft Graph tokens issued through an application credential controlled in the vendor environment. User passwords and MFA prompts were not part of those app-only sign-ins. [1], [2]
Huntress confirmed unauthorized application sign-ins in 162 tenants as of 19:00 UTC on October 16. That count is not a confirmed count of data theft. The original credential exposure mechanism and the full downstream impact were still under investigation. [2]
ConnectWise disabled seven application identities on October 17. Its October 19 advisory said Cloud Backup, SaaS Security, and Cloud Management were still suspended. Scheduled backups, archive access, and restores remained unavailable, though ConnectWise said existing backup archives were encrypted, isolated, and preserved. [1]
Containment Does Not Erase What an Application Already Changed
ConnectWise explicitly warned that disabling the affected connections does not reverse changes made earlier in a tenant. Huntress separately documented ConnectWise Cloud Management application activity that assigned Global Administrator privileges and planted new credentials in other applications. The researchers cautioned that not all observed activity could be attributed to the same operator. [1], [2]
Two Independent Failure Modes
First, the recovery service may be unavailable during containment. Second, the compromised identity environment may no longer be a trustworthy starting point for repair.
For IAM teams, the real question is not simply whether a backup exists, but whether they can actually recover. Can someone still reach a protected copy of identity state, determine which version is trustworthy, and recover the access needed to bring the business back online?
Recovery Architecture / Acsense
The Recovery History Must Survive the Compromised Administrator
A backup should not be editable by the same compromised privilege that damaged the production identity environment.
Acsense starts from the assumption that credentials can be stolen, including those held by trusted administrators. The Acsense Vault is built as an isolated, air-gapped store for identity recovery copies, with a controlled extraction path. Point-in-time copies are immutable after creation. The aim is specific: acquiring access to an administrative interface must not allow an attacker to rewrite or erase the existing recovery history.
Isolation and Immutability Solve Different Problems
Isolation separates stored recovery data from the identity environment that may be under attack. Immutability protects previously captured records against later alteration. Neither proves that every historical configuration was safe when captured. A malicious role assignment can be faithfully preserved in an immutable backup, too. The team still has to select an earlier state it can explain and trust.
Recovery Login Should Not Depend Entirely on the Broken IdP
If access to the recovery console requires SSO through the identity provider being rebuilt, the recovery plan has a circular dependency. Acsense advises maintaining a separate, authorized recovery access path rather than relying solely on the protected IdP. Acsense uses separately managed Okta-based customer identity infrastructure with enforced security policies; its employee and administrator lifecycle controls include deprovisioning departing administrators.
This is separation from the customer tenant, not a claim that recovery has no external dependencies. Operators still need to test who can authenticate, what approvals are required, and how the service behaves when either the protected IdP or a supporting provider is unavailable.
Checks Protect the Starting Point; Drills Prove the Path
Acsense performs backup-data integrity checks every two weeks. Those checks support confidence in the stored record. They are not equivalent to completing an end-to-end restore, reconnecting applications, or proving people can sign in afterward. Both kinds of evidence belong in a recovery program.
What Immutability Does Not Promise
An immutable copy cannot be treated as automatically clean, and protected storage alone does not guarantee that every restore operation will always be available. The recovery plan must account for access, approvals, supported objects, and downstream application dependencies.
See Entra ID Recovery in Action
Walk through isolated recovery history, trusted state selection, and restore verification. Live, not slides.
Request a DemoIncident Response / Identity State
From a Trusted Recovery Point to Working Access
After the attacker is contained, the real job is to recover the intended identity configuration without recreating the attacker’s access or undoing legitimate business changes.
| Step | What Happens |
|---|---|
| 01 Contain | The customer’s security and IAM teams disable affected integrations, invalidate credentials where appropriate, review issued tokens and other access paths, and preserve available investigation evidence. Acsense does not replace this incident response work. |
| 02 Reconstruct | Use provider logs and Acsense historical identity state together. Compare the current configuration with earlier versions, focusing on changed application credentials where visible, directory roles, policies, groups, users, app configurations, and assignments. A suspicious change must be checked against approvals and its surrounding context. |
| 03 Choose | Select a recovery point from before the unwanted change, but do not treat “older” as synonymous with “good.” Confirm which state is trusted, which later changes were legitimate, and whether a targeted recovery is safer than a broad rollback. |
| 04 Recover | Within the agreed Microsoft Entra ID integration and supported object/recovery scope, Acsense can help recover affected users, groups, policies, application configurations, assignments, and supported relationships. Recovery capabilities vary by provider and object. Credentials or secret values that the provider does not expose for backup may need to be reissued and reconnected separately. |
| 05 Verify | Check the resulting IdP configuration, administrator privileges, and access to the most important applications. Test actual sign-in and federation where relevant. If an application needs updated trust metadata, credentials, or downstream settings, assign an owner to finish that work. An API success response is not proof of restored business access. |
An Operational Division of Responsibility
The security team owns attacker containment and decisions about trusted state. Acsense contributes preserved identity history and supports recovery operations. Application owners and IAM teams verify that real users and responders can reach the systems needed for broader recovery.
The business outcome is not a restored object count. It is employees signing into critical systems and response teams regaining authorized access to backup consoles, operational tooling, and the systems needed to recover application data through their own recovery processes.
Practitioner Drill / 30 Minutes
Test the Recovery Dependency Before You Need It
Pick one critical application that depends on Microsoft Entra ID. Run the following exercise with the IAM lead, incident responder, and application owner. Use a test tenant or pre-agreed nonproduction scope for any write operation.
| Check | Question |
|---|---|
| A Protect | Can a compromised tenant administrator or Acsense administrator change an existing recovery copy? Which controls prove the answer? |
| B Access | If the protected IdP cannot authenticate anyone, what authorized route remains to the recovery console? Who has tested it, and what other providers does it still rely on? |
| C Trust | Can the team identify when a privileged application role or assignment changed, find the relevant historical state, and show why it is the state to restore? |
| D Restore | Can the team recover the specific supported objects and relationships without overwriting later approved changes? Who reissues nonrecoverable secrets or reconnects federation? |
| E Verify | Can a real user and a response administrator reach the critical applications and recovery systems afterward? Where is that evidence recorded? |
Acsense’s architectural principle is simple: recovery starts with a copy the attacker could not rewrite and a controlled way to restore from it. The harder test is the full sequence: preserve, investigate, approve, recover, and verify. That sequence should work before an incident makes it urgent.
Protect Your Entire Identity Infrastructure
One platform. Okta and Entra ID. Backup, configuration management, disaster recovery, and compliance under one roof.
Request a DemoFrequently Asked Questions
What happened in the ConnectWise Cloud Backup (SkyKick) incident?
On October 15, 2026, someone authenticated to customer Microsoft 365 environments as the trusted Cloud Backup application, using Microsoft Graph tokens issued through an application credential controlled in the vendor environment. Huntress confirmed unauthorized application sign-ins in 162 tenants as of 19:00 UTC on October 16. ConnectWise disabled seven application identities on October 17, and as of October 19 Cloud Backup, SaaS Security, and Cloud Management remained suspended. Root cause, data access, and full impact were still under investigation.
Does disabling a compromised integration reverse the changes it made?
No. ConnectWise explicitly warned that disabling the affected connections does not reverse changes made earlier in a tenant. Huntress documented application activity that assigned Global Administrator privileges and planted new credentials in other applications, so those changes must be found and recovered separately.
Is an immutable backup automatically a clean backup?
No. Immutability protects previously captured records against later alteration, but a malicious role assignment can be faithfully preserved in an immutable backup too. The team still has to select an earlier state it can explain and trust.
Why shouldn’t recovery console access depend on the identity provider being restored?
If access to the recovery console requires SSO through the identity provider being rebuilt, the recovery plan has a circular dependency. Maintain a separate, authorized recovery access path and test who can authenticate, what approvals are required, and how the service behaves when the protected IdP or a supporting provider is unavailable.
How do you prove an identity restore actually worked?
Check the resulting IdP configuration, administrator privileges, and access to critical applications, and test actual sign-in and federation. An API success response is not proof of restored business access; the outcome that matters is employees and responders signing into the systems they need.
Sources & Claim Limits
- ConnectWise, “Cloud Backup (formerly known as SkyKick) Service Interruption,” originally published October 16, updated October 19, 2026 at 13:45 UTC. Official advisory
- Huntress, “ConnectWise (SkyKick) Vendor Credentials Abused in M365 Attacks,” investigation and October 17–19 updates; see Figures 1 and 2, and the “What we have not confirmed” section. Primary research
- Acsense IAM Resilience Platform product description. Details on Vault architecture, customer access practices, and the two-week integrity-check cadence reflect Acsense-supplied security information for editorial review. Platform overview
Reporting cutoff: October 19, 2026, 10:45 a.m. Pacific. Incident root cause, data access, impact and service restoration remain under investigation. The ConnectWise case is not an Acsense deployment. Restore capabilities depend on the configured provider, object type, supported release, and recovery path.
