Because valid authentication does not equal valid governance. A user can approve a third-party app once, then forget it while the grant remains active and continues to operate inside approved scopes. That turns convenience into standing privilege, which is hard for conventional monitoring to detect.
Why This Matters for Security Teams
Unmanaged SaaS apps create identity risk because a legitimate sign-in can still leave behind a durable third-party grant, refresh token, or OAuth consent that persists long after the user stops actively using the app. That turns a normal productivity choice into standing access outside the visibility of most access reviews. Current guidance from the NIST Cybersecurity Framework 2.0 emphasizes governance and continuous risk management, which is exactly what shadow SaaS bypasses.
This is not a theoretical edge case. NHI Management Group research shows that only 5.7% of organisations have full visibility into their service accounts, and 97% of NHIs carry excessive privileges, which is a strong signal that identity sprawl is already outpacing oversight. The same pattern shows up in SaaS, where the user signs in legitimately but the app retains approved scope until someone finds and removes it. The operational issue is not authentication, it is forgotten authorisation.
In practice, many security teams encounter the risk only after an audit, a breach review, or a data loss event has already exposed how many dormant app grants were still active.
How It Works in Practice
Unmanaged SaaS risk usually starts with a user authorising a third-party application through SSO, OAuth, or an admin-approved marketplace integration. The sign-in itself is valid, but the app often receives permissions that outlive the original business need. Those permissions may include mailbox access, file read/write, directory data, or API scopes that continue until revoked. The control problem is lifecycle management: who approved the app, what scopes it received, where it is used, and whether the access is still justified.
This is why the best practice is moving toward continuous discovery and review rather than one-time approval. The Ultimate Guide to NHIs highlights how NHI governance breaks down when visibility and offboarding are weak, and the same discipline applies to SaaS grants. Security teams should inventory connected apps, classify them by data sensitivity, enforce app approval workflows, and remove stale consents automatically where possible. That includes watching for:
- OAuth grants that persist after role changes or employment changes
- Apps with broader scopes than the business case requires
- Consent given by a single user for organisation-wide data access
- Long-lived refresh tokens that remain usable after the initial session ends
- Apps that are legitimate individually but risky in aggregate because they expand the attack path
Practical control also depends on telemetry. Teams need visibility into which apps are connected, which identities approved them, and which data paths they can reach. NHI Management Group’s Top 10 NHI Issues and the Regulatory and Audit Perspectives sections both reinforce the same point: governance must cover entitlements, not just logins. These controls tend to break down when consent is user-driven across many SaaS tenants because access sprawl becomes distributed, inconsistent, and difficult to reconcile centrally.
Common Variations and Edge Cases
Tighter SaaS approval controls often increase user friction and admin overhead, so organisations have to balance fast adoption against the risk of hidden standing access. There is no universal standard for this yet, but current guidance suggests tiering controls by data sensitivity rather than treating every app the same. A low-risk collaboration app does not deserve the same review depth as a tool that can read mail, modify files, or call downstream APIs.
One important edge case is admin-consented applications. These may look safer because IT approved them once, but that can also create broad tenant-wide exposure if scopes are not narrowly constrained. Another is bring-your-own-app behaviour, where employees connect personal productivity tools to work accounts. The account is legitimate, but the app may not be lifecycle-managed by security, which makes offboarding incomplete. In environments with heavy third-party integrations, the risk also overlaps with NHIs because apps often act through service principals, API tokens, or automation accounts rather than just human sessions.
For deeper context on lifecycle control and residual access, NHI Management Group’s NHI Lifecycle Management Guide and the Lifecycle Processes for Managing NHIs section are useful references. The main limitation is that app inventories age quickly in fast-moving SaaS environments, so controls often fail when discovery is not continuous and revocation is not tied to real-time business events.
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-01 | Unmanaged SaaS grants behave like over-privileged NHI access. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege and access review apply to SaaS app consent risk. |
| NIST AI RMF | Governance and accountability help manage autonomous, app-like access paths. |
Establish ownership, monitoring, and review for every third-party app that can access enterprise data.
