Because the attacker may not need the password at all. If the app already holds the right tokens and permissions, abuse can happen through the SaaS workflow itself. That makes consent scope, token reuse, and application claims validation the real control points for tenant protection.
How delegated SaaS permissions create tenant risk
delegated permissions shift the security question from password theft to trust in the app’s authority. If a SaaS app is already consented, its tokens can act inside Microsoft 365 within the granted scope, so compromise often shows up as valid use of approved access rather than a noisy login event. The control problem becomes scope design, consent governance, and token handling.
That is why delegated access can still produce mailbox, file, calendar, or directory exposure even when no human password is captured. The attacker is using the application’s existing relationship to the tenant, which means defenders have to judge whether the app should have that reach at all, not only whether an account was compromised.
Where the abuse path actually sits
Delegated SaaS permissions are dangerous when the app can call Microsoft 365 APIs with enough privilege to read, modify, or forward data. The risk increases when consent is broad, the app reuses long-lived tokens, or claims validation is weak and the tenant treats the app as trustworthy by default. In practice, the threat is privilege abuse through a legitimate channel, not password reuse.
Microsoft 365 risk becomes more serious when the app is integrated deeply enough that its actions blend into normal business workflow. That makes detection harder because audit logs may show an approved application rather than an obviously malicious identity, and response often has to start by tracing consent grants, token issuance, and application permissions back to their source.
For a concrete Microsoft 365 example, the same class of issue is visible in Mimecast certificate compromise 2021, where a stolen trust artifact enabled access to Microsoft 365 Exchange without needing user passwords.
What to control before the app becomes the attacker
Consent scope should be treated as a production security decision, not a setup convenience. If an app only needs a narrow dataset or a single workflow, the right response is to grant the minimum delegated scope, verify the issuer and app claims, and reject reusable privilege that is not required for the business function.
Tenant protection also depends on reviewing who can approve apps, how often those grants are recertified, and whether the tenant has a process to revoke stale or overbroad tokens quickly. A permissioned app can become a durable foothold if no one revisits why the access existed in the first place.
For permission design and review, Enterprise AI Copilot Security Guide and Authorisation Models Guide both support the same underlying lesson: the safer model is to align access with the exact action and context the app needs, then deny everything else by default.
Risk and Threat Considerations
Delegated permissions create a trust-abuse path because the attacker can operate inside an approved application relationship. That means compromise may persist even when user passwords are strong, and it can spread if the app has access to sensitive mail, files, or directory data across a tenant.
Failure mechanism: A malicious or compromised SaaS app uses existing OAuth consent, cached tokens, or excessive delegated scope to call Microsoft 365 resources as an authorized application.
Impact: The attacker can exfiltrate data, alter workflows, forward messages, or stage further abuse while appearing to use legitimate tenant-approved access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API2 — Broken Authentication | Delegated app tokens can be abused without user passwords. |
| API5 — Broken Function Level Authorization | Overbroad delegated scopes let apps perform actions beyond intended business limits. | |
| Recommendation — Validate token handling and reject weak app authentication flows. Restrict app functions to the minimum required privileges. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Token reuse and lifecycle control are central to delegated access risk. |
| AC-6 — Least Privilege | Tenant exposure depends on whether app permissions are narrowly scoped. | |
| AC-2 — Account Management | Consent grants and app access require ongoing governance and removal. | |
| Recommendation — Rotate, revoke, and bound application authenticators and tokens. Assign only the minimum permissions required for each SaaS app. Review, recertify, and remove stale application access promptly. | ||
Practitioner Guidance
What to verify: Confirm the exact scopes, token lifetime, and tenant approval path for every app with Microsoft 365 access. If you cannot explain why the app needs a scope, treat that scope as excess until the business owner justifies it.
What to prioritise: Review high-impact apps first, especially those with mailbox, file, directory, or consent-granting privileges. Those are the permissions that turn an app compromise into tenant-wide exposure fastest.
Practitioner takeaway: The key question is not whether credentials were stolen, but whether an app was allowed to do damage on the tenant’s behalf.