An IaaS-only mindset breaks down because it ignores the scale and diversity of SaaS usage that now sits outside core IT control. That leaves shadow SaaS, abandoned apps, weak credentials, and unmanaged user to SaaS relationships outside visibility. Security teams then lose the ability to enforce consistent policy, detect risky access, or respond quickly when SaaS becomes the entry point.
Why the IaaS-Only Mental Model Fails
An IaaS-only view assumes the main security problem is in infrastructure you own and configure directly. In practice, cloud risk is increasingly dominated by SaaS usage that is purchased, connected, and shared outside the core perimeter. That means the real control problem is not just VMs and networks, it is also app-to-app trust, delegated access, and the hidden identity relationships that make SaaS usable.
The failure shows up when teams monitor accounts and assets they manage, but not the applications users have self-provisioned. Shadow SaaS and abandoned subscriptions create access paths that bypass standard review, and the same blind spot makes it harder to see which users, tokens, or integrations still have standing access to business data. In a cloud environment, those relationships can matter more than the underlying infrastructure layer.
When security architecture stops at IaaS, policy becomes inconsistent across the environments that actually store and move data. A team may harden compute and storage while leaving SaaS permissions, third-party connections, and user-granted consent untouched. That split creates a false sense of coverage, because the visible cloud estate looks controlled while the most active entry points remain outside normal enforcement.
Where the Security Gaps Actually Appear
The most common breakpoints are visibility, entitlement sprawl, and response lag. SaaS applications often arrive through business teams, browser sign-ins, or self-service procurement, so they never enter the same asset inventory as IaaS resources. Once they are in use, access can persist through stale accounts, forgotten admin roles, weak authentication, or long-lived integration tokens.
That is why cloud compromise often starts with the relationships around the service rather than the service itself. If an attacker can abuse a connected SaaS account, a shared mailbox, or an OAuth-style integration, they may not need to touch the underlying IaaS layer at all. For the defender, the practical issue is that detection rules built around server events, VM telemetry, or network controls will miss the more likely path of abuse.
For practitioners, the relevant question is not whether the organisation uses cloud security tools, but whether those tools cover the services where users actually collaborate and where data is most frequently exchanged. That is also why Ultimate Guide to NHIs is useful as a broader reference, because it frames the lifecycle and visibility problems that appear when service relationships outgrow manual oversight. The same pattern is visible in Klue OAuth Supply Chain Breach, where the risk sits in the integration chain, not just in the host environment.
One useful data point here is that only 5.7% of organisations report full visibility into their service accounts, which illustrates how easily access paths can sit outside day-to-day control. The exact number will vary by environment, but the operational lesson is stable: if you cannot inventory who can reach SaaS data and via which relationship, you cannot reliably govern the cloud estate.
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 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Covers inventory, least privilege, and access review across cloud and SaaS paths. |
| Recommendation — Inventory SaaS access paths and enforce least privilege with recurring access review. | ||
| NIST CSF 2.0 | PR.AC — Access Control | Directly supports governing access across cloud services, accounts, and integrations. |
| ID.AM — Asset Management | Cloud SaaS fails when assets and connections are not inventoried beyond IaaS. | |
| Recommendation — Apply access-control governance to user, admin, and integration access across cloud services. Maintain an inventory of SaaS applications, integrations, and connected identities. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Stale tokens and unmanaged service relationships drive SaaS exposure beyond IaaS. |
| Recommendation — Rotate and govern SaaS tokens, keys, and other long-lived credentials. | ||
Practitioner Guidance
What to prioritise: Build your cloud control view around access paths, not just infrastructure assets. Start with the SaaS applications that hold business data, then trace who can access them directly, who can administer them, and which integrations can act on their behalf.
What to verify: Confirm that SaaS onboarding, offboarding, and access review are covered by the same governance rhythm as IaaS. If a platform can be self-provisioned, connected by API, or granted by user consent without central review, treat that as a control gap until proven otherwise.
Common mistake: Teams often assume cloud security tooling is complete because it covers accounts in the main directory or the infrastructure estate. In a mixed cloud environment, that misses the places where policy is most likely to fragment, especially abandoned apps, stale grants, and third-party access chains.
Practitioner takeaway: If you only secure the infrastructure you directly administer, you will miss the control plane that now governs most real cloud exposure, the identity and access relationships around SaaS.
Related resources from NHI Mgmt Group
- What happens when organisations try to secure cloud and AI-driven environments without data-centric security?
- What breaks when organisations try to secure cloud native AI applications with siloed teams and point tools?
- What happens when organisations try to secure cloud and email environments without strong management support?
- What breaks when organisations keep standing privilege in cloud environments?
