How to Disable a Microsoft 365 App and Revoke Its Access

If you back up Microsoft 365 with ConnectWise Cloud Backup (formerly SkyKick), your backup vendor just became a security question.

On 16 October 2026, Huntress published a report saying a credential for that app was compromised and used to get Microsoft Graph tokens in customer tenants. The story is still developing. This post skips who did it and covers your side: switch the app off, take back what you gave it, and check it didn't leave anything behind.

The steps work for any enterprise app you need to cut off, not just this one. Portal labels are as of October 2026, and Microsoft moves them around.

What Huntress reported, as of 19 October 2026

Everything in this section is from Huntress's report by Jonathan Semon, first published 16 October 2026 and updated through 19 October. We haven't verified any of it independently, and the page is still changing.

• The credential. Huntress says a credential for the ConnectWise Cloud Backup app was compromised and used to sign in from a hosting provider's IP address, not Azure's, and receive Microsoft Graph tokens. It says the credential lives in the vendor's tenant, so nothing in your tenant caused it.
• The count. At its first report, Huntress had confirmed unauthorized sign-ins in 162 tenants. A later update says almost 1,000 Entra tenants saw sign-in activity from that IP and over 300 of those succeeded.
• More apps. Huntress says several ConnectWise Cloud Management apps (Exchange Online, Teams, SharePoint Online, MS Graph and Partner Center) were also abused. In one partner tenant, it says the Teams app gave itself Global Administrator and added client secrets, set to expire in 2028, to two other apps.
• What it doesn't know. Huntress's last confirmed successful sign-in with the credential was at 08:44 UTC on 15 October. In the tenant audit log it studied closely it saw no mail or file access, but it also says directory reads through Graph leave no audit record. Its own summary is "tokens issued, nothing visible taken."
• The vendor. Per Huntress, ConnectWise said on 17 October that it had disabled the relevant apps. As of Huntress's 19 October update, the page doesn't say the credentials have been reset.

That last point is why this is your job and not just ConnectWise's. Huntress's advice is to cut the apps off in your tenant until the vendor confirms.

The quick answer

1. Disable the app. Don't delete it. In the Entra admin center, go to Entra ID > Enterprise apps > All applications, open the app, select Properties, set Enabled for users to sign-in? to No, and save.
2. Check what directory roles it holds and remove any you didn't give it on purpose.
3. Review every client secret and certificate on your enterprise apps and app registrations for anything added since 13 October that you didn't create.
4. Read the service principal sign-in logs and the audit log for the app.
5. Revoke its permissions only if you've decided it isn't coming back. Otherwise leave them and keep it disabled.
6. Leave it off until ConnectWise confirms every credential has been reset.

About an hour of work if the tenant is small. Longer if you find something.

Know the pieces first

Four terms, in plain words. Microsoft's page on application and service principal objects has the long version.

App registration. The vendor's definition of the app. It lives in the vendor's tenant, which Microsoft calls its home tenant. You can't see it or change it.

Enterprise application (service principal). Your tenant's local copy of that app. Microsoft says it defines what the app can actually do in your tenant, who can access it, and which resources it can reach. Everything in this post happens here, or on your own app registrations.

Delegated vs application permissions. Delegated permissions let an app act for a signed-in user, and it can't reach anything that user couldn't. Application permissions let it act as itself with nobody signed in. Microsoft's example is an app with the Graph Files.Read.All application permission, which can read any file in the tenant. Microsoft lists backup as a typical use, and says that in general only an admin can consent to application permissions.

Admin consent. Someone with admin rights clicked Accept for the whole organization. That grant is what you revoke in Step 3.

So why does a vendor app keep working when no one is signed in? Because that's what a backup tool is for. It reads mail and files at 2am as itself. The same design is why a stolen app credential is a bigger deal than a stolen user password: there's no MFA prompt for an app. Microsoft's page on workload identities says they can't perform multifactor authentication.

Step 1: Find the app in your tenant

What it is. The enterprise application entry for the vendor's app.

