Browser-level cloud access closes the missing middle in IAM

At a glance

What this is: This is an analysis of why cloud security posture tools stop short of the browser session, and why that gap matters once attackers operate inside legitimate identities.

Why it matters: IAM, NHI, and cloud teams need browser-level visibility because posture checks do not stop session hijacking, shadow SaaS access, or legitimate-looking abuse after authentication.

👉 Read Push Security's analysis of the missing middle in cloud access security

Context

Cloud security posture tools were built to answer a configuration question: is the environment set up securely across roles, policies, and exposed services? That model works for static control planes, but it fails once access moves into a live browser session and the attacker behaves like a valid user.

The missing middle is the gap between identity provider login and cloud API execution. It matters to IAM practitioners because access decisions no longer end at authentication or infrastructure policy. They continue inside the session, where browser activity, app context, and user behaviour determine whether access is being used or abused.

Key questions

Q: How should security teams handle browser sessions in cloud access governance?

A: Security teams should treat the browser session as part of the access boundary, not just a delivery mechanism. If posture tools only assess configuration, they will miss abuse that happens after login. The practical move is to combine identity, application, and session evidence so teams can tell whether a valid session is being used normally or manipulated in real time.

Q: Why do CSPM and CNAPP miss some cloud attacks?

A: CSPM and CNAPP miss attacks that stay inside a legitimate session because they are built to assess configuration and posture, not in-session behaviour. Once authentication succeeds, an attacker can operate through normal browser workflows and look like an approved user. That makes session-level visibility essential for detecting abuse that the cloud control plane will not flag.

Q: What do security teams get wrong about browser-based cloud access?

A: Teams often assume that strong cloud configuration and identity controls are enough on their own. The gap is that many sensitive actions happen after authentication, in the browser, where shadow SaaS, local accounts, and token abuse can bypass central oversight. Governance has to account for how access is actually exercised, not just how it is provisioned.

Q: How can organisations tell whether access is being used or abused?

A: They need session evidence, not just login records. Browser context shows what was rendered, what the user clicked, and whether the session behaved like a normal workflow or a manipulated one. That evidence helps investigators separate legitimate use from compromise and makes containment decisions more accurate.

Technical breakdown

Why CSPM and CNAPP stop at configuration

CSPM and CNAPP are designed to assess cloud posture, not live user intent. They inspect configuration drift, overly permissive IAM roles, exposed resources, and policy violations across accounts and services. That makes them strong at answering whether the cloud is configured securely. They are weaker once a valid session exists, because a credentialed user can move through normal interfaces without triggering infrastructure-level alarms. In that model, the control plane still looks healthy even while the browser session is being manipulated in real time.

Practical implication: Use posture tools for configuration control, but do not expect them to detect abuse that stays inside an approved session.

The browser session as the missing middle in cloud security

The browser session is the operational layer where cloud access actually happens for many users. It sits between the IdP and the final API call, which means infrastructure tools often see only the start and end of the action, not the behaviour in between. That is why phishing kits, token theft, and lookalike login pages can remain invisible to stack components that only observe identity or cloud configuration. The session itself becomes the real control plane once authentication succeeds.

Practical implication: Treat the browser session as a governed security boundary, not a passive transport layer.

Session-level telemetry changes detection and response

Click-by-click browser telemetry gives responders context that logs alone cannot provide. Instead of a timestamp and IP address, teams can see what was rendered, what the user clicked, and whether a session was manipulated in real time. That matters for determining scope, separating legitimate activity from abuse, and containing compromise without guessing. It also helps uncover shadow SaaS, duplicate identities, and MFA gaps that sit outside centrally managed application paths.

Practical implication: Add browser-level evidence to investigation workflows so responders can assess intent and scope before they rely on brittle app logs.

Threat narrative

Attacker objective: The attacker aims to operate inside a legitimate session long enough to complete sensitive actions while remaining indistinguishable from normal user behaviour.

1. Entry occurs when an attacker compromises a user through phishing, session hijacking, or token theft and enters a valid browser session.
2. Escalation happens inside the approved session, where the attacker performs authorised-looking actions that bypass infrastructure-focused detection.
3. Impact follows when sensitive cloud or SaaS actions complete through the browser before posture tools recognise that the session was abused.

Breaches seen in the wild

• Azure Key Vault privilege escalation exposure — Azure Key Vault Contributor role misconfiguration enabled privilege escalation.
• Codefinger AWS S3 ransomware attack — Codefinger used compromised AWS credentials to encrypt S3 buckets via SSE-C.

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

NHI Mgmt Group analysis

Browser-session visibility is now an identity governance problem, not just a detection problem. CSPM and CNAPP can validate whether cloud configurations are sound, but they cannot adjudicate what happens after a user has already entered a session. That means the real governance boundary has shifted from infrastructure posture to live interaction context. Practitioners should treat browser activity as part of access governance, not as an adjacent monitoring feed.

