Microsoft 365 third-party app access is the part of your tenant almost nobody reviews, and it is exactly what attackers just used. In October 2026, one stolen credential from the ConnectWise breach opened the door to Microsoft 365 tenants around the world, with no password to guess and no MFA prompt to beat.
If a backup tool, CRM plug-in or MSP platform has permission to read your mailboxes, that permission works around your users and their security settings. This guide shows you how to audit Microsoft 365 third-party app access in about 15 minutes, what to look for, and how to stop the next vendor incident from becoming yours.
Quick answer: Open Entra ID, go to Enterprise applications, search for ConnectWise and SkyKick, check sign-in logs and credentials added since 13 October, disable (don’t delete) the apps, then review every other app that holds mail, files or directory permissions.
Table of Contents
What Happened in the ConnectWise Cloud Backup Breach
The ConnectWise Cloud Backup breach hit the product formerly known as SkyKick. Managed service providers (MSPs) use it to back up client email, files and Teams data. Reports of a SkyKick breach started appearing on Friday 16 October, and the timeline moved quickly:
- 15 October: An attacker used a stolen application credential from a single IP address to request Microsoft Graph tokens across many tenants, one after another, which points to a scripted target list.
- 16 October: Huntress published its analysis and confirmed unauthorized sign-ins in at least 162 tenants.
- 17 October: ConnectWise confirmed unauthorized access to application identities and suspended Cloud Backupalong with its connected SaaS Security and Cloud Management services.
Later reporting said that almost 1,000 tenants showed sign-in activity from the attacker’s address. In Huntress-monitored environments, ConnectWise Cloud Management service principals also assigned themselves directory roles, mostly Exchange Administrator, and in at least one case Global Administrator.
ConnectWise says it has no indication that partner backup data was compromised, and it cannot see inside customer tenants. That is why you have to check.
Note: Figures are changing. Always compare what you see against the latest vendor and Huntress advisories before closing an investigation.
Abused Microsoft 365 third-party app access is the engine of this textbook supply chain attack on Microsoft 365: the victim’s own security was fine, but a trusted vendor held the keys.
Why Microsoft 365 Third-Party App Access Bypasses MFA
Here is the uncomfortable part. Microsoft 365 third-party app access is granted to an application identity (a service principal), not to a person. When an attacker holds that application’s secret, they authenticate as the app. There is no user, no phone, and no MFA challenge.
Three things make this dangerous:
- Consent is tenant-wide. An admin approves the app once, and it keeps working for months or years.
- App-only tokens skip user controls. Standard user Conditional Access policies are built around people. Protecting apps requires Conditional Access for workload identities, which many tenants never configure.
- Backup tools need broad rights. To copy mail, files and chats, a backup app needs read access to nearly everything, so a stolen secret equals near-total visibility.
This is the core lesson of cloud application security: the strongest login policy in the world doesn’t help when the back door is an OAuth app with a long-lived secret.
Is Microsoft 365 Backup Safe?
Many owners now ask, “is Microsoft 365 backup safe?” The honest answer: backup is still essential, and so is controlling Microsoft 365 third-party app access for the backup vendor, because the connection between your tenant and that vendor is part of your attack surface.
Based on current reporting, the backup data itself was not shown to be compromised. The risk was the vendor’s application identity. So keep your backups, and treat the backup app like a privileged account:
- Grant only the permissions it truly needs.
- Rotate and monitor its credentials.
- Test restores regularly.
- Keep an offline or separate-vendor copy of critical data.
Step-by-Step: How to Audit Microsoft 365 Third-Party App Access
If you want to know how to audit enterprise applications in Entra ID, follow this order. You need at least Application Administrator or Security Reader rights.
Step 1: Find the ConnectWise and SkyKick app identities in your Microsoft 365 third-party app access list
In the Entra admin center, open Enterprise applications and search for “ConnectWise” and “SkyKick”. Public reporting lists the Cloud Backup application ID as 506e08f9-6e9a-4da4-942b-a099a03644ae, and older tenants may show names such as “SkyKick Cloud Manager”. Verify IDs against the current vendor advisory.
Step 2: Check credentials added since 13 October
Open each app under Certificates & secrets. Any client secret or certificate you did not add yourself, especially one created from 13 October onward, is a red flag. Huntress also reported planted credentials with long expiry dates.
Step 3: Review sign-in logs for service principals
In Sign-in logs, switch to the Service principal sign-ins tab. Filter by the ConnectWise and SkyKick apps and look for any IP address outside the vendor’s or Microsoft’s normal ranges.
Step 4: Look for self-assigned directory roles
Go to Roles and administrators and check Exchange Administrator and Global Administrator. No backup app should hold these roles. Review the audit log for role assignments to service principals.
Step 5: Disable, don’t delete
Disable the suspicious enterprise application (set “Enabled for users to sign in” to No). Deleting it destroys evidence you need for the investigation and for any insurer or regulator.
Step 6: Run a Microsoft 365 mailbox forwarding rules check
Attackers with Exchange access often create silent forwarding. Review mailbox forwarding, inbox rules, and transport (mail flow) rules. Microsoft also documents how to control external email forwarding. A forwarding rule can outlive the original breach by years.
15-Point Microsoft 365 Third-Party App Access Checklist
Use this list as your recurring review of Microsoft 365 third-party app access. It turns a one-off emergency into a standing security risk assessment habit and supports solid cybersecurity risk management.
Inventory
- Export every enterprise application and app registration to a spreadsheet.
- Record the business owner, vendor, purpose and date approved for each app.
- Flag apps nobody can explain. Unknown means untrusted.
Permissions
- List all apps with application permissions (not just delegated) such as
Mail.Read,Files.Read.AllorDirectory.ReadWrite.All. - Remove apps with high-risk permissions that are no longer needed.
- Check for apps holding Exchange Administrator or Global Administrator roles.
Credentials
- Review every client secret and certificate, and delete unknown or long-lived ones.
- Set a maximum secret lifetime and a rotation schedule.
- Alert on any new credential added to an existing app.
Monitoring
- Review service principal sign-in logs weekly.
- Alert on sign-ins from IP addresses outside expected vendor ranges.
- Run a Microsoft 365 mailbox forwarding rules check monthly.
Governance
- Restrict user consent so only admins can approve new apps (see Microsoft’s user consent settings).
- Apply Conditional Access to workload identities where licensing allows.
- Require a security questionnaire before any vendor gets tenant access.
How to Revoke App Permissions in Microsoft 365
To revoke app permissions in Microsoft 365, open the app under Enterprise applications → Permissions, review the granted consents, and remove the ones that are not required. Microsoft’s guide to managing application permissions walks through the portal and PowerShell options.
Before you revoke, remember the order of operations:
- Contain: disable the app.
- Investigate: capture logs, credentials and role changes.
- Rotate: reset secrets for other apps the attacker may have touched.
- Revoke: remove consent once you know what depends on it.
- Re-onboard: only when the vendor confirms a clean, re-credentialed service.
Huntress reported that an attacker added credentials to other trusted apps, including security and MSP tools. So after you revoke app permissions, re-check all Microsoft 365 third-party app access and review the neighbors, not just the vendor in the headlines.
Build a Vendor Permission Policy for Your Business
Fixing this once is not enough. A one-page policy keeps Microsoft 365 third-party app access under control for good, which is the heart of SaaS security posture management and cloud security management for small teams. Include:
- Least privilege: vendors get only the permissions they need, and read-only whenever possible.
- Named owner: every app has a person accountable for it.
- Annual re-approval: unused apps lose access.
- Incident clause: the vendor must notify you within a set number of hours.
- Exit plan: know how to remove the vendor and keep operating.
If you rely on an MSP, ask what they require of their own tools. Our readers often search for MSP and MSSP requirements, and the same rules apply: documented access, MFA for humans, monitored application identities, and a written breach notification promise.
These controls also map to frameworks you may already be pursuing, such as the NIST Cybersecurity Framework and ISO 27001. Good security compliance starts with knowing which vendors touch your data, and vulnerability management under ISO 27001 expects you to track exactly that.
Why Penetration Testing Catches What Audits Miss
An audit tells you what is configured. Penetration testing tells you what an attacker can actually do with it. That difference is why penetration testing is important after any breach, especially one involving Microsoft 365 third-party app access.
A skilled ethical hacking team will test the Microsoft 365 third-party app access paths this incident exploited:
- Cloud security assessment: can an over-permissioned app read mail, files or directory data?
- External penetration testing: what can an outsider reach without any credentials at all? A scoped external penetration test maps your exposed services, and external infrastructure penetration testing checks the edge devices and VPNs your vendors connect through.
- Web application penetration testing: login flows, OAuth consent screens and APIs are common weak points. The OWASP Web Security Testing Guide is the standard reference for a penetration test of a web application.
- Infrastructure penetration testing: internal paths an attacker could use after landing in your network.
Some customers now ask for a third party penetration test before signing a contract. If your clients or insurers require independent proof, a documented VAPT report gives you it. And while automated penetration testing tools are useful for scheduled scanning, a manual test is what finds chained permission abuse like this incident.
Nexus Web Security’s VAPT service covers vulnerability assessment and penetration testing for exactly these scenarios, and works as a cybersecurity services company and cyber security consulting services partner for small teams that cannot staff a full SOC.
A quick related tip: many admins hunting for how to encrypt email in Outlook want a safer mailbox. Message encryption is worthwhile (see Microsoft’s guide to encrypting email messages), but it will not stop a tenant-level breach. When an attacker holds a trusted app token, they read mail as the app, so fix Microsoft 365 third-party app access first.
FAQ: Microsoft 365 Third-Party App Access
What is Microsoft 365 third-party app access?
Microsoft 365 third-party app access is the set of permissions you grant to outside applications (backup, CRM, security and MSP tools) so they can read or change data in your tenant. Access is approved once and often stays active until someone removes it.
Can a backup tool bypass MFA?
Yes, in effect. Apps authenticate with secrets or certificates, not user logins, so a stolen app credential does not trigger a user MFA prompt. That is why the ConnectWise Cloud Backup incident was so serious.
How do I know if my tenant was affected by the ConnectWise breach?
Check Entra for ConnectWise and SkyKick enterprise applications, review service principal sign-in logs, look for credentials added since 13 October, and look for unexpected Exchange or Global Administrator role assignments. If your Microsoft 365 third-party app access list shows anything unusual, treat it as an incident and preserve logs.
Should I delete the ConnectWise or SkyKick app?
Disable first, delete later. Deleting removes evidence. Follow your incident response process and wait for confirmation from your MSP or vendor before removing anything permanently.
How often should I audit Microsoft 365 third-party app access?
At least quarterly, plus after any vendor breach. High-risk apps (those with mail, file or directory permissions) deserve monthly monitoring of sign-ins and credentials.
Is a vulnerability scan enough to find this kind of risk?
No. Scanners find known software flaws, but they rarely catch risky OAuth permissions and trust relationships. Manual penetration testing and a cloud security assessment do a better job.
What is the difference between a vendor risk assessment and a penetration test?
A vendor risk assessment checks policies and paperwork. A penetration test actively tries to exploit your environment to prove what is possible. Mature teams do both.
Next Steps: Get Your Microsoft 365 Access Tested
Reading a checklist on Microsoft 365 third-party app access is a start. Proving your tenant is safe is better. If you want an expert to review your Microsoft 365 third-party app access, map your vendor exposure and test whether an attacker could reach your data, our team can help.
