Start with discovery, then apply lifecycle control. Security teams need to identify the app, the identity used to create it, the data it touches, and the exit path for offboarding or revocation. If the organisation cannot answer those four questions, the app is not governed, even if it is convenient or widely used.
Why This Matters for Security Teams
Shadow IT is no longer just an application sprawl problem. When employees adopt tools outside central IAM, they also create unmanaged identities, hidden data paths, and offboarding gaps that can outlive the original business need. That is especially dangerous when the tool stores secrets, syncs customer data, or connects to SaaS APIs through delegated access.
Security teams should treat these cases as an identity governance issue, not a procurement annoyance. The right question is not whether the app is popular, but whether the organisation can see who created it, what it can reach, and how access is revoked. NIST’s NIST Cybersecurity Framework 2.0 is useful here because it anchors discovery, access control, and monitoring as continuous functions rather than one-time approvals.
NHIMG research shows the scale of the problem: in The State of Non-Human Identity Security, only 1.5 out of 10 organisations said they were highly confident in securing NHIs, and 85% lacked full visibility into third-party vendors connected via OAuth apps. In practice, many security teams discover shadow IT only after data sharing, token sprawl, or an offboarding failure has already created exposure.
How It Works in Practice
Governing shadow IT starts with discovery, but discovery has to include identity context. Security teams should identify the app, the human identity that approved or created it, the non-human identities it introduced, the permissions it requested, the data domains it touches, and the revocation path if the app must be removed. That maps closely to the lifecycle thinking in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs.
Operationally, the most effective approach is to classify shadow apps by risk and then apply controls in layers:
- Inventory the app through SaaS discovery, OAuth consent logs, browser extensions, endpoint telemetry, and finance records.
- Determine whether the app uses delegated access, service accounts, API tokens, or embedded secrets.
- Require an owner who can approve, review, or remove access on a defined cadence.
- Apply least privilege, short-lived access where possible, and immediate revocation when the app is retired or unsupported.
- Monitor for unusual token use, external data transfer, and privilege escalation paths.
This is where Top 10 NHI Issues becomes relevant, because shadow IT often turns into an NHI problem once users begin storing credentials, creating machine-to-machine access, or bypassing central controls. Current guidance suggests that organisations should not try to eliminate every unsanctioned tool immediately; instead, they should bring the highest-risk apps under governance first and remove the ones that cannot meet minimum controls. The control objective is visibility plus revocation, not blanket approval. These controls tend to break down when employees embed the app in core workflows, because removal then requires business process redesign rather than simple access cleanup.
Common Variations and Edge Cases
Tighter control over shadow IT often increases friction for employees, requiring organisations to balance agility against the need for visibility and revocation. That tradeoff is real: not every unsanctioned tool can be centrally managed on day one, and some low-risk productivity apps may be acceptable with compensating controls.
Where the answer changes is in environments that rely heavily on OAuth consent, browser-based extensions, or small-team SaaS buying. Best practice is evolving, but the current direction is clear: security teams should create a fast intake path for new tools, a minimal-risk approval path for low-impact use, and a mandatory review path for anything that touches regulated data, production systems, or privileged tokens. In parallel, logging should capture who granted access, what scopes were approved, and whether access was later revoked.
For organisations still maturing their governance model, the strongest leverage point is the exit path. If an app can be discovered but not shut down safely, it remains shadow IT in operational terms even if it is formally documented. That is why auditability matters as much as approval. For broader governance framing, Ultimate Guide to NHIs — Regulatory and Audit Perspectives helps connect app visibility to evidence, review, and accountability.
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 CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Shadow IT often creates unmanaged non-human identities and exposed secrets. |
| NIST CSF 2.0 | ID.AM-1 | Asset and software discovery are the first step in governing unsanctioned apps. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access review is central when apps bypass central IAM. |
Tie every shadow app to an owner and enforce revocation when access is no longer justified.
