Zero Trust Network Access (ZTNA) has been promoted by vendors over the last several years as a foundational approach for network security. The basic premise is to never trust and always verify.
While the core ideas behind ZTNA are valid, this multi-billion dollar market faced a brutal assessment at DEF CON 2025 when UK security researchers from AmberWolf demonstrated severe vulnerabilities across three major ZTNA vendors.
The research team found complete authentication bypasses in all tested platforms. Check Point’s Harmony SASE contained hard-coded encryption keys that exposed customer data through diagnostic logs. Zscaler’s SAML implementation failed to validate signatures, allowing attackers to forge authentication tokens. Netskope suffered from cross-tenant vulnerabilities that let attackers compromise any organization using leaked enrollment tokens.
Beyond individual flaws, the researchers systematically defeated the foundational zero-trust concept of device posture checking. They developed tools that fake compliance checks for antivirus, firewalls, disk encryption and hardware fingerprinting across all major platforms. Most damaging, they demonstrated how attackers can steal ZTNA configurations and replay them from unmonitored systems.
The findings reveal architectural problems that contradict zero-trust principles. Rather than verifying device and user trustworthiness, these solutions place enormous trust in vendor infrastructure and client-side security controls.
“Rather than being never trust, always verify, we found it was more, ‘always trust, never verify,’” AmberWolf researcher David Cash said during the session.
Major vendor vulnerabilities span authentication and design flaws
The research exposed critical vulnerabilities across Check Point, Zscaler and Netskope that fell into three primary categories: authentication bypasses, credential storage failures and cross-tenant exploitation.
Authentication bypass vulnerabilities
Zscaler’s SAML implementation contained the most severe authentication flaw. The researchers discovered that the signature on the SAML assertion was only checked for presence, and it wasn’t validated against the identity provider’s public key. This allowed complete bypass of identity provider authentication by forging SAML responses with invalid signatures.
Netskope suffered from a similar but more fundamental bypass. The enrollment API required no authentication, allowing attackers to register devices using only leaked organization keys and valid email addresses.
Check Point’s vulnerability centered on hard-coded encryption keys embedded in client binaries. These keys protected diagnostic log uploads containing JSON Web Tokens (JWTs) that lived for 30 days creating a potential compromise scenario for any customer who had uploaded logs to support.
Credential storage and token management flaws
All three vendors implemented weak credential storage mechanisms. Zscaler stored Device Token Authentication credentials in Windows registry in clear text, allowing local attackers to extract tokens and impersonate any user by modifying registry values. Netskope’s “Secure Enrollment” tokens used DPAPI encryption with insufficient protection.
Vendor response and remediation
Vendor responses varied significantly in speed and effectiveness. According to the researchers, Zscaler responded most rapidly, initially patching their SAML vulnerability (CVE-2025-54982) within four hours. However, the fix introduced compatibility issues requiring a rollback before a permanent solution was implemented.
Check Point immediately removed SFTP read access upon disclosure but has additional vulnerabilities still under responsible disclosure. Netskope fixed their cross-tenant issue in version 126 on May 12, 2025, but notably does not issue CVEs for server-side fixes despite being a Certificate Numbering Authority.
A concerning pattern emerged around legacy vulnerabilities. Netskope’s original authentication bypass (CVE-2024-7401) was disclosed in April 2024 but remained exploitable in production environments as of August 2025. The advisory noted the vulnerability “was exploited in the wild by bug bounty hunters,” yet organizations continued running vulnerable configurations.
Architectural trust contradictions undermine zero-trust principles
The research exposed fundamental contradictions between zero-trust marketing and implementation reality.
All ZTNA solutions install trusted root certificates for traffic inspection, creating centralized trust dependencies that contradict core zero-trust principles. This architecture requires organizations to trust vendor infrastructure completely.
The trust contradiction extends beyond traffic inspection to fundamental security assumptions. Rather than implementing continuous verification, the researchers claimed that these products rely heavily on client-side security controls and vendor infrastructure integrity. This represents a significant departure from zero-trust principles that assume compromise and require constant validation.
Best practices for reducing ZTNA risk
The researchers didn’t just poke holes in ZTNA, they also provided guidance for how to plug those holes. The AmberWolf researchers suggest ZTNA users take the following steps to mitigate potential risk:
Critical immediate actions
- Update all ZTNA clients to latest versions regardless of published CVE status.
- Activate server-side validated posture checks where supported by vendors.
- Implement cryptographically secured compliance verification features.
Enhanced monitoring and detection
- Monitor ZTNA logs for new device registrations from unexpected locations, rapid posture check state changes and users with multiple devices.
- Deploy EDR rules targeting sensitive registry access, process injection into ZTNA clients and unexpected child processes.
- Enable DPAPI auditing through Microsoft-Windows-Crypto-DPAPI/Debug logging to detect credential extraction.
Configuration hardening
- Audit and minimize domain-based bypass rules, reviewing them regularly for abuse.
- Implement network segmentation independent of ZTNA policy enforcement.
- Establish authentication token rotation schedules and demand vendor transparency on security architectures.
“In conclusion, well, it turns out there are no magic ZTNA beans, we’ve got the same old bug classes reimagined for a new technology stack,” AmberWolf researcher Richard Warren said. “Rather than zero trust, we’re actually putting a lot of trust into these vendors to process our data securely.”
Source:: Network World