What breaks when organisations assume OAuth 2.0 scopes fully describe what a Microsoft application can do?

Why This Matters for Security Teams

OAuth 2.0 scopes are often treated as the full story of what a Microsoft application can do, but that assumption breaks as soon as the app can act through other authorization paths, delegated trust, or downstream API permissions. The danger is not just incomplete inventory. It is a false sense of containment that hides effective privilege, especially in environments where app registrations, consent grants, and service principals are managed by different teams.

This matters because Microsoft app access is not always expressed as a neat scope list. An application may have no obvious high-risk scope yet still reach mailboxes, files, or directory objects through consented app permissions, admin grants, or adjacent identity relationships. NHI Mgmt Group’s research on Ultimate Guide to NHIs — Key Challenges and Risks shows why visibility gaps remain common, and the pattern is reinforced by real-world OAuth abuse seen in Microsoft OAuth Breach cases. The control problem is not hypothetical; it is an identity governance failure disguised as an authorization detail.

In practice, many security teams encounter this only after a benign-looking application has already been used to reach data or pivot into broader administrative activity.

How It Works in Practice

For Microsoft applications, the published OAuth scope list is only one input into effective privilege. Security teams need to distinguish between delegated permissions, application permissions, tenant-wide admin consent, and the actual actions the app can perform once tokens are issued. A scope can look narrow while the app still has broad reach because the relevant authority is expressed elsewhere, such as Graph permissions, service principal role assignments, or an exposed secret that lets an attacker reuse the app identity.

A practical review should trace the app from registration to runtime use:

• Inventory the app registration, service principal, and consent grants together, not separately.
• Compare the scope list to effective API calls in logs and audit trails.
• Review directory roles, app roles, and tenant-wide admin consent for hidden privilege.
• Validate whether the app can read, write, or impersonate beyond its declared scopes.
• Check whether tokens, refresh paths, or secrets allow broader access than the UI suggests.

That approach aligns with broader NHI guidance in the Ultimate Guide to Non-Human Identities, where visibility, rotation, and lifecycle control are treated as core security functions rather than after-the-fact checks. It also matches the OWASP position that non-human identities should be governed by effective privilege, not just declared configuration, as described in the OWASP Non-Human Identity Top 10. The practical test is simple: can the app do more than its scope list implies, and can that be proven from logs and permissions data?

These controls tend to break down in large Microsoft tenants with delegated administration, legacy consent grants, and multiple cloud apps sharing the same service principals because effective access becomes distributed across identities and policies.

Common Variations and Edge Cases

Tighter permission review often increases operational overhead, requiring organisations to balance faster app delivery against the cost of validating real access paths. That tradeoff is especially visible in Microsoft ecosystems where internal line-of-business apps, partner integrations, and automation tools all rely on different consent models.

There is no universal standard for this yet, but current guidance suggests treating scope review as a starting point rather than a control verdict. Some apps expose minimal scopes intentionally while gaining powerful behavior through Microsoft Graph application permissions, Exchange or SharePoint access, or privileged directory roles assigned outside the app registration. In those cases, the scope list is technically accurate and operationally misleading.

Edge cases also appear when vendors use shared multi-tenant apps, when an integration is approved by one administrator but operated by another, or when the app’s real risk sits in refresh token persistence rather than initial consent. NHI Mgmt Group research on The State of Non-Human Identity Security highlights how often organisations lack full visibility into third-party oauth application, which makes this class of risk easy to miss. For baseline control expectations, pair that with NIST SP 800-53 Rev. 5 Security and Privacy Controls to anchor access review, audit logging, and least-privilege enforcement.

In environments with heavy automation or rapid SaaS onboarding, the gap widens because permissions change faster than review cycles can keep up.

Related resources from NHI Mgmt Group

• What breaks when organisations rely on visibility alone for Microsoft 365 sharing risk?
• What breaks when organisations assume every Microsoft Copilot surface inherits the same HIPAA coverage?
• What breaks when organisations cannot inventory cryptographic libraries and algorithms in their products?
• What breaks when organisations rely only on segregation of duties checks in ERP cloud security?