They need both, but not as separate workstreams. ITAM tracks what exists and what it costs, while IAM determines who can use it, administer it, and revoke it. If those disciplines do not share the same approval and offboarding process, unsanctioned SaaS will continue to slip through governance gaps.
Why Shadow SaaS Needs Both Inventory Control and Access Control
shadow saas becomes a governance problem only when organisations can answer two different questions at once: what has appeared in the estate, and who can use or administer it. ITAM is the discovery and ownership lens, while IAM is the access and entitlement lens. If either side is missing, a subscription can remain invisible, or remain reachable long after it should have been revoked.
That distinction matters because shadow SaaS often enters through ordinary employee choice, not a formal project. One team may see a spend line, another may see a login path, but no one sees the full lifecycle unless inventory and identity data are reconciled.
For broader lifecycle coverage, the NHI Lifecycle Management Guide is useful because the same provisioning, rotation, and offboarding logic applies when organisations are trying to retire unsanctioned software access cleanly.
How ITAM and IAM Split the Problem
ITAM is strongest at software discovery, contract visibility, ownership, renewal dates, and cost attribution. It helps answer whether the SaaS instance exists, who paid for it, which department it belongs to, and whether it should be tolerated, approved, or retired. Without ITAM, shadow SaaS often survives because no one can prove it is part of the managed estate.
IAM addresses a different control point: access. It determines which users, groups, admins, tokens, and delegated roles can authenticate to the service, and whether those permissions should still exist. Without IAM, a SaaS tool may remain reachable through stale SSO assignments, orphaned admin roles, or user-managed credentials even after procurement has flagged it.
The practical boundary is simple: ITAM tells you what to govern, IAM tells you who may touch it. Organisations that treat one as a substitute for the other usually end up with partial visibility and incomplete enforcement. The IAM and Identity Provider Buyer’s Guide helps frame the access side of that split, especially where SaaS approval, SSO enforcement, and deprovisioning need to line up.
What Works in Practice When Governance Is Shared
The best operating model is a shared approval and offboarding path, not two disconnected queues. New SaaS should be captured at intake by ITAM, checked for business justification, then bound to IAM controls before broad use begins. Offboarding should work in reverse: remove assignments, revoke admin privileges, and confirm the application is retired or brought under approved management.
That workflow needs one owner for inventory and one owner for access enforcement, with a clear handoff point. If procurement, security, and business teams each keep separate records, the result is duplicated truth and delayed action. If they share one workflow, shadow SaaS becomes easier to classify, constrain, and remove. The Identity Security Programme Guide is a useful model for that kind of shared operating structure because it ties governance, ownership, and lifecycle controls together.
Risk and Threat Considerations
Shadow SaaS creates exposure when discovery and access control fall out of sync. The common failure mode is not just unknown software, but unknown authentication paths, lingering admin access, and untracked data movement through a service that was never formally approved.
Failure mechanism: An application can sit outside ITAM records while still being reachable through SSO, direct login, or shared credentials, which leaves revocation incomplete and makes offboarding ineffective.
Impact: Organisations can lose control of data residency, auditability, and privilege boundaries, and they may only discover the problem after the service is used for sensitive work or after an employee leaves.
For attack-path context, the risk is similar to other overexposed SaaS and cloud access paths: once an unsanctioned service has active identities attached to it, the control problem shifts from procurement to compromise containment. The Cloud PAM and CIEM Guide illustrates why entitlement visibility matters when access must be right-sized and revoked decisively.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CSA Cloud Controls Matrix, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CSA Cloud Controls Matrix | IAM — Identity & Access Management | Shadow SaaS governance depends on controlling who can access and administer services. |
| Recommendation — Enforce SaaS identity controls and right-size access for approved applications. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Shadow SaaS persists when accounts and entitlements are not provisioned or revoked cleanly. |
| IA-5 — Authenticator Management | Shadow SaaS often survives via unmanaged credentials and tokens tied to the service. | |
| Recommendation — Track and revoke SaaS accounts through a centralized account management process. Manage SaaS credentials and tokens through formal lifecycle and rotation controls. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Shadow SaaS requires access rules that align use and administration with policy. |
| Recommendation — Define and enforce access control rules for sanctioned SaaS services. | ||
| CIS Controls v8 | CIS-5 — Account Management | Unmanaged SaaS access is an account management problem that CIS Control 5 directly addresses. |
| CIS-1 — Inventory and Control of Enterprise Assets | ITAM-style discovery is needed to find unsanctioned SaaS before it spreads. | |
| Recommendation — Inventory and disable unauthorized SaaS accounts and access paths. Maintain an enterprise inventory of SaaS assets and ownership. | ||
Practitioner Guidance
What to prioritise: Build one approval and offboarding workflow that both ITAM and IAM must use. If a SaaS app is visible in spend but absent from identity controls, treat it as partially governed, not managed.
What to verify: Check that every sanctioned SaaS app has an owner, an access path, and a revocation path. If any of those three is missing, the app is already drifting into shadow territory.
Practitioner takeaway: Shadow SaaS is not solved by choosing ITAM or IAM alone, because the real control objective is to connect inventory truth to access truth before users, admins, or tokens outlive approval.
Related resources from NHI Mgmt Group
- What should organisations do when they discover shadow IT through their IAM platform?
- When should organisations integrate shadow SaaS into their central IAM framework rather than treat it as a separate problem?
- What happens when organisations try to manage IAM and PAM separately across multiple SaaS tools?
- What do organisations get wrong when they try to manage shadow AI only through approved tool inventories?