Cloud access security brokers and the IAM gap in shadow IT

At a glance

What this is: This is an overview of CASBs, with the key finding that they fill cloud security and governance gaps left by perimeter-centric IAM and legacy controls.

Why it matters: It matters because IAM teams now have to govern sanctioned and unsanctioned cloud usage, not just authenticate users, and CASB patterns intersect with NHI, autonomous, and human access models.

By the numbers:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.

👉 Read StrongDM's overview of cloud access security brokers and shadow IT

Context

Cloud access security brokers sit between users and cloud services to apply policy where legacy perimeter controls stop short. In practical terms, a CASB is meant to see cloud usage, enforce data rules, and surface shadow IT, which makes it relevant to cloud access security broker governance, IAM, and broader identity programmes.

The governance gap is not just about visibility. Once cloud apps, unmanaged devices, and third-party services enter the access path, identity teams need controls that connect authentication, authorisation, and data handling across SaaS, IaaS, and PaaS without assuming the old network boundary still exists.

Key questions

Q: How should security teams govern shadow IT in cloud environments?

A: They should treat shadow IT as an access governance problem, not just an asset inventory issue. The first step is to discover unsanctioned apps, then classify them by data sensitivity and business need, and finally decide whether to block, constrain, or formally approve them. Visibility is the prerequisite for control.

Q: Why do CASB controls matter when IAM already exists?

A: IAM can authenticate users and assign permissions, but it often cannot see how cloud apps are used, which devices are connecting, or where sensitive data moves after access is granted. CASB adds that missing visibility and policy enforcement layer, especially in SaaS, IaaS, and PaaS environments.

Q: What breaks when cloud access is managed only through perimeter security?

A: Perimeter-only models miss unmanaged devices, unsanctioned apps, and data movement inside cloud services. That creates blind spots where authenticated users can still expose sensitive information without triggering the controls that were designed for on-premises networks. Cloud governance fails when the access path is no longer bounded by the network edge.

Q: Should organisations use CASB, SASE, or IAM as the primary cloud control?

A: They should not treat them as interchangeable. IAM governs identity and permissions, CASB governs cloud app visibility and data policy, and SASE broadens enforcement across networking and security services. The right choice depends on which gap is most urgent, but none of the three fully replaces the others.

Technical breakdown

CASB enforcement layers in cloud access security

A CASB works as a control point that applies policy through APIs, proxies, gateways, and log analysis. API mode is best for post-connection inspection and configuration changes, while proxy and gateway modes can block, allow, or redact activity in real time. That architecture matters because cloud services are distributed and often outside direct enterprise control. CASBs commonly combine authentication, authorization, device profiling, logging, malware detection, and tokenization so policy follows the access request rather than staying trapped inside a perimeter firewall.

Practical implication: map which cloud apps need real-time enforcement and which can be covered by API-based inspection before choosing controls.

Shadow IT discovery and cloud discovery analytics

Shadow IT is not only unsanctioned software. It is any cloud app, device, or service used outside approved governance. CASBs try to expose that blind spot by discovering sanctioned and unsanctioned services, scoring their risk, and identifying data movement across them. The technical value is in correlation. If an identity system sees successful login but the CASB sees an unknown app, an unmanaged device, or unusual upload volume, security teams can connect access activity to governance risk rather than treating each signal separately.

Practical implication: use discovery data to decide which apps to allow, restrict, or retire instead of relying on self-reported inventories.

Data protection, DLP, and contextual access control

CASBs extend data loss prevention into cloud environments by classifying data and applying alert, block, audit, delete, and encrypt actions. They also support contextual access control, which means the level of access can change based on user, device, app, or data sensitivity. That is especially important when sensitive files move across SaaS platforms where traditional endpoint DLP may not see the full path. In identity terms, the CASB becomes the control layer that ties access decisions to data handling rules, not just to who authenticated.

Practical implication: align cloud DLP policies with identity conditions so access decisions reflect both the actor and the data being touched.

Breaches seen in the wild

• Azure Key Vault privilege escalation exposure — Azure Key Vault Contributor role misconfiguration enabled privilege escalation.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

CASB is really a cloud access governance problem, not a product category problem: the article shows that cloud controls fail when identity, device, and data decisions are split across separate tools. The practical issue is not whether a CASB exists, but whether the organisation can see sanctioned and unsanctioned cloud usage well enough to govern it. For practitioners, the lesson is that cloud access needs identity-led policy, not just added monitoring.

