Zero Trust Network Access checks who you are and whether your device is healthy at the moment you connect. After that, a standard ZTNA gateway rarely looks again. That gap is where modern identity attacks live, and it is why Identity Threat Detection and Response (ITDR) has become part of the conversation for mid-market security teams.
This post explains what ITDR actually is, why preventative access controls like IAM, PAM and ZTNA cannot stop credential abuse on their own, and how a consolidated SASE platform closes most of the risk without standing up a Security Operations Centre. The angle is honest. Platforms like Jimber are not dedicated ITDR products. The point is how posture, isolation and least-privilege shrink the identity attack surface that ZTNA alone leaves open.
What ITDR is and why it sits next to your access controls
Identity Threat Detection and Response is a security discipline focused on protecting credentials, user privileges and the authentication infrastructure itself. Unlike access controls that decide who gets in, ITDR assumes compromise has already happened. It continuously monitors behavioural patterns and directory telemetry to spot active account abuse and unauthorised privilege changes.
That distinction matters because the threat has moved. According to the Verizon Data Breach Investigations Report published in 2026, stolen credentials are involved in 39% of all analysed breaches. The CrowdStrike Global Threat Report found that 82% of security detections in 2025 were entirely malware-free, relying instead on credential abuse and legitimate administrative tools. Attackers are not breaking down the door. They are walking in with a valid key.
ITDR does not replace your identity provider or your ZTNA gateway. It fills the blind spot those tools share: neither was built to notice when a legitimate session turns hostile.
Why IAM and PAM alone fail to stop modern intrusions
Identity and Access Management sets the permission rules. Privileged Access Management gates the high-value accounts. Both are static, preventative tools. They define what should be allowed, then trust that whoever passed the check is who they claim to be.
That trust is the weakness. Once an attacker successfully impersonates a legitimate user, IAM and PAM cannot tell the difference between a normal request and active credential abuse. The policy was satisfied. The gate opened. Nothing in the design says to keep watching.
Basic identity hygiene is still where most damage starts. The Verizon DBIR found that 4% of Active Directory user accounts use passwords already compromised and circulating in the wild. It also reported that 37% of organisations maintained an administrative account with multi-factor authentication disabled on an infrastructure-as-a-service offering, though that figure comes from a specific slice of cloud telemetry rather than a triangulated sample. Either way, preventative tools cannot compensate for an admin account left wide open.
How the allow-and-ignore model of standalone ZTNA creates a blind spot
Standalone ZTNA evaluates trust as a one-time gate at session start. Once the connection is approved, the platform routes traffic without inspecting it further. This binary model does its job at the door and then stops paying attention.
The result is a post-admission blind spot. Lateral movement, credential abuse and quiet data exfiltration all happen inside an already-approved session, where the gateway no longer looks. ZTNA narrows the network to specific applications, which is a real improvement over flat VPN access. But narrowing the path is not the same as watching what travels down it.
This is the architectural point competitors tend to skip. ZTNA is sold as the answer to secure access, and for initial access it is strong. The honest version is that initial access was never the whole problem.
How session hijacking defeats MFA and your access gate
Attackers increasingly skip the login entirely. Instead of cracking passwords, they harvest active session cookies and refresh tokens from unmanaged endpoints using infostealer malware. Because a stolen token represents an authentication event that already succeeded, the attacker imports it into their own browser and gets in without ever triggering a password prompt or an MFA challenge.
This is why MFA, on its own, is not the finish line. Multi-factor authentication is enforced at the initial login. Infostealer malware extracts the session cookie that login produced, straight from the browser. Replaying that cookie satisfies a requirement that was already met, so no new challenge fires.
The data shows how directly this feeds the worst outcomes. The Verizon DBIR found that 73% of ransomware victims had experienced an infostealer infection or credential leak in the year before the attack. For half of those organisations, according to the same report, the credential leak happened within 95 days of the attack. Stolen credentials are not a side issue. They are the on-ramp to ransomware.
Clientless ZTNA for contractors and BYOD makes this worse, not better. Much advice recommends exactly that model for unmanaged devices. The problem is that session cookies then sit in the user’s local, unsecured browser, where infostealers can copy them and emulate the full session from another machine.
A password reset does not fix it either. Resetting a password does not automatically end active sessions or revoke stolen refresh tokens, which can stay valid until they are explicitly revoked at the identity provider. The attacker keeps generating fresh session cookies in the background until someone cuts the token off at the source.
The signals that expose an active compromise
Catching session hijacking means looking at telemetry beyond the login parameters. The login already passed. The evidence is in what happens next.
Useful indicators include mid-session changes to the browser fingerprint, anomalous shifts in the Autonomous System Number a session connects from, the same credential being used from two distant locations at once, and unusual data extraction from automated cloud service accounts. None of these are visible to a gateway that stopped inspecting after admission. All of them require continuous evaluation rather than a one-time check.
This is also where the gap between conditional access and continuous posture becomes practical rather than academic. Standard conditional access evaluates a device’s security state once, at login. Continuous posture verification keeps checking throughout the session. If a device disables its firewall, loses disk encryption or gets infected mid-session, access can be revoked the moment the signal changes. For a deeper breakdown of how those signals are collected and scored, see our guide to continuous device posture signals and scoring, and our explainer on how conditional access policies protect hybrid teams.
Practical identity security for mid-market teams without a SOC
Running a dedicated SOC alongside standalone ITDR, SIEM and PAM tools is unrealistic for a European organisation of 50 to 400 users. The budget is not there, and neither is the headcount. Large vendors promote ITDR as a complex suite that assumes continuous monitoring by a high-end security team. For most mid-market organisations, that is a non-starter.
The pragmatic alternative is consolidation. Instead of bolting on another standalone tool, fold continuous posture checks and browser isolation into a single platform that already handles network access. Platforms like Jimber take this approach, combining ZTNA, SWG, FWaaS, SD-WAN and NIAC hardware under one console, so identity risk is reduced by design rather than by adding another product to manage.
Two Jimber controls do most of the work against the attacks described above.
Browser isolation neutralises token theft at the source. Jimber’s browser isolation runs the session inside an isolated container in the cloud and streams only safe pixels to the user. The actual browser and its session cookies never touch the local endpoint. Local infostealer malware has nothing to copy. On an unmanaged contractor laptop or a BYOD device, this creates a secure working bubble without forcing a heavy endpoint agent onto a machine you do not control, which also sidesteps the privacy friction that deep posture scans on personal devices tend to cause.
Continuous posture checks fix the one-time-gate limitation of ZTNA. Jimber evaluates device state continuously across the session rather than once at login, so a device that degrades mid-session loses access when it degrades, not at the next morning’s sign-in.
There is an honest caveat here. A SASE platform protects against network and session-based attacks well, but it does not replace basic directory hygiene. If an administrator runs weak Active Directory passwords or disables MFA on cloud admin accounts, network controls can limit the blast radius but cannot prevent the initial break-in. Strong identity foundations and platform-level protection are complements, not substitutes. There is also a practical note for older systems: SASE-based posture and isolation assume applications work with modern proxy architectures, and a few legacy applications may need extra coordination to fit.
For European teams, this consolidation also lines up with compliance. NIS2 and CyberFundamentals both demand demonstrable access control and supply chain security, and the Belgian CyFun deadline of 18 April 2026 has already passed. Continuous posture and browser isolation produce the access-control evidence those frameworks expect, without an enterprise SOC behind them. This is the detection-and-containment layer that complements a full zero trust architecture rather than replacing it.
If you want to see how continuous posture and browser isolation handle stolen-token attacks in your own environment, book a Jimber demo and walk through it with your team.
Frequently asked questions
What is the difference between ZTNA and ITDR?
ZTNA is a gateway that verifies identity and device posture before letting a user connect to specific applications. ITDR is an active detection discipline that continuously monitors identity infrastructure and session behaviour for signs of compromise after access has been granted. One controls entry, the other watches what happens inside.
How do infostealer infections bypass multi-factor authentication?
MFA is enforced only at the initial login. Infostealer malware extracts active session cookies straight from the browser. Because those cookies represent a session that already satisfied MFA, the attacker replays the cookie to reach the account without ever triggering a new authentication challenge.
Why does a password reset fail to stop a session hijacking attack?
Resetting a password does not automatically terminate active sessions or revoke stolen refresh tokens, which can remain valid until explicitly revoked at the identity provider. Until that revocation happens, the attacker can keep generating new session cookies and stay inside the account.
How does browser isolation protect session tokens from local malware?
Browser isolation runs all web code inside a secure container hosted in the cloud and streams only safe visual pixels to the user. Because the real browser and its session cookies never reside on the local endpoint, local infostealer malware has no physical access to harvest the tokens.
How is continuous posture verification different from conditional access?
Standard conditional access checks a device’s security configuration once, during login. Continuous posture verification monitors endpoint health throughout the whole session. If a device disables its firewall, loses disk encryption or is infected mid-session, access is revoked immediately rather than at the next login.
Is ZTNA still worth deploying if it has this blind spot?
Yes. ZTNA is a strong improvement over VPN for initial access and least-privilege segmentation. The blind spot is post-admission, not at the gate. The fix is adding continuous posture and session isolation on top, ideally within the same platform, rather than abandoning ZTNA.