The missing middle is the control gap this article exposes. The article is really describing a regime where identity is valid, access looks expected, and misuse still succeeds because the session itself is outside the security model. That is a classic control-plane blind spot: the programme can certify configuration while remaining blind to the execution layer where abuse occurs. The implication is that access assurance must extend to the session, not stop at login.

Session-level telemetry is becoming the named concept teams need to govern cloud abuse. The browser session is where legitimate-looking behaviour, shadow SaaS access, and token misuse converge into one operational problem. When teams can observe page rendering, interaction, and in-tab behaviour, they can distinguish authentic use from manipulated use with far more confidence. Practitioners should expect identity programmes to widen their evidentiary model from logs to live session context.

Cloud security controls and browser controls solve different halves of the same access problem. Infrastructure tooling governs configuration, but access abuse now often occurs after the identity layer has already done its job. That means cloud teams, IAM teams, and identity architects need a shared operating model for what constitutes a trustworthy session. Practitioners should align governance, detection, and response around the point where access is actually exercised.

Shadow SaaS turns browser access into an inventory and policy problem as well as a security one. When users reach sensitive services through local accounts, duplicate identities, or MFA gaps, central cloud controls inherit weaknesses they cannot see or fix on their own. The governance lesson is that application access paths must be discovered where they are used, not only where they are provisioned. Practitioners should map browser-mediated access paths into IAM and risk reporting.

From our research:

• 59.8% of organisations see value in a solution that simplifies non-human access management and introduces dynamic ephemeral credentials, according to The 2024 Non-Human Identity Security Report.
• Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities, which shows how narrow the operational trust margin still is.
• For broader lifecycle context, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for how access governance changes once identities are no longer static.

What this signals

Browser-mediated access is becoming a control-plane issue for IAM teams. As cloud usage shifts deeper into SaaS and session-driven workflows, the evidence needed to prove legitimate use also shifts. Teams that keep relying on configuration posture alone will struggle to separate compliant access from in-session abuse, especially when shadow SaaS and unmanaged login paths sit outside central policy.

Session telemetry will increasingly complement, not replace, existing posture controls. The right operating model is layered: cloud posture for configuration, identity controls for authentication, and browser visibility for execution. The article's broader signal is that governance programmes need evidence at the point of use, because that is where modern cloud compromise often hides.

The browser session is where access can still look valid while being actively abused, which means detection, investigation, and access assurance need to converge around observed behaviour. For IAM leaders, this is a prompt to update control mappings, evidence collection, and incident workflows before session-level blind spots become routine.

For practitioners

• Extend identity controls into the browser session Define the browser as a governed access boundary for cloud and SaaS use, then include session context in monitoring and investigation workflows. Prioritise services where users complete privileged actions after authentication, because that is where posture tools lose visibility.
• Inventory shadow SaaS and local account paths Track unmanaged applications, duplicate identities, and password-only access paths that bypass SSO or MFA. Use that inventory to identify where cloud posture is being undermined by application-level access drift.
• Add session evidence to response playbooks Require responders to capture click-by-click browser evidence when investigating suspected compromise. That context helps distinguish legitimate use from manipulated sessions and reduces reliance on incomplete logs.
• Review authentication assumptions at the app layer Check where a user can still reach sensitive cloud services through unmanaged login paths even when the core cloud estate is locked down. Close the gaps that let a valid session become the attacker's operating space.

Key takeaways

• CSPM and CNAPP remain necessary, but they do not see abuse that happens after a user enters a valid browser session.
• The missing middle is the gap between identity provider login and cloud API execution, and attackers increasingly operate inside that gap.
• Browser-level visibility gives defenders the evidence they need to separate legitimate use from manipulated access and contain compromise faster.

Key terms

• Browser session: A browser session is the live, authenticated interaction between a user and an application after login. In identity governance, it is where access is actually exercised, which makes it a security boundary when attackers can manipulate the user interface, tokens, or workflow without changing infrastructure configuration.
• Missing middle: The missing middle is the gap between identity provider authentication and final cloud or SaaS action. It is the place where posture tools, login logs, and infrastructure monitoring often lose visibility, even though the browser session can still be abused by a valid-looking identity.
• Shadow SaaS: Shadow SaaS is unmanaged application use that sits outside central identity and security oversight. It often includes local accounts, duplicate identities, or unreviewed login paths that bypass SSO and MFA, creating access risk that cloud posture tools cannot reliably see from the control plane alone.
• Session telemetry: Session telemetry is the evidence captured from live user interaction inside an application session, such as page structure, clicks, and in-tab behaviour. It gives responders context that login timestamps and IP addresses cannot provide, especially when attacker activity looks normal from the outside.

Deepen your knowledge

Browser-session visibility and identity governance are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are trying to extend access control beyond configuration and into live session activity, it is worth exploring.

This post draws on content published by Push Security: one of the key questions about why browser visibility matters alongside CSPM and CNAPP. Read the original.