ConnectWise Cloud Backup Is Coming Back: How I'd Re-authorize Each Microsoft 365 Tenant

Two weeks ago I wrote about the ConnectWise Cloud Backup breach and the checks I’d run in every Microsoft 365 tenant. The short version: a stolen credential for the Cloud Backup application (the product that used to be SkyKick) was used to sign in to customer tenants, and ConnectWise switched the service off.

The update since then is that ConnectWise is bringing Cloud Backup back, and it isn’t flipping the old app back on. It’s restoring service through a new, security-hardened application, and every tenant has to be re-authorized to it. If you have clients on Cloud Backup, that’s a job you’ll be doing tenant by tenant, probably this week.

Here’s how I’d approach it so that “backups are back” actually means something.

What changed since October 21

From ConnectWise’s advisories on its Trust Center and status page, and the reporting linked at the end:

• Credentials reset. On October 20, ConnectWise said it had finished an account and credential reset in the affected Cloud Backup environment and was preparing a phased restoration.
• A new app. ConnectWise’s October 30 advisory says restoration is underway through a new, security-hardened application, ConnectWise Cloud Backup for M365. Backups and restores resume for a tenant once it has been re-authorized to the new app.
• The old app connections stay off. ConnectWise is telling partners not to re-enable any app connections they disabled during the incident unless ConnectWise specifically says to.
• Re-authorizing isn’t the finish line. ConnectWise’s guidance also says re-authorization alone doesn’t confirm backups are running. You have to check that new backups actually complete.

What hasn’t changed: Microsoft’s October 21 write-up attributed the original compromise to a China-aligned group it tracks as Storm-0940. And as I said last time, rotating the vendor’s credential does nothing about a secret or role an attacker may have added inside a client’s tenant. If you haven’t run those checks, do that first. Re-authorizing a backup app into a tenant that still has an attacker’s credential on another app is putting a new lock on a house with an open window.

The order I’d work in

The per-tenant order I’d follow. Steps 2 and 3 are ConnectWise’s; the rest is the paperwork that makes them trustworthy.

1. Export the logs and record the old app IDs first. Before you change anything, save the tenant’s directory audit log and service principal sign-in log from early October on, outside the tenant. Write down the application IDs of the old ConnectWise apps you disabled. Once you start consenting to new apps, the audit trail gets noisier, and you’ll want a clean “before.”
2. Reset the Cloud Services portal password and complete MFA. That’s ConnectWise’s first step, and it’s the right one. Your portal account is the thing that drives authorization into every client tenant.
3. Re-authorize the tenant to ConnectWise Cloud Backup for M365, using the method that matches how that tenant was set up: self-authentication, delegated authentication or Partner Center. Use ConnectWise’s own instructions for your method, from the Trust Center, not a link someone forwarded you. An incident like this is perfect cover for a phishing email that says “re-authorize your backup,” so I wouldn’t click one.
4. Record the new app’s application ID and the permissions it was granted. You’ll want this for your documentation and for the next time you review consented apps. I’d match it by ID, not by display name, for the same reason as last time: names can change.
5. Confirm the old apps are still disabled. The new consent shouldn’t touch them, but check. Don’t delete them either. They’re evidence until you’re sure you won’t need them.
6. Check that a new backup completes, then test a restore. Restore a single file or mailbox item to an alternate location. “Authorized” and “protected” are not the same thing.

📝 Note: If you’re also using ConnectWise SaaS Security or Cloud Management, they were suspended at the same time because they’re integrated with Cloud Backup. Treat each one the same way: follow ConnectWise’s instructions for that product and don’t re-enable an old connection on your own.

A read-only check for steps 1, 4 and 5

This uses the Microsoft Graph PowerShell SDK and doesn’t change anything in the tenant. Run it once before you re-authorize and once after. Pass it the application IDs you’re tracking (the old ones from your notes, and the new one once you have it), and it shows whether each is present and enabled, what application permissions it holds, and every consent, new-app, permission and credential event in the audit log since the date you give it.

# Read-only. Requires: Install-Module Microsoft.Graph -Scope CurrentUser
param(
    [Parameter(Mandatory)] [string]   $TenantId,
    [Parameter(Mandatory)] [string[]] $AppId,      # old and new app IDs you're tracking
    [datetime] $Since = '2026-10-15'
)

Connect-MgGraph -TenantId $TenantId -Scopes 'Application.Read.All','Directory.Read.All','AuditLog.Read.All' -NoWelcome

