Teams often treat shadow IT as a discovery problem alone, but the real issue is governance. If employees can build and connect apps outside sanctioned identity and access processes, security loses visibility into permissions, federation, and offboarding. The common mistake is waiting until the environment is already fragmented instead of setting policy, education, and control boundaries early.
Where teams misread the problem
Shadow IT and citizen-developed SaaS and PaaS applications are often treated like a discovery backlog, but that misses the operational reality. The issue is not only that an app exists outside the approved stack, it is that it may create its own trust relationships, data paths, and permission grants without the same review, ownership, or retirement discipline that centrally managed systems receive.
That is why the hard part is usually not finding the app once, but understanding what it can reach, who can change it, and how it will be decommissioned when the original builder leaves or the business process changes. When organisations ignore that lifecycle, they end up with unmanaged integrations that still function long after the human context around them has disappeared.
- Shadow IT becomes a governance issue when the app can connect to sanctioned systems, not just when it is undocumented.
- Citizen development creates risk when permissions, federation, and offboarding are handled ad hoc instead of by policy.
- The control gap is usually lifecycle drift, not a single bad app.
Why SaaS and PaaS change the security model
SaaS and PaaS make these problems sharper because they lower the barrier to publishing something useful, then quietly increase the number of identities, tokens, connectors, and delegated permissions in the environment. A low-code workflow or internal app may look harmless, but once it is linked to mail, storage, CRM, or cloud services, it becomes part of the organisation’s access fabric.
That means teams need to think in terms of access boundaries, not just application inventory. If a citizen-built app can obtain broad API scopes, reuse shared credentials, or inherit access through a federated connection, the blast radius can be much larger than the business owner expects. NHIMG’s Ultimate Guide to Non-Human Identities is useful here because it frames visibility, offboarding, rotation, and overprivilege as ongoing governance problems, not one-time setup tasks.
One practical sign of this pattern is that the app works only because someone has granted it durable access that no one has reviewed since launch. In that state, the question is no longer “is it approved?” but “what would fail if we had to revoke it tomorrow?”
What good control boundaries look like
The right response is to set lightweight guardrails before the environment fragments. Teams should define which use cases are allowed to be built by business users, which integrations require security or platform review, which data classes are prohibited, and what minimum ownership evidence is needed before an app can go live. Policy is most effective when it is paired with education and a clear approval path, so teams do not bypass central processes just to move faster.
Practitioners should also insist on revocation discipline. A citizen-developed app is not safe because it was built internally; it is safe only if its permissions, data access, and lifecycle are visible enough to be reviewed and removed. That is why Salesloft OAuth token breach and Vercel Context.ai OAuth Supply Chain Breach are strong reminders that unmanaged integrations can outlive the people who created them and still retain access to sensitive systems.
Practitioner takeaway: Treat shadow IT as an access-governance and lifecycle problem first, because the real risk is not undocumented software, it is durable permissions that nobody can confidently explain, monitor, or revoke.
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 CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Citizen-built SaaS/PaaS apps rely on tokens, keys and delegated access that must be governed. |
| NHI-02 — Lifecycle and Offboarding | Offboarding unmanaged apps is central when builders leave or business use changes. | |
| NHI-03 — Least Privilege and Access Scope | Shadow integrations become risky when they receive broader permissions than their use case needs. | |
| Recommendation — Inventory app credentials, rotate them routinely, and remove unmanaged secrets from ad hoc storage. Define app ownership, retirement triggers, and revocation steps before approving deployment. Constrain scopes to the minimum required and review delegated access for excess privilege. | ||
| CIS Controls v8 | 5 — Account Management | Unmanaged apps and integrations create account and credential sprawl that needs control. |
| 6 — Access Control Management | The issue is controlling who and what can connect to sanctioned systems. | |
| 16 — Application Software Security | Citizen-developed SaaS and PaaS apps need secure build and release boundaries. | |
| Recommendation — Maintain a complete inventory of app accounts and remove stale or orphaned access promptly. Approve and periodically validate all third-party and citizen-built access paths. Apply security review gates to low-code and custom app releases before they integrate with production data. | ||
Related resources from NHI Mgmt Group
- What do teams get wrong about shadow SaaS and authentication?
- What do teams get wrong about SSPM when trying to secure SaaS applications?
- What do security teams get wrong about monitoring identities across SaaS applications?
- What do teams get wrong about detecting abuse of SaaS identities and OAuth applications?