Where to click. Sign in to the Microsoft Entra admin center as at least a Cloud Application Administrator, which is the minimum role Microsoft lists for the next step too. Go to Entra ID > Enterprise apps > All applications and search by name.

Huntress gives the Application ID for ConnectWise Cloud Backup: 506e08f9-6e9a-4da4-942b-a099a03644ae. It also lists IDs for each Cloud Management app on its post, and says older tenants may show them as "SkyKick Cloud Manager." Open each match, select Properties, and compare the Application ID. Microsoft defines two different IDs here: the Application ID, and the Object ID of the service principal. Write both down. PowerShell wants one or the other.

What good looks like. Either the app isn't there, or you recognize it and know who approved it. If you have several ConnectWise apps and can't say why, ask your provider before touching anything.

How to confirm. The Permissions page shows what was granted, on the Admin consent tab for the whole organization and the User consent tab for individuals. Microsoft's review page covers both. A backup tool will list mail and file permissions. That's the job. You're checking that nothing else is on the list.

Step 2: Disable it, and don't delete it

What it is. One switch that stops your tenant issuing tokens for the app.

Where to click. On the app's Properties page, set Enabled for users to sign-in? to No and select Save. Microsoft says this prevents all tokens from being issued for that application. The app's Activation status will then read Deactivated.

If you'd rather script it, this is Microsoft's own example for Graph PowerShell:

Connect-MgGraph -Scopes "Application.ReadWrite.All"

$appId = "506e08f9-6e9a-4da4-942b-a099a03644ae"
$servicePrincipal = Get-MgServicePrincipal -Filter "appId eq '$appId'"

Update-MgServicePrincipal -ServicePrincipalId $servicePrincipal.Id -AccountEnabled:$false

What good looks like. The app's Activation status says Deactivated.

How to confirm. Reload Properties and check the toggle, then check the sign-in logs in Step 4 for new activity after the time you flipped it.

One caution on timing. Microsoft's page on deactivating app registrations says tokens already issued stay valid until they expire, and its revoke-access page puts the default access token lifetime at one hour. Neither page speaks to this exact switch, so don't assume instant. Give it an hour before you call the app quiet.

Why disable and not delete

Huntress's advice is blunt: disable the apps, don't delete them. Its reason is that deleting removes the consent, and you'd have to re-consent to restore service.

Microsoft adds a second reason. A deleted enterprise app doesn't keep its configuration, though it does sit in the recycle bin for 30 days. Microsoft's delete page says to consider deactivating first because it's "ideal for investigation, security incidents, or temporary suspension." You want the app's permissions and settings left exactly as they are while you work out what happened.

Here's how the options compare.

Huntress is explicit that disabling doesn't clean up after the app: "Disabling M365 apps, including the abused ConnectWise apps will not remove credentials that were already added." That's why Step 3 exists.

What you lose

Backups stop. Per Huntress, disabling the app pauses automated backups until it's re-enabled, and existing backups held by ConnectWise aren't deleted. Write down the date and time you disabled it so you know how long the gap is.

Accept the gap for now. Then ask ConnectWise about retention and how a restore works, so you know the answer before you need it. Huntress's piece on operational resilience includes backup restore tests in its closing checklist, and this is a good week to run one.

Step 3: Take back what it holds

Disabling blocks new sign-ins. These four checks look at what's left behind.

3a. Permissions it was granted

Where to click. App's Permissions page. On the Admin consent tab, select the ... next to a permission and choose Revoke permission. Microsoft notes you can't revoke from the User consent tab in the portal, and points to Graph or PowerShell for those. See the review page.

Here's the decision. Revoking removes the grants, which is the same thing Huntress says deleting would lose. If the app is coming back, leave the grants and keep it disabled. If it isn't, revoke.

To review without changing anything, Microsoft's page shows these lines, after you connect with the scopes it lists:

$sp = Get-MgServicePrincipal -ServicePrincipalID "<ServicePrincipal objectID>"

# Delegated permissions
Get-MgOauth2PermissionGrant -All | Where-Object { $_.clientId -eq $sp.Id }

