Security teams should include unmanaged SaaS applications in the same identity review process as approved applications. If an app is visible in use but absent from governance records, it should be treated as a control gap, not as a low-priority exception. The right response is to reconcile app ownership, user access, and risk classification before the next review cycle.
Why This Matters for Security Teams
Unmanaged SaaS applications are not just procurement noise. They are identity-relevant systems that often hold OAuth grants, delegated admin access, shared accounts, and hidden data flows outside the approved stack. In identity reviews, that means an app can look “low risk” simply because it was never classified, not because it is actually benign. Current guidance from the NIST Cybersecurity Framework 2.0 still points teams toward governance, access visibility, and continuous assessment, which applies just as much to shadow SaaS as to sanctioned platforms.
NHI Management Group research shows how often visibility breaks down in practice: only 5.7% of organisations report full visibility into service accounts, and 85% lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security. That pattern matters because unmanaged SaaS often becomes the place where identity sprawl turns into credential sprawl. The failure is usually discovered during an incident or audit, not during routine review. In practice, many security teams encounter the unmanaged app only after a user has already connected it to production data and the risk has already expanded.
How It Works in Practice
Handle unmanaged SaaS as part of the identity review workflow, not as a separate app-discovery exercise. The review should ask three questions for every visible application: who owns it, which identities can authenticate to it, and what data or admin scopes it has been granted. If the answers are unclear, the application should remain in a pending-risk state until it is reconciled.
A practical process usually includes:
- Discover the app from SSO logs, browser telemetry, CASB findings, OAuth consent records, or endpoint inventory.
- Map the app to a business owner and a technical owner before the review is closed.
- Classify access by identity type, including users, service accounts, API keys, and delegated OAuth tokens.
- Check whether the app has excessive scopes, shared admin credentials, or stale tokens.
- Decide whether the app should be approved, restricted, monitored, or removed.
This is also where Ultimate Guide to NHIs is useful: unmanaged SaaS often hides non-human identities that persist long after the original business need ends. If the app uses API keys, background syncs, or automation hooks, those credentials must be reviewed with the same discipline as any other NHI. For access governance, the review logic should align with least privilege and continuous validation principles described in NIST CSF 2.0 and NHI lifecycle guidance, not with one-time approval records. Many organisations also use Top 10 NHI Issues to triage whether the app represents an exposure path, a secrets issue, or an offboarding gap.
These controls tend to break down in decentralised environments where employees can authorise SaaS tools directly with OAuth and no central app register exists.
Common Variations and Edge Cases
Tighter SaaS governance often increases review overhead, so teams have to balance completeness against the operational cost of investigating every unknown application. That tradeoff is real, especially in fast-moving business units, but unknown should never mean exempt.
One common edge case is “benign” productivity software that still receives calendar, mailbox, or file permissions. Best practice is evolving here: there is no universal standard for exactly which consent scopes should trigger automatic escalation, but current guidance suggests treating any app with broad read/write access as material in an identity review. Another edge case is vendor-managed SaaS embedded inside a larger contract. Even when procurement owns the contract, security still needs visibility into the identities, tokens, and admin roles that the app uses.
A second variation is when the app is already active but cannot be fully inventoried. In that case, do not downgrade the finding to informational. Keep it open until ownership, access scope, and offboarding path are documented. The same applies to abandoned apps that still retain delegated tokens. If the organisation cannot show who can revoke access, the review is incomplete. For teams looking to harden the process further, the lifecycle and audit perspectives in Ultimate Guide to NHIs — Regulatory and Audit Perspectives help translate that gap into evidence for governance committees.
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-05 | Unmanaged SaaS often hides orphaned secrets and tokens that need review. |
| NIST CSF 2.0 | GV.OV-01 | Identity reviews should govern unknown SaaS as a tracked risk, not an exception. |
| NIST AI RMF | Identity review of SaaS should support ongoing risk monitoring and accountability. |
Use AI RMF governance practices to maintain ownership, traceability, and continuous review of app access.
Related resources from NHI Mgmt Group
- How should security teams run access reviews for non-human identities?
- How should security teams handle risks from AI browser extensions?
- How should security teams handle AI agents that need to log into SaaS applications?
- How should security teams handle identity-led attacks across cloud, SaaS, and browsers?
