Who Has Keys to Your Microsoft 365? A Third-Party Access Audit

Your Microsoft 365 tenant is your business operating system. Email, files, calendars, Teams, SharePoint, and increasingly your AI tools all run through it. Every vendor, contractor, and third-party app that connects to your tenant has some level of access to that data. The problem is that most SMBs cannot produce a complete list of who and what has access, much less explain what level of access each one has or whether it’s still needed.

The 2026 Verizon DBIR reports that third-party involvement in security incidents hit 48% this year, up from 30% in 2025. The Black Kite Third-Party Breach Report found that each vendor breach now affects an average of 5.28 downstream companies. These aren’t abstract statistics. They describe a specific mechanism: an outside party with legitimate access to your environment gets compromised, and that access becomes the attacker’s entry point.

This post walks through a practical audit of the three places where third-party access accumulates in Microsoft 365: OAuth app registrations, external user accounts, and MSP administrative access. If you’ve never done this audit, expect to find things that surprise you.

OAuth Apps: The Permissions You Granted and Forgot About

Every time someone on your team clicks “Allow” on a prompt that says “AppName wants to access your organization’s data,” they’re granting an OAuth consent that persists until someone explicitly revokes it. These consents don’t expire on their own. The app gets a token that lets it access your tenant’s data continuously, even when the employee who granted it leaves the company.

Common examples include calendar scheduling tools (Calendly, Reclaim), project management platforms (Monday.com, Asana), email signature tools, CRM integrations that sync with Outlook, and AI-powered productivity apps that read email and files to generate summaries. Each one of these has a defined set of permissions, ranging from “read your profile” to “read and write all files in SharePoint” or “send email on behalf of any user.”

How to audit OAuth apps in Entra ID:

1. Sign in to the Microsoft Entra admin center with a Global Administrator or Application Administrator account.
2. Navigate to Identity > Applications > Enterprise applications.
3. Set the Application type filter to “All applications” and sort by the “Created” column to see the oldest registrations first.
4. For each application, click into it and select Permissions in the left panel.
5. Review the list of granted permissions. Pay attention to anything with “Application” permission type (as opposed to “Delegated”), because Application permissions operate without a user context and are often more powerful.
6. Check the Properties page for sign-in activity. If the app hasn’t been used in 90+ days, it’s a candidate for removal.

What to look for:

• Apps with Mail.ReadWrite, Files.ReadWrite.All, or Sites.ReadWrite.All permissions. These can read and modify email and files across your entire organization. Verify that the app’s function justifies that level of access.
• Apps that were consented to by a single user who no longer works at the company. The consent persists even after the user account is disabled.
• Apps you don’t recognize. If nobody on your team can explain what an application does or why it’s connected, revoke consent and see if anyone notices. Legitimate apps will prompt for re-consent when someone actually needs them.
• Admin-consented applications. When an admin grants consent “on behalf of the organization,” every user in the tenant is covered. Review these with particular care because they affect your entire company.

Microsoft’s documentation on reviewing permissions granted to applications provides additional detail on interpreting the permission list. If you’re running Microsoft 365 E3 or E5, the app governance add-on in Microsoft Defender for Cloud Apps can flag overprivileged and inactive apps automatically.

External Users and Contractor Accounts

Guest accounts in Entra ID let external users access specific Teams channels, SharePoint sites, and shared mailboxes. They’re the standard way to collaborate with vendors, consultants, and contractors. The problem is that guest accounts tend to accumulate without a cleanup process.

A typical 100-person company that’s been on M365 for three or more years will have dozens of guest accounts. Some belong to current vendors with active projects. Others belong to consultants who finished their engagement two years ago. A few belong to individuals at companies you no longer do business with. All of them still have the access they were originally granted unless someone has gone in and removed them.

How to audit external accounts:

1. In the Entra admin center, go to Identity > Users > All users.
2. Add a filter for User type = Guest.
3. Review each guest account. Note the Creation date and Last sign-in columns.
4. For accounts that haven’t signed in within 90 days, check with the internal team member who invited them. If the project is over or the vendor relationship has ended, remove the account.
5. For active accounts, verify that the Teams, SharePoint, and mailbox access is still appropriate. Guest accounts often retain access to channels and sites from past projects that are no longer relevant.

