IAM teams should judge unsanctioned SaaS by ownership, data sensitivity, and integration risk, not by whether employees find it useful. If an app lacks an accountable owner, handles regulated data, or connects to core identity systems without review, it needs a decision workflow for sanction, restriction, or removal.
Why This Matters for Security Teams
Sanctioned versus shadow IT is rarely a simple procurement question. For IAM teams, the real issue is whether a SaaS app creates unmanaged identity, data, or integration risk that can outlive the business need that introduced it. A tool can be popular with staff and still be unacceptable if it exposes regulated data, bypasses review, or connects to identity systems in ways that weaken control. NIST’s Cybersecurity Framework 2.0 is useful here because it frames governance as a risk decision, not a popularity contest.
This distinction matters because SaaS adoption often happens faster than security review. Once employees connect a new app to SSO, email, or file storage, the app can inherit trust before anyone has assessed its owner, purpose, or data handling. The pattern is visible in incidents like the Snowflake breach and the Salesloft OAuth token breach, where connected services and tokens became the real exposure path. In practice, many security teams discover shadow IT only after a SaaS integration has already touched identity, data, or production workflows.
How It Works in Practice
IAM teams usually need a repeatable intake workflow, not an ad hoc approval. The decision starts with three questions: who owns the app, what data it can see, and what systems it can integrate with. If the app has a named business owner and a technical owner, the next step is to classify the data it stores or processes. Current guidance suggests that regulated, confidential, or identity-related data should raise the approval threshold immediately.
Integration risk is often the deciding factor. A low-risk collaboration app may be acceptable with limited scopes, but an app that requests directory sync, mailbox access, OAuth consent, or admin-level APIs needs deeper review. This is where teams should compare requested permissions against actual business need and reject blanket access by default. For operational clarity, many teams also route apps into one of three outcomes: sanctioned with controls, sanctioned with restrictions, or unsanctioned pending removal.
- Sanctioned means the app has an owner, documented purpose, and approved controls.
- Restricted means the app can stay, but only with limited scopes, monitored integrations, or segmented data.
- Unsanctioned means there is no acceptable risk case, no accountable owner, or no safe way to integrate it.
Visibility matters as much as policy. NHI Management Group notes that only 5.7% of organisations have full visibility into their service accounts in its Ultimate Guide to NHIs, which is a strong reminder that app sprawl quickly becomes identity sprawl. When IAM teams lack inventory and consent oversight, the app decision becomes difficult to enforce, especially when secrets or tokens are embedded in workflows the security team cannot see.
These controls tend to break down in environments where employees can self-authorise third-party apps through SaaS marketplaces or where integrations are created directly by power users without central review.
Common Variations and Edge Cases
Tighter app governance often increases friction for business teams, so organisations have to balance speed against control. That tradeoff becomes sharper when a SaaS app is useful but not clearly mission-critical, because the cost of approval can feel higher than the perceived risk. Best practice is evolving, but there is no universal standard for every SaaS category yet.
One edge case is a tool that starts as shadow IT and later becomes operationally important. In that situation, the right answer is usually not instant removal. IAM teams may need a transition plan: document ownership, reduce scopes, move to centrally managed SSO, and require a formal review before any privileged integration remains active. Another edge case is a low-risk app that still touches identity data indirectly through webhooks, exports, or automation bots. That app may look harmless until it becomes a bridge into core systems.
Use The 2024 Non-Human Identity Security Report when the concern is whether the app introduces unmanaged machine-to-machine access, because insecure SaaS often brings secrets, tokens, and service accounts along with it. That same pattern shows up in incidents like the BeyondTrust API key breach, where an exposed integration credential became the real problem. The practical rule is simple: if the app cannot be owned, scoped, and monitored, it should not be treated as sanctioned.
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 |
|---|---|---|
| NIST CSF 2.0 | GV.OV-01 | Sanctioning apps is a governance and oversight decision tied to risk acceptance. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Unsanctioned SaaS often introduces unmanaged machine identities and credentials. |
| NIST AI RMF | App approval should reflect context, accountability, and ongoing risk management. |
Apply AI RMF-style governance to continuously assess app purpose, owners, and downstream risk.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