# Application permissions
Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $Sp.Id -All | Where-Object { $_.PrincipalType -eq "ServicePrincipal" }

Don't run the rest of that page's script. It removes everything.

Two more things from the same page. Revoking doesn't stop someone consenting again, and consent isn't the only way an app gets access. Entra roles, Exchange RBAC and Teams resource-specific consent can each grant access on their own. Check them too. The page also has a script that removes users and groups assigned to the app.

3b. Directory roles

What it is. The most dangerous thing in Huntress's report. It says one ConnectWise app gave itself Global Administrator in a partner tenant, and in about 50 monitored tenants the Cloud Management apps assigned themselves directory roles, mostly Exchange Administrator.

Where to click. Go to Entra ID > Roles & admins, then select a role's name (don't tick the box) and open Assignments. That's Microsoft's method. Start with Global Administrator and Privileged Authentication Administrator, which Huntress names, then Exchange Administrator. Look for any vendor app in the list.

In PowerShell, Microsoft shows this filter for one principal:

Get-MgRoleManagementDirectoryRoleAssignment -Filter "PrincipalId eq '<service principal object ID>'"

How to fix it. Back on the role's page, tick the assignment and select Remove assignment. Microsoft's removal page says you need at least Privileged Role Administrator. The PowerShell version is Remove-MgRoleManagementDirectoryRoleAssignment -UnifiedRoleAssignmentId $roleAssignment.Id. With Entra ID P2 and Privileged Identity Management, the screens differ, and Microsoft links separate steps.

What good looks like. No vendor app holds a role you didn't deliberately give it.

3c. Secrets and certificates

What it is. The part Disable doesn't touch. Huntress says the actor added client secrets, set to expire in 2028, to two other apps in one tenant: an MSP management app and a single-tenant Huntress app. A secret on a trusted app is a spare key that outlives everything else you do.

Huntress's own write-up of a five-minute privilege escalation shows why this matters. A standard user reached Global Administrator by finding a service account that owned an over-privileged app and creating a credential for it. No exploit needed.

Where to click. Go to Entra ID > App registrations > All applications, open each app, and select Certificates & secrets. Microsoft lists three tabs: Certificates, Client secrets and Federated credentials. Check all three. Huntress says to include management and security tools, and your Huntress app if you use one. That also covers apps you built or inherited.

What good looks like. Every credential has a description you recognize and a date that fits when someone legitimately created it. Anything added since 13 October that you can't explain is a problem. Huntress says to remove anything unexpected.

How to fix it. Select the credential and remove it, as in Microsoft's walkthrough. First make sure it isn't one your own app depends on. If you can't tell, find out who added it in the audit log (Step 4) before you delete it.

Service principals carry credentials too. Microsoft's page says to query the service principal's key and password credentials in Graph (beta) and use removePassword or removeKey. SAML certificates are under Enterprise apps > the app > Single sign-on.

3d. Sessions and refresh tokens

A backup app acts as itself, so there's no user session to kill for the app. If a person's account is involved, revoke it from Entra ID > Users > All users, select the user, then Revoke sessions, or run Revoke-MgUserSignInSession -UserId $User.Id, per Microsoft.

Why bother? Huntress's OAuth token research shows a refresh token working from other machines and networks until someone revokes it. If your accounts sync from on-premises Active Directory, Huntress also notes that a cloud-disabled account could be re-enabled by sync within seconds. Disable at the source.

Step 4: Investigate what it did

What it is. Two logs. Neither gives you a clean yes or no.

Sign-in logs. Go to Entra ID > Monitoring & health > Sign-in logs and open the Service principal sign-ins tab. Huntress warns that the default User sign-ins tab won't show this data. Filter by the app's ID. Microsoft's FAQ shows filtering by Service Principal ID. Huntress says to look for IPs that aren't Microsoft or Azure, and puts its list of indicators on its post, so we won't copy it here. Microsoft says these entries can't be changed or deleted, and that repeat sign-ins from the same app, status, IP and resource are grouped into one row you can expand.

Audit logs. Go to Monitoring & health > Audit logs and set Category to ApplicationManagement, as Microsoft shows. Then filter Activity. Microsoft's activity list includes these for what we're after:

