Treat each SaaS integration as delegated identity, not just an application. Security teams should inventory Graph permissions, minimise consent scopes, verify token handling, and review whether the app can continue acting through refresh tokens after the user is no longer actively present. The governance control is the delegated path, not only the login event.
Why This Matters for Security Teams
SaaS applications that access Microsoft 365 on behalf of users are not just integrations, they are delegated identities with standing reach into mail, files, calendars, and collaboration data. That makes consent review, token lifetime, and Graph permission scope a governance issue, not a one-time onboarding step. The risk is amplified because the app can continue acting after the user is gone if refresh tokens remain valid. This is exactly the kind of delegated-path exposure captured in the State of Non-Human Identity Security, where 85% of organisations reported incomplete visibility into third-party vendors connected via OAuth apps.
Teams often over-focus on the initial login or admin consent event and under-monitor what the app can do afterwards. Current guidance suggests treating each SaaS integration as a separate NHI lifecycle: approve, scope, monitor, rotate, and offboard. That means mapping the integration to the exact Microsoft 365 resources it can touch, checking whether consent is broader than the business need, and determining whether delegated access persists through long-lived tokens. The OWASP Non-Human Identity Top 10 frames this as an identity and lifecycle problem, not only an application security problem. In practice, many security teams discover the issue only after a vendor escalation or data exposure, rather than through intentional access governance.
How It Works in Practice
Governance should start with inventory: which SaaS apps have access to Microsoft 365, what permissions they hold, who approved them, and whether the consent is user-delegated or admin-granted. For Microsoft Graph, the practical question is not simply “is the app trusted?” but “what can this app do, for how long, and under whose authority?” That distinction matters because delegated access can survive user interaction through refresh tokens, while the original human user may no longer be aware the app is still active.
Security teams should align controls to the delegated path:
- Minimise scopes and remove broad permissions that are not essential to the business use case.
- Review token handling, including storage location, refresh behavior, and revocation triggers.
- Separate user consent from operational approval so shadow integrations do not bypass review.
- Continuously log Graph activity and alert on unusual access patterns, such as bulk reads or mailbox searches.
- Set offboarding rules for the app itself, not only the user account that first authorised it.
This is consistent with the Ultimate Guide to NHIs, which treats secrets, tokens, and service access as lifecycle-managed identities. It also aligns with the NIST Cybersecurity Framework 2.0, especially asset inventory, access control, and continuous monitoring expectations. Practically, the strongest control is to tie every SaaS integration to an owner, a documented business purpose, a minimum scope, and a scheduled revalidation cycle. These controls tend to break down when Microsoft 365 permissions are granted through scattered user consents and no central team owns the delegated relationship.
Common Variations and Edge Cases
Tighter consent governance often increases operational friction, so organisations have to balance user productivity against delegated access risk. That tradeoff becomes especially visible when business units depend on fast-moving SaaS tools and expect immediate Microsoft 365 access without formal review.
There is no universal standard for this yet, but current guidance suggests treating certain cases more strictly than others. For example, admin-consented apps with tenant-wide scopes deserve stronger review than narrow, single-user integrations. Apps that can read mail, access shared files, or create content on behalf of users should be treated as higher impact than reporting-only tools. The same is true for integrations that use long-lived refresh tokens, because token persistence can outlast the user relationship and complicate revocation.
Edge cases also matter. Some vendors route all access through a shared service principal, which can hide per-user accountability. Others mix delegated and application permissions, making the effective blast radius larger than the front-end product description suggests. For those scenarios, the safe approach is to pair permission review with periodic vendor reassessment, because the delegated identity may be embedded deep in the SaaS operating model. In practice, teams often inherit these integrations after a procurement decision and only later discover that the Microsoft 365 connection is the real control point.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Delegated SaaS access depends on token and credential lifecycle control. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access applies to Microsoft 365 delegated permissions. |
| NIST AI RMF | AI RMF supports governance of autonomous delegated decision paths. |
Inventory delegated apps, minimise scopes, and revoke stale Microsoft 365 tokens on a fixed schedule.
Related resources from NHI Mgmt Group
- How should security teams govern non-human identities that have persistent access?
- How should security teams govern API keys used for generative AI access?
- How should security teams govern consented Microsoft 365 applications?
- How should teams govern Microsoft 365 access across users and service identities?