# State and application permissions for each tracked app, matched by AppId (not name)
foreach ($id in $AppId) {
    $sp = Get-MgServicePrincipal -Filter "appId eq '$id'" -Property Id,AppId,DisplayName,AccountEnabled
    if (-not $sp) {
        Write-Host "`n$id : not present in this tenant" -ForegroundColor Yellow
        continue
    }
    Write-Host "`n== $($sp.DisplayName) ($id) Enabled: $($sp.AccountEnabled) ==" -ForegroundColor Cyan
    Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $sp.Id -All | ForEach-Object {
        $resource = Get-MgServicePrincipal -ServicePrincipalId $_.ResourceId -Property DisplayName,AppRoles
        $roleId   = $_.AppRoleId
        $role     = $resource.AppRoles | Where-Object { $_.Id -eq $roleId }
        [pscustomobject]@{
            Resource   = $resource.DisplayName
            Permission = $role.Value
            Granted    = $_.CreatedDateTime
        }
    } | Sort-Object Resource, Permission | Format-Table -AutoSize
}

# Consents, new service principals, new app permissions and new app credentials since $Since
Write-Host "`n== Consent, permission and credential events since $($Since.ToString('yyyy-MM-dd')) ==" -ForegroundColor Cyan
$filter = "activityDateTime ge $($Since.ToUniversalTime().ToString('yyyy-MM-ddTHH:mm:ssZ'))"
# Partial matches on purpose: Entra's activity names vary slightly
# (e.g. "Add app role assignment to service principal" vs "... to the service principal")
$events = 'Consent to application|Add service principal|Add app role assignment|Certificates and secrets management|service principal credentials'
Get-MgAuditLogDirectoryAudit -All -Filter $filter |
    Where-Object { $_.ActivityDisplayName -match $events } |
    Select-Object ActivityDateTime, ActivityDisplayName,
        @{ n = 'Actor';  e = { if ($_.InitiatedBy.User.UserPrincipalName) { $_.InitiatedBy.User.UserPrincipalName } else { "app: $($_.InitiatedBy.App.DisplayName)" } } },
        @{ n = 'Target'; e = { ($_.TargetResources | ForEach-Object DisplayName) -join ', ' } } |
    Sort-Object ActivityDateTime |
    Format-Table -AutoSize -Wrap

Disconnect-MgGraph | Out-Null

What I’m looking for after re-authorizing: the old apps show Enabled: False, the new app shows Enabled: True with the permissions you’d expect a backup tool to need, and every consent, permission or credential event in the audit log is one you made, at the time you made it. A consent, or a new secret or certificate on any app, that you can’t account for is the thing to stop and investigate.

📝 Note: If the audit section comes back empty, that may just mean the logs have aged out on that tenant. That’s another reason step 1 says export them first.

Tell the client the date backups resumed

This is the part that’s easy to skip. For the stretch Cloud Backup was off, scheduled backups weren’t running. When a client asks for a restore of something from late October, you need to know whether a backup existed then.

So for each tenant I’d write down three dates in the ticket: when backups stopped, when the tenant was re-authorized, and when the first new backup completed. Then I’d tell the client in plain language. Something like: “Your Microsoft 365 backups were paused from mid-October while the vendor dealt with a security incident. They resumed on this date, and we’ve tested a restore.” That’s a much better conversation to have now than during a restore request.

What I’d change going forward

Last time I said one cloud backup vendor, connected with broad standing permissions, may not be enough. Coming out of this, here’s what I’d put on the list:

1. A second copy for the clients who can’t afford a gap. For some of them, a few weeks without a Microsoft 365 backup is a shrug. For others, like anyone with legal holds or heavy SharePoint use, it isn’t. Have that conversation per client, not as a blanket policy.
2. App IDs in your documentation. For every tenant, keep a short list of consented third-party apps, their IDs and why they’re there. It made this incident much faster for anyone who had it.
3. Alerts on consents, new app permissions and new app credentials. The same events this script reads from the audit log (consents, app role assignments, and secrets or certificates added to any app or service principal) are worth alerting on all the time, not just during an incident.
4. A restore test on a schedule. We do this with on-site backups already. The UniFi NAS backups I run get the same treatment. Cloud-to-cloud backups deserve it too.

None of that is specific to ConnectWise. Any vendor that holds a key to your clients’ tenants can have a bad month, and the cleanup always lands on the MSP.

If you manage your own Microsoft 365 tenant and aren’t sure what’s connected to it, or whether your backups actually ran last month, get in touch. It’s the kind of check that takes an afternoon and saves a very bad day.

Sources

• ConnectWise Trust Center: security advisories, ConnectWise, October 2026 (including the October 30 restoration advisory)
• ConnectWise Product and Services Status, ConnectWise, October 2026
• AI-driven, large-scale nation-state campaign using ARTEX enables supply chain compromise, Microsoft Security Blog, October 21, 2026
• ConnectWise (SkyKick) Vendor Credentials Abused in M365 Attacks, Huntress, October 16, 2026