• Add service principal credentials
• Update application - Certificates and secrets management
• Add app role assignment to service principal
• Add delegated permission grant
• Consent to application
• Add member to role outside of PIM (permanent)

Huntress says to look for the ConnectWise or SkyKick apps adding themselves to roles or changing other apps, and to note the User-Agent. It also says a user-agent on its own is low-fidelity.

Conditional Access exclusions. Open Entra ID > Conditional Access > Policies and check whether any policy excludes these apps. Huntress lists it as a check.

What good looks like. Sign-ins only from Microsoft ranges, no unexplained credential or role events since 13 October.

What a clean result doesn't prove. Huntress says a clean result "does not rule out access." It also says directory reads through Graph leave no audit trail, so nobody can tell you from the logs that nothing was read. It also says the IP alone doesn't identify the operator. If the logs show something odd, that's the point to get help, not to guess.

If you have Entra ID Protection, check ID Protection > Risky workload identities too. Microsoft says it detects risk on single-tenant, third-party SaaS and multitenant apps, though full detail needs Workload Identities Premium. The same page lists the questions to ask: unusual sign-ins, unauthorized credential changes, suspicious configuration changes, new application roles.

Step 5: Block the next one

None of these would have stopped a vendor's own credential being stolen. They limit what a stolen credential, or a rogue consent, can do in your tenant.

On the first row, Microsoft's tutorial recommends blocking client secrets entirely and capping certificates at 180 days. That's a good default for apps you own. For vendor apps, check with the vendor before you flip anything, because it can break them.

Huntress's own take on the weak spots is worth reading. Its Rogue Apps announcement says default Microsoft 365 settings let almost any user install almost any app. And its password spray write-up shows organizations with MFA policies that had gaps getting breached anyway. Both are one more reason to know what's in your enterprise apps list. We also cover the connected apps problem from the user side, and credential stuffing for the passwords half.

Huntress also makes a wider point in its piece on supply chain attacks: keep a current map of your vendors and what each can reach. Your enterprise apps list is that map. Review it on a schedule.

Step 6: Turning it back on, or not

Don't, yet. Huntress says not to re-enable affected ConnectWise apps until ConnectWise confirms all credentials have been reset.

When that day comes, Microsoft says to review why sign-in was disabled before restoring it. Then set Enabled for users to sign-in? back to Yes and save. Before you do, get answers from the vendor in writing:

• Which credentials were reset, and when?
• Can they tell you whether your tenant saw sign-ins from the compromised credential?
• How do you restore from existing backups while the app is off?

Then re-run Steps 3 and 4 once more. Backups will resume, but you'll have a gap, so check what the vendor can tell you about it.

Do this today

• Write down the Application ID and Object ID of every ConnectWise or SkyKick app in your tenant.
• Disable each one that you can't verify.
• Check directory roles for any vendor app. Remove what you didn't grant.
• Review client secrets and certificates on all enterprise apps and app registrations. Anything added since 13 October that you didn't create gets investigated.
• Read the service principal sign-ins and the audit log. Save screenshots.
• Check Conditional Access exclusions.
• Note the date backups paused and ask ConnectWise about retention and restore.
• Put a recurring reminder on your calendar to review your enterprise apps list.

If you don't have a team for this

Some of this needs Cloud Application Administrator, some needs Privileged Role Administrator, and all of it needs a free afternoon. A lot of small businesses have none of the three on hand.

If you already have an IT person, our co-managed security service is built for this: they keep the day-to-day, we handle the watching and the hardening. We're a Huntress reseller, so weigh that when you read our take. Every claim about the incident above comes from Huntress's public page, not from anything we've seen. Can We Get Huntress Without Switching IT Providers? explains how that works.

If you'd rather talk it through, contact us.

Related reading

• Which Apps Can Access Your Business Email and Files? How to Audit Connected AI Tools
• The Microsoft 365 Security Settings Small Businesses Never Turn On
• Our Only IT Person Is Out. Who Answers a 2am Security Alert?