Microsoft supports access reviews in Entra ID Governance, which automate periodic reviews of guest accounts by requiring the person who invited them to confirm continued need. If you have Entra ID P2 licensing, setting up quarterly access reviews for guest users is one of the highest-value governance controls you can deploy.

If you’ve already done a broader admin access audit, extending it to cover guest accounts is a natural next step. The same principle applies: access should be granted for a specific purpose with a defined expiration, not left open indefinitely.

MSP and IT Provider Admin Access

If you work with a managed service provider or IT consultant, they almost certainly hold administrative credentials in your Microsoft 365 tenant. The question is what kind of access, how broad it is, and whether it follows Microsoft’s current security standards.

Before October 2023, many MSPs connected to client tenants through Delegated Admin Privileges (DAP), which granted Global Administrator access to every client tenant through a single relationship link. If the MSP’s own environment was compromised, every client tenant was exposed. Microsoft deprecated DAP in favor of Granular Delegated Admin Privileges (GDAP), which allows specific admin roles to be assigned with mandatory expiration dates.

What to check:

1. In the Entra admin center, go to Identity > External identities > Cross-tenant access settings.
2. Check the Partner relationships tab to see which external organizations have administrative access to your tenant.
3. For each partner, verify they’re using GDAP (you’ll see specific roles listed) rather than DAP (which shows as “Global Administrator” with no role restrictions).
4. Confirm that GDAP assignments have reasonable expiration dates. Microsoft allows up to two years, but shorter periods with renewal are more appropriate for most engagements.

Additional MSP access points to audit:

• Break-glass accounts. Some providers create a separate admin account in your tenant as a backup. Verify these exist, that they use strong MFA, and that sign-in activity is monitored. If the provider has GDAP access, a break-glass account in your tenant may be redundant.
• Service accounts for automation. Providers often create accounts for backup tools, monitoring agents, or automation scripts. These accounts should use certificates or managed identities rather than passwords, and their permissions should be scoped to only what the automation requires.
• Former provider access. If you’ve switched IT providers, verify that the old provider’s administrative relationship has been fully removed. We’ve seen cases where a former MSP’s GDAP relationship or standalone admin account persisted for months after the transition because nobody explicitly revoked it.

Your MSP’s access to your tenant carries the same risk profile as any other third-party vendor with privileged access. The RMM and remote access tool compromises of the last several years have demonstrated what happens when an IT provider’s infrastructure becomes the attack vector. Understanding exactly what your provider can do in your tenant, and limiting it to what they actually need, is a straightforward risk reduction.

Building a Recurring Audit Process

A one-time cleanup is valuable but insufficient. Third-party access accumulates continuously, and the only way to keep it under control is to review it on a regular schedule. For most SMBs, quarterly reviews strike the right balance between diligence and practicality.

Quarterly audit checklist:

• Review all OAuth app registrations in Entra ID. Remove apps that are unused, unrecognized, or overprivileged.
• Review all guest user accounts. Disable accounts for completed vendor engagements.
• Confirm MSP administrative access uses GDAP with appropriate role scoping and expiration dates.
• Verify that Conditional Access policies apply to external users and service principals, not just internal accounts. Microsoft’s identity-first security controls should cover every account type in your tenant.
• Check the Entra ID sign-in logs for external account activity that doesn’t match expected patterns.

If you have Entra ID P2 licensing, configure automated access reviews for guest users and set up alerts for new OAuth consents through Microsoft Defender for Cloud Apps. If you’re on Business Premium or E3, the manual audit above is your primary tool, and it works if you actually do it on schedule.

The M365 security settings that SMBs most commonly get wrong include leaving user consent for OAuth apps unrestricted. Consider requiring admin approval for new app consents, which forces every new third-party connection through a review process rather than letting individual employees grant access on their own. This single setting change, found under Identity > Applications > Consent and permissions in Entra, prevents the sprawl problem from recurring after your initial cleanup.

Every connected app, every guest account, and every administrative relationship is a potential entry point into your M365 environment. The organizations that get breached through third-party access aren’t the ones with too many connections. They’re the ones that don’t know what connections exist. Running this audit gives you an answer to the question “who has keys to your Microsoft 365?” and puts you in a position to decide whether each one should keep them.