Shadow IT is the signal that access governance has lost coverage: when users adopt apps outside IT control, the organisation no longer knows which identities are touching which data paths. That creates a governance gap across human access, third-party access, and non-human workflows that use the same cloud surfaces. The implication is to treat discovery as a governance input, not a reporting feature.

Cloud policy cannot stop at authentication because access risk now lives in the session and in the data path: CASB value comes from seeing how access is used, not only whether it was granted. That makes it relevant to NHI, human IAM, and delegated access chains alike. Practitioners should read this as a warning that identity proof and policy enforcement must be coupled to cloud usage telemetry.

Contextual access control is the right named concept for this category: the real shift is from static permissioning to access that changes with device posture, app risk, and data sensitivity. CASBs operationalise that shift by connecting identity signals to data controls. The practitioner conclusion is that cloud governance becomes dynamic only when identity and data policy are evaluated together.

IAM tools alone do not tell you where cloud exposure begins: CASBs fill the visibility layer that IAM systems do not natively provide. The category therefore sits between identity governance and data security, which is why it keeps reappearing in hybrid and multi-cloud discussions. For teams, the takeaway is to use CASB as a control-extension layer, not a substitute for IAM or DLP.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
• From our research: Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to The 2026 Infrastructure Identity Survey.
• Forward pivot: For the identity baseline behind that gap, see Ultimate Guide to NHIs for the lifecycle and governance controls that cloud access programmes still need to extend into non-human access.

What this signals

Contextual access control: cloud governance is shifting from binary allow or deny decisions to policy that reacts to device posture, app risk, and data sensitivity. That means identity programmes need clearer separation between authentication, entitlement, and data-use enforcement, especially in multi-cloud estates.

The pressure will be highest where cloud discovery, DLP, and identity telemetry are still managed as separate workstreams. If the organisation cannot correlate those signals, shadow IT becomes a standing governance blind spot rather than a temporary exception.

For teams looking to anchor their control model, the OWASP Non-Human Identity Top 10 remains relevant because cloud access increasingly includes service accounts, tokens, and workload identities that CASB-like visibility alone cannot govern end to end.

For practitioners

• Inventory cloud apps beyond the approved stack Correlate identity logs with cloud discovery analytics to identify sanctioned and unsanctioned services, then classify them by business use, data sensitivity, and access risk.
• Tie cloud access decisions to data sensitivity Align CASB policy with DLP labels so uploads, sharing, and downloads can be blocked or audited when sensitive data moves across SaaS, IaaS, or PaaS.
• Use device and session context in access policy Require contextual access control for unmanaged devices, unusual locations, and high-risk applications so access can be reduced when posture changes.
• Define where CASB sits in the control stack Decide which enforcement belongs in IAM, which belongs in CASB, and which belongs in DLP before integrating more tools into the cloud access path.

Key takeaways

• CASBs matter because cloud access now creates governance gaps that perimeter IAM cannot see or control on its own.
• The clearest signal in this category is the rise of shadow IT, unmanaged devices, and data movement across SaaS, IaaS, and PaaS.
• Practitioners should use CASB as an enforcement and discovery layer that complements IAM and DLP, not as a replacement for either.

Key terms

• Cloud Access Security Broker: A CASB is a control layer that sits between users and cloud services to apply security policy, visibility, and data protection. It helps organisations see and govern cloud activity that would otherwise sit outside traditional perimeter controls and legacy monitoring.
• Shadow IT: Shadow IT is the use of software, services, or devices without IT’s knowledge or approval. In cloud environments, it creates governance blind spots because identities can authenticate and move data through services that the security team does not fully inventory or control.
• Contextual Access Control: Contextual access control changes access decisions based on factors such as device posture, application risk, location, or data sensitivity. In cloud security, it helps move access policy from static entitlements toward decisions that reflect the actual conditions of use.
• Cloud Discovery Analytics: Cloud discovery analytics identifies cloud applications and usage patterns across sanctioned and unsanctioned services. Security teams use it to expose shadow IT, rank cloud risk, and connect identity activity to the data paths that need governance.

Deepen your knowledge

Cloud access governance and shadow IT discovery are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your cloud programme is already dealing with cross-platform access and unsanctioned usage, it is worth exploring.

This post draws on content published by StrongDM: Understanding Cloud Access Security Brokers (CASBs). Read the original.