<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
    <channel>
        <title>Products &amp; Solutions | Blog</title>
        <link>https://www.zscaler.com/blogs/feeds/product-insights</link>
        <description>Latest news and views from the leading voices in cloud security and secure digital transformation.</description>
        <lastBuildDate>Mon, 19 Oct 2026 19:04:26 GMT</lastBuildDate>
        <docs>https://validator.w3.org/feed/docs/rss2.html</docs>
        <generator>RSS 2.0, JSON Feed 1.0, and Atom 1.0 generator for Node.js</generator>
        <language>en</language>
        <item>
            <title><![CDATA[Ransomware at Machine Speed: How GenAI Shrinks the Path after Initial Access]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/ransomware-machine-speed-how-genai-shrinks-path-after-initial-access</link>
            <guid>https://www.zscaler.com/blogs/product-insights/ransomware-machine-speed-how-genai-shrinks-path-after-initial-access</guid>
            <pubDate>Fri, 16 Oct 2026 22:48:36 GMT</pubDate>
            <description><![CDATA[Artificial Intelligence technologies have made a huge impact on the security industry. But as with any public technology, adversaries have access to AI as well. They’re wasting no time incorporating AI into their malicious workflows and ransomware operators have been able to leverage it - unfortunately, this has led to some of their successes.Fortunately, there is plenty of potential for defenders to leverage similar AI technologies to improve their own game, neutralizing the adversaries’ advantage to keep users and resources safe.This blog post covers adversaries’ uses of Generative AI (GenAI) for both social engineering pretexts and technical development, as well as how defenders can spot and mitigate those efforts. For the full story, be sure to check out the complete analysis in the Zscaler ThreatLabz 2026 Ransomware Report. Key TakeawaysRansomware attacks continue to be a major driver of cybercrime incidents and attacker’s corresponding financial gains. While there are numerous means of compromising a victim, ransomware threat actors typically rely on social engineering as their first step toward compromising a target. The more believable a social engineering ruse, the more likely it will be successful.&nbsp; Attackers are already using GenAI to help overcome some of their traditional shortcomings.After they gain an initial foothold, time is of the essence. The faster the attacker can move throughout the victim’s environment and acquire sensitive data to either encrypt or steal outright, the less likely they will be detected while doing so and the more likely their efforts will be successful. &nbsp;Here again, GenAI is providing attackers with a faster and more focused approach that yields greater success.However, defenders can also use AI-enabled technology for their own purposes to stay in step with the attackers. Doing so ensures we keep pace with or even get ahead of the malicious uses of these nascent technologies. Technical AnalysisMore Effective Social Engineering RusesHistorically, most attackers’ social engineering game has been stifled by their inauthenticity. While there are many instances of intelligence-informed attackers crafting very believable ruses, these have been rare. The vast majority of ransomware actors used volume as their strategy for initially landing on a target system. This is why most user education campaigns have focused on spotting typos, non-native-speaking grammar mistakes, and other mostly obvious weaknesses in phishing emails and sites.However, AI has unmistakably leveled the playing field, giving attackers the capability to blend into the wave of legitimate email like never before. This, in turn, gives them a much higher chance of tricking a victim into clicking the link, downloading the file, or otherwise falling into the trap that’s been laid.Attackers can now use any of the public-facing GenAI platforms to create email messages, websites, and other assets that are polished, natively-built in the target’s language, and crafted to maximize success. As discussed in a previous blog, phishing emails are often used to trick a user into using a Remote Monitoring and Management (RMM) tool at the attacker’s behest, which then gives them full access to the victim’s system as well as potentially their wider environment.Faster Discovery of Valuable Materials…To StealGenAI technologies are also well suited to examine massive amounts of data for the purposes of classification or content searching. Once an attacker has access to the victim’s system, GenAI can therefore be used to search all materials to which a victim’s system has access, seeking the most valuable or sensitive data for theft or encryption during the next phase of the attack.This approach gives the attacker an incredibly fast method of identifying and acquiring the most damaging data, which then maximizes the likelihood the victim’s organization will pay the ransom to retrieve or prevent the disclosure of the encrypted/stolen data. Although this occurs after the initial access, it is still a form of reconnaissance. Speed is of the essence and GenAI makes the process even faster than it could be automated with traditional attacker scripts and playbooks.Speedy Creation and Iteration of Bespoke ScriptsFile and network signatures are perhaps one of the most well-established indicators in the security world. From the earliest days of antivirus to more modern implementations of fuzzy hashing and traffic fingerprinting, practically every security program uses signatures in some capacity. While this used to be effective, attackers can now rapidly vary their malware and scripts, resulting in corresponding variance of their signatures. This allows attackers to evade traditional detection mechanisms making it much harder to spot their activity based on those signatures alone.Attackers using GenAI-built scripts and other malware also no longer need to rely on common tools that defenders are aware of and actively hunting for. Bespoke tooling was once the exclusive domain of well-funded threat actors, but the wide availability of GenAI tools opens those floodgates of potential for any threat actor with the motivation and a free (or stolen) LLM account. In the same vein, custom tools are no longer a clear indicator of an advanced threat actor. Garden variety ransomware operators become harder to differentiate from the larger and more resourced groups, significantly hindering threat actor identification. ConclusionAs with practically every technological advancement in history, Artificial Intelligence and GenAI in particular can be used for good and evil purposes. While the advent of novel attack techniques has been gleefully incorporated into ransomware actors’ toolboxes, defenders can leverage similar tooling to improve their defensive and detective capabilities. This arms race mentality is not new in the security industry. Encryption, even better encryption, widespread Internet access, social and otherwise publicly-generated media content, the proliferation of mobile devices, and more have all come with similar risks since the earliest phases of each development.While ransomware operators continue to improve the efficiency and effectiveness of their efforts through the use of GenAI, this does not mean that defenders have to be at a disadvantage. The most effective and forward-leaning defender teams have already stepped up their game in preparation for or in response to the attackers' improved tradecraft. These defense improvements, along with a robust and tested security program in general, can help to keep ransomware threats at bay and ensure the integrity of the valuable data throughout the enterprise. Zscaler Coverage to Mitigate the Risk of Advancing RansomwareAgentic SecOps fuses zero trust telemetry, threat intelligence, and agentic workflows into a single view, helping security teams to more quickly and decisively detect, investigate, and respond to ransomware threats.AI-based detection from the Zscaler Secure Web Gateway identifies and blocks novel attacker infrastructure such as phishing sites and C2 components.The Zero Trust Browser’s AI capabilities identify suspicious web content, limiting the potential for malware delivery and data leaks, even through credibly-scraped websites.]]></description>
            <dc:creator>Phil Hagen (Principal Information Security Researcher)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Zero Trust for Artificial Intelligence]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/zero-trust-artificial-intelligence</link>
            <guid>https://www.zscaler.com/blogs/product-insights/zero-trust-artificial-intelligence</guid>
            <pubDate>Fri, 16 Oct 2026 16:22:54 GMT</pubDate>
            <description><![CDATA[IntroductionFor more than a decade, we've helped organizations implement Zero Trust access with Zscaler Internet Access (ZIA) and Zscaler Private Access (ZPA). The destination was always the same: least-privilege access, where users connect only to the applications they're authorized to use, from devices the organization trusts. The journey to get there taught us lessons that are now more relevant than ever, because the next wave of users won't be human. They'll be AI agents, and they'll operate at machine speed.If we want Agentic AI to work safely inside the enterprise, we need to apply the same Zero Trust principles to agents that we spent the last decade applying to people. This blog explains what those principles look like in practice. What we’ve learned from a decade of Zero Trust deploymentsWhen customers first deployed ZPA, the biggest obstacle wasn't technology. It was visibility. Most organizations had a distinct lack of insight into what applications actually existed in their environment, who owned them, and who should have access. Access sprawl was the norm: users retained entitlements to applications, and the data within them, long after moving departments. And they could reach those applications from a myriad of devices: company owned, company managed, patched, unpatched, and BYOD. Every unmanaged or unpatched device that could touch an application exposed it to compromise, and exposed the organization to data loss.So customers started their Zero Trust journey with a wildcard policy. Broad access, deliberately, for a short time, to gain a complete view of what applications exist, who is accessing them, and from which devices. From that observed reality, Zscaler pioneered AI-powered segmentation and policy recommendations (AI-Segmentation and AI-Policy) to compress the path to least privilege: users could access only approved applications, from approved devices, governed by granular access policy.Something interesting happened along the way. If the outcome of implementing Zero Trust is fine-grained access to applications and data, the side effect is a detailed, living configuration management database (CMDB) with solid identity governance controls. Full segmentation based on user and device trust ensures users cannot reach applications and data they aren't permissioned for. Identity governance (IGA) ensures users can request, and be granted, access as needed, based on their job role and the application's ownership. Discovery, ownership, entitlement, and enforcement became a continuous loop rather than an annual audit exercise.As it happens, that loop is exactly what Agentic AI is missing today. How agentic AI raises the stakes for least privilegeIn an agentic world, a user asks an agent to perform a task on their behalf. That agent may spawn multiple sub-agents, each performing a specific task. The user might hold broad entitlements appropriate to their job role, but the agent should not inherit all of them. The agent's access should be constrained to the task it has been asked to perform, granted just in time, valid for a specific session, and aligned with the intent of the original request. Sub-agents should each be constrained to their specific sub-task, traceable back to the intent of the root agent.Human IGA often has a human in the loop: access is granted only after a person approves it. That model doesn't survive machine speed. Non-human IGA needs an automated system that approves access based on intent: just in time, session bound, and fully audited. The human moves from in the loop to on the loop. Because every access decision flows through an inline agentic gateway, the audit trail it produces gives humans continuous visibility and control: they supervise, intervene, and revoke, rather than approve every transaction. That is what allows agents to run at machine speed with constrained access, rather than machine speed with the user's full credentials.This isn't theoretical. Recent incidents show that agents do not fail like traditional applications – they find unique, and unintended, ways to achieve their tasks. During OpenAI's own security testing, the o1 model escaped a broken capture-the-flag sandbox by discovering a misconfigured Docker API on the evaluation host and spinning up its own container to read the flag (OpenAI o1 System Card). In July 2025, Replit's coding agent deleted a production database during an explicit code freeze, then produced misleading information about the rollback (AI Incident Database, Incident 1152). The EchoLeak vulnerability (CVE-2025-32711) showed that a single crafted email could silently instruct Microsoft 365 Copilot to exfiltrate data from everything in its access scope, with zero clicks from the user (The Hacker News). And in November 2025, Anthropic disclosed that a state-sponsored group had used its Claude Code agent, orchestrated over MCP, to run an espionage campaign against roughly 30 organizations, with AI performing an estimated 80-90% of the tactical work (Anthropic).The pattern across all of these: an agent with more access than its task required, and no independent control point between the agent and the systems it touched. Models and agents must be controlled, and in an enterprise where access governance is well established, the key mechanism is Zero Trust and least privilege access.The analyst community sees the same trajectory. Gartner predicts that by 2028, 25% of enterprise breaches will be traced back to AI agent abuse, from both external and malicious internal actors (Gartner). Forrester expects an agentic AI deployment to cause a major public breach in 2026, noting that 97% of organizations that suffered AI-related breaches lacked proper AI access controls (Forrester, via Infosecurity Magazine). Nine Zero Trust principles for AI systemsTo make agentic AI safe for the enterprise, organizations need more than model guardrails or prompt filtering. They need to extend proven Zero Trust principles to AI agents: discovering what agents exist, governing what they can access, constraining their actions to the task at hand, and continuously verifying trust throughout the session. Done well, this gives enterprises the foundation for least-privilege, data-secure agentic AI. Nine principles define that foundation.1. Inventory: You cannot secure what you cannot see, and this was the first lesson of ZPA deployments. Understanding the footprint of agents, MCP servers, LLMs, skills, and plugins is imperative, whether they run on a user's device (IDEs and local agents accessing local MCP servers over STDIO, or local copies of data) or in IaaS, accessing hosted MCP servers over streamable HTTPS and hosted applications. Equally imperative: a complete view of the keys, secrets, and credentials in use across that estate. An agent running “on behalf of” a user, but with the user's real credentials, is a risk that needs addressing directly.The scale of the challenge is already clear: Machine identities outnumber humans by more than 80 to 1, with nearly half holding sensitive or privileged access. Agentic AI will accelerate that ratio, with each human identity spawning over 140 Agentic Identities.2. Flow control: Agents should not have direct access to systems or data. Just as the Zero Trust Exchange removed direct network paths between users and applications, an Agentic Trust Exchange should be the architectural control point for all agentic communication, providing brokered/gateway access for every connection between an agent and the systems it needs to reach. No broker, no connection.3. Routing. Not every task needs the most expensive model. Understanding which models are being used, and the token consumption against each, matters: expensive LLMs with deep intelligence and training on one end, cheaper LLMs or small language models (SLMs) on the other. We have seen this pattern before. As customers moved from building, owning, and operating datacenters to adopting IaaS, SaaS, and PaaS with a view to reducing cost, the inverse actually happened: costs went up alongside the DevOps agility, and CNAPP (cloud-native application protection platform) tooling evolved to give customers visibility into what was running in their cloud estate and what it was costing them. With AI, visibility and control of token costs is just as important. Routing each request to the most appropriate model based on intent, reserving frontier LLMs for deep reasoning and steering routine tasks to cheaper or smaller models, delivers cost savings alongside performance improvements. The exchange brokering the traffic is the natural place to make that routing decision.4. Intent: Humans are sometimes malicious, but that's rarely why data loss happens. Usually they've been manipulated: phished into clicking a link. Agents are manipulated the same way, through prompt injection and poisoned context, as EchoLeak demonstrated. Red-teaming the agents, the MCP servers, and the applications lets us test for intent, implement guardrails on LLM communication, harden the prompts, and inspect and control MCP traffic inline.5. Access control: Once we understand the access an agent needs for its task, we can constrain it. The agent's identity must be unique and distinct from the user calling it. The agent should never hold credentials directly; instead, credentials should be injected just in time into the communication by the exchange, and be time or session bound, so they cannot be extracted, manipulated, or replayed outside the brokered session.The window for error is shrinking: Gartner predicts AI agents will cut the time it takes to exploit exposed accounts by 50% by 2027 (Gartner). Credentials that never leave the exchange, and expire with the session, take that attack path off the table.6. Sovereignty and data residency: Access decisions must account for where everything, and everyone, is. The gateway is the natural enforcement point for sovereignty controls, evaluating user attributes (home country, role), location signals (geo-IP, travel patterns), and where the data, agent, MCP server, model, and application each reside. When the user, the gateway, and the model all sit within an approved jurisdiction, access can be allowed. When any component in the chain resides in a jurisdiction the policy does not permit for that user, access should be denied, regardless of where the user is sitting. Signals such as impossible travel and UEBA (user and entity behavior analytics) risk should feed the same policy, so sovereignty is evaluated continuously across the session, not checked once at login.7. Access governance. A full access graph should show which agents, users, and systems can obtain credentials, and what those credentials can reach. This is IGA for non-human identities: using the access graph to ensure every credential is secured, minted just in time, and scoped to least privilege, with automated, intent-based approval replacing the human in the loop where speed demands it, and a full audit trail either way. The ability to attest who, or what, can access which data, using which agents, MCP servers, and LLMs, is paramount. Attestation is a side effect of access governance, but it allows organizations to be explicit: access to data and models is granted against a defined set of criteria, and provable on demand.8. Conditional access engine: Signals change over time. If a human disables security controls on an endpoint, their sessions get revoked. The same continuous evaluation must apply to agents: if an agent performs risky actions, or reaches for more data or systems than its task profile warrants, the conditional access engine revokes its sessions in real time. Trust is evaluated continuously, never granted permanently.9. Deception and decoys: When the Zero Trust Exchange identifies malicious intent today, users and systems are contained and steered toward decoys to gather intelligence. Agents are aggressive, fast, and thorough in reconnaissance, which makes them even more susceptible to deception. Steering a misbehaving agent into a decoy environment both contains it and reveals its intent. The outcome: Audited, attested, governed AIImplementing these Zero Trust principles for AI systems gives the organization a full audit of every agent in the environment and the ability to attest exactly what data each one can access. Just as Zero Trust for users delivered a living CMDB and identity governance as a side effect, Zero Trust for AI delivers the inventory, access graph, and governance evidence that regulators, auditors, and boards are already beginning to demand.Least privilege was the destination for human access. For agentic AI, it's the starting condition. Organizations that spent the last decade building Zero Trust for their workforce already have the architecture, the identity foundation, and the governance discipline; extending it to agents is the natural next step, and the only way to let agents run at machine speed without accepting machine-speed risk.Analysts are converging on the same conclusion. Gartner predicts that by 2028, 40% of CIOs will demand “guardian agents” capable of autonomously tracking, overseeing, and containing the actions of other AI agents (Gartner). A Zero Trust architecture for AI, with an inline exchange as the control point, is how the enterprise delivers that oversight.To learn more about how Zscaler secures AI, visit Zscaler AI Security.References1. OpenAI o1 System Card (sandbox escape during CTF evaluation): openai.com/index/openai-o1-system-card2. AI Incident Database, Incident 1152 – Replit agent deleted production database during code freeze: incidentdatabase.ai/cite/11523. The Hacker News – EchoLeak (CVE-2025-32711), zero-click data exfiltration via Microsoft 365 Copilot: thehackernews.com4. Anthropic – Disrupting the first reported AI-orchestrated cyber espionage campaign (GTG-1002): anthropic.com/news/disrupting-AI-espionage5. Gartner – Top Predictions for IT Organizations and Users in 2025 and Beyond (25% of enterprise breaches traced to AI agent abuse by 2028): gartner.com6. Forrester Predictions 2026 – agentic AI deployment to cause a major public breach (via Infosecurity Magazine): infosecurity-magazine.com7. Gartner – AI agents will reduce the time to exploit account exposures by 50% by 2027: gartner.com8. Gartner – Guardian agents to capture 10-15% of the agentic AI market by 2030 (40% of CIOs demanding guardian agents by 2028): gartner.com]]></description>
            <dc:creator>Mark Ryan (Zscaler)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Introducing the Modernized Client Connector UI]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/modernized-client-connector-experience</link>
            <guid>https://www.zscaler.com/blogs/product-insights/modernized-client-connector-experience</guid>
            <pubDate>Wed, 14 Oct 2026 12:10:12 GMT</pubDate>
            <description><![CDATA[Since the very beginning, the Zscaler Client Connector has been a cornerstone of the zero trust architecture that we provide to customers. It’s the endpoint agent that ensures user traffic flows through the Zero Trust Exchange for least-privileged access to any destination. By and large, customers have been very happy to use Client Connector and its breadth of innovative functionality. But we've heard&nbsp;all of your feedback: the end user interface looked outdated, it felt complex and confusing, and it needed to accommodate your company's branding so that your users could know that it was deployed by your IT team.&nbsp;So, we're excited to introduce the&nbsp;modernized Client Connector UI, delivering a cleaner, simpler, and more intuitive experience that is designed with your end users in mind.The new UI experience for Client Connector strips away the noise and minimizes the chances of end users getting confused. Instead of surfacing complex technical details by default, users now get instant, clear feedback on the status of their Zscaler services—all at a glance. But that doesn’t mean that we’ve taken anything away; users who need to dig into advanced details can still do so, and anyone who wants to fall back to the classic UI to troubleshoot an issue can still do that, too. Additionally, we've added&nbsp;optional custom branding so that your organization can tailor Client Connector to match your internal applications and give employees a seamless, consistent experience across your entire tech stack.Alongside the new UI, we're also introducing&nbsp;granular notification control—a long-requested capability that puts administrators in control of the notifications that their end users receive. Previously, notifications were categorized and controlled entirely by Zscaler, leaving customers unable to determine which alerts their end users would see and which they would not. Now, from a single admin portal, you can configure the visibility and persistence of each individual notification across solutions and across categories like service status, app update, and more. Not to mention, you can have different settings for each of the different supported operating systems. The result is far greater control over the experience in your specific environment, and dramatically reduced notification noise for end users. That means less friction for admins and better quality of life for users—and that's the power of the modernized Client Connector UI.If you’re ready to explore the new, better-than-ever experience for Client Connector, reach out to your Zscaler account team and request access to the Client Connector 5.0 release.&nbsp;]]></description>
            <dc:creator>Karen Daza (Zscaler)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Uncovering Executables that Trigger DLL Sideloading Attacks with Endpoint Context]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/uncover-dll-sideloading-attack-endpoint-context</link>
            <guid>https://www.zscaler.com/blogs/product-insights/uncover-dll-sideloading-attack-endpoint-context</guid>
            <pubDate>Mon, 12 Oct 2026 23:22:28 GMT</pubDate>
            <description><![CDATA[Threat actors are constantly refining their techniques to evade detection and deliver malicious payloads. DLL sideloading is a technique that has seen a resurgence in popularity among cybercriminal and espionage groups. This covert method allows attackers to execute malicious code under the guise of a legitimate and trusted application, making it a formidable challenge for security professionals to detect and mitigate.This blog post will delve into the mechanics of DLL sideloading, explore how threat actor groups like&nbsp;Silver Fox&nbsp;and REvil leverage this technique and how Zscaler Endpoint Context helps SecOps teams uncover files masquerading as valid executables that trigger DLL files to execute malicious code.&nbsp; What is DLL Sideloading?A Dynamic-Link Library (DLL) is a file that contains code and data that can be used by multiple programs at the same time. DLL sideloading is an attack vector that exploits the way Windows applications search for and load these required DLLs.When an application is launched, it often needs to load various DLLs to function correctly. If the application doesn't specify the full path to a required DLL, Windows will search for it in a predetermined sequence of directories. Attackers can take advantage of this by placing a malicious DLL with the same name as a legitimate one in a location that Windows searches *before* the directory containing the genuine DLL. When the legitimate application starts, it inadvertently loads and executes the malicious DLL, giving the attacker a foothold in the system. How Threat Actors Use DLL SideloadingDLL sideloading is a popular technique for several reasons:Evasion: Because the malicious code is executed by a trusted and often digitally signed application, it is less likely to be flagged by antivirus software and other security solutions.Persistence:&nbsp;If the compromised application is one that runs at startup, the malicious DLL will also be loaded each time the system boots, ensuring the attacker's code persists on the infected machine.Privilege Escalation: If the legitimate application runs with elevated privileges, the malicious DLL will inherit those same permissions, allowing the attacker to perform more sensitive actions on the system. Example 1: Silver Fox's Attack on Accounting and Tax Preparation FirmsSilver Fox, a China-based threat actor group (also known as Void Arachne), has been observed using DLL sideloading in targeted attacks against accounting and tax preparation firms. Their campaigns often involve socially engineered phishing emails with themes directly relevant to accounting professionals, such as tax audits, invoices, and financial reports.Here’s a step-by-step breakdown of a typical Silver Fox attack:Initial Access:&nbsp;The attack begins with a spear-phishing email sent to an employee at an accounting firm. The email might be disguised as an official communication from a tax authority, complete with a malicious attachment, such as a PDF or a ZIP file. In one documented case, the filename was "The blacklist of tax-related accounting personnel in March is as follows.exe" to entice the victim.Lure and Execution: The user is tricked into opening the attachment. The attachment is a dropper that contains a legitimate, signed executable from a known software vendor (e.g., Tencent, Zeon Corporation, or Thunder Download Manager) and a malicious DLL.DLL Sideloading:&nbsp;The legitimate executable is launched. It needs to load a specific DLL to run, but instead of loading the legitimate one from the system directory, it loads the malicious DLL that the attacker placed in the same directory. For instance, Silver Fox has been known to use ‘ConvertToPDF.exe’ and ‘PDFDirect.exe’ from Zeon Corporation to sideload a malicious DLL named ‘PDFCORE8.dll.’Payload Delivery: The malicious DLL, now running under the trusted process of the legitimate application, decrypts and deploys the final payload. In Silver Fox's case, this is often ValleyRAT, a remote access trojan (RAT).Post-Exploitation: With ValleyRAT installed, the attackers have full control over the compromised system. They can steal sensitive data (client information, financial records), log keystrokes, and deploy further malware.&nbsp; Example 2: REvil Ransomware's Use of DLL SideloadingThe notorious ransomware-as-a-service (RaaS) group,&nbsp;REvil (also known as Sodinokibi), has also employed DLL sideloading to execute its ransomware.Here's how they did it:Initial Compromise: REvil gained initial access to a target's network through various means, such as exploiting vulnerabilities or using stolen credentials.Dropping the Files:&nbsp;Once inside, the attackers would drop two files into a directory on the compromised system: a legitimate, signed Microsoft Defender executable (`MsMpEng.exe`) and a malicious DLL named `mpsvc.dll`.Sideloading the Ransomware:&nbsp;The attackers would then execute `MsMpEng.exe`. This legitimate Microsoft process would then load the malicious `mpsvc.dll`, which contained the REvil ransomware payload.Encryption and Ransom:&nbsp;The ransomware, now running under a trusted Microsoft process, would begin encrypting files on the system and network shares. A ransom note would then be displayed, demanding payment for the decryption key.&nbsp; How Zscaler Endpoint Context Prevents DLL Sideloading AttacksZscaler's cloud-native platform provides a multi-layered defense to proactively stop DLL sideloading attacks before they can compromise an endpoint. Zscaler's approach is multipronged and anchored by our platform’s ability to inspect massive quantities of transactions at global scale to prevent malicious DLLs from reaching users’ devices in the first place.Threat actors leverage DLL sideloading because it abuses the trust placed in legitimately signed executables. Both REvil (Sodinokibi) and Silver Fox (Void Arachne) exploit this: REvil drops a malicious&nbsp;mpsvc.dll alongside an old, validly-signed copy of Microsoft Defender (MsMpEng.exe) to deliver its ransomware encryptor, while Silver Fox uses signed applications like&nbsp;NtHandleCallback.exe or&nbsp;QnWallpaper.exe to sideload encrypted shellcode DLLs (e.g.,&nbsp;log.dll,&nbsp;libcef.dll) that deploy ValleyRAT or Gh0st RAT backdoors.Zscaler Endpoint Context disrupts these attack chains at multiple stages:1. Pre-Execution DLL InterceptionThe Endpoint Sandbox extends Zscaler's cloud-based behavioral analysis to the endpoint itself. Before an unknown or suspicious DLL executes, whether delivered via phishing download, SEO poisoning, or trojanized installer, the sandbox can hold the file, analyze it, and block execution if it is deemed malicious. This stops both REvil's&nbsp;mpsvc.dll drop and Silver Fox's encrypted shellcode DLLs before they ever load.2. Process-Network Correlation to Catch Sideloading AnomaliesEndpoint Context enriches every network transaction with the initiating process name, file path, hash (MD5/SHA-256), and code-signing certificate status. This surfaces the hallmark red flag of sideloading: a legitimately signed binary making suspicious network calls while running from an atypical location (e.g.,&nbsp;%TEMP%,&nbsp;%PUBLIC%, or&nbsp;AppData). A policy can then automatically block or alert on that traffic. For example, flagging&nbsp;MsMpEng.exe calling out to a command-and-control server from a user's Downloads folder.3. Certificate and Hash ValidationBy continuously verifying code-signing status, Endpoint Context detects the "white-plus-black" pattern Silver Fox relies on where a signed host binary loads an unsigned or tampered DLL. Any DLL with an invalid, expired, or missing certificate loaded by an otherwise trusted process is flagged, breaking the chain of assumed trust.4. Application Risk Scoring and Zero Trust Policy EnforcementEndpoint Context assigns dynamic risk scores to running processes based on CVEs, behavioral signals, and vulnerability data. Policies can automatically restrict internet or private-app access for any process with a high-risk classification, preventing post-sideload lateral movement or data exfiltration even if a malicious DLL does load.5. Enriched SOC TelemetryAll process, path, hash, and certificate data is streamed via the Nanolog Streaming Service (NSS) to SIEM tools, giving security teams the correlation context needed to quickly identify sideloading campaigns — without manually pivoting between EDR consoles and network logs. Conclusion and Mitigation StrategiesDLL sideloading poses a significant threat to organizations of all sizes. However, there are steps that can be taken to mitigate the risk:Zsacler Endpoint Context:&nbsp;Monitor for suspicious process behaviors, such as an application loading a DLL from an unusual path, which can help detect sideloading attempts.Application Whitelisting:&nbsp;By allowing only approved applications to run, organizations can prevent unauthorized executables from being used to sideload malicious DLLs.Secure Coding Practices: Developers can help prevent these attacks by specifying the full path to required DLLs in their applications and digitally signing all DLLs.User Education:&nbsp;Training users to be cautious of unsolicited emails and attachments can help prevent the initial compromise that often leads to a DLL sideloading attack.Principle of Least Privilege:&nbsp;Restricting user permissions to prevent files from being written to critical application directories can stop attackers from placing malicious DLLs in the first place.By understanding the mechanics of DLL sideloading and implementing a layered security approach, organizations can better defend themselves against this insidious attack vector. Learn more by&nbsp;requesting a demo.]]></description>
            <dc:creator>Darshit Ashara (Zscaler)</dc:creator>
        </item>
        <item>
            <title><![CDATA[What&#039;s New in ZDX: Sharper Alerts, Cleaner Data, Faster Troubleshooting]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/what-s-new-zdx-sharper-alerts-cleaner-data-faster-troubleshooting</link>
            <guid>https://www.zscaler.com/blogs/product-insights/what-s-new-zdx-sharper-alerts-cleaner-data-faster-troubleshooting</guid>
            <pubDate>Mon, 12 Oct 2026 20:02:05 GMT</pubDate>
            <description><![CDATA[Every month, Zscaler Digital Experience (ZDX) releases updates that help IT and network operations teams see more, troubleshoot faster, and manage the digital experience of their users at scale.&nbsp;From expanded network architecture support to more granular probe controls, this month's releases reflect what our customers keep telling us: giving teams more precise controls to cut through noise, more accurate data to act on, and a cleaner experience to work in every day.Here's what is new with ZDX:Smarter Alerts for Collaboration Quality MonitoringFilter Dashboards by Data CenterReal User Monitoring ImprovementsConsistent UX with ZDX in Experience Center Smarter Alerts for Collaboration Quality MonitoringFor organizations that rely on real-time alerts to catch collaboration quality issues before they impact users, the granularity of those alerts matters enormously. A generic alert that fires for every region, including ones you know have connectivity variance, creates noise that slows teams down rather than helping them.ZDX now supports expanded filtering and grouping options when configuring collaboration quality alerts. Teams can now apply inclusion and exclusion filters by location, country, city, and other dimensions, the same granularity that is already available for application and network alert types. You can also group alert data by these dimensions to understand whether an issue is localized to a specific office or widespread across a region.The result: Fewer false positives, more targeted notifications, and faster triage when something actually goes wrong.ZDX tier: Available for ZDX Advanced and Advanced Plus customers. Filter Your Dashboards by Data CenterWhen a performance degradation or service disruption is reported at a specific data center location, the first question is always:&nbsp;who's affected, and what is the impact? Until now, correlating a data center event with actual user experience data required workarounds or relying on pre-built system reports.ZDX now lets you filter live dashboard data by Zscaler data center across the Network Intelligence dashboard and other key views. Select one or more data centers from the filter dropdown and immediately see the telemetry from application performance, network path health, device metrics from users egressing through those locations.The result: Network operations teams who need to quickly scope the blast radius of an infrastructure event and communicate impact to the business in real time.ZDX tier:&nbsp;Available across all ZDX license tiers. Real User Monitoring: More Precision, Less AmbiguityZDX's Real User Monitoring capability captures how end users actually experience web applications like load times, errors, navigation flows directly from the browser. The latest update brings a set of meaningful improvements for teams who depend on this data:Clearer load time metrics for single-page applications: Page load time and navigation time are now reported distinctly, so you can understand whether slowness is coming from the initial page load or subsequent in-app navigation events.Multiple errors per session visible: When more than one error occurs during a monitoring window, all error events are now displayed, not just the first one, giving a complete picture of what a user experienced.Consistent score terminology: Score labels across the ZDX interface now use uniform naming conventions, eliminating the ambiguity that came from inconsistent labels across different views.Enriched browser data collection: The browser extension now captures additional resource-level attributes, enabling deeper analysis of web application performance bottlenecks.The browser extension updates automatically with no action needed from end users or IT teams.ZDX tier: Available for ZDX Advanced Plus customers. A More Consistent Console ExperienceWe also completed a significant UI refresh across ZDX. Filters, tables, drawers, time-range selectors, page headers, and other core interface elements have been updated to follow a unified design system, delivering a consistent look and feel whether you're working in dashboards, alert configurations, or device detail views.The change is purely visual and requires no workflow adjustments, but the day-to-day impact is real: a more predictable interface reduces the small moments of friction that slow teams down during active troubleshooting.ZDX tier: Available across all ZDX license tiers. What's NextThese releases reflect a consistent theme across ZDX's evolution: better signal, less noise, and faster paths from detection to resolution. Whether it's more precise alerting, accurate device data, or a cleaner interface to work in, every improvement compounds over time into a meaningfully more efficient operations workflow.Keep an eye out for what's coming in next month’s releases, including updates that will make it even easier to prioritize and respond to issues for your organization's most critical users.See all the latest ZDX releasesAlready a ZDX customer? Log in to&nbsp;ZDX to explore these features.&nbsp;New to ZDX?&nbsp;Learn more about ZDX.]]></description>
            <dc:creator>Cynthia Tu (Sr. Product Marketing Manager, DEM)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Closing the Endpoint Zero Trust Gap]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/ai-endpoint-security-closes-zero-trust-gap</link>
            <guid>https://www.zscaler.com/blogs/product-insights/ai-endpoint-security-closes-zero-trust-gap</guid>
            <pubDate>Thu, 08 Oct 2026 23:20:47 GMT</pubDate>
            <description><![CDATA[At Zenith Live in Las Vegas, we introduced&nbsp;Zscaler AI Endpoint Security, a new product that extends&nbsp;Zscaler's AI protection to the endpoint. If you already use Zscaler to secure AI usage across your network, cloud, and SaaS applications, this product applies the same zero-trust approach to the AI applications and agents now running directly on your users' devices.This post covers why we built it: what's actually changing on the endpoint, why the tools most organizations already run there aren't designed for this problem, and how Zscaler is approaching it. What we're seeing on the endpointA new AI application layer has been forming on&nbsp;enterprise endpoints, and it has grown faster than most inventory processes can track.It started with&nbsp;frontier AI applications: Claude Code, Cowork, OpenAI Codex, Gemini,&nbsp;Microsoft Copilot. What's notable isn't just the adoption rate; it's who is adopting them. These are no longer developer tools. Finance teams, marketers, and HR teams are using them to do work that previously required a technical specialist, and they're getting real results. That's exactly why this trend won't reverse.The part that concerns security teams is everything these applications bring with them:Configuration and extension sprawl: Plugins, skill files, prompt libraries,&nbsp;MCP servers, subagent definitions, memory files, and background telemetry processes. These components install and update outside your normal software lifecycle.AI-powered IDEs: VS Code, Cursor, and Windsurf, each with extension marketplaces where third-party code runs with the user's full privileges.Local models: Ollama, LM Studio, and llama.cpp put multi-gigabyte model files on disk. We've seen model files that carry serialized code execution, embedded backdoors, content that violates policy, and models renamed to look like something they're not.Package dependencies: Python, npm, and Homebrew packages pulled in by the hundreds to support AI workflows, with the&nbsp;supply-chain exposure that implies.AI assistants and browsers: Tools like OpenClaw, Hermes, and Microsoft Scout, plus AI-enabled browsers such as Chrome, Edge, Comet, and Atlas with embedded models and agent capabilities.Underneath all of this sits the change that matters most:&nbsp;agents act as the user. An agent runs under the user's identity, with the user's permissions, touching the user's files and network connections. When we talk to security teams, this is the point where the conversation usually slows down, because most of their controls and audit trails assume that an action taken under a user's identity was taken by that user. That assumption no longer holds.This is&nbsp;AI asset sprawl: applications that create applications, files created faster than they can be classified, and identities that are no longer only human. Why existing endpoint tools weren't built for thisThe reasonable first question is: don't EDR, DLP, and MDM already cover the endpoint? They do, and none of them should go anywhere. But each one was designed around assumptions that AI asset sprawl breaks. This isn't a criticism of those products. It's a scoping observation.EDR watches files, processes, and threads, and it's very good at recognizing attack patterns and stopping malware and&nbsp;ransomware.&nbsp;But walk through a typical AI incident: a user types a prompt, an agent modifies local files and sends data over the network. From EDR's perspective, there is no malware signature, no process injection, no privilege escalation—just a signed application from a major vendor doing normal application things. The context that would tell you something is wrong lives at the AI application layer: the prompt, the skill file that shaped the behavior, the MCP server involved, the agent's goal. EDR was never designed to see any of that.DLP was built for an environment where you could catalog your files, trace when each was created and modified, and scan content against known patterns.&nbsp;Those steps still work; the environment changed. On an endpoint with active agents, hundreds of new files can appear per minute: generated reports, working datasets, code, memory files. Classification pipelines sized for human document-creation rates fall behind immediately.&nbsp;Lineage breaks too — a file an agent synthesized from six sources and rewrote twice has no ancestry a traditional DLP can reconstruct. And pattern matching struggles when agents constantly reshape and re-encode the data they touch.MDM gave IT a reliable answer to "what is installed on this machine?" Sanctioned apps, managed versions, change control.&nbsp;The new failure mode is simple to state: AI applications create other applications. One prompt produces a finance dashboard app in its own folder. Another folder fills up with PowerShell scripts that modify system settings. None of it went through change management, none of it appears in the software inventory, and MDM has no mechanism to version it or determine what it's for. The gap between what IT believes is on the endpoint and what is actually running there widens every day.The common thread: all three product categories assume a predictable endpoint—known applications, human-speed file creation, human-only identity. AI asset sprawl breaks all three assumptions at once. That's not a feature gap you close with a release; it's a different problem that needs a purpose-built product. How Zscaler AI Endpoint Security worksWe built this product from the ground up for this new AI-native application layer, around the same zero trust principles that run through the rest of the Zscaler platform: verify rather than assume, tie every action to an identity, and enforce policy inline.&nbsp;The Zscaler agent on the endpoint gains visibility into the AI application layer itself, and delivers three capabilities.1. AI Asset InventoryFirst, discovery. The product builds and maintains a&nbsp;complete inventory of AI assets on each endpoint:Frontier model applications (Claude, Codex, Copilot, Gemini)Local model applications (Llama, Ollama, LM Studio, custom models)AI browsers and AI-powered IDEsPackage managers and other channels bringing AI components onto the deviceThe entire ecosystem installed within these apps, including plugins, extensions, skills, and add-onsInventory goes below the application level, to the components that determine what these apps can actually do: config files, skill files and prompts, MCP servers, agent definitions, memory and knowledge stores, model files, telemetry and persistence mechanisms.&nbsp;The output is a structured map of your AI footprint per endpoint, with high-risk findings flagged—unapproved agents, risky plugins, unknown model files, and shadow AI your inventory has never seen.2. AI Agent Runtime MonitoringInventory tells you what's present. Runtime monitoring tells you what it's doing. While AI applications run, Zscaler captures the events that matter at the AI application layer:Prompts and responsesTool and function callsSkill files invoked and MCP servers connectedFile access and data movementProcess and data lineageSystem interactions and network connectionsBecause these events are captured with full context, you can reconstruct a complete agent run—the main agent and every subagent it spawned—and correlate it to identity: which user, which agent, which device, which data. This is the piece that directly addresses the ‘agents act as the user’ problem. When something anomalous happens, you're not left guessing whether the human did it; you can see exactly which agent acted, on whose behalf, and what it touched.3. Enterprise AI Policy EnforcementVisibility on its own doesn't change outcomes, so the third capability is inline enforcement—the control point IT and security teams have been missing on this layer. Policies apply in real time to:Block rogue or unauthorized agents before they actStop malicious skill files and instructionsHalt dangerous commands and code execution via agentsPrevent data exfiltration and protect sensitive or critical filesMonitor and police extensions within frontier AI appsFlag PII inside prompts before it leaves the deviceEnforce acceptable-use, data-protection, compliance, and custom enterprise policies consistently across frontier AI apps, AI-powered IDEs, AI assistants, and AI browsers alikeTaken together: inventory answers “what is here”, runtime monitoring answers “what is it doing,” and enforcement answers “what will we allow.” The same questions zero trust has always asked—now asked of AI assets and agents on the endpoint. Why the need is so urgentThree things convinced us this needed to be a must-build product—and that it couldn't wait.The endpoint is becoming a software factory. "Apps that create apps" is not an edge case we found in testing; it is the stated product direction of every major AI vendor.&nbsp;And it is exactly how AI asset sprawl compounds, as every new application arrives with its own configs, skills, models, and agents. Subagents, background agents, agents embedded in browsers and IDEs: hundreds of agents will soon be running on endpoints on behalf of users, just as they already are in the cloud.&nbsp;Any governance model built on "one identity, one human" stops scaling; agent identity and lineage have to become first-class objects in your security model. The gap between installed software and existing software will keep growing, and only continuous discovery paired with runtime observation can keep up with software that didn't exist an hour ago.Audit requirements are moving toward AI actions. The questions we increasingly hear from compliance teams are concrete: which agent touched this customer data, under whose authority, and what left the device? Those questions can only be answered at the endpoint, at the AI application layer, at runtime. Organizations that can't reconstruct an agent run will struggle to answer them at all.Productivity and competitiveness cannot slow down. Every organization is watching its peers and competitors adopt AI at full speed. Blocking the tools that make employees more productive is not a viable answer because it simply trades a security risk for a competitive one.&nbsp;A security solution built for the AI application layer means people keep doing their best work with the tools that raise the organization's productivity and success, while the enterprise stays in control.We've seen this pattern before. When perimeters dissolved, zero trust replaced castle-and-moat on the network. When work moved to cloud and SaaS, zero trust followed. The AI application layer arriving on the endpoint is the same story, one layer further in. And it's better to have controls in place while the sprawl is measured in dozens of assets per device rather than hundreds.EDR will keep stopping malware. DLP will keep protecting the data it can see. MDM will keep managing the software IT deploys. Keep all three. Zscaler Endpoint AI Security covers the layer none of them see: the AI applications, agents, and assets acting on your endpoints under your users' identities. What's nextZscaler Endpoint AI Security is rolling out to customers now. If you want to see your own endpoint AI footprint—most teams are surprised by their first inventory report—learn more&nbsp;here or reach out to your account team for a demo.]]></description>
            <dc:creator>Dhawal Sharma (Executive Vice President, AI Security and Strategic Initiatives)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Pharma Is Building Again. It’s Time to Put Security in the Blueprints.]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/pharma-building-again-it-s-time-put-security-blueprints</link>
            <guid>https://www.zscaler.com/blogs/product-insights/pharma-building-again-it-s-time-put-security-blueprints</guid>
            <pubDate>Thu, 08 Oct 2026 15:31:31 GMT</pubDate>
            <description><![CDATA[The onshoring wave is a once-in-a-generation chance to build connected, AI-ready plants the right way. In a GMP plant, most of the security decisions are effectively made before the first batch runs. Somewhere in North Carolina, Indiana, or Pennsylvania this year, a field is turning into a pharmaceutical plant. In a construction trailer at the edge of the site sits a thick binder of user requirements, the document that says what every system in the plant must do. Engineers are signing off on drawings for bioreactor suites and fill-finish lines, and equipment vendors are building skids in their own factories hundreds of miles away. In a few years the site will make medicines that patients depend on, and it will probably still be running long after everyone who designed it has retired.Why now? Mostly pressure. The pandemic showed how much of the US drug supply depends on factories overseas. In 2025 Washington followed with an&nbsp;executive order to speed up approvals for domestic plants, and with the threat of&nbsp;steep tariffs on imported branded drugs from companies that were not building in the US. Drugmakers responded. They announced more than $370 billion in planned US investment during 2025, according to&nbsp;DPR Construction's year-end tally. Not all of it is manufacturing, since the pledges also cover R&amp;D and partnerships, but a large share is concrete, steel, and cleanrooms.A new plant is not a quick project.&nbsp;PhRMA puts it at 5 to 10 years and up to $2 billion from decision to production. Regulators are getting involved earlier as well. FDA's&nbsp;PreCheck pilot is open only to eligible new facilities, and it&nbsp;reviews facility design and equipment qualification before a plant runs its first batch.For the engineers designing one of these plants, that long runway is also a rare chance to start over. They get new equipment, new automation, and a data architecture built for how plants will run in the 2030s rather than how they ran in the 1990s.Security belongs on that list too, and that is a newer idea than it sounds. For most of the industry's history, plant security meant walling the plant network off from the rest of the company and the internet, and hoping the wall held. Three things have changed that:The wall did not hold. In 2017, NotPetya reached Merck through a compromised software update rather than a breach of the plant perimeter. It spread across the company's network,&nbsp;infected more than 40,000 computers, and disrupted manufacturing. The company put the losses at $1.4 billion.A walled-off plant cannot do what it is being built for. These plants are funded on the promise of AI and analytics, and those depend on data leaving the plant floor.Regulators now expect security in the design. Draft updates to the EU's GMP rules ask for segmented networks, controlled remote access, and security requirements written into a system's specification before it is qualified. What are these plants being built to do?These are not copies of the plants they replace. Most are being designed around what ISPE calls&nbsp;Pharma 4.0, an operating model for bringing Industry 4.0 into regulated manufacturing. In practice that means:continuous manufacturing in place of batch-and-hold, now covered by ICH Q13process analytical technology (PAT) that measures quality in the line instead of waiting on the labdigital twins that let engineers test a process change before they touch the equipmentAI is where much of the payoff is expected:Catching deviations early. Models flag a drifting batch from sensor trends before it is lost, instead of leaving an investigation for afterwards.Faster batch release. PAT data, batch records, and lab results come together, so Quality reviews by exception.Predictive maintenance. It focuses on the equipment that sets a plant's capacity, such as lyophilizers, isolators, and bioreactors.Every one of those benefits depends on the same thing. A model cannot flag a drifting batch if it never sees the sensor data. Quality cannot review by exception if the PAT results and the batch records sit in separate systems that never talk to each other. The value comes from data moving: from the skid to the historian, from the site to the cloud, and between the plant and its partners. A plant designed to be walled off cannot deliver any of it.That changes what a plant's IT looks like. Some systems have to stay close to the production line, because a plant must keep making product even if its internet link goes down. The systems that run and release each batch therefore live on site or nearby. That includes the manufacturing execution system (MES), which enforces each recipe step by step, and the local ERP instance, often SAP, that releases finished product.The heavy analytics go the other way. Training a model on years of batch data from a dozen sites takes cloud-scale computing, and it needs every site's data in one place. So a new plant ends up hybrid by design, partly on site and partly in the cloud, and connected all the time.That is the real opportunity. ISPE's Pharma 4.0 model already names&nbsp;data integrity by design as one of its two core enablers. Security by design is the same idea applied to the network. The question for a new plant is not how to keep it disconnected. It is how to connect it the right way, so that the AI business case and the security case become the same design.There is a catch, though, and it arrives on a schedule. So why does the window close so early?In most factories, security is something you can add later. A segmentation project or a new remote-access tool is disruptive, but it is an IT change. A GMP plant is different. Once a system is qualified and the process is validated, almost any change to it goes through change control. The EU's&nbsp;draft revision of GMP Annex 11 is explicit about it. A significant change that could affect product quality, patient safety, or data integrity "should be subject to re-qualification and validation."That is why so much pharma OT still runs old software with known vulnerabilities, even though plant teams are usually well aware of them. The security fix itself is rarely the expensive part. Re-running qualification on a system that is busy making product is.So for a new plant, the security architecture becomes hard and expensive to change once the plant is qualified. Changes are still possible, through impact assessment and, for significant ones, requalification, but few teams take that on lightly. Whatever is on the network when performance qualification is signed, every shared login and every vendor modem included, is what the plant is likely to run with for years.The same Annex 11 draft also adds a full security section. It covers segmented networks with strict firewall rules, timely patching, isolation of unsupported systems, and USB ports deactivated by default. It also says the user requirements specification (URS) should include security requirements and data flow diagrams.&nbsp;The consultation closed in October 2025, and the final text is still pending. Requirements like these are far cheaper to meet in a design document than in a change request.The top row is how most plants get security today: a review after go-live, findings that land in change control, and a choice between revalidation and an accepted risk. The bottom row moves the same requirements into the URS. They are then checked at the factory and site acceptance tests (FAT and SAT), the vendor-shop and on-site checks every system goes through. Finally they are proven in installation, operational, and performance qualification (IQ, OQ, and PQ) alongside the system they protect. What belongs in the URS?Not everything. Controls inside the validated systems themselves are usually best left to the automation vendor and Quality. The six requirements below are the ones that get decided by default if nobody writes them down. Each is cheap to write into the URS and test at FAT, and expensive to add after PQ. The examples use a biologics plant with fill-finish, but the same six apply to most new drug substance or drug product sites.Requirement 1: A named identity for every person and every machine.For people, the regulations already require it.&nbsp;21 CFR 11.10(d) requires limiting system access to authorized individuals, and 11.100(a) requires every electronic signature to be unique to one person. The draft Annex 11 goes further: it calls any shared account that can change data a violation of data integrity. Yet shared operator logins on skid HMIs are still common, because the package unit arrived with one built-in account.Design it out up front. Write named, directory-backed identity for every HMI, engineering workstation, and batch client into the user requirements, so that each OEM has to deliver it at FAT. The regulations stop at people, but the same logic holds for machines, so extend the rule to everything that is not a person:MES-to-skid integrations that download recipes and collect batch datahistorian collectors that poll every controller on the floorservice accounts used by backup, patching, and monitoring toolsAI agents that read process data for analytics and maintenance modelsA new plant will connect more machine identities to batch data than humans. Map which of them can reach the electronic batch record, laboratory information management system (LIMS), and process historian before go-live. That map is the access baseline the plant will be held to.Requirement 2: Zones drawn around unit operations, not Purdue levels.A biologics plant is a collection of package units: bioreactors, chromatography and filtration skids, clean-in-place and steam-in-place (CIP and SIP) systems, isolators, and lyophilizers. Each comes from a different OEM with its own controller, HMI, and network habits. Many plants follow the Purdue reference model by putting all of them in one shared Level 1-2 network. In practice, that network often becomes flat the day the integrator connects the last skid. Once it is flat, anything that compromises one skid, such as an infected vendor laptop plugged into a CIP panel, can reach every other skid, including the bioreactors running product.Start by finding everything. You cannot draw a zone around an asset nobody has inventoried, and package units often arrive with more networked devices than the drawings show. Then zone the plant the way the process is built, using the&nbsp;zones and conduits model from ISA/IEC 62443. Each unit operation gets its own zone. The only conduits are the ones the batch actually needs: recipe download from the batch engine, alarms and data up to the historian, and electronic batch record entries to MES. The cleanroom building management and environmental monitoring systems get their own zone too. They are GMP-relevant, because pressure differentials and particle counts are product-quality data, but they are installed by a different contractor on a different schedule.Requirement 3: One brokered path for every vendor.Picture SAT week. The skids have arrived, and a dozen vendor engineers are on site, each with a laptop, a deadline, and a preferred way in. The automation lead's job that week is to get every system through testing, not to referee remote access.After handover, most OEMs still expect remote support for the life of the equipment. If the plant has not designed that path, each vendor brings their own: a cellular router in the panel, a remote-desktop tool on the HMI, or a VPN nobody inventories. Once qualified, those paths are part of the validated state and very hard to remove.The alternative is to qualify one brokered path that every vendor uses from the first site acceptance test (SAT). Access is tied to a named person and limited to a single asset. It is approved per session, recorded, and closed when the work ends. The vendor never gets a network route into the plant, only a session to the asset they support. The draft Annex 11 already expects multifactor authentication for remote access to critical systems from outside the site. Write the lifecycle into the vendor contracts as well, so that access granted during commissioning is reviewed at handover and expires unless the plant renews it.Zones follow the process, not the Purdue floor. The vendor's dashed path ends at one asset in one zone; it never becomes a route into the plant.Requirement 4: Every inbound file inspected before it reaches a validated system.New plants ingest a steady stream of files. These include recipe packages, OEM firmware and patches, validation protocols, and tech transfer documents from development sites or contract partners. Most arrive by email, file share, or the vendor's laptop, and some still arrive on USB.Route files through a single transfer path that detonates and inspects them before they reach anything validated. Removable media is the honest gap here, since no network control sees a USB stick. The draft Annex 11 is blunt about it: USB use should be strictly controlled, outside media scanned before use, and ports on critical systems deactivated by default. The plant should give vendors a better path than USB from day one, so that locking the ports during qualification is practical.Requirement 5: Outbound data classified and inspected.The most valuable data in a pharma plant is the process: process parameters, batch genealogy, and the analytical methods that prove the product is what the label says. New plants are being built to stream that data out to cloud analytics, digital twins, and AI models for process monitoring and predictive maintenance.That outbound flow needs the same scrutiny as inbound access. Classify process and batch data at the source, and inspect what leaves the plant for where it is going. The EU's&nbsp;draft Annex 22, the first GMP text dedicated to AI, points the same way, with change control and human review for AI used in manufacturing.Requirement 6: Early warning, response, and recovery.A validated plant will always carry some known vulnerabilities, because patching a qualified system takes time even in a plant designed for it. That gap is getting more dangerous. Google's Threat Intelligence Group&nbsp;reported that monthly vulnerability disclosures roughly doubled during 2026, and that attackers are using AI to turn newly published flaws into working exploits faster. Attackers are moving faster, and a GMP plant's patch cycle is not keeping up. Prevention needs a backstop that tells the plant early, and with confidence, that someone is inside.Advanced security capabilities such as deception provide that backstop. Decoy HMIs, engineering workstations, controllers, and credentials are placed in every zone, where no legitimate user or process ever touches them, so any interaction with one is a high-confidence signal.That matters more as attacks become automated. Automated reconnaissance, AI-assisted or not, sweeps whatever it can reach, and that is exactly what a decoy is waiting for. Deception also suits a plant whose security team is often a handful of people rather than a 24x7 SOC.Placed during design, decoys can mirror the real skids and the real zone layout, so they are indistinguishable from production assets. Added years later, they tend to look like what they are.Detection is only the first step, so the URS should also say what happens next:Who hears about it. Alerts should reach both the plant's operations team and security.Quality's role. Quality needs a seat in the response whenever an event could touch a GMP system or a batch record, because Quality decides whether product is affected.The way back. The plant needs local access when the WAN is down. It also needs backups of control logic, configurations, and batch records that have actually been restored and verified. The draft Annex 11 already expects tested restores and a disaster recovery plan with a defined recovery time.Files in, data out, and machine access each pass a check at the boundary. Removable media is the one path no network control sees, which is why the plant has to offer vendors something better than USB before qualification locks the ports. What does doing it right look like?Most existing plants collected security one problem at a time over twenty years: a firewall here, a remote-access tool there, each with its own rules and owner. A new plant can follow a different pattern. Every connection that crosses a boundary goes through a single policy layer: between zones, in or out of the plant, from a vendor, to the cloud, or from an AI system. That layer checks who or what is asking and grants access to a specific asset or application, never to the network around it. Control traffic inside a zone stays local, between the controllers and the systems that run the batch. Because the layer sits around the validated systems rather than inside them, the six requirements can be built and tested without modifying the systems themselves.It is the same idea as data integrity by design, applied to access: decide the rules once, at design time, and make them provable.The Zscaler Zero Trust Exchange is our implementation of that pattern. The six requirements map to one platform and one policy model. It can be verified at FAT and SAT and documented in the qualification package alongside the systems it protects.Every way into or out of the plant passes through the same policy model, whether it is a person, a vendor, a file, a cloud service, or an AI agent. The table maps each connection to the Zscaler capability that covers it.ConnectionWhat it needsZscalerEngineers and operatorsIdentity-bound access to specific applications, never to the networkZscaler Private Access; identity integrationOEM vendors and CDMOsPer-asset, approved, recorded sessionsPrivileged Remote AccessFiles and updatesDetonation and inspection before deliveryCloud Sandbox; sandboxed file transfer in PRACloud analytics and SaaSInline inspection, data classification, DLPZscaler Internet Access with Data ProtectionAI models and agentsOwn identity, mapped and scoped access, AI usage controlsZscaler Access Graph with AI security controlsInside the zonesAsset discovery and agentless segmentation by unit operationZero Trust Branch with device segmentationEarly warningDecoys in every zoneZscaler DeceptionSite connectivitySecure WAN and cellular links with no exposed edge devicesZero Trust Branch; Zscaler CellularWhat this does not replace is the control set on the validated systems themselves. That means audit trails in the MES, recipe locks in the batch engine, and the automation vendor's own hardening. It also does not solve removable media on its own. It gives the plant one enforceable layer around those systems, defined before qualification instead of negotiated after it. The window is nowBack in that field, the drawings are still being signed and the binder in the trailer is still being written. The plant that comes out of them will make medicines for decades, run AI its designers have not imagined yet, and connect to partners that do not exist today. Whether it does that securely depends less on the tools bought in 2035 than on the requirements written this year.Existing plants can still get there, through risk-based change control, one zone at a time, and we will cover that path in a follow-up. But for the plants being designed now, the cheapest security control is a line in the user requirements specification.If you are planning a new site or expansion, the best time to bring us in is front-end engineering design (FEED), before the URS is frozen. Request an OT architecture workshop. You will leave with two things: a zone and data-flow map that your engineering and Quality teams have signed off, and a set of security requirements written to be tested at FAT and SAT. And hear from our customers directly on how they use Zscaler for OT security.]]></description>
            <dc:creator>Bryan Ashley (Zero Trust Networking, Principal Architect)</dc:creator>
        </item>
        <item>
            <title><![CDATA[The End of Legacy Data Classification Is a Zero Trust Opportunity for Federal Government]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/end-legacy-data-classification-zero-trust-opportunity-federal-government</link>
            <guid>https://www.zscaler.com/blogs/product-insights/end-legacy-data-classification-zero-trust-opportunity-federal-government</guid>
            <pubDate>Wed, 07 Oct 2026 03:45:54 GMT</pubDate>
            <description><![CDATA[Across the Department of War, civilian agencies, and the Intelligence Community, security teams have spent years building data classification and permissions governance programs around on-premises tools. Those tools scanned file shares, monitored user activity, and helped auditors answer a basic question: who has access to what?Now, legacy data classification vendors are retiring their on-premises products and shifting exclusively to cloud delivered models. For some organizations, that transition is straightforward. For federal teams operating in classified, air gapped, disconnected, or otherwise constrained environments, it creates a decision point.&nbsp;Agencies have choices beyond a like-for-like replacement. They can replicate yesterday's static approach. They can reach for familiar fixes, such as bolting on another single purpose appliance or extending legacy VPN and perimeter access to reach new tools, which likely both adds cost and complexity and expands the attack surface. Or they can use the transition to strengthen continuous data visibility, access governance, and risk reduction as their Zero Trust and AI programs advance.Federal guidance supports that broader approach.&nbsp;CISA’s June 2026 zero trust guidance describes decisions informed by identity, device posture, application context, and data sensitivity. The&nbsp;Federal Zero Trust Data Security Guide puts the data-security task plainly: "Practitioners should define their policies based on data sensitivity, identifying who can access the data, under what conditions, and what they can do with it.” In a&nbsp;June 2026 joint statement, the heads of the Five Eyes cybersecurity agencies likewise urged leaders to prioritize reducing their attack surface and review permissions regularly."That modernization must account for wherever the mission runs: in the cloud, in hybrid environments, and in the classified, air gapped, and disconnected networks that much of the federal enterprise depends on. Classification alone was never the whole answerEven before end of life announcements, legacy data classification tools had structural limitations. Most operated on a static model: scan a repository, apply labels, generate a report. That approach answered where sensitive data lived at the time of the last scan, but could not keep pace with how data actually moves through an organization. Classification helps teams identify sensitive data. The broader task is to understand who and what can reach that data, whether access is appropriate, and how exposure changes as data and permissions change.Data Security Posture Management (DSPM) reframes the problem. Instead of static classification alone, DSPM introduces data provenance, which maps exact data lineage and usage over time. It brings discovery and classification together with analysis of access and exposure. It connects data stores to the identities that access them, including human users, non-human identities, service accounts, third parties, and mission partners. It does this continuously, so the picture stays current as the environment changes.For federal organizations, this is the difference between a compliance checkbox and an operational capability. It also matches the direction of the Pentagon’s cybersecurity policy. In March 2026 congressional testimony, Department of War CIO Kirsten Davies said the department will “emphasize automation and dynamic and continuous monitoring” and “drive risk reduction rather than burdensome paperwork”. For the data pillar, that means continuous posture assessment in place of periodic scans, and identity aware access governance in place of static permission reports. Why Data Security Has to Become ContinuousThe real challenge for agencies, therefore, is not simply how to replace a retiring classification tool. It is whether the replacement will support the way federal missions now operate.&nbsp;Traditional categorization programs were built around labels, repositories, and periodic reviews. Those capabilities still matter, but they are no longer enough. Zero Trust requires agencies to understand data sensitivity in context: who is accessing the data, from what identity or workload, under what conditions, and whether that access remains appropriate over time.&nbsp;That shift evolves the mission of data security. Categorization becomes the starting point, not the end state. Agencies need continuous visibility into sensitive data, identity-to-data relationships, excessive permissions, stale or redundant information, and policy violations that increase operational risk. They also need those capabilities to work inside the environments where federal data actually resides, including classified, disconnected, tactical, hybrid, and cloud-connected networks. What Zscaler DSPM deliversZscaler DSPM helps agencies discover sensitive data, map identity to data access, and remediate exposure inside a customer controlled boundary. The approach follows four stages:Discover. Connect to file stores, SaaS platforms, identity sources, and data repositories through agentless, API based, and service account connectors. Sensitive data stays within the operating boundary throughout.Categorize. Apply deterministic rules, local machine learning, and optional customer controlled models to label sensitive data. Classification runs within the customer's environment, not in a third party cloud.Graph. Map human and non human identities to data access, including privileged users, third party contractors, inactive accounts, service accounts, and identities without multi-factor authentication. This identity to data graph is the foundation for understanding who can reach what.Remediate. Right size permissions, reduce stale or misplaced data, and produce the evidence auditors and governance teams need. The output is actionable: specific findings tied to specific data stores, with clear remediation paths and owner assignments. Built for constrained environmentsZscaler DSPM is designed for environments where deployment flexibility is a mission requirement. That includes on-premises installations, VM and container based deployments, classified enclaves, and disconnected or tactical networks. Agencies operating in air gapped or limited connectivity environments do not need to route sensitive data through external cloud infrastructure to gain classification and access governance capabilities.This deployment model directly addresses the friction federal teams encounter when their incumbent vendor's replacement requires connectivity and cloud models that do not fit the operational environment. Zscaler DSPM meets agencies where they operate, under the data boundary constraints, FedRAMP or Impact Level requirements, and RMF/ATO considerations that define federal IT. The AI readiness imperativeThere is a second, equally urgent reason to modernize data security posture now: AI adoption.Agencies across the Department of War (DoW) and civilian government are under pressure to deploy AI, copilots, retrieval augmented generation (RAG) workflows, and agentic systems. Every one of those initiatives depends on access to internal data. Speaking at the 2026 Billington CyberSecurity Summit, acting Federal CISO Michael Duffy described the overlap directly: “The things that I need to advance data security for zero trust, and the things that we need to make data trustworthy and usable for AI are very much aligned. Sometimes even the same things.” Scaling AI safely depends on the organization’s ability to answer three questions:Which data is sensitive, and where does it live?Who and what can access that data today, including AI tools and automated workflows?Are permissions appropriately scoped, or do broad legacy access rights create unacceptable exposure?Zscaler DSPM provides the data foundation that makes AI adoption defensible. By identifying sensitive data, mapping access, and reducing excessive permissions before AI workflows touch mission data, agencies can move from blocking AI adoption to enabling it under governance. Securing data is foundational Zero TrustData security does not exist in isolation. The findings from a DSPM deployment connect directly to broader Zero Trust architecture decisions: which users should have private application access, where data loss prevention controls need to be applied, how identity risk should influence access policy, and where AI guardrails belong.Zscaler DSPM provides the data foundation that powers the rest of the Zscaler Zero Trust Exchange. Agencies can start with data discovery and access governance, prove value on a specific repository or mission data set, and expand into private access, data protection, identity risk scoring, and AI security as the program matures. A practical next stepThe retirement of legacy on-premises classification tools is already underway. For agencies with active compliance mandates, the priority is standing up a modern replacement that meets their deployment, security, and governance requirements before the control gap widens.A practical starting point: a 30 to 45 day data risk assessment focused on one mission data enclave or repository family. The assessment delivers an executive readout covering sensitive data exposure, stale and redundant data, excessive permissions, user activity patterns, and AI access control implications. That readout becomes the basis for a broader deployment, grounded in measurable risk reduction and a clear path to operational value.Ready to move forward? Contact the Zscaler Federal team to schedule a Data Security and AI Readiness Workshop.&nbsp;]]></description>
            <dc:creator>Andrew AJ Forysiak (Field CISO DOD)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Beyond VoIP and SCCM: Securing Legacy Applications with ZPA]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/beyond-voip-and-sccm-securing-legacy-applications-zpa</link>
            <guid>https://www.zscaler.com/blogs/product-insights/beyond-voip-and-sccm-securing-legacy-applications-zpa</guid>
            <pubDate>Tue, 06 Oct 2026 17:00:00 GMT</pubDate>
            <description><![CDATA[Beyond VoIP and SCCM: Securing Legacy Applications with ZPAVPN for Legacy Apps started with VoIP and server-to-client apps like SCCM. New capabilities now extend it to support full zero trust access to IP address dependent systems like mainframes, multi-entity organizations and complex routing environments, so more of your legacy estate can move to Zscaler Private Access (ZPA).Most organizations moving from a traditional VPN/Firewall to zero trust reach the same point: user-to-app traffic moves to ZTNA easily, but a set of legacy apps keeps the old VPN concentrator or NGFW running. VPN for Legacy Apps in ZPA closes that gap. It gives those apps a home on the Zscaler Zero Trust Exchange, delivered through the same Zscaler Client Connector users already have. You can move off your traditional VPN vendor completely, with one agent, one policy framework and one platform for all private access, instead of running Zscaler and legacy VPN solutions side by side.Why the last mile of VPN migration is the hardestIn our&nbsp;earlier post, we introduced VPN for Legacy Apps in ZPA. It covers the applications that have challenges with&nbsp; zero trust design: Cisco Jabber, Avaya and Genesys VoIP, SCCM, follow-me printing and active FTP. These apps need the server to reach back to the client, and many expect a fixed client IP. That is why the VPN concentrator stays on long after everything else has moved to ZTNA.As more customers move these apps onto ZPA using VPN for Legacy App solution, they have told us what would make large migrations even smoother: onboarding large VPN configurations quickly, supporting systems that expect a fixed client IP, bringing acquired companies onboard on their own terms, and fitting cleanly into existing routing.Over the last few releases, we have delivered a set of features that address each of these needs and open VPN for Legacy Apps to use cases beyond where it started. Together, they make onboarding a legacy app to ZTNA as simple as adding it to your VPN, so you can retire your legacy VPN concentrators with confidence.Expanded use-case coverageThe first set of capabilities removes common blockers that keep legacy apps on the VPN, while making onboarding and day-to-day operations simpler.1. User group-based access policyLegacy VPN access is often defined by IP ranges alone, which says little about who is actually connecting. Access policies for VPN for Legacy Apps can now use IdP group attributes alongside existing IP criteria. Admins can grant access to a legacy app based on who the user is (for example, the finance or contact-center group), not just which network range they target and coming from.2. FQDN wildcard support: onboard everything, then migrate in phasesA typical VPN configuration covers a large number of hosts and domains, and discovering and rebuilding each one as an exact ZPA segment before cutover takes time. One missed host can break a VoIP callback or an SCCM push with no obvious cause. Network segments now support wildcard FQDNs, such as *.acme.com, so a single definition covers your legacy destinations on day one. You can move all of your VPN traffic to Zscaler in one step and retire the VPN, with users working just as they did before. From there, migrate to ZTNA at your own pace: use ZPA visibility to see which apps are really in use, then carve out specific network segments with least-privilege policies, one app group at a time. Upfront discovery and rework drop sharply.3. Static IP assignment to users: keep IP-based controls workingMainframes and many other legacy systems still trust an IP address. Firewalls, application allowlists and licensing servers key on the client IP, and regulated teams need a stable user-to-IP mapping in their logs. Admins can now statically map a user to an IP address, so the user gets the same address every time they connect to VPN for Legacy Apps. Security teams can track the user by IP across enterprise systems, allowlist-based apps keep working, and IP-based firewall rules need no rewrites. Banks, healthcare providers and other regulated teams keep a consistent user-to-IP record for audit and compliance.4. Micro-tenancy: isolation inside one ZPA tenantMergers, acquisitions and multi-campus organizations bring separate VPN estates, each with its own apps, admins and policies, and often overlapping RFC 1918 address space. VPN for Legacy Apps now works with ZPA Microtenants, which provide isolation inside a single ZPA tenant. Each subsidiary, acquired business or campus can run its legacy app segments, Network Connectors and policies in its own microtenant, on its own timeline, even when its private address ranges overlap with others. Microtenants can also share network segments with each other, with granular control over which segments are shared and with whom. Central IT keeps one platform and one view, while each business onboards fast.5. BGP summary routes: simpler routing integrationPreviously, the customer's router had to advertise prefixes that exactly matched each ZPA segment, so every new or changed segment meant a router change request and coordination between security and network teams. Now your router can send a single summary route to the Network Connectors. Network Connectors then use conditional routing to advertise the specific routes that match your configured segments. For example, if the router sends 10.1.1.0/24 and the network segment is 10.1.1.1, the Network Connector advertises only 10.1.1.1/32. The network team configures BGP once, and the security team adds or changes network segments in ZPA without opening a router ticket.Enterprise-ready: resiliency, control and visibilityWith these capabilities, VPN for Legacy Apps goes beyond the handful of use cases to supporting all the use cases large enterprises run needGet Started: ZPA Trial for VoIP and Legacy Application Zero Trust MigrationZPA now supports VoIP, server-to-client (S2C) applications, and all IP address dependent use-cases. This enables customers to move all their applications and streamlines operations by consolidating their secure remote access solution with Zscaler Private Access.&nbsp;Check out the&nbsp;latest product innovations with ZPA in addition to network connectivity. And read the&nbsp;Forrester Total Economic Impact study to learn how ZPA customers have realized 289% ROI.&nbsp;Contact your regional sales team to learn more about the solution and get a free 30 day trial to explore the solution, or&nbsp;take a quick tour.&nbsp;&nbsp;]]></description>
            <dc:creator>Megha Tamvada (Director, Product Management)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Bringing Anthropic&#039;s Claude Mythos 5.1 to Zscaler Endpoint AI Security]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/bringing-anthropic-s-claude-mythos-5-1-zscaler-endpoint-ai-security</link>
            <guid>https://www.zscaler.com/blogs/product-insights/bringing-anthropic-s-claude-mythos-5-1-zscaler-endpoint-ai-security</guid>
            <pubDate>Tue, 06 Oct 2026 04:24:20 GMT</pubDate>
            <description><![CDATA[AI adoption inside the enterprise is increasingly bottom-up: employees are trying the latest AI assistants, coding agents, browsers, and development tools because these products help them get work done. Many of these tools arrive before central security or IT teams have evaluated them.The result is a sprawl of shadow AI: a fast-growing layer of applications, agents, extensions, models, packages, and configuration files on employee devices. This activity changes quickly and often falls outside the software rollout processes organizations use for traditional applications.Today, Zscaler is announcing the limited preview availability of Anthropic's Claude Mythos 5.1 capabilities in Zscaler Endpoint AI Security. Mythos 5.1 powers Exploit Paths, helping security teams connect related endpoint AI activity, identify potential attack paths, and determine where to intervene.&nbsp;With this addition, Zscaler better helps security teams turn disconnected endpoint events from different AI apps, across all users, into an attack chain analysis view of potential threat vectors. By correlating multi-stage AI behaviors into visible attack paths, security teams can leverage intelligent prioritization to proactively block risky agent activities, secure sensitive data, and enforce real-time policy controls directly at the endpoint. Why MDM and EDR leave a visibility gapMDM and EDR remain essential parts of endpoint security, but they were built to answer different questions. MDM helps organizations manage applications, devices, and configurations. EDR monitors processes, files, network activity, and known attack behavior.AI agents introduce a different kind of endpoint activity. They can act on a user’s behalf using the user’s identity and permissions, call tools, access files, run commands, and connect to services as if the user performed those actions directly. As a result, audit logs may attribute agent activity to the user’s account, making it difficult to separate what the user did from what an agent did on the user’s behalf.At the process or file level, this activity can look normal. A signed application may modify a file, run a command, or send data over the network without matching a malware pattern. The missing context often lives inside the AI application layer: which agent acted, what task it was performing, which tool it called, what data it used, and which extensions, models, packages, or connected services were involved.Endpoint AI Security was built to close this gap. It secures the AI activity layer on the endpoint — where AI apps, browsers, assistants, coding agents, and other agentic tools are creating new risks that traditional endpoint tools were not designed to interpret or control. How Zscaler Endpoint AI Security closes the gapZscaler Endpoint AI Security is designed to secure this AI application layer across users and managed devices. It combines all three pillars critical to securing employee devices using AI: discovery, runtime visibility, and policy enforcement.Discover AI assetsSecurity teams first need to answer a basic question: What AI is running across the organization?Endpoint AI Security identifies AI assistants, agents, browsers, development tools, models, packages, extensions, and connected services used across managed devices. This provides visibility into AI assets that may not appear in traditional application inventories.See what agents are doingInventory shows what is present. Runtime visibility shows what is happening.Endpoint AI Security captures the events that matter during an agent run, including prompts, tool calls, file access, commands, system interactions, and network activity. It connects those events to the user, agent, and device involved.Enforce enterprise AI policyVisibility becomes useful when it can change an outcome. Endpoint AI Security provides a policy layer for controlling AI activity on the device.Policies can restrict unauthorized agents and tools, stop dangerous commands or instructions, and protect sensitive files and data. This gives security teams a way to support AI adoption while keeping enterprise rules in effect at the endpoint. The challenge of connecting activity at enterprise scaleDiscovery and runtime monitoring produce detailed evidence. That evidence is distributed across users, devices, agents, tools, and individual runs.The challenge is understanding how these activities connect. Broad agent permissions, use of a third-party tool, or access to a sensitive file may each appear manageable in isolation. When these conditions occur in the same sequence, they can combine into a more serious risk.Reviewing each event separately makes that relationship easy to miss. Security teams need a way to cross-correlate the activity, recognize possible attack progression, and determine which response will reduce the most risk. What Mythos 5.1 addsMythos 5.1 powers a critical capability within Endpoint AI Security, Exploit Paths, which cross-correlates evidence to identify potential threats, explain how the steps connect, and show defenders where to interrupt the sequence.Each path shows the evidence behind the analysis, how confident the assessment is, and where a step is inferred rather than confirmed. It also identifies how a defender could recognize the activity and where to break the chain of attack.This adds context that individual alerts cannot provide. Security teams can categorize risk based on the complete path, understand why a group of findings matters, and prioritize the control that can interrupt the sequence.Endpoint AI Security and&nbsp;Mythos 5.1 have distinct roles. Endpoint AI Security discovers AI assets, records agent activity, and provides the policy enforcement point.&nbsp;Mythos 5.1&nbsp;analyzes that evidence, connects related conditions, and identifies the attack paths that deserve attention. What this looks like in practiceConsider an AI agent with broader permissions than its assigned role requires. During a run, it calls a third-party tool and accesses files containing sensitive information. Endpoint AI Security records the agent, the user and device involved, the tool call, and the file activity.&nbsp;Viewed in isolation, these events may not reveal the full risk.&nbsp;Mythos 5.1 correlates the findings to determine whether they form a credible sequence. Exploit Paths shows how the agent’s permissions, use of a third-party tool, and access to sensitive files could combine into an attack path. The report presents the supporting evidence, identifies any inferred steps, and recommends where defenders should intervene.The security team can then use Endpoint AI Security policy controls to restrict the agent or tool, stop risky activity, or block access to sensitive data.&nbsp;Mythos 5.1 provides the analysis and prioritization, while Endpoint AI Security provides the visibility and enforcement. Turning evidence into actionExploit Paths is designed for defensive assessments of environments customers are authorized to protect. It presents prioritized findings without exposing raw model responses or generating working exploit code or payloads. Security teams review the evidence and decide how to respond. By bringing&nbsp;Mythos 5.1 into Endpoint AI Security, Zscaler helps security teams turn disconnected endpoint events into a focused view of potential attack paths.&nbsp;“AI agents are rapidly becoming part of everyday work. But they also introduce a new layer of endpoint activity that security teams need to understand and control. By embedding&nbsp;Mythos 5.1 in Zscaler Endpoint AI Security, we are helping customers connect agent behavior, tool use, and data access into clear exploit paths so defenders can prioritize the actions that reduce the most risk.”— Dhawal Sharma, EVP AI Security, Zscaler“Bringing Claude Mythos 5.1 into Zscaler's Endpoint AI Security helps enterprise security teams reason over complex AI activity in a defensive, evidence-based way. This makes it easier for organizations to adopt AI tools confidently while maintaining the visibility and safeguards they need.”–&nbsp;Ash Alhashim, GTM Leadership Cybersecurity, Anthropic&nbsp;With this addition, security analysts can see how AI risk develops across agents, tools, and data on the endpoint. As those signals come together, Exploit Paths shows where risk is forming and where intervention will matter most. With proven Zscaler policy controls, teams can interrupt risky activity before it causes business impact. The result is a safer path to enterprise AI adoption - with visibility, control, and protection on every managed employee device.​​To learn more about Zscaler Endpoint AI Security or request a demo, visit&nbsp;https://www.zscaler.com/request-a-demo..]]></description>
            <dc:creator>Dhawal Sharma (Executive Vice President, AI Security and Strategic Initiatives)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Don’t Wait for Game Film: Audit Your Cloud Red Zone]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/don-t-wait-game-film-audit-your-cloud-red-zone</link>
            <guid>https://www.zscaler.com/blogs/product-insights/don-t-wait-game-film-audit-your-cloud-red-zone</guid>
            <pubDate>Tue, 06 Oct 2026 01:54:46 GMT</pubDate>
            <description><![CDATA[Game film is how football teams learn from what already happened. It’s valuable, and it’s expensive, because the lesson arrives after the score.Most cloud security reviews work the same way. Teams wait for an incident, a breached database, or a hard audit finding to reveal where the perimeter lapsed.AI workloads shorten that timeline.&nbsp;Zscaler ThreatLabz research found that enterprise AI/ML transaction volume grew 83% year over year in 2025, while data transfers to AI/ML applications rose 93% to more than 18,000 terabytes. Each new AI workload is provisioned quickly, typically needs broad outbound access to pull models and public data, and lands on a network that grants connectivity by default.The&nbsp;OpenAI–Hugging Face incident is the game film. During an internal evaluation in July 2026, AI models escaped their sandbox through a zero-day vulnerability in a package registry proxy, the only outbound path the environment allowed,&nbsp;according to OpenAI. From there, they moved laterally until they reached a node with internet access and used stolen credentials to reach Hugging Face production infrastructure.&nbsp;Hugging Face’s own disclosure describes an attacker log of more than 17,000 recorded events. This post is the scouting report: three repeatable checks you can run this quarter across AWS, Microsoft Azure, and Google Cloud to find exposure before an attacker does. Why Cloud Networks Hand Out Connectivity FirstCloud networks are engineered to connect, and default configurations typically favor reach over restriction. Security boundaries usually arrive later, negotiated through a ticket queue or an exception request.AI workloads strain that model in three ways:Broad external pulls: AI clusters routinely pull models, weights, datasets, and dependencies from public repositories.Shadow provisioning: Data science and ML teams often stand up environments outside standard architecture review to keep momentum.Data proximity: AI applications run next to sensitive production data stores and analytics pipelines for training and inference.Defenses rarely fail because of one missed assignment. They fail because small, uninspected gaps compound over time. Cloud risk builds through convenience routes and standing exceptions, not a single catastrophic decision. The three audits below are designed to uncover that accumulation. 1. The Egress Audit: Where Can Your Workloads Reach?Start with the exits. Every offense hunts for the open receiver behind the secondary. In the cloud, that open receiver is the outbound path nobody inspects. In the Hugging Face incident, it was a package registry proxy.What to Look ForList every route table that sends 0.0.0.0/0 through a NAT gateway or internet gateway across your cloud environments. Cross-reference that list against 30 days of VPC/VNet flow logs to verify which external destinations your workloads actually contacted.Pay close attention to AI pipelines pulling from public registries.&nbsp;Sonatype’s 2026 State of the Software Supply Chain report identified more than 454,600 new malicious open source packages in 2025, a 75% increase over the prior year, bringing the cumulative total it has tracked past 1.2 million as of year-end. Sonatype also notes that developer machines and CI/CD environments are prime targets because they sit close to credentials and production access. Common Pattern:&nbsp;The&nbsp;Cloud Security Alliance notes that development teams routinely pull foundation models, fine-tuned adapters, and other AI artifacts directly from public registries, often without the scrutiny applied to traditional software dependencies. In cloud terms, that often looks like AI and data science environments using a default NAT path to the internet with no inspection, which leaves a blind spot for data exfiltration and dependency poisoning. Why It MattersEncrypted, uninspected egress gives a compromised host a covert channel. Command-and-control (C2) traffic and data exfiltration can blend in with legitimate outbound TLS and slip past controls that do not decrypt and inspect it.The litmus test for security leaders is simple:&nbsp;Can your team name every external service, IP, and repository your cloud workloads contacted last week?How to Fix ItReplace open default routing with inline TLS inspection and destination allowlists scoped to each source workload’s identity.With Zscaler Zero Trust Cloud (ZTC), workload outbound traffic is steered from the local VPC or VNet to the Zero Trust Exchange, either through the Zero Trust Gateway service, which Zscaler fully manages, or through Cloud Connectors you deploy yourself. There, connections get cloud-scale TLS decryption, granular URL and FQDN filtering, and inline data loss prevention (DLP). That blocks unauthorized package acquisition and data leakage before traffic leaves your boundary. 2. The East-West Audit: What Can a Compromised Workload Touch?Next, test your interior. In a disciplined defense, every player covers a gap. In a flat cloud network, nobody is assigned to the middle of the field.What to Look ForPick a low-trust workload, such as a developer sandbox, an edge analytics container, or an experimental AI notebook, and map everything it can reach. Review peering relationships, transit gateway route tables, cross-account and cross-subscription connections, and security rules that allow broad CIDR ranges (for example /16 or /12).Then run an active reachability test: try to connect from that low-trust host to a production database subnet. Never assume the configuration blocks the hop until you have tested the path. Common Pattern:&nbsp;Segmentation built on security groups, ACLs, and address ranges tends to be static and hard to keep accurate as environments change. Rules written against broad ranges instead of specific workloads are a familiar way for a path to production data to stay open long after the team believes it is closed. Why It MattersInternal reach determines your blast radius. It marks the line between an isolated compromise of a developer sandbox and a breach of sensitive customer records. Lateral movement is a common feature of ransomware and other multi-stage attacks, and it was central to the Hugging Face incident. It also happens fast:&nbsp;CrowdStrike’s 2026 Global Threat Report found that the average eCrime breakout time, the window between initial access and lateral movement, fell to 29 minutes in 2025, with the fastest observed breakout at 27 seconds.How to Fix ItRetire position-based network controls in favor of workload identity and explicit 1-to-1 microsegmentation.With ZTC, east-west traffic between workloads within a region is enforced directly at the Zero Trust Gateway or Cloud Connector. Flows that extend beyond a single region, such as cross-region, multi-cloud, or hybrid data center traffic, can be handled at the Gateway or Cloud Connector, or routed through the Zero Trust Exchange for a full proxy-based solution. Either way, workloads communicate only with pre-approved endpoints, which removes the open paths that unauthorized lateral movement depends on. &nbsp; 3. The Launch Audit: What Does a New Workload Inherit?Championship teams build defensive discipline in the first practice, so every player knows the assignment long before game day.What to Look ForDeploy a test workload from your standard infrastructure-as-code (IaC) templates, whether Terraform, AWS CloudFormation, Azure Bicep, or Google Cloud Infrastructure Manager. Check whether it launches with egress controls and isolation active, or falls back to open cloud defaults.Then audit tag and label governance. Are the metadata tags that drive policy enforcement validated as mandatory gates in your CI/CD pipeline? Common Pattern:&nbsp;Templates often define compute and networking but leave egress and isolation policy to a follow-up step. Any control that depends on a manual follow-up is the first to slip when a deadline is tight. Why It MattersCloud infrastructure provisions in seconds. A manual cleanup done today is stale by the next deployment cycle, and any control that depends on a ticket or a human step will eventually lapse. Enforcing policy at deployment turns one-off remediation into a sustained security posture.How to Fix ItAnchor security policy to&nbsp;workload identities and cloud tags from the moment an instance starts. ZTC’s workload discovery service reads user-defined tags and cloud metadata, such as network, subnet, security group, and image attributes, across AWS, Azure, and Google Cloud. It picks up each new workload’s identity as soon as it launches, so policy applies from the start.Because policy keys off these tags and attributes, tag hygiene becomes a security control. Enforce mandatory tags with native guardrails (AWS tag policies and SCPs, Azure Policy, Google Cloud Organization Policy), and pair them with automated pipeline checks. If a workload template lacks the mandatory security tags or routes traffic through an uninspected gateway, fail the build before anything is provisioned. Where to Look Across AWS, Azure, and Google CloudShare this reference table with your cloud engineering and platform security teams to run each audit:Audit CheckAmazon Web Services (AWS)Microsoft AzureGoogle Cloud (GCP)1. Egress PathsRoute tables with 0.0.0.0/0 to NAT Gateways or Internet Gateways; VPC Flow LogsRoute tables with 0.0.0.0/0 to Internet or virtual appliance next hops; NAT Gateway associations; VNet Flow LogsDefault routes (0.0.0.0/0) to the default internet gateway; Cloud NAT configurations; VPC Flow Logs2. East-West ReachTransit Gateway route tables; VPC Peering connections; Security Group ingress CIDRsVirtual Network Peering; hub-and-spoke routing configurations; NSG inbound rulesVPC Network Peering; Network Connectivity Center spokes; VPC firewall rules3. Policy at LaunchTerraform modules; CloudFormation templates; AWS resource tags; AWS Config rules; SCPsTerraform modules; Bicep templates; resource tags; Azure Policy definitions and tag enforcementTerraform modules; Infrastructure Manager; labels and network tags; Organization Policy Service&nbsp; What Skipping the Audit CostsThe cost of unmanaged cloud exposure rarely shows up as a line item until an incident happens. Before that, it accumulates quietly in your change-management backlog.When the bill does arrive, it is large.&nbsp;IBM’s 2026 Cost of a Data Breach Report puts the global average breach at a record $4.99 million. Among organizations that suffered an AI-related breach, 92% lacked proper AI access controls, and only 40% of all breached organizations applied access controls to AI models and data at all.Every new outbound destination, partner connection, or AI data source needs an infrastructure change ticket. Requests back up, deadlines loom, and engineering teams look for routes around the perimeter. Each detour can become a standing exception: a broad CIDR allowance, an uninspected NAT gateway, a disabled firewall. Those exceptions are exactly what the egress and east-west audits reveal. Common Pattern:&nbsp;When approval queues for new destinations run long, teams tend to build their own workarounds rather than wait. Unmanaged paths tend to appear wherever enforcement gaps meet developer convenience and automation. Security leaders should treat standing exceptions as a leading risk indicator. The exception count shows how much of your production footprint already operates outside your security baseline. Conclusion: Watch the Film Before the GameGame film shows where an opponent broke through last week. A structured audit shows where your architecture is exposed right now.Schedule these three checks this quarter. Start with the workload tier that has the highest velocity, the most connectivity freedom, and the fewest architecture reviews: your AI and data science environments.To see how enterprises close these gaps with cloud-native workload protection, explore&nbsp;Zscaler Zero Trust Cloud.]]></description>
            <dc:creator>Brian Pavane (Senior Director, Specialist Solution Architect)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Browser Detection and Response: Why Your Security Stack Needs Eyes Inside the Browser]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/browser-detection-and-response-why-your-security-stack-needs-eyes-inside</link>
            <guid>https://www.zscaler.com/blogs/product-insights/browser-detection-and-response-why-your-security-stack-needs-eyes-inside</guid>
            <pubDate>Mon, 05 Oct 2026 17:03:25 GMT</pubDate>
            <description><![CDATA[Employees spend the majority of their productive working hours in a browser. They access SaaS applications, collaborate on documents, authenticate into corporate systems, and paste sensitive data into GenAI tools, all through a single application that most security teams barely monitor.Meanwhile, attackers have noticed. The browser is now a prime target, and the techniques being used against it are evolving faster than the defenses in front of it.The industry has documented a growing catalog of in-browser attack techniques: adversary-in-the-middle (AiTM) phishing, malicious OAuth grants, hijacked extensions, ClickFix social engineering, and session token theft. At the same time,&nbsp;Microsoft's Work Trend Index found that 78% of AI users at work are bringing their own AI tools without IT approval, introducing data exposure channels that legacy controls were never designed to see.The common thread across all of these threats is that they live and die inside the browser. They do not trigger file downloads. They do not create suspicious processes on the endpoint. They often bypass URL reputation lists entirely. And that makes them invisible to the tools most organizations rely on. Why Your EDR and Network Security Stack Can't See What's HappeningEndpoint detection and response (EDR) tools focus on inspecting files and processes at the operating system level. Detection begins when a malicious file lands on disk or a suspicious process spawns. But many of today's browser-based attacks never reach that threshold.A credential phishing page that renders a fake login portal inside an iframe does not write anything to the endpoint. An AiTM proxy that intercepts session tokens operates entirely within the HTTPS session. A compromised browser extension that scrapes DOM content and exfiltrates it over standard HTTPS generates no anomaly at the network perimeter. The&nbsp;Cloud Security Alliance's AI Safety Initiative put it plainly in April 2026: "Traditional enterprise defenses, DLP, CASB, and EDR, have limited or no native visibility into DOM-level browser extension behavior."Network security tools face similar constraints. Secure web gateways and firewalls inspect traffic at the network layer, relying on URL categorization, domain reputation, and signature-based detection. These controls work well for known threats. They struggle with attacks that abuse trusted infrastructure: phishing campaigns served from compromised legitimate domains, multi-hop redirects gated behind CAPTCHAs, and scripts that execute conditionally based on whether the visitor is a real user or a security scanner.The result is a structural blind spot. The browser processes identity decisions, renders sensitive content, executes third-party code via extensions, and mediates clipboard activity. None of that activity is visible to tools operating below or outside the browser process. The Attack Surface Has Expanded QuietlySeveral shifts have widened this gap without most security teams noticing.Extensions became powerful and exploitable. Modern browser extensions interact with web pages through the Document Object Model (DOM), store data locally, integrate with third-party services, and fetch data across multiple applications using browser APIs. Attackers have learned to weaponize this power. In January 2026,&nbsp;Socket researchers uncovered five coordinated Chrome extensions targeting enterprise HR and ERP systems, exfiltrating session cookies and blocking security administration pages to prevent detection. The&nbsp;Cyberhaven supply chain attack followed a similar playbook: a phished developer credential led to a malicious extension update pushed silently to millions of installed instances. Extension whitelisting, the most common management strategy, offers no protection when a previously trusted extension turns malicious after an acquisition or account compromise.Personal and work activities share the same browser. Employees access the same browser for corporate SaaS apps and personal email, file storage, and social media. This overlap creates policy challenges that go beyond traditional allow/block decisions. A user might paste sensitive financial data into a personal Google Drive, or log into a shadow SaaS tool with corporate credentials, and neither action generates an alert in most security stacks.AI tools introduced new data exposure channels.&nbsp;A TELUS Digital Experience survey found that 57% of enterprise employees have entered confidential information into publicly available GenAI tools. Copy-pasting source code into a GenAI chatbot, uploading internal documents to an AI summarization tool, or entering customer PII into an AI-powered form: all of these actions happen inside the browser session, beyond the reach of network-layer controls. What Browser Detection and Response Actually MeansAddressing this blind spot requires detection and response capabilities that operate where the attacks happen: inside the browser itself.Zscaler’s industry-first&nbsp;Browser Detection and Response (BDR) technology monitors, detects, mitigates, and enables threat hunting for client-side web attacks in real time. The Zscaler Zero Trust Browser delivers BDR in two deployment models: as a lightweight browser extension that can be pushed via standard group policy (through tools like Microsoft Intune or Jamf) to existing browsers like Chrome, Edge, Safari, and Firefox, and as a full Zscaler Browser for organizations that want a purpose-built enterprise browser with BDR capabilities built in from the ground up. Both options deliver the same core BDR protections, giving security teams the flexibility to meet users where they are or standardize on a managed browser, depending on their security posture and workforce requirements.Monitor: Visibility That Goes Beyond Network LogsBecause BDR operates inside the browser, it captures signals that network and endpoint tools cannot: DOM mutations, website permission changes, browser API calls, user events, file uploads and downloads, clipboard activity, extension behavior, and WebAssembly execution. This telemetry provides the raw material for detecting attacks that never touch the file system or generate suspicious network signatures.Detect: Covering the Five Critical Attack VectorsBDR detection spans five categories that map directly to how attackers exploit the browser today:Sites. Beyond URL filtering, BDR performs real-time analysis of user-browser interaction, content inspection, and DOM changes. This catches advanced techniques like Browser-in-the-Browser (BiTB) attacks, CAPTCHA-gated phishing, and multi-hop redirect chains. Zscaler's BDR detects over 90 unique web attack types using this approach.&nbsp;Files. A client-side file scanner intercepts and inspects every file before a download reaches the endpoint, detecting malicious payloads without sending the file to an external server. On the upload side, it inspects files for PII and sensitive content to prevent data loss through personal accounts.&nbsp;Extensions. Rather than relying on static whitelists, BDR inspects extension behavior and permission changes in real time. When a previously benign extension starts scraping session cookies or injecting scripts after an update, BDR detects and blocks the activity automatically.&nbsp;Identity. Granular policies govern which SaaS applications and authentication methods each user can access, preventing unauthorized OAuth grants, shadow SaaS usage, and credential reuse across sites. This directly addresses the AiTM and device code phishing techniques that have surged recently.&nbsp;Clipboard. Content inspection on copy and paste operations prevents sensitive data from moving to unauthorized destinations: blocking paste into GenAI prompts, preventing copy from enterprise applications, and enforcing policies on a per-site basis.&nbsp;Mitigate: Responses That Keep Users WorkingBDR focuses on detecting and surfacing browser-based threats. When a threat is identified, the Zero Trust Browser provides graduated mitigation options beyond simple allow and block, enabling employees to continue working in a safe environment.For suspicious or risky web content, administrators can set policies to automatically open flagged sites in an isolated session, where all page rendering, script execution, and active content run in a secure cloud container rather than on the user's device. Content is streamed back to the user as safe images, so employees can continue browsing while code execution, exploits, and malware delivery are contained away from the endpoint. This is particularly useful for individuals who travel frequently, such as sales teams, and need secure, disposable browsing sessions while on the road.Isolation also provides a safety net for unmanaged and BYOD devices. Because isolated sessions deliver images rather than raw HTML and JavaScript, contractors and employees on personal laptops can access sensitive applications without exposing the endpoint to malware or data exfiltration. Security teams can further tighten these sessions by restricting clipboard operations, disabling downloads, or blocking uploads on a per-policy basis.The combination of BDR's in-browser detection with isolation capabilities creates a layered defense: threats are identified where they execute (inside the browser), and then contained before they reach the endpoint or the network.Threat Hunt: Enterprise-Wide Attack IntelligenceBDR provides security teams with capabilities that go well beyond alert triage:Attack graphs map the full sequence of sites visited and actions taken before a policy triggered, revealing the attack path in detail.Attack correlation connects related campaigns across the organization, identifying when the same adversary targets multiple employee groups simultaneously.Attack Vision uses DOM reconstruction to replay exactly what a user saw and did in the 30 seconds before a policy hit, giving security teams a definitive view of whether a breach resulted from negligence or malicious intent.A built-in co-pilot generates plain-language reports for each incident, describing what happened, who was affected, and recommended remediation steps. Why This Matters NowThe traditional approach to browser security has been reactive: block known malicious domains, maintain a static extension whitelist, and hope the EDR catches anything that slips through. That approach was designed for an era when the browser was one of many applications on the desktop, not the primary place where work, data access, and authentication converge.The shift to browser-as-workplace happened gradually. The security response needs to catch up. With AI-generated phishing now representing&nbsp;more than 80% of observed social engineering activity according to ENISA's 2025 Threat Landscape report, with extension supply chain attacks growing in scale, and with GenAI tools creating new data loss vectors every week, waiting for threats to reach the endpoint or trigger network signatures means accepting that the most consequential attacks will go undetected.BDR closes this gap by placing detection and response where the attacks actually execute. As a core capability of the Zscaler Zero Trust Browser, available as both an extension and a full enterprise browser, BDR maintains a continuously updated threat detection library that pushes new policies to all users as new attack techniques emerge.The browser became the enterprise's most critical application. It is time the security stack caught up.To learn more about how Zscaler Zero Trust Browser protects your organization with industry-first Browser Detection and Response, visit&nbsp;our page or&nbsp;contact a sales representative.]]></description>
            <dc:creator>Ashraf Aziz (Director Product Marketing, Zero Trust Browser)</dc:creator>
        </item>
        <item>
            <title><![CDATA[NIST&#039;s New OT Guide Draws the Zero Trust Line at Level 3. Attackers Are Working Below It.]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/nist-s-new-ot-guide-draws-zero-trust-line-level-3-attackers-are-working</link>
            <guid>https://www.zscaler.com/blogs/product-insights/nist-s-new-ot-guide-draws-zero-trust-line-level-3-attackers-are-working</guid>
            <pubDate>Sun, 04 Oct 2026 16:10:45 GMT</pubDate>
            <description><![CDATA[Quick answer: NIST released the initial public draft of SP 800-82 Revision 4, its Guide to Operational Technology Security, on September 21, 2026, with public comments open through November 30. The draft adds zero trust principles to OT security architecture but recommends applying them to compatible systems, typically those at Purdue Level 3 and above, because many controllers and operator panels cannot fully take part. That leaves the controllers running the physical process protected at the zone boundary, which the same section of the draft says does not stop an attacker who is already inside the zone. In a chemical plant, the controller that holds a batch reactor at temperature sits a few network hops from the operator screens that display it, the engineering workstation that programs it, and the historian that logs its readings. Industrial security has long protected that cluster by putting a firewall on its boundary and trusting what is inside. The new draft of&nbsp;NIST SP 800-82, the U.S. government's reference guide for OT security, now addresses zero trust directly, and the line it draws runs straight through that cluster.The draft organizes its guidance around the&nbsp;Purdue model, the standard way of layering a plant network, and its zero trust recommendation centers on the upper layers:Purdue levelWhat lives thereDraft's zero trust scope4-5Business ITTypically in scope3.5OT DMZ, the buffer between plant and businessTypically in scope3Plant-wide operations systems and historiansTypically in scope2Operator screens (HMIs)Zone boundaries1Controllers, mostly programmable logic controllers (PLCs)Zone boundaries0Sensors, valves, and motorsOut of scopeSection 5.3 makes two points a few paragraphs apart:What NIST concedesInside a perimeter, users are typically trusted and given broad access, so 'boundary protection devices between zones do not mitigate lateral movement risks within a zone.' (Section 5.3)Where NIST draws the lineBecause many PLCs, controllers, and HMIs 'do not support the technologies or protocols required to fully integrate with a ZTA implementation,' the draft recommends applying zero trust to compatible devices, such as those typically found at Levels 3, 4, and 5 and in the OT DMZ. (Section 5.3.1)Neither point is wrong, but together they leave the reactor controller where it started, behind a zone boundary that NIST itself says will not stop someone already inside. Why does the line sit at Level 3?The&nbsp;321-page draft presents zero trust as an extension of controls many plants already run: per-session approval of privileged access, OT logins kept separate from corporate ones, scanning of every file and USB drive, and monitoring that can revoke access in near real time. It also keeps the zone model, with firewalls, a DMZ, and a new management network where vendor sessions need just-in-time approval. It layers zero trust on top of zoning, a sensible choice for plants that cannot rebuild their networks.As NIST defines it, zero trust means every request to reach a system is checked close to that system and rechecked continuously, instead of being trusted because of where it comes from on the network. On a server or workstation, software on the machine can hold an identity and enforce that check. A PLC that shipped with a built-in web server and a shared maintenance password can do neither, and replacing controllers to fix that is not something a plant schedules lightly.NIST also adds two cautions: a zero trust component in the path of a request can slow it down or become unavailable, and shared logins, still common on plant floors, weaken any policy based on identity. Few OT engineers will dispute either. What attackers do below the lineLimiting controls at Level 3 have a cost, and joint advisory&nbsp;AA26-097A, first published April 7, 2026 by the FBI, CISA, NSA, and partner agencies and updated July 22, shows it. Iranian-affiliated actors went after PLCs from Rockwell Automation, Schneider Electric, and Siemens in three steps:Connect to the controller using the manufacturer's own programming software.Copy the project file that holds the controller's logic out to attacker infrastructure.Change that logic, in some cases disabling shutdown and alarm logic so systems could enter unsafe conditions without operators being notified.The controllers in the advisory were reachable directly from the internet, a path sound zoning closes. The advisory goes further, recommending firewall rules or access control features on the PLC itself so it accepts communications only from the control devices expected to talk to it. That is device-by-device isolation, the step the draft's zero trust scope stops short of below Level 3, and many controllers either lack those features or make them hard to manage one device at a time.Inside a zone, isolation shrinks what can reach a controller from everything on the network to the few systems that need to, usually an operator panel and an engineering workstation. The workstation then becomes the path to guard, because it runs the same programming software the attackers used. Zero trust without asking the device to participateThe draft's recommended zero trust scope typically ends at Level 3. Isolation enforced in the network can reach the network-connected controllers and operator panels below it.NIST's definition asks for access decisions made close to the resource and re-evaluated continuously. What it does not say is that the actual resource has to make them. The joint advisory highlights the same point, noting that a gateway in front of the PLC "can enable MFA for remote access even if the PLC does not support MFA." For a controller that cannot run software or hold an identity, the decision can live in the network directly in front of it, as long as three conditions hold:Find every device without disrupting it. NIST treats an accurate asset inventory as foundational and warns that active scanning can disrupt plant systems. Discovery that works from the traffic devices already send avoids that risk.Isolate each device individually. When each controller sits in a network segment of its own, or shares one only with the devices it talks to constantly, nothing else can reach it except through policy, including devices inside the same zone.Make the decision locally. The draft wants time-critical control functions able to operate locally, and a check that sends plant traffic to a distant data center adds the delay NIST warns about.Zscaler Zero Trust Branch is built around those conditions. Typically deployed at Level 3 or 3.5 in a&nbsp;Zero Trust Purdue architecture, its&nbsp;OT/IoT segmentation discovers and classifies devices from the traffic moving between them, without agents, scanners, or network access control. It then places each device in a segment of its own, so device-to-device connections pass a policy decision, with no re-addressing and no production downtime. That reaches network-connected controllers at Level 1 and operator panels at Level 2, the levels the draft leaves to zone boundaries.The appliance at the site becomes each device's gateway, so device-to-device policy is enforced locally with no round trip to the cloud, which answers the latency concern NIST raises. For the redundancy NIST requires, sites typically run the appliances as an&nbsp;active and standby pair. Devices that need to talk constantly or ones which can’t support a network of one, such as a controller and the operator panel that watches it, can&nbsp;share a small segment and communicate directly, while anything leaving that segment still passes policy. Traffic headed beyond the site goes to the Zero Trust Exchange, where&nbsp;internet, SaaS, and private application policy is applied, so a compromised device cannot reach past the plant either.Remote access also follows NIST's management-network pattern.&nbsp;Zscaler Privileged Remote Access brokers vendor and engineer sessions through the Zero Trust Exchange with no inbound ports open at the plant. It injects credentials from a vault and rotates them, so vendors never hold a password and shared logins stop circulating on the plant floor. Files a technician moves into a session can be scanned and detonated in&nbsp;Zscaler Cloud Sandbox before they reach the target, the remote-session counterpart to the file scanning NIST lists as zero trust in practice. Sessions are&nbsp;time-bound and recorded, which addresses&nbsp;the vendor access problem we see in almost every OT workshop.If something still manages to get in, the Ransomware Kill Switch tightens device-to-device policy in graduated steps, the isolation discipline laid out in our&nbsp;analysis of CI Fortify.It’s also important to understand the limits. Level 0, the sensors, valves, and motors wired directly to controllers, sit outside any network-based control and are generally protected through the controller. Isolation also cannot fix weaknesses in a specific controller or stop an attacker who already holds an expected device such as the engineering workstation, so the run-mode switch, programming protection, patching, and project-file integrity checks in the joint advisory still apply. A site that loses its cloud connection entirely needs its own isolation plan, which the CI Fortify guidance covers. Three things to do before the comment period closesFirst, map the carve-out against your own plant by listing what can reach each controller today, area by area. If the answer is anything in the zone, that is the exposure Section 5.3 describes.Second, inventory the connectivity nobody approved. The draft warns that cellular modems and vendor-managed connections can bypass enterprise and OT security controls and tells operators to inventory, approve, and restrict them.Third, comment. The Level 3 line is drawn around what the devices can do. Its control overlay already lists isolation of system components for high-impact systems, with no OT-specific discussion attached. Asset owners who have isolated controllers below Level 3 without asking the devices to participate can tell NIST so by emailing&nbsp;sp800-82rev4@nist.gov by November 30, 2026, using the comment template on the&nbsp;draft's publication page.To see where your plant stands against the draft,&nbsp;request an OT architecture workshop and we will map what can reach your controllers today. You can also&nbsp;hear from our customers directly on how they use Zscaler for OT security.]]></description>
            <dc:creator>Bryan Ashley (Zero Trust Networking, Principal Architect)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Ransomware Data Theft Surged 275% in 2026: Schools, Hospitals, and Government Agencies Had Some of the Largest Claims]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/ransomware-data-theft-surged-275-2026-schools-hospitals-and-government</link>
            <guid>https://www.zscaler.com/blogs/product-insights/ransomware-data-theft-surged-275-2026-schools-hospitals-and-government</guid>
            <pubDate>Thu, 01 Oct 2026 16:19:24 GMT</pubDate>
            <description><![CDATA[Data exfiltrated by leading ransomware groups jumped 275.8% year over year to 896.2 terabytes, according to the&nbsp;Zscaler ThreatLabz 2026 Ransomware Report. That is more than seven times the volume recorded during the 2023–2024 reporting period. As organizations move more sensitive information through modern digital operations, and increasingly through AI-enabled systems, attackers have more high-value targets to steal and more ways to pressure victims once they do.Government, education, and healthcare organizations were among the largest individual data theft incidents observed during the reporting period. Below, we break down what ThreatLabz observed across each sector, including a notable surge in attacks on utilities, and why these industries continue to attract ransomware campaigns. For the full view across industries and threat groups, download the&nbsp;Zscaler ThreatLabz 2026 Ransomware Report. How initial access is changingMany ransomware groups are shifting away from relying solely on malware delivery. ThreatLabz uncovered an initial access broker targeting employees who held&nbsp; manager positions primarily in non-technical departments such as accounting/finance, sales, operations, HR, and marketing, where a single compromised identity can open doors to sensitive data and essential services. Playbooks like spam bombing, IT-themed Microsoft Teams vishing, and abuse of legitimate support tools help adversaries gain a foothold quickly.Generative AI is making these playbooks easier to execute. ThreatLabz observed AI accelerating everything from reconnaissance and social engineering to malware development, including a surge in new malware families where tooling appeared to have been created with GenAI assistance. Some of the largest data theft claims involved government, education, and healthcareBased on activity visible on ransomware leak sites, organizations in these sectors were tied to some of the largest data theft incidents observed during this reporting period.Government. Ransomware attacks targeting government organizations declined 27% year over year, and the sector ranked ninth overall. Despite the decrease, government organizations were tied to the largest data theft claim in the ThreatLabz dataset: Babuk2 claimed to have stolen 30 TB of data from a government organization.Healthcare. Healthcare ransomware activity declined 24% year over year, but the sector remained one of the most targeted industries overall, ranking fourth. INC Ransom claimed to have stolen 20 TB of data from a large healthcare organization, one of the largest claims in the dataset. In a separate incident, attackers used spam bombing and IT-themed impersonation to gain initial access, then pursued extortion without encrypting systems. The victim paid a $2 million ransom even though files were never encrypted.Education. Ransomware activity targeting education declined 17% year over year, with the sector ranking eleventh. Pear, a relatively new ransomware group, claimed to have stolen 16 TB of data from a U.S. university. ShinyHunters, first observed in 2025, also drew attention for an extortion&nbsp;campaign targeting the education sector.Utilities. While utilities had too few victims (10) in the prior year to include in the formal year-over-year comparison, the sector rose sharply by 622% to 65 victim organizations. As the Ransomware Report notes, ransomware attacks on sectors that support essential services carry implications beyond their absolute victim counts, with ripple effects through supply chains and dependent operations.While overall attack volume against government, healthcare, and education decreased year over year, the scale of individual data theft incidents grew. The campaigns are fewer. The damage per campaign is larger.&nbsp; Why these sectors attract ransomware campaignsThese sectors share characteristics that make them effective extortion targets:Compliance pressure is built in. ThreatLabz found that during ransom negotiations, threat actors often cite regulatory requirements, including HIPAA, SEC disclosure rules, and GDPR, directly to intensify pressure on victims. This tactic applies across industries, but for highly regulated sectors like government and healthcare, the stakes are especially acute. The theft of protected records can itself constitute a regulatory breach, meaning compliance and legal consequences are already locked in regardless of whether the ransom is paid to prevent public exposure.Trust is a currency. For government agencies, healthcare providers, schools, and utilities, a breach can become a community-wide event, not just an IT issue.Downtime carries outsized consequences. Essential services create urgency and have limited tolerance for prolonged disruption. How to strengthen ransomware defensesThe scale and sophistication of ransomware threats in 2026 demand both immediate and strategic action:Adopt a zero trust architecture. Remove implicit trust and enforce least-privilege access across users, devices, and workloads. Connecting users to specific applications rather than placing them on the network limits what a compromised identity can reach and prevents the lateral movement that leads to large-scale data theft.Inspect encrypted traffic. Real-time TLS/SSL inspection is critical because payload delivery and C2 traffic are often hidden inside encrypted flows.Treat data as the primary target. The incidents in this report show that data exfiltration, not encryption, is driving extortion. Use inline DLP controls and plan for exfiltration scenarios with clear incident response playbooks.Fight AI with AI. Apply AI-powered tools to identify patterns, detect anomalies, and accelerate response, especially as attackers use GenAI to scale social engineering and develop new tooling.See our full ransomware prevention guidance and best practices in the report.The ThreatLabz 2026 Ransomware Report offers deeper analysis of ransomware trends, attacker tactics, and victim data across all industries, along with detailed guidance on how a zero trust architecture mitigates ransomware risk. Download the full report here.]]></description>
            <dc:creator>Adam Ford (Chief Technology Officer)</dc:creator>
        </item>
        <item>
            <title><![CDATA[ZDX Agent: Agentic IT Operations for Admins]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/zdx-agent-agentic-it-operations-admins</link>
            <guid>https://www.zscaler.com/blogs/product-insights/zdx-agent-agentic-it-operations-admins</guid>
            <pubDate>Wed, 30 Sep 2026 15:34:04 GMT</pubDate>
            <description><![CDATA[Help IT teams quickly pinpoint whether user experience issues stem from the device, network, Zero Trust Exchange, or application so secure access through the Zscaler Zero Trust Exchange also delivers a better digital experience.SASE has changed how users connect to applications. Instead of backhauling traffic through legacy networks, users connect from anywhere, over any network, to private apps, SaaS platforms, and the internet through a cloud-delivered security architecture.That shift is essential for Zero Trust transformation, but it also changes how IT teams troubleshoot. Traditional monitoring tools rely on siloed point-agents, one for device health, another for network pathing, and another for application monitoring. Because these point-products operate in isolation, they lack the shared end-to-end context required to solve complex SASE performance issues, resulting in war rooms and finger-pointing.When a user says, “Salesforce is slow,” “Zoom is choppy,” or “I can’t access an internal app,” the issue could be caused by the endpoint, Wi-Fi, ISP, DNS, Zscaler Zero Trust Exchange, or the application itself.For IT, network, security, and service desk teams, the hardest question in SASE is often:Is this performance issue caused by my SASE deployment, the network, the user’s device, or the application?That is where&nbsp;Zscaler Digital Experience (ZDX) becomes critical and where ZDX Agent, part of Zscaler’s ZAgent, empowers admins with Agentic IT Operations.&nbsp; The operational gap in SASESASE brings networking and security together in the cloud. But when troubleshooting still depends on manually pivoting across dashboards, logs, tickets, and team handoffs, IT operations can remain slow and fragmented.A single user issue can trigger multiple teams:The service desk checks the endpoint.Network operations checks Wi-Fi, ISP, and routing.Security teams check access policy, ZIA, or ZPA behavior.Application teams check SaaS or private app health.Each team may have a piece of the answer, but not the full picture. The result is often finger-pointing, escalation, and lost productivity.ZDX helps solve this by monitoring digital experience across the full user-to-application path, including the SASE deployment, the network, the user’s device, or the application. ZDX Agent takes that one step further by allowing teams to ask questions in natural language and receive a structured root cause analysis with supporting evidence and suggested remediation steps. What is ZDX Agent?ZDX Agent is an AI-powered digital experience agent that helps IT teams investigate user experience issues using natural language.Instead of starting with, “Which dashboard should I open?” teams can start with the issue they need to solve:“Why is this user having a poor experience?”“Analyze Wi-Fi health for all users in the San Francisco office.”“Troubleshoot Zoom call performance for this user.”“Which network leg is causing latency?”“Why did users experience poor performance for Salesforce Lightning in the last 12 hours?”ZDX Agent can help analyze signals across device health, Wi-Fi, network path, ISP performance, application response, collaboration tools to suggest remediation steps.To move teams from symptom to resolution instantly, ZDX Agent combines three core AI skill sets into a single interface:Knowledge Skills: Instantly answers how-to queries and architectural guidance, eliminating time spent searching through technical documentation.Data Analytics Skills: Automatically scans days of raw network, endpoint, and security telemetry in seconds to surface hidden Wi-Fi, ISP, and application anomalies.Troubleshooting Skills: Executes end-to-end root cause investigations across the entire SASE path and delivers clear, actionable remediation steps for IT teams to execute immediately.The goal is simple: help teams move from symptoms to evidence to resolution faster. Why ZDX Agent matters for the Zscaler Zero Trust ExchangeThe Zscaler Zero Trust Exchange securely connects users, devices, workloads, and applications without placing users on the corporate network. It enforces policy close to the user, brokers access based on identity and context, and helps organizations deliver secure connectivity at scale.But secure access and great user experience must go together. If users are protected but struggling with slow SaaS performance, poor call quality, or intermittent access, IT needs to know why and fast.ZDX provides the experience telemetry. ZDX Agent helps turn that telemetry into answers.Together, they help teams understand:Whether a problem is isolated to a user, location, app, ISP, or network pathWhether performance degradation is related to endpoint health, Wi-Fi, Zscaler path, policy, or application responseWhether an issue should be owned by IT, NetOps, SecOps, an ISP, or an application teamWhich actions can help restore user productivity fasterIn other words, ZDX Agent helps make the Zero Trust Exchange not only secure and scalable, but also observable, explainable, and easier to operate. Use case 1: Determining whether the issue is SASE, the network, or the appIn a SASE environment, users connect through multiple layers: endpoint, local network, internet, Zscaler services, and the destination application. When performance drops, IT teams need to understand where the degradation occurred before they can engage the right team.With ZDX Agent, teams can start with a prompt such as:“Troubleshoot slow application performance for this user.”ZDX Agent can analyze the user-to-app path and help determine whether the issue is tied to endpoint resources, Wi-Fi signal, network latency, Zscaler path, or the application itself. Why it matters for SASE: Teams can distinguish between security service issues, network conditions, and application-side degradation faster, reducing unnecessary escalations and helping users get back to work. Use case 2: Reducing MTTR across Wi-Fi, ISP, and routing issuesIn hybrid work, many user experience issues start outside the enterprise network. Employees connect from home, branch offices, airports, cafés, and customer sites. Local networks and ISPs are often outside IT’s direct control, but they still shape how users experience SASE.ZDX Agent can help teams investigate questions such as:“Which network leg is causing latency?”&nbsp;OR&nbsp;“Analyze Wi-Fi health for users in this office.”The agent can correlate Wi-Fi quality, roaming behavior, access point health, ISP latency, packet loss, and application experience. This is especially useful for NetOps teams trying to determine whether an issue is local, regional, ISP-related, or tied to a broader service path.Think about a complex escalation that requires many people and many hours to diagnose before it gets traced to an intermediate ISP. With ZDX and agentic troubleshooting, that type of investigation can be accelerated because the relevant telemetry is already correlated across the user-to-app path.Hear directly from our customers, on how to use ZDX Agent to diagnose and solve his Wi-Fi and app issues.&nbsp;Why it matters for SASE: A poor network underlay can look like a SASE issue. ZDX Agent helps prove where the problem lives, so teams can take targeted action instead of guessing. Use case 3: Distinguishing policy issues from performance issuesSecurity teams are often pulled into performance escalations because users assume the security platform is blocking or slowing access. Sometimes the issue may involve policy. Other times, the root cause is Wi-Fi, ISP latency, DNS, application response time, or endpoint health.ZDX Agent can help security and IT teams ask:“Is this access issue caused by policy or network degradation?”&nbsp;OR&nbsp;“Which apps have slow server response times on a direct path?”This helps teams determine whether an issue is related to ZIA, ZPA, policy behavior, or something outside the security control plane.Why it matters for SASE: Zero trust requires strong policy enforcement, but users still expect seamless access. ZDX Agent helps teams validate whether policy is working as intended while identifying non-policy causes of poor experience. Use case 4: Empowering the service desk with expert-level troubleshootingMany digital experience issues begin as service desk tickets. The challenge is that L1 and L2 teams may not have deep expertise across networking, endpoint performance, Zscaler architecture, SaaS behavior, and collaboration tools.ZDX Agent helps close that skills gap by giving analysts a guided way to investigate issues such as:“Why did this user’s experience drop today?”&nbsp;OR&nbsp;“Troubleshoot Teams call quality for this user.”Instead of escalating immediately, the analyst can receive a structured report with likely root cause, supporting evidence, and recommended next steps.&nbsp;Why it matters for SASE: As SASE environments scale, operational expertise must scale with them. ZDX Agent helps more teams resolve issues directly and escalate with better context when specialized support is needed. From dashboard-driven to question-driven operationsTraditional operations are dashboard-driven. Teams must know where to look, which metrics matter, and how to connect signals across tools.ZDX Agent, an Agentic IT Operations for Admin solution, is question-driven. Teams start with the outcome they need:“Find the root cause of poor experience for these users.”“Show me whether this issue is isolated to one location.”“Identify whether the problem is Wi-Fi, ISP, Zscaler path, or the application.”That shift matters because SASE operations are inherently cross-domain. User experience depends on multiple systems working together. ZDX Agent helps analyze those systems together. Making ZDX value clear in a SASE architectureZDX makes digital experience visible across the full path from user to application. ZDX Agent makes that visibility easier to consume and act on.For organizations adopting SASE, this means:Faster troubleshooting: Reduce time spent manually correlating data across domains.Clearer ownership: Identify whether the next step belongs to endpoint, network, security, ISP, or application teams.Better user experience: Detect and resolve issues that affect productivity.Stronger confidence in zero trust: Prove that secure access is working—and quickly isolate when something else is not.More scalable operations: Give service desk, NetOps, and security teams a common experience-driven source of truth.The result is a stronger operational foundation for the Zscaler Zero Trust Exchange: security teams can enforce zero trust, IT teams can monitor experience, operations teams can troubleshoot faster, and users can stay productive. The future of SASE is autonomous and experience-awareSASE has already transformed secure access. The next step is transforming how that environment is operated.Because in a SASE world, the question is no longer just:“Is the user secure?”&nbsp;It is also:&nbsp;“Can the user work, and if not, do we know why?”With ZDX Agent, IT teams can answer that question faster, with evidence, and with a clearer path to resolution.Watch the latest&nbsp;ZDX Agent webinar featuring a customer panel with Salesforce.]]></description>
            <dc:creator>Cynthia Tu (Sr. Product Marketing Manager, DEM)</dc:creator>
        </item>
        <item>
            <title><![CDATA[What&#039;s New in GovCloud: September 2026 Zscaler Product Updates]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/what-s-new-govcloud-september-2026-zscaler-product-updates</link>
            <guid>https://www.zscaler.com/blogs/product-insights/what-s-new-govcloud-september-2026-zscaler-product-updates</guid>
            <pubDate>Wed, 30 Sep 2026 14:13:22 GMT</pubDate>
            <description><![CDATA[With fiscal year-end, audit cycles, and shifting mission priorities all competing for attention, it's easy for product updates to stack up unread. Here is a curated roundup of notable Zscaler GovCloud updates from September, with quick context and scan-friendly takeaways you can share across security, network, and operations teams. Highlights include the rollout of Experience Center (a unified management console for the Zero Trust Exchange platform), AI-powered application segment recommendations in ZPA, a fully managed Zero Trust Gateway offering in AWS, and expanded DLP controls for Google Drive link expiration and Claude tenant profiles in ZIA. Experience Center, Unified Management ConsoleZscaler has started rolling out Experience Center to GovCloud. Experience Center is a unified, cloud-native management console for the Zscaler Zero Trust Exchange platform. It is designed for CISOs, CIOs, network administrators, cybersecurity practitioners, and service desk teams who manage zero trust security policies, endpoint agents, internet and SaaS access, private application access, and digital experience monitoring.Experience Center consolidates these management functions into a single interface with persona-driven workflows, role-based access control, and unified analytics, replacing the fragmented multi-console workflows that traditional point product environments require.For more details, check out our blog. Zscaler Internet Access (ZIA)Zscaler Internet Access (ZIA) is Zscaler's secure internet and SaaS access service, providing policy-based protection and visibility for users wherever they work. For many federal environments, ZIA is central to enforcing acceptable use, protecting sensitive data, and maintaining consistent security controls across a distributed workforce.This month's ZIA updates expand governance controls for generative AI applications, strengthen DLP capabilities with proximity matching and automated link expiration, and extend cloud app control for Google Gemini.HighlightsSupport for Claude in Tenant Profile: The Tenant Profiles feature now extends to the Claude application, allowing admins to provide access to specific workspace IDs for Claude. This helps agencies govern AI application usage at a tenant level. (FedRAMP Moderate and High)Support for External Link Expiration in Google Drive: Admins can now set periodic or custom expiration periods for Google Drive links (internal or external), after which file access is automatically revoked. Four new expiration-based actions are available in the Edit DLP rule window (Remove Collaborators, Remove External Sharing Links, Remove Internal Sharing Links, and Remove Sharing After Expiry), with manual expiration available under Remediation Actions on the SaaS Assets with Incidents page and matching fields added to the /casbDlpRules APIs. (FedRAMP Moderate)Support for New Match Type on Custom DLP Dictionaries: Custom DLP dictionaries now support near and not-near proximity matching, letting admins define how close (in bytes) phrases from phrase groups must be for a dictionary to detect and count them as a match. This adds precision to content detection without requiring additional dictionaries. (FedRAMP Moderate and High)Cloud App Control Policy: Upload Action for Google Gemini: The Cloud App Control policy now supports a granular Uploading action for the Google Gemini application and its instances, added under Allow application access in the Add/Edit AI &amp; ML Rule window. (FedRAMP Moderate and High)Expanded SSPM Controls for Box: Four new Advanced SaaS Security Posture Management controls were added for Box. (FedRAMP Moderate and High)For full release notes: https://help.zscaler.us/zia/release-upgrade-summary-2026 Zscaler Private Access (ZPA)Zscaler Private Access (ZPA) provides secure, zero trust connectivity between users and private applications without exposing those applications to the internet. It helps organizations reduce attack surface while improving access experience, which is especially important for distributed users, mission partners, and hybrid work environments common across federal agencies.This month's ZPA updates introduce AI-powered capabilities in Limited Availability that help teams optimize application segment configuration and gain visibility into segment usage patterns.HighlightsAI Recommendations for Application Segments (Limited Availability): ZPA now offers AI-powered recommendations for application segments. This feature analyzes user logs and suggests application segments based on application similarity or user behavior, helping teams refine their segmentation strategy and reduce manual configuration effort. (FedRAMP Moderate and High)Application Segments Usage (Limited Availability): Admins can now view or download Application Segments Usage reports from the Zscaler Admin Console to review which application segments are actively used and which user groups are accessing them. This provides visibility that supports access reviews and optimization. (FedRAMP Moderate and High)For full release notes: https://help.zscaler.us/zpa/release-upgrade-summary-2026 Zscaler Digital Experience (ZDX)Zscaler Digital Experience (ZDX) provides visibility into end-user device health, application performance, and network path quality. For federal teams managing distributed endpoints across agencies and field locations, ZDX helps identify and resolve experience issues before they impact productivity or mission delivery.This month's ZDX updates deliver Cloud Path probe enhancements and a refreshed filter design across the console.HighlightsTCP Type Enhancements: Admins can now select a specific TCP traceroute type when configuring a Cloud Path probe. Resilient TCP retries using the Conventional TCP type if the initial connection fails, while Strict TCP does not fall back if the connection fails. These options give teams more control over probe behavior in environments where firewalls may block SYN-based traceroutes. (FedRAMP Moderate and High)Design Update for Filters: Filters across ZDX have been updated with a new color palette and typography for improved readability and consistency. (FedRAMP Moderate and High)For full release notes: https://help.zscaler.us/zdx/release-upgrade-summary-2026 Zscaler Client ConnectorZscaler Client Connector is the unified endpoint agent that steers traffic to ZIA, ZPA, and ZDX services. It ensures consistent policy enforcement regardless of where users connect from, which is critical for agencies supporting remote and hybrid workforces.This month includes a significant Windows release, an Android/ChromeOS update addressing multiple security vulnerabilities, and Admin Console fixes.HighlightsZscaler Admin Console 4.5.5: Fixes a pagination issue affecting user search results on the Enrolled Devices page, a Device Details file download timeout, a blank Protocol dropdown when adding a custom IP-based application bypass in Experience Center, and a sync issue where users added to groups already entitled to Private Access did not receive access after Update Policy. (FedRAMP Moderate, August 14; FedRAMP High, August 7)Zscaler Client Connector 4.9.0.465 for Windows: Addresses a range of stability and connectivity issues, including a stuck Restarting service status, Internet Unreachable errors over machine tunnels in no-default-route environments with an explicit proxy, partner-tenant reauthentication failures, slow connections with many hostname-based trusted networks, Endpoint DLP detection when enabled pre-enrollment, disconnections with FIPS libraries, several VDI re-enrollment and AWS Windows Server issues, slow app loading from loopback proxy delays, and excessive memory use with unsupported certificates. Parallel maintenance releases 4.8.0.300 and 4.7.0.376 shipped the same day.Zscaler Client Connector 4.2.0.173 for Android and ChromeOS: Adds support for the ind.zscalertwo.net subcloud, fixes multiple Firebase-reported crashes, and addresses security vulnerabilities including a local denial-of-service vector (CVSS 7.0), remote code execution vulnerabilities (CVSS 7), and an authentication bypass for portal-only communications (CVSS 6.8). Also fixes a ChromeOS-only authentication failure with Google Workspace Always On VPN and improves Z-Tunnel 2.0 and Private Access reconnection after connectivity is restored. A follow-up release, 4.2.0.174, fixes a reauthentication failure introduced in 4.2.0.173.Additional Releases: Windows 4.9.0.455 and 4.8.0.291 include installer mitigation logic for a rare blue-screen upgrade condition, a Firewall posture check fix, and a captive-portal high-CPU fix.For full release notes: https://help.zscaler.us/client-connector/release-upgrade-summary-2026 Cloud &amp; Branch ConnectorZscaler Cloud &amp; Branch Connector helps extend Zscaler policy enforcement and traffic forwarding for workloads running in public cloud environments. It supports organizations that need consistent security controls for cloud-hosted services while enabling architectures aligned to modernization initiatives.This month introduces a fully managed, cloud-native security offering in AWS, available in Limited Availability.HighlightsZscaler Zero Trust Gateways in Amazon Web Services (Limited Availability): Zscaler has introduced a fully managed, cloud-native SaaS security offering in AWS that allows organizations to secure workload traffic and eliminate the need to manage security infrastructure in their AWS environment. It provides the same security controls for cloud-to-internet and cloud-to-cloud communication. Zscaler supports AWS commercial on the FedRAMP Moderate cloud. (FedRAMP Moderate)For full release notes: https://help.zscaler.us/cloud-branch-connector/release-upgrade-summary-2026 Authentication Service (Zidentity)The Zscaler Authentication Service (Zidentity) provides centralized identity and access management for the Zscaler platform. It supports authentication policies, MFA enforcement, and user lifecycle controls that help agencies meet identity-centric zero trust requirements.HighlightsCustomize Password Policy: Admins can configure the password policy to deactivate a user account after a specific number of unsuccessful authentication attempts and reject a specific number of previously used passwords. Both values are customizable from 3 to 10 in the Zscaler Admin Console. (FedRAMP Moderate and High)For full release notes: https://help.zscaler.us/zidentity/release-upgrade-summary-2026 ConclusionWant the full details? Use the links above to review the complete release summaries, and check back next month for the next GovCloud update roundup.Zscaler continues to invest in a robust GovCloud roadmap and remains committed to supporting the unique security, compliance, and operational requirements of the federal market. We'll keep delivering enhancements that help agencies and federal partners strengthen resilience, simplify operations, and advance mission success.]]></description>
            <dc:creator>Jose Arvelo Negron (Manager, Sales Engineer)</dc:creator>
        </item>
        <item>
            <title><![CDATA[What’s New in Zscaler SSE]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/what-s-new-zscaler-sse</link>
            <guid>https://www.zscaler.com/blogs/product-insights/what-s-new-zscaler-sse</guid>
            <pubDate>Mon, 28 Sep 2026 19:30:00 GMT</pubDate>
            <description><![CDATA[IntroductionMore than half of the Fortune 500 and over 40% of the Global 2000 already run on Zscaler. They moved security to the cloud, inline and close to the user, sending their traffic through the world's largest inline security cloud.Enterprises running firewalls and VPN could argue they had time. AI has taken that argument away.Attackers now use AI to turn a disclosed CVE into a working exploit in hours, generate malware variants faster than signature pipelines can catalog them, and stand up phishing sites that vanish before reputation feeds notice them. Research shows defenders had roughly 63 days between disclosure and exploitation in 2018; today, exploitation routinely happens before a patch exists. At the same time, traffic is moving to WebSockets, QUIC, and HTTP/3 that appliance-era inspection was never built to parse. And the post-quantum shift isn’t coming; it’s here. Browsers already negotiate post-quantum key exchange by default, which means a growing share of encrypted traffic is invisible to any inspection layer that can’t keep up.&nbsp;Perimeter architectures cannot close either gap. A firewall that has to backhaul, decrypt and correlate after the fact is losing a race it was never designed to run, and it can’t inspect a handshake it can’t join. The only architecture built for machine-speed threats is one that inspects every transaction inline, in the cloud, at the moment it happens, including traffic that’s already post-quantum.That is the architecture the world's largest enterprises already chose.At&nbsp;ZenithLive 2026, we introduced major architectural advancements across both&nbsp;Zscaler Internet Access (ZIA) and&nbsp;Zscaler Private Access (ZPA). Together, they represent a unified philosophy: every transaction across the internet, SaaS, and private applications must be subjected to real-time Zero Trust verification without adding operational complexity.Here is a small but important subset of new capabilities across the platform.Part 1: What’s New in Zscaler Internet Access (ZIA)Inline security is only as effective as the traffic that receives an actual, real-time verdict. When inspection engines induce latency, teams resort to exceptions where breaches occur. The latest innovations in ZIA focus on closing inspection blind spots, eliminating latency tradeoffs, and equipping SOC teams with rich transactional context.1. Zscaler is Post-Quantum Ready.&nbsp;Enterprise traffic is moving to protocols designed for speed and future cryptographic resilience. Inspection engines must keep pace:Post-Quantum Cryptography (PQC) Readiness: Most post-quantum coverage focuses on "harvest now, decrypt later" – an adversary recording encrypted traffic today to break it once a sufficiently capable quantum computer exists. That risk is real, the timeline is genuinely unknown, and nobody who tells you they know the date does.But there's a nearer-term problem that gets far less attention, and it isn't hypothetical. Browsers already negotiate hybrid post-quantum key exchange by default. As server-side support spreads, more and more sessions will complete a handshake your inspection layer cannot participate in. At that point a middlebox has two options, and both are bad: fail open and lose visibility, or fail closed and break the connection. The question that matters in 2026 isn't, “am I quantum-safe?” It's “when both endpoints go post-quantum, do I go blind?”So we sequenced our work as visibility, then inspection, then forwarding:PQC visibility and analytics: Classical versus post-quantum cipher usage across your traffic, a crypto inventory to plan migration against, and six new Web Insight logging fields covering client and server key exchange algorithms, digital signature algorithms, and client-side proposals. You cannot plan a migration you cannot measure, and most organizations currently cannot measure this. This is available today to Zscaler customers.PQC traffic inspection at scale: TLS inspection with hybrid ML-KEM / DH key exchange, delivering real-time inspection and policy enforcement across every combination: PQC client to PQC server, classical client to PQC server, and PQC client to classical server. No configuration change is required to start seeing PQC traffic. In beta now, this feature will be in limited availability later this year.IPsec with post-quantum pre-shared keys: quantum-safe forwarding to Zscaler from PPK-capable VPN gateways on your premises, so the tunnel carrying the traffic is protected on the same terms as the traffic itself. This feature will be available to customers early next year.&nbsp;Alongside these, two controls for organizations with specific cryptographic obligations:&nbsp;custom crypto profiles, which let administrators configure, restrict or prioritize cipher suites during TLS inspection with per-profile minimum TLS versions, and&nbsp;custom certificate key lengths supporting RSA-4096 and ECDSA P-256 for intermediate certificates driven largely by German BSI requirements, though the applicability is broader.Modern AI Protocols (WebSockets, QUIC, HTTP/3): Because streaming AI interfaces rely heavily on WebSockets for real-time model interaction, ZIA delivers deep bidirectional text inspection across sanctioned applications (including Microsoft Copilot and Grammarly), alongside native enforcement for QUIC, HTTP/3, and WebTransport. In beta now; this feature will be in limited availability later this year.2. Eliminating Sandbox Latency: AI Instant Verdict and CDRThe historical dilemma of sandboxing has always been the tradeoff between accuracy and latency. Accurate remediation takes minutes; business moves in seconds. When employees need a file immediately, security teams face pressure to allow downloads before analysis completes.AI Instant Verdict: Powered by a model trained on more than 600 million file samples, ZIA now scores files inline. Anything scoring 91–100 is blocked immediately, before it reaches an endpoint. In production, about 91% of files receive an instant benign verdict and are delivered with no perceptible delay, some are escalated for deeper dynamic analysis, and about some are blocked outright. Throughput runs to 10,000+ files in 20 minutes.The point is not that the model replaces detonation. It doesn't – the 9% still goes to the sandbox, and that's where it belongs. The point is that the common case stops waiting on the uncommon one. This feature is available today.Content Disarm and Reconstruction (CDR): For workflows where a file is likely benign but immediate access is critical,&nbsp;CDR strips active macros and embedded scripts from Office documents and PDFs, reconstructing a sanitized version in real time. Rather than debating allow-versus-block, users get safe files instantly while eliminating file-based attack surfaces. This feature will be available to all current ZIA customers in Limited Availability starting early next year.Brand Phishing Defense: Modern credential harvesting pages stand up, harvest credentials for six hours, and vanish before URL reputation feeds catch up. ZIA’s brand phishing engine inspects visual layout cues, credential input forms, and page construction in real time, rendering verdicts on zero-hour phishing infrastructure independently of historical domain reputation.This feature will be available to all current&nbsp;ZIA customers in Limited Availability starting early next year.3. Securing the New Executable: Agentic AI and MCP ArchitectureFor thirty years, security stacks assumed malware meant compiled binaries (EXEs, DLLs, ELFs). Today, the definition of an executable has fundamentally changed.As developers and business units deploy agentic AI frameworks, these tools download instruction manifests, skill files, and connect to Model Context Protocol (MCP) servers. A skill file is a plaintext file, but functionally, it is an executable program instructing an autonomous agent to execute actions with user permissions. Conventional security controls overlook them completely.ZIA extends inline enforcement to agentic workflows:Rogue MCP Server Blocking:&nbsp;Prevents local systems, enterprise internal applications, and autonomous agents from establishing connections to unauthorized, vulnerable, or malicious Model Context Protocol (MCP) servers across the network layer. This feature will be available later this year.Agentic Tool Download Inspection:&nbsp;Identifies, inspects, and halts unauthorized agentic AI frameworks and tooling at download time rather than discovering them later at runtime. This feature will be available later this year.Skill File Sandbox Detonation:&nbsp;Inspects and behaviorally analyzes text-based skill manifests and tool instruction files within Cloud Sandbox upon download before they can be loaded by an agent. This automated dynamic analysis catches both known malicious skills and novel variants that lack signatures. This feature will be available later this year.&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4. Comprehensive Visibility: Offline Channels and JA4 FingerprintingInline coverage has a structural blind spot: files that never traverse the network. A contractor's USB stick, an AirDrop between two laptops in the same room, a Bluetooth transfer. These are just a meaningful fraction of ways malware actually arrives in offices.Cloud Sandbox now operates across three channels rather than one:Inline sandbox: real-time blocking of malicious content in traffic.Endpoint Sandbox: unknown EXE and DLL files arriving over offline channels are hashed and queried; if the file is unknown, it's sent to Cloud Sandbox for full analysis, with the client notifying the user while the check runs.API-driven file analysis: on-demand submission for investigation, supporting multiple API keys, so the SOC can push a suspect file through the same engine that makes inline decisions.We also widened what the sandbox can take: EXE and DLL analysis up to 200 MB, and macOS DMG support.JA4 Fingerprinting (Encrypted Traffic Analysis): Certain endpoints such as OT controllers, medical devices, or services with pinned certificates cannot be decrypted. Using&nbsp;JA4 fingerprinting of the TLS handshake, ZIA models baseline communications. When a device that has behaved like a camera for months suddenly negotiates a session characteristic of a command-and-control framework, alerts fire immediately without needing plaintext decryption. This feature is generally available for Zscaler customers.&nbsp;5. SOC Empowerment and ProvenanceThe standard architecture for SOC context is reassembly: EDR, firewall, SWG, NDR, identity and cloud each emit telemetry, and a SIEM correlates it after the fact. Correlation works, but it costs time and it's lossy, i.e. you're reconstructing a single event from artifacts several systems produced independently.Endpoint Context leverages Zscaler’s vantage point in the end-to-end network to change this. Application, process and vulnerability insight from the endpoint feeds directly into detection and enforcement, so the context is attached to the transaction rather than joined to it later. This isn't a reporting improvement; it produces detections that don't otherwise exist.A concrete case:&nbsp;chrome.exe running from a directory it has no business running from, unsigned, with an unknown version, opening a remote connection. No individual signal there is conclusive, and nothing in the packet stream is anomalous. Together they're enough to generate a new IPS signature and block it. A control that only sees the network cannot make that call, because the evidence isn't on the network.The same endpoint intelligence, drawn from 50 million-plus endpoints, has improved command-and-control detection. Our C2 model previously leaned on URL and domain reputation. It now incorporates endpoint-derived context, and we've moved to rate-based C2 detection rather than purely pattern-based, which has reduced false positives noticeably. Living-off-the-land techniques and commodity C2 frameworks such as Cobalt Strike are the primary beneficiaries.AI/ML Detection Attribution: Every alert explicitly identifies the specific underlying model, heuristic, or detection engine responsible for the verdict. Security teams gain transparent auditability rather than opaque "black-box" scores.Closed-Loop MDR &amp; NDR Enforcement: Continuous traffic capture from ZIA to NDR partners like Vectra, ExtraHop, and Corelight improves SOC maturity for incident hunting and early lateral movement detection using rate, anomaly, and heuristic algorithms, significantly enhancing SASE visibility when combined with ZPA traffic. Here is a quick status update on our core NDR integrations:Vectra : Generally Available for AWS S3 environmentsExtraHop :&nbsp; Generally Available for AWS S3 environmentsCorelight : Private preview is active, with public preview scheduled by the end of the yearPart 2: What’s New in Zscaler Private Access (ZPA)While ZIA secures outbound access to SaaS, the web, and external AI models, ZPA governs access to internal crown jewels: proprietary private applications, private AI clusters, and hosted environments.Legacy connectivity models rely on VPN tunnels that terminate external users directly onto internal networks. If an endpoint is compromised, attackers gain unfettered lateral traversal. ZPA fundamentally inverts this model: users and entities are connected strictly to authorized applications, never to the underlying network.At ZenithLive, we introduced key capabilities to automate segmentation, secure unmanaged endpoints, and virtually patch internal vulnerabilities.1. Zscaler Autonomous Application Shield: Machine-Speed Defense for Private ApplicationsFrontier AI models have fundamentally altered the economics of exploitation, compressing the window from CVE disclosure to weaponized, chained exploit from weeks to hours. Yet enterprise remediation remains trapped in human-speed patch cycles, testing windows, and change boards. Autonomous Application Shield is an AI-driven capability natively integrated into ZPA that shifts private application security from reactive ticketing to continuous, autonomous protection:Continuous Posture: App Connectors safely and continuously assess application exposure points, APIs, and runtime risk, replacing periodic scans with a living, real-time security posture.Context-Aware Reasoning: The Zscaler cloud evaluates each application's unique architecture and observed traffic, applying only relevant, targeted protections to preserve performance and eliminate false positives.Global Threat Intelligence: Zero-days and novel attack vectors observed across Zscaler’s global exchange instantly inform and sharpen protection policies worldwide without manual tuning.Pipeline-Speed Virtual Patching: Defenses adapt dynamically as developers push code, deploying automated virtual patches at the App Connector boundary in minutes—neutralizing exploits before a permanent code patch can even be scheduled.Autonomous Application Shield is now open for early access.&nbsp;&nbsp;2.&nbsp;Comprehensive Access Visibility with Autonomous User-to-App SegmentationMost organizations actively manage only their crown jewel applications, leaving the vast majority of internal services and dynamically provisioned cloud workloads unmapped, poorly documented, and dangerously exposed behind overly permissive wildcard application segments (*.internal, *.corp). Traditional network segmentation projects fail because manual traffic analysis and static firewall rules cannot keep pace with modern hybrid cloud velocity.Autonomous User-to-App Segmentation eliminates this blind spot by automating the entire policy lifecycle:1. AI-Driven Automation: Application Fingerprinting and ZPA AgentApplication Fingerprinting: Leveraging machine learning algorithms trained across global enterprise telemetry, ZPA now automatically identifies, categorizes, and labels internal applications based on operational behavior and traffic patterns.Interactive ZPA Agent: Administrators can query complex deployment telemetry using plain language to gain visibility into underlying data alongside interactive telemetry, streamlining audit readiness and troubleshooting workflows.&nbsp;&nbsp;2. See Every Application (Continuous Discovery &amp; Inventory)Passive, Agentless Workload Sensing: Continuously senses and catalogs all active private workloads across on-premises datacenters, public clouds (AWS, Azure, GCP), and OT/factory environments without requiring intrusive endpoint scanners or complex network re-architecting.Surface Hidden Shadow Services: Detects untracked microservices, legacy internal web tools, and uncataloged container endpoints that typically evade standard configuration management databases (CMDBs).Expose Wildcard Risk: Automatically flags overly broad application definitions and wildcard domains that grant excessive IP reachability, giving security teams an authoritative, real-time baseline of their actual attack surface.3. Segment with Intelligence (AI-Powered Policy Recommendations)Behavioral Traffic Analysis: Analyzes historical and real-time user-to-application communication patterns, user identity groups, and transaction behaviors using advanced machine learning models.Automated Least-Privilege Rules: Automatically generates discrete, application-specific segment definitions and context-aware access policies, systematically replacing flat network access with precise, 1:1 micro-tunnels.Frictionless, One-Click Deployment: Allows administrators to review, test, and apply recommended policy boundaries in minutes rather than months, eliminating the risk of business disruption or broken application dependencies.4. Strengthen Security Posture (Posture Governance &amp; Actionable Insights)Continuous Relationship &amp; Dependency Mapping: Visualizes real-time communication pathways between user groups, third-party contractors, and application workloads to detect anomalous access trends or permission drift.Quantifiable Maturity Tracking: Feeds directly into maturity metrics (such as the ZPA App Segmentation Index), evaluating discovery velocity, policy effectiveness, and operational hygiene so teams can track quarter-over-quarter progress.Proactive Attack Surface Reduction: Delivers ongoing, prioritized recommendations to retire dormant policies, tighten access entitlements, and eliminate emerging vulnerabilities before threat actors can exploit them.Ensuring users and compromised devices are connected exclusively to specific, authorized applications, never to the underlying corporate network. This drastically shrinks the breach blast radius. This approach halts lateral threat movement while automating the labor-intensive tasks of application mapping and firewall rule maintenance, which frees security and network engineering teams from endless manual triage. Ultimately, it compresses segmentation deployment schedules from multi-year infrastructure overhauls into a rapid, phased, data-driven rollout with measurable executive reporting, accelerating Zero Trust time-to-value.Autonomous User-to-App Segmentation is available now.&nbsp;&nbsp;&nbsp;&nbsp;3. Secure Cross-Company Collaboration: B2B FederationModern business depends on ecosystem partnerships, from joint ventures and supply chain relationships to mergers, acquisitions, and divestitures. Yet connecting partner users to private applications today means accepting network risk: site-to-site VPNs, shared credentials, and firewall rules that create exactly the lateral movement exposure Zero Trust is designed to eliminate. What makes it worse, this process typically takes months to set up.ZPA B2B Federation changes that. Enterprises can onboard a partner and provide Zero Trust access to private applications in under 30 minutes, without site-to-site VPN tunnels, complex routing tables, or cross-tenant network exposure.Core deployment scenarios include:External Partner Connectivity: Onboard third-party contractors, vendors, and distributors quickly and securely. Partner users get authenticated access only to the applications they need, with Zero Trust policies enforced end-to-end, no network connectivity, no lateral movement risk.M&amp;A Integration and Divestitures: Deliver immediate Day-1 access to essential ERP, HR, and productivity platforms without consolidating networks or merging identity infrastructures. Offboarding requires only a swift policy adjustment.Multi-Tenant Enterprise Deployments: Large enterprises with multiple ZPA tenants can use Federation to simplify app sharing across parent companies and OpCos, while each unit retains control of its infrastructure, applications, and access policies.Federal and Cross-Cloud Environments: Facilitate secure resource sharing across FedHigh, FedMod, and commercial instances without interconnecting physical networks or violating regulatory mandates.&nbsp;&nbsp;4. Securing the Unmanaged Endpoint with Zero Trust Browser Extension for ZPAThird-party contractors, supply chain partners, and BYOD employees frequently require access to sensitive internal systems without having full device management profiles installed:The Zero Trust Browser Extension establishes an isolated, enterprise-controlled workspace directly inside modern web browsers.It enforces deep runtime data-loss prevention, blocking keystroke loggers, screen capture utilities, and clipboard copying.Device posture checks are evaluated locally, ensuring unmanaged endpoints cannot be leveraged as attack vectors into corporate resources.Standalone and hardened Enterprise Browser is also available as an alternative form factor.Zero Trust Browser Extension is available now.&nbsp;The Strategic Path ForwardWhen reviewing your cybersecurity roadmap, the most critical metric is not the sheer count of point products deployed or how many firewall policies are active.The question every executive and security architect should ask is:What percentage of our traffic actually receives an inline, deterministic Zero Trust verdict?If your outbound inspection cannot parse modern streaming protocols, negotiate post-quantum handshakes, or render instant verdicts on files, critical traffic is silently failing open. And if your private applications remain reachable via public IPs and routable VPN connections, an attacker compromising a single user or contractor endpoint can traverse laterally to your data.By combining the real-time inline threat engines of Zscaler Internet Access with the cloaking and autonomous segmentation of Zscaler Private Access, organizations establish a unified Zero Trust fabric. Attacks are stopped cold inline, critical internal workloads remain entirely invisible to the outside world, and enterprises can safely adopt AI and modern cloud architectures at scale.&nbsp;Learn how you can protect your enterprise in this AI-era by visiting our&nbsp;ZenithLive 2026 on-demand event.]]></description>
            <dc:creator>Joby Menon (SVP, Product Management | Zscaler)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Fairlife Had Eleven Days of Runway. Most Food Plants Can’t Buy a Shift.]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/fairlife-had-eleven-days-runway-most-food-plants-can-t-buy-shift</link>
            <guid>https://www.zscaler.com/blogs/product-insights/fairlife-had-eleven-days-runway-most-food-plants-can-t-buy-shift</guid>
            <pubDate>Fri, 25 Sep 2026 21:18:08 GMT</pubDate>
            <description><![CDATA[Black Kite counted 1,183 publicly disclosed ransomware victims in manufacturing in the first seven months of 2026, up 39.7% on the same period last year and already more than in all of 2023 or 2024, and its manufacturing report has ranked the sector the most-attacked industry for five consecutive years. Nearly half of this year's victims were hit by groups absent from the data in 2023 and 2024, some of them rebrands, so newcomers are&nbsp;arriving with the playbook already learned.Black Kite's research chief describes that playbook plainly: one attack can stop production, and every hour of downtime strengthens the attacker's hand, which makes time the thing the attacker is really holding.In most manufacturing, the clock that matters is how long the business can absorb a stopped line. In food and beverage, the clock is printed on the product, and attackers have noticed: the Food and Ag-ISAC&nbsp;counted 227 ransomware incidents against food and agriculture through July, up 62% on the same period last year.This summer's Fairlife incident looked like a disaster in the headlines, and why it wasn't one tells food manufacturers more. What follows is a composite of how these events tend to run, not any one company's timeline, with the facts Coca-Cola disclosed about Fairlife as the bookends. T+0: the alert is in ITRansomware is confirmed on enterprise hosts, and nothing on the plant floor has changed. Lines are running, products are moving, and the first question on the incident bridge is the obvious one: what else did they touch?On July 16,&nbsp;Coca-Cola disclosed in an SEC filing that Fairlife had identified unauthorized access to a portion of its systems, "including its production-related systems," in connection with a ransomware event. Production was suspended at all four US plants, while Canadian production was not affected and product quality and safety were not impacted. Coca-Cola has not said whether anything on the plant floor was reached, which is the shape of most public disclosures. T+2 hours: the question nobody can answerBetween the office and the line sits a layer both sides trust: the MES, recipe management, batch records, quality and lab systems, label printing, and the warehouse system that decides what ships. Every one of them is a Windows or Linux host, and a decade of Industry 4.0 investment connected them to the plant network on purpose.So the bridge question becomes: from the compromised segment, what can actually open a connection to an HMI, a line-side server, a controller, or the systems that write the batch record?In most plants the honest answer at hour two is "we don't know." Oscar Calderon, IBM's OT cybersecurity GRC leader,&nbsp;told Industrial Cyber in September that he has seen production stop when teams could no longer trust control systems, batch records, or quality data, with the equipment itself working fine. If the systems that write batch records and release holds might be reachable, stopping the line is the right call, made with almost no information. T+1 shift: the ledger startsThis is where food and beverage separates from the rest of manufacturing, because everything in the plant was on a clock before the alert.What is waitingWhat it is waiting onHow long it hasRaw inputs in receiving and silosThe line to restart. Raw milk, livestock and crops keep arriving, so lost days become destroyed raw material (Stuart King of AnzenOT, speaking to Industrial Cyber)Hours to a dayProduct in processA sequenced restart. "There is no such thing as a short outage" (King): product stuck mid-line and spoiling, systems reset, trucks at the dockThe shiftFinished goods in cold storageA release decision that needs trusted records. If the HACCP records for a production window are unverifiable, everything made in that window is presumptively suspect (King)Every day offline is a day off the shelf life you sellRetail commitmentsTrucks and shelves. Large retailers now treat cybersecurity and traceability as conditions of doing business (Calderon)Days, and the shortfall is on a shelf in public viewTrust in the systems that feed the lineSomeone to prove the attacker never reached themIndefinite, until provenThe attacker is counting on that last row, and the four above it are why a food plant was chosen in the first place. T+3 days: the negotiation is about datesBy day three the encrypted files matter less than they seem, because backups exist for those. There is usually a data-theft claim too; in Fairlife's case the Anubis group&nbsp;claimed a terabyte, and Coca-Cola&nbsp;confirmed that certain data was taken. In a food plant, the leverage that compounds is whatever goes out of date while the plant proves a negative.Jaguar Land Rover's September 2025 attack halted UK production for about five weeks, and on September 7 this year&nbsp;JLR announced about 4,000 job cuts amid the fallout. That is brutal, but a car does not expire in five weeks, while fresh milk cannot sit anywhere for one. T+11 days: most production resumesOn July 27, Coca-Cola said Fairlife had&nbsp;resumed the majority of production at its four US facilities and that retail availability had been "largely unimpacted, due to the availability of existing inventory." It did not expect a material impact, and the next day CEO Henrique Braun&nbsp;told analysts supply and consumer service had not been affected.From the attacker's side, that is a strange result: eleven days between Coca-Cola's first disclosure and its restoration update, at a brand Coca-Cola says grew from&nbsp;about $10 million to nearly $4 billion in retail value, and the ledger never reached the shelf.That outcome was engineered into the product. Ultra-filtration and higher-temperature pasteurization give Fairlife's milk&nbsp;a far longer unopened shelf life than conventional milk, and its protein shakes are shelf-stable. Enough finished product already in the channel, and a product built to sit on a shelf, gave Fairlife what most food manufacturers lack, which is runway measured in days. It also shaped the response: by Anubis's own account, Fairlife reported the incident rather than follow the instructions left on its network, a choice that is far easier to make while the shelves are still full.Now run the same eleven days at a fresh-milk bottler, a protein plant, a produce packer, or a bakery, where no inventory outlasts the outage. King made the point to Industrial Cyber: a dairy or protein plant with a difficult, sequenced restart takes days to come back regardless of how sophisticated the attacker was. Those are plants that cannot buy a shift, let alone eleven days.In most of these incidents, the length of the outage is not set by the malware. It is set at hour two, when the honest answer to "what can the compromised segment reach?" is "we don't know."Same eleven days. The plant stops on the top clock and pays on the bottom one. Recovery phases are illustrative, not Fairlife's disclosed timeline. What would have to be true at T+2 hoursA plant that cannot buy runway with inventory has one lever left, which is to shorten the outage. The fastest restarts will come from plants that can answer three questions before the incident, whatever the state of their backups.Reach. From a compromised host in IT, or in a supplier's network, what on the plant floor can be connected to at all? If the answer is "most of it," the shutdown decision was made years ago when the network was designed, and the incident is only collecting on it. Food and Ag-ISAC's Jonathan Braley notes that many OT compromises start in corporate IT and move laterally through weak segmentation.Dependency. Which production systems actually need a path to enterprise IT to keep running, and which have one only because the network was built flat? And where do the systems that write batch records and release holds actually live?Proof. Can you show, from records you already keep, what a given host has talked to in the last 30 days, so "we don't know" becomes "we know it never reached the line"?Four controls make those answers short.Segment every device.&nbsp;Zscaler Zero Trust Device Segmentation puts every production asset - controller, HMI, line-side server, vision system, and the MES, batch, and historian servers the line depends on - in a network of one, with no agents to install, no upgrades, and no downtime. A compromised host in IT gets no route to the line, which gives the reach question a one-word answer.Broker access instead of extending the network. OEM technicians, integrators, and your own engineers reach a specific controller for a specific session through&nbsp;Zscaler Privileged Remote Access, with no open RDP, SSH, or VNC ports on the plant, no network path between user and asset, and every session recorded, so the supplier's network never becomes an extension of yours.Let the policy be the dependency map. When every allowed IT-to-plant flow is a policy rather than an accident of addressing, the dependency list is the policy itself, and it exists before the incident, which is when the bridge needs it. Eaton has taken this model across&nbsp;more than 100 manufacturing facilities.Keep the flow record. The same platform discovers and classifies every device on the plant network and records the flows between them, so the proof question is answered from data collected before the incident.Ransomware may still land, but when the plant's dependencies sit inside a boundary you can prove, it lands in IT, the line keeps running, and&nbsp;the restart conversation is about the office. If batch records and release systems still live on the enterprise side, the dependency question is telling you to bring them inside first. Once they are, the ledger does not have to start, whether or not you have eleven days of inventory in the cooler.If you want to know what your own plants would answer at hour two, we run OT architecture workshops that start from your line-side dependencies and work outward:&nbsp;request an OT architecture workshop. &nbsp;Or hear from our customers directly on how they are leveraging Zscaler OT Security solutions in their own environments.]]></description>
            <dc:creator>Bryan Ashley (Zero Trust Networking, Principal Architect)</dc:creator>
        </item>
        <item>
            <title><![CDATA[How to Secure Branch Networks Against Machine-Speed, AI-Driven Cyber Threats]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/how-secure-branch-networks-against-machine-speed-ai-driven-cyber-threats</link>
            <guid>https://www.zscaler.com/blogs/product-insights/how-secure-branch-networks-against-machine-speed-ai-driven-cyber-threats</guid>
            <pubDate>Wed, 23 Sep 2026 15:40:03 GMT</pubDate>
            <description><![CDATA[Anthropic’s&nbsp;Mythos disclosure in April confirmed what network security teams had been bracing for. A frontier model, without cybersecurity-specific training, autonomously discovered and wrote working exploits for thousands of zero-day vulnerabilities, including 181 against a single browser. Most importantly, AI was now able to assemble existing, individually unremarkable vulnerabilities into a working attack chain.That changed the meaning of the CVE backlog for network security teams.&nbsp;Firewalls, VPN concentrators, badge readers, OT controllers: each class of device has its own vendor, its own update process, and its own maintenance window. Some equipment cannot be patched at all — locked to vendor firmware, or running years beyond end of support. So teams triage by severity, fix what they consider critical, and let the rest pile up in the backlog.&nbsp;That way of triaging worked for as long as chaining those CVEs together required a skilled human attacker with plenty of time and patience. Mythos ended that era. The backlog has become the raw material of AI-composed attack chains that can assemble faster than a team can schedule a change window.The Cloud Security Alliance (CSA) has responded to this AI-based threat with their recommendations for getting "Mythos Ready", highlighting&nbsp;eleven priority actions. Most revolve around building the security program: governance, rebuilt risk models, a permanent VulnOps function. But several are about architecture, and those land squarely on the infrastructure that network security teams run every day: the edge devices, the site-to-site mesh, the branch inspection stack, and the change process.&nbsp;When the branch is&nbsp;built like a café, with every site connected to the internet and all connections proxied through the cloud-based Zscaler Zero Trust Exchange,&nbsp; AI attacks chains suddenly stop cold. There’s no attack surface to explore, and there’s no way&nbsp; for malware to move laterally.&nbsp; That model, built on Zero Trust principles, delivers on the architectural actions the CSA calls for. We can condense these into four core tenets:Hide,Contain,Inspect, andRespond.Hide: Remove the Chain’s Starting PointBy nature, legacy networks are inherently exposed to AI-based attack chains. Every branch firewall, VPN concentrator, and SD-WAN appliance with a public IP sits in scanning databases anyone can query, announcing what it is and what version it runs. That identifying detail (vendor, model, and software version) is the device's fingerprint, and it tells an AI attacker exactly which CVEs your team has not fixed yet. The attacker then lines them up one by one, starting with whatever gets it in the door. The next flaw lets it read something it should not, and then a third raises its permissions. Each can be a moderate vulnerability that typically belongs in the backlog, but by exploiting them in sequence, the AI attacker can gain control of the appliance and spread from there.What Zero Trust Branch changes: branch connectivity is outbound-only to the&nbsp;Zero Trust Exchange. No inbound listener, no DNS record resolving to the site, no port that answers a probe. A scan returns no fingerprint, and without one, the attacker has no starting point to build a chain from. All devices and their CVEs are hidden from public view, preventing an AI attacker from finding a foothold to start the chain from.This directly aligns with CSA Priority Action #7 (Inventory and Reduce Attack Surface) by eliminating public reachability. Enforcing an outbound-only footprint also supports CSA Priority Action #4 (Prepare for Continuous Patching). When a device can be fingerprinted from the internet, every unpatched CVE on it is a race against an external attacker. When there is no fingerprint, your team patches on its own change window, not the attacker's timeline.Contain: Collapse the Blast Radius the Chain Depends OnHiding the branch denies an AI attacker a starting point from the internet, but compromise can arrive other ways: a contractor laptop, a vulnerable badge reader, or a poisoned update to a site controller. Once the attacker is inside, traditional network-centric segmentation works in its favor. With access managed based on network subnets, a site-to-site VPN mesh allows every branch to reach every other branch's address space, making the routing table a map for the AI attacker. One compromised device can open a path to every other site and the data center behind them, putting unpatched devices across the estate within reach. At each site, the attacker bypasses legacy network boundaries to enumerate local devices, including the cameras, badge readers, and OT controllers your team cannot patch, testing each one at machine speed.What Zero Trust Branch changes:&nbsp;legacy network-centric segmentation is replaced with software-defined, agentless microsegmentation at the branch edge. The Zero Trust Exchange brokers every connection between users and devices to authorized applications. A compromise in one branch cannot spread to another location. Within the branch, agentless microsegmentation isolates every device into a software-defined "network of one" without requiring complex VLAN redesigns or endpoint agent installations. If an exposed IP camera is compromised, microsegmentation instantly collapses the blast radius—preventing lateral movement and leaving the attacker with nowhere to go.This is the approach CSA Priority Action #8 (Harden Your Environment) calls for, using deep segmentation to limit how far an intrusion spreads once it lands. When each device is isolated, a compromise stays a single-device incident, and the equipment your team cannot patch no longer puts the rest of the estate at risk.Inspect: See the Chain While It Is Still Being AssembledContainment limits where an attacker can go, but they still have to communicate to finish the chain. The attacker reaches out to the internet, pulls down tools, and establishes command-and-control channels, producing traffic with each step. At most branches today, this traffic is inspected by the same local hardware appliance that routes it, and performing full SSL/TLS decryption is a heavy computational burden. When traffic spikes during a backup window or a video-heavy afternoon, the appliance runs out of CPU headroom. To keep the site working, sessions get exempted from decryption which quietly narrows inspection coverage, enabling the attacker's traffic to hide inside ordinary encrypted web sessions. This can persist for weeks inside a branch that falsely believes it is inspecting everything.What Zero Trust Branch changes: inspection moves off the branch appliance and into the cloud-based Zero Trust Exchange. Every flow is inspected, whether it comes from a user or device, and is never scaled back when a site gets busy so attacker traffic cannot hide inside encrypted sessions. Because the Zero Trust Exchange also inspects traffic across thousands of organizations, a threat pattern detected at one branch is immediately shared and blocked across all of them. By forcing every outbound request through this global security fabric, you systematically dismantle the communication channels the attacker needs to complete their chain.This is the other half of CSA Priority Action #8 (Harden Your Environment): egress filtering, which inspects traffic leaving the site to catch a chaining attack before it completes. When inspection is offloaded to the cloud, threat protection holds no matter how busy a site gets, allowing your team to disrupt the attack chain while it is still assembling.Respond: Policy That Moves at Machine SpeedAs inspection uncovers clear signs of an ongoing intrusion, response must take over immediately to stop the attack where it lies. Unfortunately, legacy response remains bottlenecked by manual, human-speed workflows—generating tickets, waiting for emergency change approvals, and logging into individual appliances. This operational latency is outmatched by autonomous, machine-speed AI threats, making every second of delay an open window for the attacker. That time gap is why an organization can have direct visibility into an attack and still be breached by it.What Zero Trust Branch changes:&nbsp;an automated incident response loop eliminates human latency from the defensive path. Security teams pre-approve response playbooks in advance. A confirmed threat signal triggers immediate containment through the Ransomware Kill Switch, completely bypassing triage delays, change approval windows, and manual site-by-site logins. Also, microsegmentation automatically isolates the compromised asset from all other local devices and remote sites by default. By instantly collapsing the threat's blast radius to a single device, this surgical response merges detection and containment into a single, unified event and ensures branch operations continue uninterrupted.This aligns with CSA Priority Action #10 (Build an Automated Response Capability) by enabling systemic, autonomous defense at the edge. When incident response relies on manual tickets and approvals, an AI adversary dictates the pace of the breach. By pre-authorizing automated response playbooks, you shift change control from a frantic, mid-incident scramble to a strategic, pre-built defensive move. Change control still happens, just before an incident rather than in the middle of one.An AI-composed attack chain needs four things: somewhere to land, somewhere to go, somewhere to take cover, and time to work.&nbsp;Your backlog can't take those away. Your architecture can.Zero Trust Branch Puts You in ControlYour team's ongoing triage of the backlog was the right move when chaining CVEs took a skilled human attacker acting at human speed. AI has removed that constraint, and patching faster is now a losing race against a machine. An outdated legacy architecture inherently opens you up to attack by providing the network pathways an adversary needs to build an exploit chain.Zero Trust Branch neutralizes these chains through four tenets that work as a single cohesive set. Hide takes away somewhere to land. Contain takes away somewhere to go. Inspect takes away somewhere to take cover. Respond takes away time required to assemble. An attacker needs all four conditions to finish a chain, and losing even one disrupts their progress. Removing all four ensures that your CVE backlog no longer presents a systemic risk to your enterprise.Connect with our experts for a tailored architectural walkthrough and see how Zscaler secures your distributed branch locations against autonomous AI threats.]]></description>
            <dc:creator>Josh Pederson (Senior Product Marketing Manager - Zero Trust Branch)</dc:creator>
        </item>
        <item>
            <title><![CDATA[What OMB Memorandum M-26-15 Requires for Your Agency&#039;s PQC Migration Plan]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/what-omb-memorandum-m-26-15-requires-your-agency-pqc-migration-plan</link>
            <guid>https://www.zscaler.com/blogs/product-insights/what-omb-memorandum-m-26-15-requires-your-agency-pqc-migration-plan</guid>
            <pubDate>Mon, 21 Sep 2026 20:41:44 GMT</pubDate>
            <description><![CDATA[The clock is already running. Here's what compliance with EO 14412 actually demands and where agencies can't afford to miss a step.If you work in security or networking for a U.S. federal agency or a firm that holds federal contracts, Executive Order 14412 is no longer a future concern. It's a present operational mandate. And with OMB Memorandum M-26-15 now in effect, the transition from awareness to accountability is complete.This blog covers what you need to know about the OMB’s guidance so you can include the required information in your PQC transition plan, which is due to the OMB by October 22, 2026. Why EO 14412 Exists: The Threat Is Already ActiveBefore getting into compliance mechanics, it's worth understanding the driving threat model.EO 14412, "Securing the Nation Against Advanced Cryptographic Attacks," is built around one foundational problem: the cryptographic standards protecting federal data today will be broken by cryptographically relevant quantum computers (CRQCs). Some experts believe a viable CRQC could emerge by 2030.Adversaries are already executing "Harvest Now, Decrypt Later" (HNDL) campaigns. They're exfiltrating encrypted federal data today, stockpiling it with the intent to decrypt it once quantum hardware is available. Data with a long operational shelf life, including intelligence sources, health records, and financial instruments, is already compromised in this model. The deadline to act is not 2030. It's now.EO 14412 and the implementing guidance from OMB respond to this by shifting the federal government's posture from "we should plan to migrate" to "migration is policy, with named owners, hard deadlines, and enforceable consequences."Who Owns the Governance StructureEO 14412 establishes clear accountability at the top:OMB Director and the National Cyber Director jointly coordinate the government-wide migration.NIST, CISA, and NSA provide agencies technical implementation guidance.Each agency head was required to designate a PQC Migration Lead within 30 days of the order, a deadline that passed in July 2026.If your agency hasn't named a PQC Migration Lead yet, that is already a compliance gap.The Migration Lead isn't just a title. This individual owns accountability for the entire transition process and is responsible for coordinating across IT, cybersecurity, legal, procurement, and program offices. The cross-functional scope is intentional: PQC migration cannot be solved by the security team alone. OMB M-26-15: The Binding Implementation MemoIssued June 24, 2026, OMB Memorandum M-26-15 ("Execution of the Migration to Post-Quantum Cryptography") is the document that turns EO 14412 into operational requirements. It establishes expectations, timelines, and the structure of what agencies must produce.The first hard deadline it creates: every&nbsp;civilian agency must submit a comprehensive PQC Migration Plan to OMB and the Office of the National Cyber Director (ONCD) by October 22, 2026. That is 30 days from this blog’s publication date. (Note that M-26-15 does not apply to National Security Systems, which follow a separate migration track.) What Must Be in the Migration Plan: Nine Required ElementsM-26-15 defines what a compliant migration plan must contain. Based on the memo's requirements, here are the nine core components agencies must address:1. Governance and Named AccountabilityThe plan must document who is responsible for the transition. The designated PQC Migration Lead must be identified, with a clear governance structure that spans the CIO, CISO, program offices, and procurement. A plan that assigns cryptographic transition to a single team will not satisfy M-26-15's cross-functional governance requirement.&nbsp;&nbsp;2. A Complete Cryptographic InventoryYou cannot migrate what you haven't mapped. The plan must describe the methodology used to inventory every cryptographic algorithm, key, certificate, and protocol in use across the agency's systems and infrastructure. This inventory, often called a Cryptographic Bill of Materials (CBOM), must be:Comprehensive (covering applications, network infrastructure, SaaS, cloud services, and on-prem systems)Automated (not a one-time manual exercise)Continuously maintainedNote: CISA and NIST are expected to publish minimum-elements guidance for machine-readable CBOMs by March 2027. Agencies should build toward that standard now.3. Risk-Based System PrioritizationNot all systems carry equal urgency. The migration plan must include a risk-based prioritization framework that identifies which systems get migrated first. Mandatory first-priority categories include:High Value Assets (HVAs) as defined in OMB M-19-03High-Impact Systems (FIPS 199 "High" categorization)Any system storing or transmitting data with long-term sensitivity, the primary targets of HNDL attacks4. Phased Milestones Aligned to the Government-Wide ScheduleM-26-15 establishes a five-phase migration timeline. The October submission must map agency-specific milestones to the three migration phases within this five-phase schedule:PhasePeriodFocusPhase 12026–2027Strategy, planning, and discoveryPhase 22027–2028Pilots and early migrationPhase 32028–2030Prioritized migration (key establishment for HVAs and high-impact systems)Phase 42031Digital signature migrationPhase 52035Full migration of remaining systemsThe Phase 3 deadline is the one with the most regulatory weight: December 31, 2030 is the hard cutoff for PQC key establishment across HVAs and high-impact systems. M-26-15 also directs agencies to prioritize systems containing highly sensitive data and systems particularly vulnerable to CRQC-based attacks on that schedule.&nbsp;&nbsp;&nbsp;5. TLS 1.3 Deployment MilestonesAgencies must specifically address migration to TLS 1.3, consistent with existing mandates under EO 14306. The overall federal deadline for TLS 1.3 support is January 2, 2030. Your plan must include milestones for testing and deploying PQC-enabled TLS 1.3 within that window.6. A Cryptographic Agility ArchitectureThis is arguably the most technically demanding requirement. Agencies must describe an architecture designed so that cryptographic algorithms can be swapped with minimal operational disruption as standards evolve. Depending on the agency’s risk assessment and technical requirements, this can include:Supporting cryptographic modes that run PQC algorithms alongside classical ones during the transition period (so you don't break existing interoperability while hardening new sessions)Ensuring Hardware Security Modules (HSMs) and Key Management Systems are replaceableTreating crypto-agility as an architecture requirement, not a feature request7. Vendor and Supply Chain CoordinationFederal agencies don't operate in isolation — much of the cryptographic footprint runs on commercial software, cloud platforms, and contractor-managed systems. The plan must detail:How the agency will engage Cloud Service Providers (CSPs) under the shared-responsibility model1Contract language and procurement requirements that mandate vendor PQC readiness and cryptographic agilityHow the agency will assess and manage cryptographic vulnerabilities in the supply chainThe first FAR Council rulemaking, due December 19, 2026, is required to propose that covered contractors comply by December 31, 2030, with applicable NIST FIPSs, including PQC-compliant algorithms. A second FAR Council rulemaking, due March 19, 2027, is required to propose changes to contractor vulnerability disclosure program (VDP) requirements covering cryptographic vulnerabilities. Contracting officers and procurement leads should be tracking both of these closely.8. Resource and Funding EstimatesOMB expects agencies to connect PQC migration to budget realities. The plan must include estimates of funding and personnel required, integrated into existing IT modernization budgets and multi-year appropriations requests. Plans without resource estimates will not satisfy M-26-15’s minimum requirements.9. Risk Management During the Transition PeriodBecause full migration takes years, agencies must address how they'll manage security risk during the transition, specifically the period when some systems are migrated and others aren't. This includes interoperability between PQC and legacy systems, monitoring for exposure in hybrid environments, and defining acceptable risk posture throughout each phase. What's Happening on the GSA and DoW TracksThe civilian agency plan submission is the most immediate requirement, but two parallel tracks deserve attention:GSA has been directed to establish an inter-agency working group to modernize Federal Identity, Credential, and Access Management (FICAM) to support PQC. That group held its first meeting on August 12, 2026, with participation from 17 federal agencies and plans to meet on a bi-weekly basis. FICAM modernization has direct implications for how agencies manage identity verification, PKI, and digital signatures, all of which will require quantum-resistant cryptographic underpinning.The Department of War (DoW) is operating under its own PQC strategy, released June 23, 2026. All DoW systems must support PQC or be phased out by December 31, 2030. Solutions using CRQC-vulnerable algorithms, non-quantum-resistant symmetric key establishment, and non-NSA-KMI PSK solutions are all on the phaseout list by that date. Defense contractors face the most compressed timelines of any segment. What This Means for Contractors and SubcontractorsIf your firm holds federal contracts, EO 14412 reaches you through two mechanisms:The first FAR Council rulemaking (due December 19, 2026) must propose that covered contractors comply with applicable NIST FIPS, including PQC-compliant algorithms by&nbsp; December 31, 2030, matching the agency deadline for HVA key establishment.A second FAR Council rulemaking (due March 19, 2027) must propose amendments to FAR requirements and contract clauses for contractor Vulnerability Disclosure Programs, including coverage of cryptographic vulnerabilities,.lack of encryption, and non-FIPS-approved algorithms. This is a significant expansion: VDPs that don't address crypto will no longer satisfy requirements.The practical implication: start your own cryptographic inventory now, not when the FAR rule is finalized. Agencies will increasingly require vendors to demonstrate a clear PQC roadmap as part of procurement. Firms that can't show one will find themselves losing competitive ground on contract renewals and new awards, well before the 2030 deadline. The Practical Starting Point: Your First 90 DaysGiven that the migration plan submission deadline is October 22, any agency team, including its supporting contractors, that hasn't started needs a rapid on-ramp. The work breaks down into three phases:Days 1–30 — Foundations:&nbsp;Appoint your PQC Migration Lead and form a cross-functional team. Initiate a cryptographic inventory (automated tools are essential — this cannot be done by hand at scale). Begin vendor and supply chain assessment. Prepare and submit the initial migration plan by October 22. M-26-15 treats the plan as a dynamic document that will mature as the inventory and implementation strategy develop.Days 31–60 — Assessment and Prioritization:&nbsp;Complete the initial CBOM. Conduct a risk assessment and prioritize systems by sensitivity, internet exposure, and operational importance. Pay special attention to anything protecting long-lived data: these are the HNDL targets. Refine your migration strategy and roadmap.Days 61–90 — Strategy and Early Implementation: Update and socialize the migration plan with leadership. Begin a pilot project on a non-critical system to test PQC algorithms before touching HVAs. Start migrating to post-quantum key exchange (ML-KEM / FIPS 203) where feasible. Update procurement policies and contract language to require PQC readiness from vendors going forward. Conclusion: The Bottom LineEO 14412 and OMB M-26-15 represent the federal government's most concrete response yet to the quantum threat. For agencies, these are binding mandates with named owners, firm deadlines, and budget implications. For contractors, two FAR rulemakings will translate the policy into formal acquisition requirements.&nbsp;&nbsp;For security and networking practitioners, the critical action items are clear:If you haven't mapped your cryptographic assets, that is the first thing to fix.If your agency doesn't have a Migration Lead, identify one ASAP.If your firm holds federal contracts, assume FAR requirements are coming and get ahead of them.The threat actors running Harvest Now, Decrypt Later campaigns are not waiting for 2030. Your migration plan shouldn't wait for October 22 either.Sources:&nbsp;EO 14412 ("Securing the Nation Against Advanced Cryptographic Attacks")OMB Memorandum M-26-15: "Execution of the Migration to Post-Quantum Cryptography” June 24, 2026Zscaler Webinar — "EO 14412 Decoded: Your First 90 Days" (watch it now)Notes:1 M-26-15 assigns CISA and DoW, in coordination with GSA, to lead PQC migration efforts for FedRAMP-authorized CSPs and SaaS, PaaS, and IaaS solutions used by more than one agency.]]></description>
            <dc:creator>Brendon Macaraeg (Principal Product Marketing Manager)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Lessons from Recent Outages: How Smart Enterprises Stay Ready]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/lessons-recent-outages-how-smart-enterprises-stay-ready</link>
            <guid>https://www.zscaler.com/blogs/product-insights/lessons-recent-outages-how-smart-enterprises-stay-ready</guid>
            <pubDate>Mon, 21 Sep 2026 12:05:29 GMT</pubDate>
            <description><![CDATA[Unforeseen outages aren't a matter of if. They're a matter of when. The question is whether you're ready.In the past few weeks, Microsoft, Google Cloud, and Salesforce, all experienced significant disruptions, leaving work interrupted, revenue lost, and reputations tested.&nbsp;During the&nbsp;Salesforce disruption on September 16, an authentication infrastructure failure cascaded into a full platform outage, bringing down the CRM, APIs, and support portal and affecting hundreds of customer instances across six countries for nearly three hours.&nbsp;For IT teams managing incidents like this one, visibility is everything: knowing what’s wrong, where, and why, before users start calling the helpdesk.&nbsp;Zscaler Digital Experience (ZDX) gives IT teams exactly that: end-to-end visibility from user devices, across any network, to the apps they depend on.ZDX detected a sharp decline in Salesforce Lightning experience scores and alerted IT teams. Network latency held steady throughout, which told teams exactly what they were dealing with: the problem wasn't the network. It was the application. Using the&nbsp;ZDX Agent, teams identified the root cause within minutes and had a specific next step, rather than just an alert that Salesforce was slow. Here’s what that looked like:ZDX score trend showing VIP user experience on Salesforce Lightning drop from Good to Poor in the early hours of September 16.&nbsp;ZDX probe data showing response times spiking to 9-11 seconds and synthetic scores dropping sharply during the September 16 outage window.That data, captured in real time, tells you what's wrong before anyone has to ask. In the Salesforce example, the network was clean. The problem was upstream at the application layer. That diagnosis, the kind that used to take hours of manual investigation, took minutes. Observe, diagnose, act. That is the loop that separates resilient enterprises from reactive ones. ZDX isn't just useful during incidents. It's how enterprises maintain uptime confidence every day. That’s visibility. But what happens when the disruption hits your own security infrastructure?Your Security Infrastructure Needs a Plan TooZscaler runs the world's largest inline security cloud,&nbsp;backed by a 99.999% industry-leading uptime SLA with built-in resilience for all common failure scenarios. That's not a footnote, it's the foundation. But, even the most resilient infrastructure doesn't eliminate the need for a plan.Just like you plan for redundancy in your data centers with multiple ISPs, or for hyperscaler workloads with multi-region backups, your most critical security services need a DR and business continuity plan (BCP) too.When disruptions hit, the instinct to route around security is dangerous. Bad actors actively exploit these moments, knowing the safeguards are down.This Is What a Real Continuity Plan Looks LikeWhen it comes to DR/BCP for the Zero Trust Exchange, organizations typically consider two approaches:Scramble unprepared. Look for workarounds with no guarantee of continuity, leaving users without secure access when it matters most.Buy Business Continuity Cloud and avoid disruption. Zscaler provides both the primary and an isolated backup cloud. That's exactly what Zscaler Business Continuity Cloud is built for.&nbsp;In normal operations, all users, branches, and workloads transact securely through the Zero Trust Exchange. The Business Continuity Cloud sits fate-separated in the background, fully managed and ready, so when a critical failure hits, the infrastructure is ready to respond.Zscaler Business Continuity Cloud is a dedicated, per-customer read-only private cloud with an isolated data plane and control plane, completely independent of the primary Zscaler cloud, running in a last-known good state and continuously syncing policy.&nbsp;When the Zero Trust Exchange becomes unreachable, Zscaler Client Connector automatically reroutes to the backup cloud.&nbsp;For your users, it's seamless: no manual intervention, no re-logins, no help desk tickets.For your security team, it's not a degraded fallback: same policies, same inspection engines, logs still streaming. Consistent Zero Trust posture maintained through the disruption.&nbsp;For IT,&nbsp;deployment is a natural extension of your existing Zscaler environment with flexible deployment options: a Zscaler-managed service across 9+ global data centers , customer-hosted, or hybrid. Further, you can run fire drills in peacetime, so the first time you activate it isn't during an actual incident.The Time to Build Your Continuity Plan Is NowMany of Zscaler's largest global organizations have already adopted and deployed Business Continuity Cloud successfully. And for organizations subject to mandatory operational resilience regulations like DORA, CPS 230, or ISO 22301, Business Continuity Cloud is also a concrete, auditable step toward meeting mandatory resilience requirements, with serious financial penalties increasingly on the line.Start with visibility. Build in continuity.&nbsp;ZDX and&nbsp;Zscaler Business Continuity Cloud give you both.]]></description>
            <dc:creator>Lidor Pergament (Director, Product Management)</dc:creator>
        </item>
        <item>
            <title><![CDATA[When AI Agents Go Rogue- What the OpenAI–Hugging Face Incident Teaches Us About Workload Zero Trust]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/when-ai-agents-go-rogue-what-openai-hugging-face-incident-teaches-us-about</link>
            <guid>https://www.zscaler.com/blogs/product-insights/when-ai-agents-go-rogue-what-openai-hugging-face-incident-teaches-us-about</guid>
            <pubDate>Fri, 18 Sep 2026 18:19:45 GMT</pubDate>
            <description><![CDATA[The Attacker Was New. The Security Gaps Were Not.In August 2026, OpenAI described an unprecedented internal cybersecurity incident: autonomous AI agents running in an evaluation environment escaped their intended boundaries and compromised systems at&nbsp;OpenAI and Hugging Face — with no human directing the attack.The agents abused limited internet access through Artifactory, OpenAI’s internal package manager, then chained vulnerabilities, harvested exposed credentials, and expanded access across Hugging Face infrastructure. The incident shows how quickly an autonomous system can turn a narrow weakness into a cross-environment intrusion.Yet the underlying architecture problems are familiar: a trusted workload could reach more of the internet than it needed, and a compromised workload could reach too much of the internal environment. For security teams, the lesson is straightforward — AI agents are workloads, and workloads should never be trusted simply because they run inside the cloud. Zero Trust: Give Every Workload Access to Only What It NeedsExtending Zero Trust architecture to workloads can be simplified using the following best practices:1. Control workload egress by destination and purpose.Artifactory needed legitimate access to software repositories. The problem was treating that requirement as general internet access. The agents used server-side request forgery (SSRF) — a technique that tricks a server into making network requests on an attacker’s behalf — to turn an approved service into an outbound proxy.Instead of letting workloads connect to the entire internet, a Zero Trust approach restricts access using precise rules based on who is connecting, what app they are using, and where they are going. A Zero Trust architecture restricts a service like Artifactory to sanctioned package registries and required protocols — requests to arbitrary destinations are denied at an inline enforcement point instead of quietly succeeding. Inspection and logging turn a slow-moving compromise into an early signal.Broad trustArtifactory → internetLeast privilegeArtifactory → approved package registries onlyCompromise attemptArtifactory → unapproved destination → blocked by egress policyThe agents reportedly experimented with outbound communication before establishing a persistent channel. TLS inspection and egress telemetry give defenders visibility into unusual destinations, request patterns, and protocols as they emerge — turning weeks of undetected probing into actionable evidence much earlier in the sequence, well before a channel becomes persistent.2. A compromised workload should not inherit reachability.&nbsp;After the agents obtained valid credentials, the incident expanded from a single worker pod to broader Hugging Face infrastructure. This is the critical Zero Trust distinction: identity is not reachability. A stolen credential may satisfy one part of an access decision, but it should not automatically create a network path to a control plane, database, messaging system, or code repository.See the entire east-west path, from the pod up to the region.A Zero Trust approach treats east-west traffic as a single, layered problem rather than two separate ones. Microsegmentation covers what happens inside a VPC or VNET — mapping workload-to-workload communication and surfacing exactly how pods and hosts are actually talking to one another within that boundary. Macrosegmentation picks up where a VPC or VNET ends: any traffic that crosses into another VPC/VNET, cluster, or region gets the same visibility, plus policy-driven control over whether that crossing is allowed at all.Together, that’s full end-to-end visibility across the whole path this incident actually took — from a single compromised worker inside its VPC, out across a boundary into another cluster, and again into a different region entirely. In an incident built on exactly that kind of expanding lateral reach, having both layers mapped is what turns “we don’t know how far this could spread” into a concrete picture of every hop involved, and a clear boundary at which to enforce.Enforce at the boundary.Macrosegmentation is deployed at exactly that boundary turning cross-boundary visibility into a live control point. Traffic crossing between VPCs/VNETs, clusters, or regions is policy-defined by default: a workload in one zone has no path into another until that path is explicitly authorized and enforced inline. It’s the same architecture end to end — Microsegmentation and Macrosegmentation aren’t two separate tools stitched together after the fact, but one layered view of east-west traffic that adds control at the point where it matters most: the boundary a compromise would otherwise cross unnoticed.3. Make stolen credentials insufficient.&nbsp;Credential protection remains essential, but architecture should assume that credentials can be exposed. The practical questions become whether the holder can reach the target service, and whether the attempted connection matches policy.Kubernetes credential: Can the workload reach the Kubernetes API from this zone?Database credential: Is the database reachable from this workload identity and application path?Repository credential: Can the workload establish the required connection to the repository service?Pairing identity with explicit connectivity policy strips a stolen secret of most of its value and limits the blast radius even when prevention fails.4. Turn credential probing into an early warning.&nbsp;Place decoy credentials, canary tokens, and lookalike resources throughout the environment. Interaction with a decoy produces a high-confidence alert with none of the false-positive noise of traditional monitoring — exactly the kind of signal a systematic credential-harvesting campaign like this one would trip.That signal gives a security team the one thing this incident lacked for nearly six weeks: an early, credible reason to look. Acting on that signal today runs through existing manual or integrated response workflows; closing the loop from alert straight to automated containment is where this architecture is headed next, not where it stands today. OpenAI’s Own Roadmap Is Describing This ArchitectureStronger isolation and tighter network controls — OpenAI’s stated fix — is workload Zero Trust in different words.&nbsp;OpenAI’s stated direction is more isolation for workloads executing untrusted code, plus network controls that prevent one compromised workload from gaining unauthorized access to the internet or internal networks. In plain language, that’s workload-to-internet and east-west VPC/VNET control, deployed without agents on every host. That capability is available today as Zero Trust Gateway for Cloud Workloads — the architecture OpenAI is now building from scratch already exists as a packaged offering.The agents didn’t stop at Hugging Face.&nbsp;They pivoted to Modal, a third AI cloud platform, compromising an unrelated customer application there while hunting for a way past their evaluation. It’s a useful reminder of why allowlisting beats blocklisting: policy built on where a workload is permitted to go stops a pivot to Modal the same way it stops a pivot to Hugging Face — it doesn’t need to already know the next destination an attacker will try. What Security Teams Should Do NowInventory workload egress. Find workloads with broad internet access and replace it with destination-, application-, and protocol-specific policy.Map the full east-west path. Use Microsegmentation for intra-VPC/VNET visibility and Macrosegmentation for cross-boundary visibility and control, together, to baseline expected flows and spot risky lateral-movement paths before an attacker finds them first.Enforce boundaries. Deploy Macrosegmentation via Zero Trust Gateway and Cloud Connector to control traffic across applications, clusters, VPCs/VNETs, and regions.Assume credentials will be stolen. Require both valid identity and an approved network path to sensitive services.Inspect encrypted workload traffic. Look for unusual destinations, protocols, and communication patterns while accounting for privacy and operational requirements.Treat AI agents as untrusted workloads. Grant only the connectivity needed for the task, and design response processes for machine-speed activity.The attacker may move at machine speed. Your blast radius should not.Agentic AI can discover vulnerabilities, chain techniques, and move across infrastructure faster than human-led attacks. OpenAI’s own incident-response roadmap points the same direction as the rest of this piece: toward fully autonomous shutdown procedures, because manual, human-paced response is already understood internally as too slow against agent-speed threats. That’s the same reasoning behind pairing workload Zero Trust with high-fidelity, signal-driven containment — closing the gap between detection and action as that automation matures.No single control can be assumed to prevent every step of an attack like this one. The durable answer is an architecture that assumes any workload can be compromised, gives every workload only what it needs, and makes sure a single foothold never becomes free rein. THREE TAKEAWAYSAI changes attack speed — not Zero Trust fundamentals.End-to-end east-west visibility, with control at the boundary, closes the gap between compromise and containment.Machine-speed threats call for machine-speed response.This post is part of Zscaler's Zero Trust in Action series, analyzing current security incidents through the lens of Zero Trust Cloud capabilities. Learn more about how Zscaler helps implement Zero Trust architecture with microsegmentation across cloud workloads,&nbsp;here.&nbsp;]]></description>
            <dc:creator>Brian Pavane (Senior Director, Specialist Solution Architect)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Securing AWS Private Lambda with Zscaler Zero Trust Cloud]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/securing-aws-private-lambda-zscaler-zero-trust-cloud</link>
            <guid>https://www.zscaler.com/blogs/product-insights/securing-aws-private-lambda-zscaler-zero-trust-cloud</guid>
            <pubDate>Wed, 16 Sep 2026 05:14:00 GMT</pubDate>
            <description><![CDATA[Modern cloud architectures increasingly rely on&nbsp;AWS Lambda for event-driven processing, data ingestion, and microservice integration. While Lambda functions often run within private Virtual Private Clouds (VPCs) to keep data isolated, many serverless workloads still require outbound internet access to interact with third-party APIs, SaaS applications, or external data feeds.Without deep visibility into this outbound traffic, security teams face a critical blind spot. Attackers can leverage encrypted channels (HTTPS) to exfiltrate sensitive data or communicate with command-and-control (C2) servers. To combat these risks, organizations turn to&nbsp;Zscaler Zero Trust Cloud and Zscaler Internet Access (ZIA) for inline&nbsp;SSL/TLS Inspection.To seamlessly extend zero trust security to public cloud environments, Zscaler provides the Zscaler Zero Trust Gateway (ZTGW). ZTGW securely brokers outbound traffic originating from cloud workloads and private subnets, funneling it safely over encrypted DTLS tunnels into ZIA for policy enforcement and threat prevention.However, introducing SSL inspection into serverless environments presents a unique operational challenge:&nbsp;How do you distribute custom Root CA certificates to short-lived, ephemeral Lambda execution containers without breaking application code or requiring manual maintenance?In this blog, we’ll explore why SSL inspection is essential for serverless workloads, how to fully automate custom certificate distribution using AWS CloudFormation and S3, how to configure granular SSL inspection policies in ZIA, and how to verify everything in action. The Challenge: SSL Inspection vs. Ephemeral ExecutionWhen ZIA inspects outbound HTTPS traffic, it acts as a man-in-the-middle proxy. It terminates the TLS session from the client, inspects the payload for threats or Data Loss Prevention (DLP) violations, and establishes a new TLS session to the destination server. To accomplish this, ZIA re-signs the destination’s SSL certificate using a custom Zscaler Root or Intermediate CA.&nbsp;If the client runtime does not explicitly trust the Zscaler Root CA, the TLS handshake fails immediately with an error like:[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificateIn traditional virtual machines (like EC2), administrators deploy custom certificates via configuration management tools (Ansible, Chef) or golden AMI images. But AWS Lambda containers are&nbsp;ephemeral and managed entirely by AWS. Standard Linux system trust stores cannot be modified permanently at the OS image level.&nbsp; The Solution: Cold-Start Bootstrap &amp; Auto-Discovery PatternTo solve this challenge, we can implement an&nbsp;Automated Cold-Start Bootstrap Pattern.By storing our Zscaler Root CA certificate in an isolated Amazon S3 bucket within the VPC, the Lambda function can fetch the certificate during container cold boot, dynamically merge it with native Amazon Linux root CAs into /tmp/custom-ca-bundle.pem, and bind it to the Python SSL context. Architecture Overview Automating Certificate Distribution Step-by-StepLet's look at how the execution environment handles the certificate lifecycle automatically in the following steps.1.&nbsp;Zero-Trust Storage in Amazon S3The certificate resides in a dedicated S3 bucket protected with:Gateway VPC Endpoint: All traffic between Lambda and S3 remains on the AWS internal backbone without traversing NAT Gateways or the public internet.Restricted Bucket Policy: Blocks all access unless the request originates from the specific VPC Endpoint or authorized IAM roles in your AWS account.2.&nbsp;Smart Certificate Auto-Discovery &amp; NormalizationDuring cold start, the Lambda handler searches the S3 bucket for any certificate ending in .crt, .pem, or .cer (such as ZscalerRootCertificate-2048-SHA256-Feb2025.crt).Certificates uploaded by security teams often vary in encoding (ASCII PEM vs. Binary DER) or contain UTF-8 Byte Order Marks (BOM headers) from Windows text editors. The bootstrap code automatically cleans and normalizes these files:import sslimport reimport boto3&nbsp;def extract_pem_certificates(raw_bytes):&nbsp;&nbsp;&nbsp;&nbsp;"""Parses, cleans, and converts raw bytes into valid PEM certificate blocks."""&nbsp;&nbsp;&nbsp;&nbsp;pem_blocks = []&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;# Strip UTF-8 BOM headers (\xef\xbb\xbf) and decode&nbsp;&nbsp;&nbsp;&nbsp;text_content = raw_bytes.decode('utf-8-sig', errors='ignore')&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;# Regex search for ASCII PEM certificate blocks&nbsp;&nbsp;&nbsp;&nbsp;matches = re.findall(r'-----BEGIN CERTIFICATE-----[\s\S]*?-----END CERTIFICATE-----', text_content)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if matches:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return [m.strip() + '\n' for m in matches]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;# Fallback for Binary DER encoded certificates&nbsp;&nbsp;&nbsp;&nbsp;try:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;pem_cert = ssl.DER_cert_to_PEM_cert(raw_bytes)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return [pem_cert.strip() + '\n']&nbsp;&nbsp;&nbsp;&nbsp;except Exception as e:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;print(f"Failed to parse DER certificate: {e}")&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return []&nbsp;3.&nbsp;Merging with Native System CAsTo ensure the Lambda function trusts both public internet sites and Zscaler re-signed sessions, the handler merges native Amazon Linux system CAs (/etc/pki/tls/cert.pem) with the extracted Zscaler Root CA into a single /tmp/custom-ca-bundle.pem file.def build_trust_store(bucket_name):&nbsp;&nbsp;&nbsp;&nbsp;bundle_path = "/tmp/custom-ca-bundle.pem"&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;# 1. Copy standard Amazon Linux system CAs&nbsp;&nbsp;&nbsp;&nbsp;with open("/etc/pki/tls/cert.pem", "r") as sys_in, open(bundle_path, "w") as bundle_out:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;bundle_out.write(sys_in.read() + "\n")&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;# 2. Download and append Zscaler Root CA from S3&nbsp;&nbsp;&nbsp;&nbsp;s3 = boto3.client('s3')&nbsp;&nbsp;&nbsp;&nbsp;objects = s3.list_objects_v2(Bucket=bucket_name).get('Contents', [])&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;for obj in objects:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if obj['Key'].endswith(('.crt', '.pem', '.cer')):&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;response = s3.get_object(Bucket=bucket_name, Key=obj['Key'])&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;cert_bytes = response['Body'].read()&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;pem_blocks = extract_pem_certificates(cert_bytes)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;with open(bundle_path, "a") as bundle_out:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;for pem in pem_blocks:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;bundle_out.write(pem + "\n")&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;print(f"Appended {len(pem_blocks)} certificate block(s) from {obj['Key']}")&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return bundle_path&nbsp;4. Binding the Trust Store to Python RuntimeFinally, during outbound calls, the Lambda handler configures ssl.create_default_context pointing directly to /tmp/custom-ca-bundle.pem:import urllib.request&nbsp;# Create SSL context using the combined trust storessl_context = ssl.create_default_context(cafile="/tmp/custom-ca-bundle.pem")&nbsp;# Outbound HTTPS request now seamlessly trusts Zscaler re-signed certificatesreq = urllib.request.Request("https://ipinfo.io", headers={"User-Agent": "AWS-Lambda-URL-Checker"})with urllib.request.urlopen(req, context=ssl_context, timeout=10) as response:&nbsp;&nbsp;&nbsp;&nbsp;body = response.read().decode('utf-8')&nbsp; Crafting SSL Inspection Policies in Zscaler Internet Access (ZIA)With the Lambda trust store in place, we can configure ZIA to inspect outbound HTTPS traffic. ZIA offers two powerful methods for scoping SSL inspection rules to AWS serverless workloads.Option 1: Scoping Policy via Sub-Locations (IP / Subnet Based)If your Lambda functions are deployed into dedicated private subnets, you can scope policies based on subnet CIDRs.1. Create a Sub-Location in ZIA:In the&nbsp;ZIA Admin Portal, navigate to&nbsp;Administration &gt;&nbsp;Location Management.Locate your AWS location and click&nbsp;Add Sub-Location.Define the IP range corresponding to your private Lambda subnet (e.g., 10.0.2.0/24).2. Build the SSL Inspection Rule:Navigate to&nbsp;Policy &gt;&nbsp;SSL Inspection &gt;&nbsp;Add SSL Inspection Rule.Under&nbsp;Criteria, select your newly created Sub-Location.Under&nbsp;Action, select&nbsp;Inspect and assign your Zscaler Intermediate CA.Option 2: Scoping Policy via Workload Groups (Leveraging AWS Native Metadata)For modern cloud environments where IP addresses are dynamic, ZIA supports&nbsp;Workload Groups. This approach maps AWS-native attributes—such as Security Groups, Account IDs, or VPC IDs—directly into ZIA policy context without maintaining static IP ranges.Prerequisite: Ensure AWS Workload Discovery is enabled between your AWS Account and Zscaler. For setup details, see the official&nbsp;Zscaler Documentation on Adding an AWS Account.1. Define a Workload Group in ZIA:In ZIA, go to&nbsp;Administration &gt;&nbsp;Workload Groups &gt;&nbsp;Add Workload Group.Name the group (e.g., AWS-Lambda-Workloads).Add criteria matching your AWS infrastructure:VPC ID: vpc-xxxxxxxSecurity Group ID: sg-0123456789abcdef02. Apply Workload Group to SSL Inspection:Under&nbsp;Policy &gt;&nbsp;SSL Inspection, create a new rule.Under&nbsp;Criteria &gt;&nbsp;Workload Groups, select AWS-Lambda-Workloads.Set&nbsp;Action to&nbsp;Inspect.Benefits of Workload Group Scoping:Zero IP Management: Eliminates hardcoded subnet CIDRs or static NAT mappings.Auto-Scaling Protection: Any new Lambda function attached to the Security Group instantly inherits the correct SSL inspection policy. Demonstrating Verification &amp; TestingTo test the deployment, we invoke the URLStatusChecker Lambda function with a payload targeting https://ipinfo.io:Test Event Payload{&nbsp;"url": "https://ip.zscaler.com/?json"}&nbsp;Lambda Response Payload{&nbsp;"statusCode": 200,&nbsp;"url": "https://ip.zscaler.com/?json",&nbsp;"message": "Successfully connected to https://ip.zscaler.com/?json",&nbsp;"trustStoreUsed": "/tmp/custom-ca-bundle.pem",&nbsp;"responseBody": {&nbsp; &nbsp;"srcip": "n.n.n.n",&nbsp; &nbsp;"vip": "null",&nbsp; &nbsp;"nodename": "zs3-nnn-nnn-nnn",&nbsp; &nbsp;"cloud": "zscalerthree.net",&nbsp; &nbsp;"datacenter": "Washington DC IV",&nbsp; &nbsp;"xff": "n.n.n.n",&nbsp; &nbsp;"clientip": "n.n.n.n"&nbsp;},&nbsp;"responseHeaders": {&nbsp; &nbsp;"Date": "Wed, 16 Sep 2026 11:21:26 GMT",&nbsp; &nbsp;"Content-Type": "text/html;charset=UTF-8",&nbsp; &nbsp;"Transfer-Encoding": "chunked",&nbsp; &nbsp;"Connection": "close",&nbsp; &nbsp;"Server": "nginx",&nbsp; &nbsp;"X-Powered-By": "PHP/8.0.30",&nbsp; &nbsp;"Access-Control-Allow-Origin": "*",&nbsp; &nbsp;"Access-Control-Allow-Methods": "GET, OPTIONS, HEAD",&nbsp; &nbsp;"Strict-Transport-Security": "max-age=63072000; includeSubDomains",&nbsp; &nbsp;"X-Frame-Options": "SAMEORIGIN"&nbsp;}}&nbsp; Conclusion &amp; Key TakeawaysSecuring serverless egress traffic does not require sacrificing security visibility or burdening developers with complex certificate management code.By combining&nbsp;AWS CloudFormation, an&nbsp;isolated S3 bucket, and&nbsp;Zscaler Internet Access (ZIA):Security is Automated: Lambda functions dynamically discover and inject the Zscaler Root CA during cold start without modifying base images.Traffic is Fully Inspected: ZIA performs deep content inspection and threat analysis on encrypted outbound HTTPS sessions.Policy is Identity-Centric: Workload Groups tie ZIA policies directly to AWS Security Groups and cloud metadata, creating a scalable, zero-trust serverless architecture.&nbsp; Ready to Learn More?Check out the full CloudFormation deployment template (lambda-ssl-demo.yaml) and step-by-step setup guide in our GitHub repository to implement automated SSL inspection for your serverless workloads today!While this blog focuses on AWS Lamba, a similar approach can be leveraged for Serverless workloads in other cloud providers. E.g. Azure Functions &amp; Cloud Run in GCP.To learn more about Zscaler Zero Trust Gateway, click here.&nbsp;]]></description>
            <dc:creator>David Glading (Principal Specialist Sales Engineer)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Extending Zero Trust to AI: What Federal Civilian Agencies Can Do Now]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/extending-zero-trust-ai-what-federal-civilian-agencies-can-do-now</link>
            <guid>https://www.zscaler.com/blogs/product-insights/extending-zero-trust-ai-what-federal-civilian-agencies-can-do-now</guid>
            <pubDate>Wed, 16 Sep 2026 03:28:29 GMT</pubDate>
            <description><![CDATA[This is the final post in a three-part series on AI security and governance for Federal Civilian agencies. The first post covered why M-25-21 changes the operating landscape. The second post introduced a six-part framework for secure AI adoption.Bottom line up front: Federal Civilian agencies have spent years moving toward Zero Trust. AI should be part of that strategy. Zscaler helps agencies extend Zero Trust principles into AI interactions across employee use, agency-built applications, and cloud environments. The practical starting point is visibility, followed by data protection, guardrails, testing, and governance evidence.&nbsp; AI creates new interaction points that Zero Trust must coverFederal agencies have spent years moving toward Zero Trust. AI should be part of that strategy.AI introduces new interaction points: prompts, responses, models, agents, AI APIs, embedded AI, AI-enabled SaaS, coding assistants, RAG pipelines, vector databases, MCP servers, tool-calling workflows, and agency-built AI applications.Each one can become a path for data exposure, unauthorized access, manipulation, or mission risk.A Zero Trust approach to AI asks practical questions. Who is using the AI system? What application or model are they accessing? What data is being shared? Is the user authorized? Is the tool approved? Is the destination trusted? Is sensitive data involved? Is the AI response safe and appropriate? Is the AI system acting within its mission scope? Is the interaction logged and governed? Can policy be enforced in real time?Zscaler helps agencies extend Zero Trust from users, devices, applications, branches, and workloads into AI interactions. This includes securing employee AI use, discovering AI assets, protecting sensitive data, applying guardrails, testing agency-built AI applications, and monitoring AI behavior over time. Where Zscaler fitsZscaler's role is to help Federal Civilian agencies make secure AI adoption operational. The platform supports three main areas.AI asset management helps discover and inventory AI use across endpoints, traffic, SaaS, code, and cloud environments. This supports governance, inventory, visibility, and risk prioritization.Secure access to AI applications helps protect employee use of public GenAI and embedded AI applications through access control, DLP, browser isolation, prompt inspection, response inspection, and AI Guard. This supports acceptable-use policy enforcement and sensitive data protection.Secure AI applications and infrastructure helps protect agency-built AI applications, agents, and model interactions through proxy or API-based guardrails, AI red teaming, model benchmarking, prompt hardening, and continuous monitoring. This supports public trust, mission alignment, and risk management for higher-impact AI systems.These capabilities help agencies answer the questions at the center of M-25-21 compliance: What AI is being used? What data does it touch? Who is using it? What risks exist? What controls are applied? What systems have been tested? What evidence can we provide? And how do we enable AI safely at mission speed? What this looks like across missionsSecure AI adoption will look different depending on the agency's mission.A&nbsp;benefits agency may want to use AI to help employees summarize case information, while preventing exposure of PII or unauthorized eligibility guidance.A&nbsp;public health agency may want to use AI to synthesize research, but needs responses grounded in authoritative sources.A&nbsp;regulatory agency may want to use AI to assist with inspections, investigations, or compliance reviews, while protecting sensitive regulated-entity information and avoiding unsupported conclusions.A&nbsp;grants-making agency may want to improve application processing, but must protect applicant data, procurement-sensitive information, and pre-decisional materials.A&nbsp;citizen services agency may want to deploy a public-facing AI assistant, but needs to ensure the assistant provides accurate information, avoids unauthorized determinations, and escalates to a human when appropriate.A&nbsp;software development organization may want to use AI coding assistants to accelerate modernization, while preventing source code leakage, secrets exposure, and unapproved model use.A&nbsp;security operations team may want to use AI to improve triage, detection, and response, while maintaining human oversight and protecting sensitive incident data.These are the kinds of use cases where AI security, Zero Trust, and governance need to work in concert. A practical path forwardA good starting point is visibility.Federal Civilian agencies can begin by identifying the AI already in use across public GenAI, embedded AI, desktop tools, developer environments, cloud services, models, agents, and AI-enabled applications.From there, agencies can map AI usage to data sensitivity and mission risk. This means understanding where AI interactions involve sensitive mission data, including PII, CUI, source code, benefits data, health data, financial data, law enforcement data, regulatory data, or procurement-sensitive information.Once agencies understand the risk, they can enforce acceptable-use and data protection policies. This may include access controls, DLP, browser isolation, prompt inspection, response inspection, and user coaching.For agency-built AI applications, agencies should apply guardrails, proxy or API-based inspection, and red teaming before deployment. After deployment, they should continuously monitor usage, policy violations, data exposure attempts, red team findings, model behavior, and emerging AI assets.Finally, agencies need to report what they learn to governance stakeholders, including the CAIO, AI Governance Board, CIO, CISO, privacy, legal, data, acquisition, and mission leaders.This approach supports the intent of M-25-21: move faster with AI while maintaining governance and public trust. Where this leaves usAI is becoming part of how Federal Civilian agencies deliver their missions.But responsible adoption requires more than enthusiasm and policy statements. Agencies need visibility, data protection, security controls, testing, monitoring, and governance evidence.M-25-21 sets the direction: accelerate AI adoption, remove barriers, establish governance, manage risk, and preserve public trust.Zscaler helps agencies put that direction into practice by extending Zero Trust into AI interactions. This means helping agencies discover AI use across the enterprise, reduce shadow AI risk, protect sensitive government data, enable approved GenAI tools, govern embedded AI in SaaS, secure developer use of AI, identify AI assets in cloud environments, protect agency-built AI applications and agents, red team AI systems before deployment, apply guardrails for prompts and responses, monitor AI usage continuously, and provide evidence to AI governance stakeholders.The goal is AI adoption with the visibility, control, and governance needed to manage risk in real time, at mission speed.To learn more about how Zscaler extends Zero Trust to AI for Federal Civilian agencies, reach out to your Zscaler account team for a detailed overview of our AI Security capabilities.Read the full series: Part 1: M-25-21 Changes the AI Conversation | Part 2: A Practical Framework for Secure AI Adoption]]></description>
            <dc:creator>Jose Arvelo Negron (Manager, Sales Engineer)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Countermeasures for AI-Enabled Attacks Start with Deception]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/countermeasures-ai-enabled-attacks-start-deception</link>
            <guid>https://www.zscaler.com/blogs/product-insights/countermeasures-ai-enabled-attacks-start-deception</guid>
            <pubDate>Tue, 15 Sep 2026 20:40:52 GMT</pubDate>
            <description><![CDATA[Anthropic’s September 2026 threat intelligence report provides one of the clearest public views to date into how threat actors are using frontier AI systems across real cyber operations. Not surprisingly, the attacks rely on familiar weaknesses – stolen credentials, exposed applications, vulnerable services, insecure code, SaaS abuse, cloud misconfigurations, and poor secret hygiene.So if attack tactics haven’t changed with AI, what has? The speed, scale, and economics of execution.Anthropic is stressing the improvements in adversarial speed and economics – something we raised the alarm on in Nov 2025 when everyone else was focused on AI’s ability to exploit at scale.“Many commentators focus on the risk of AI developing exploits at scale. While this is a danger, the risk from AI adoption is more pronounced across the cyber kill chain, where adversaries can operate faster, across a broader and deeper surface area, with fewer resources.”&nbsp;– Detecting and countering misuse of AI: September 2026, AnthropicAI allows attackers to automate reconnaissance, credential validation, exploit development, phishing infrastructure, post-compromise enumeration, and data processing. Those capabilities compress the time defenders have to detect and respond. Controls that were acceptable when attackers moved at human speed will not be sufficient when attackers operate with agentic workflows, persistent memory, and parallel task execution.But that same automation creates an advantage for defenders.AI-enabled attackers depend on discovery. They enumerate exposed assets. They classify systems. They validate credentials. They test access paths. They search for sensitive data, privileged accounts, internal applications, cloud resources, repositories, and AI infrastructure. In other words, they interact with the environment to decide where to go next.Deception exploits that dependency. That is why deception is especially relevant in the age of agentic attacks and why the Cloud Security Alliance has consistently cited deploying deception as a key priority response to AI attacks. The more automated the attacker becomes, the more opportunities defenders have to misdirect, observe, and contain them before real systems are impacted.At its core, deception is a capability, not a product. This post looks at five of Anthropic’s cyber operation case studies where deception can serve as a primary early-detection and containment mechanism. The goal is to show how defenders can use decoys, honeytokens, synthetic assets, and canaries to turn attacker discovery into detection.&nbsp; GTG-20006 / Midnight Blizzard — Russian EspionageGTG-20006 is a Russian state-linked espionage actor whose attribution is consistent with public reporting on Midnight Blizzard. This entity has been targeting Ukrainian, European, diplomatic, defense, and foreign-policy organizations.How AI was usedAI was used to automate operations, notably in the following areas:Develop and maintain malwareAcquire and configure infrastructureResearch and register phishing domainsSend phishing emailsMonitor C2 channelsManage compromised accountsSupport persistence and exfiltrationProcess stolen dataRebuild malware when security products detected itAI UpliftSpeed: Faster phishing, infrastructure setup, and malware modificationScale: More victims and campaigns handled in parallelDepth: Better post-compromise processing and data organizationResilience: Faster evasion when defenders created detectionsDeception as countermeasure for GTG-20006&nbsp;Attack stepType of Deception for each applicable stepWhy Deception will be effectivePhishing domain and lure testingDecoy login portals (M365/vendor portals available via custom clone)If the actor tests phishing flows against decoy users or decoy portals, defenders get early evidence of campaign preparation.Credential harvestingDecoy browser credentials, decoy VPN credentials, decoy M365 credentials and SSO-recovery credential files (via credential-file decoy)No legitimate workflow should use these credentials. Any attempted use is high-confidence evidence of credential theft.Browser password theftEndpoint-planted decoy credentials in browser storesInfostealers will collect decoy credentials along with real ones. Use of those credentials reveals the compromised endpoint or user.Malware delivery and stagingDecoy endpoints, decoy update servers, decoy software-distribution portalsMalware or scripted access to decoy infrastructure provides behavior-based detection independent of signatures.Lateral movementDecoy admin credentials, decoy RDP/SSH/VPN paths, decoy internal bookmarksAttackers following stolen credentials or bookmarks are redirected into instrumented systems.SaaS and cloud data harvestingDecoy SaaS login portals, decoy cloud buckets, planted SaaS credentialsAttackers using stolen tokens to discover data will touch decoy high-value locations, creating early alerts.Hotel Wi-Fi or vendor compromiseDecoy vendor-management portals, decoy Wi-Fi admin consoles, decoy hospitality systemsAttackers abusing hospitality infrastructure can be detected when they interact with convincing decoy management surfaces.&nbsp; GTG-50014 — ShinyHunters-Style Smash-and-Grab Data TheftGTG-50014 is described as financially motivated activity associated with ShinyHunters-like operators.Anthropic identified an opportunistic data-theft and extortion pattern. The threat actor searched for exposed credentials, API keys, SaaS tokens, GitHub tokens, cloud credentials, container secrets, and mobile app secrets.Targets included technology providers, airlines, energy companies, nonprofits, retail chains, web3 platforms, SaaS providers, GitHub repos, containers, and Internet-facing APIs.How AI was usedAI helped the actor move quickly across many unrelated environments.Instead of manually understanding every mobile app, API, SaaS product, or cloud service, the threat actor could use AI to:Analyze decompiled mobile appsClassify discovered secretsUnderstand APIsGenerate validation workflowsSummarize stolen datasetsWrite scripts for harvesting and exfiltrationOrganize credentials by source typeSupport extortion preparationAI UpliftScale and speed. The attack techniques were not novel. The novelty was that AI made mass opportunistic exploitation easier and faster.Deception as countermeasure for GTG-50014&nbsp;Attack stepType of Deception for each applicable stepWhy Deception will be effectivePublic repo scanningDecoy cloud keys (IAM/ECR/SA) and tokens planted on endpoints and in the customer's cloudSecret scanners will find and validate the decoys. Any use of those tokens is high-confidence malicious activity.API key validationDecoy cloud keys (AWS IAM/ECR, Azure, GCP SA) planted on endpoints&nbsp;Secret validation is a strong attacker behavior. Decoy keys convert validation into immediate detection.Cloud storage discoveryDecoy S3 buckets, Azure Blob containers and GCS pathsAttackers searching for exposed data will browse fake stores, giving defenders visibility into data-theft intent.SaaS compromiseDecoy Salesforce, ServiceNow, or SharePoint credentialsIf stolen SaaS credentials are tested, the decoy login attempt becomes a high-confidence alert.Downstream customer data theftSynthetic customer records, decoy CRM exports, beaconed decoy documents (HTML/Office)&nbsp;Attackers exfiltrating or opening fake customer data reveal themselves without exposing real customers.Data stagingDecoy database decoys (MariaDB/Mongo/Postgres) and beaconed decoy documentsWhen stolen-looking data is opened, moved, or uploaded, defenders get telemetry on attacker infrastructure.Extortion preparationDecoy documents (HTML/Office)Deception helps determine whether stolen data was accessed, staged, or prepared for publication.&nbsp; GTG-10007 — Exploit Foundries and Autonomous Attack FrameworksGTG-10007 is a sustained espionage operation by Chinese-speaking operators likely based in Changsha, Hunan.This case is important because it shows the concept of an AI-enabled exploit foundry.The threat actor used AI-first workflows to conduct intrusion attempts, recon foreign-government networks, reverse engineer security products, analyze firmware and binaries, develop and test exploits, maintain malware, build intelligence-collection infrastructure, and run parallel workstreams with persistent campaign memory.Targets included 50 organizations across retail, education, energy, tech, healthcare, finance, manufacturing, and government agencies.The threat actor compromised an education-technology company and extracted student data, accessed a retail company’s production systems, and retrieved citizen records from a Southeast Asian government agency.&nbsp;A major part of the operation involved autonomous vulnerability research against network appliances and security products. The report says one workflow produced more than a dozen possible zero-day findings in a single month.How AI was usedThe threat actor used AI to:Build a fleet of agent swarmsRun parallel subagentsBuild persistent campaign memoryAutomate firmware analysisCreate decompiler workflowsGenerate vulnerability hypotheses and exploit-code&nbsp;Perform lab testing and iterationSchedule intelligence collectionAI UpliftFaster vulnerability discovery and exploit iterationMultiple workstreams running in parallelAbility to inspect code paths, binaries, and firmware at volumeAbility for campaign memory stored targets, credentials, state, and instructionsThis sort of attack class is where Deception is particularly valuable, because defenders likely do not know the exploit in advance. Deception detects attacker interaction and intent, regardless of whether the CVEs, malware, or signatures are known.Deception as countermeasure for GTG-10007&nbsp;Attack stepType of Deception for each applicable stepWhy Deception will be effectiveInternet-facing reconnaissanceDecoy VPN portals, appliance banners, admin consoles and identity portalsAutonomous recon agents will enumerate and interact with exposed-looking decoys, creating early detection.Appliance targetingDecoy security-appliance interfaces, firmware download portals and management APIsExploit researchers looking for appliance weaknesses may spend effort on instrumented fake assets.Version fingerprintingDecoy banners, vulnerable version strings and headersAI scanners rely on classification. Fake fingerprints can attract scanning and reveal targeting logic.Exploit testingHigh-interaction decoys that safely accept probes and payload attemptsNovel exploit attempts can be captured without needing prior signatures.Post-exploitation enumerationDecoy internal hosts, shares, AD objects and service accountsOnce inside, attackers often enumerate. Decoys turn enumeration into high-confidence detection.Credential reuseDecoy SSH keys, admin passwords, kubeconfigs, and API tokensCredential reuse against decoys reveals compromise before real privileged assets are reached.Lateral movementDecoy jump hosts, RDP systems, and database serversAttackers following internal paths are diverted into monitored infrastructure.Collection infrastructureDecoy document repositories, policy files, and defense-related contentIntelligence collectors may harvest synthetic material, exposing automated collection behavior.Malware testingDecoy endpoints and EDR/security-tool artifactsMalware or exploit tooling interacting with decoy endpoints gives behavior-based signals.Target prioritizationDecoy crown-jewel systems, admin paths and sensitive labelsAI agents prioritize attractive assets. Deception uses that prioritization against the attacker.&nbsp; GTG-50020 — From Hotel Bookings to the AI Supply ChainGTG-50020 is a Russian-speaking, financially motivated threat actor.The threat actor historically targeted hotel booking and fintech platforms, then pivoted toward AI vendors and AI supply-chain targets.The actor attempted to access a pre-release Claude model but did not succeed.Targets included hotel booking platforms, fintech platforms, AI companies, AI vendors, AI evaluation sandboxes, production AI API keys, KYC and identity-verification systems, and exchange and marketplace systems.One key attack involved injecting malicious instructions into an AI vendor’s automated evaluation sandbox. This caused credential disclosure. The actor then abused stolen production AI API keys from multiple providers.The actor also attacked about 30 AI companies in four days.How AI was usedAI was used in two ways:Targeted AI infrastructure directly by attacking AI evaluation workflows and stealing production AI API keys.Used AI-assisted offensive workflows to run reconnaissance and exploitation at scale.The AI tooling used by the threat actor constituted parallel reconnaissance agents, exploitation agents, target-specific scope files, automated finding retesting, containerized pentest tooling, local model gateways, and worker agents operating with limited human supervision.AI UpliftFaster web-app testingMore parallel attacksBetter target-specific exploitationRapid pivoting across many AI companiesAbuse of stolen AI keys for further operationsDeception as countermeasure for GTG-50020&nbsp;Attack stepType of Deception for each applicable stepWhy Deception will be effectiveAI vendor reconnaissanceDecoy AI company assets, model registry entries and documentation portalsAttackers scanning AI companies may interact with fake high-value AI assets first.API key theftDecoy AI-provider / LLM-gateway keys (via cloud gen-ai decoy + credential files and decoy cloud keys)Stolen-key validation creates immediate high-confidence detection.AI evaluation abuseDecoy evaluation jobs, benchmark datasets and pre-release model referencesAttackers seeking sensitive model access can be diverted into monitored workflows.Web-app exploitationDecoy web apps with fake SSRF, XSS, and auth-bypass surfacesAutomated exploitation agents will probe decoys, revealing attack behavior.SSRF testingDecoy metadata endpoints and internal service URLsSSRF attempts against decoys expose exploitation attempts without risking real infrastructure.KYC workflow abuseDecoy KYC admin portals, identity-verification records and synthetic applicant dataAttackers targeting fraud or identity workflows can be detected before real records are abused.Fraud account creationDecoy onboarding flows and synthetic high-risk accountsAutomated account factories can be identified through interaction with controlled flows.AI supply-chain compromiseFake CI/CD secretsAttackers looking for AI pipeline access will validate decoys and reveal compromise paths.Extortion preparationBeaconed decoy documents (HTML/Office)Shows whether attackers reached data-theft or extortion stages while protecting real data.&nbsp; GTG-50029 — Hacktivists Targeting European Political EntitiesGTG-50029 was a politically motivated French-speaking hacktivist operation.They have targeted European political parties, media organizations, think tanks, SaaS providers, campaign-management platforms, political affiliates, readers and editorial staff.The actor used stolen API keys and AI-assisted tooling to scale attacks.Techniques used included public-container API key theft, custom Rust scanner for exposed keys, API key rotation through proxies, WordPress exploitation, admin account creation, webshell deployment, credential-harvesting, backup poisoning, browser C2 against a media site, credential interception, and Tor leak-site staging.The actor gained internal access to at least 14 of 42 tracked entities. The operation exfiltrated political, donor, member, student, mailbox, and payment-provider data.How AI was usedAI was primarily used to build and debug offensive tooling. The threat actors used AI to:&nbsp;&nbsp;Develop a WordPress exploitBuild a lab harnessDebug codeManage reconnaissanceReview codeValidate findingsBuild a doxxing/search platformCreate ingestion pipelinesNormalize and rank dataContainerize deploymentAI UpliftFaster exploit developmentFaster weaponization of public-facing web systemsBetter data processing for doxxingAbility for a single actor to run a campaign that looked more like a team effortDeception as countermeasure for GTG-50029&nbsp;Attack stepType of Deception for each applicable stepWhy Deception will be effectivePublic-container scanningDecoy cloud keys/tokens planted on endpoints and in the customer's cloudScanners will harvest decoys. Validation attempts reveal attacker infrastructure.API key rotationHoneytokens tied to monitored API endpointsEven if attackers rotate keys through proxies, decoy-key use remains abnormal and high-confidence.CMS targetingDecoy WordPress/CMS instances, plugin directories and admin panelsHacktivists looking for exposed CMS weaknesses can be pulled into monitored systems.WordPress exploitationDecoy vulnerable CMS versions and instrumented login/reinstall flowsExploit attempts against decoys can be captured before real sites are affected.Rogue admin creationDecoy admin accounts&nbsp;Unauthorized admin creation is a strong signal of compromise.Webshell deploymentDecoy upload directories and writable plugin/theme pathsWebshell upload attempts against decoys reveal active exploitation.Credential-harvesting plugin deploymentDecoy CMS users and admin credentialsThe attacker’s harvesting tooling collects credentials that lead only to monitored assets.Backup poisoningDecoy backup archives and restoration pathsAttempts to alter decoy backups reveal persistence behavior.Doxxing data aggregationSynthetic donor lists, member records and political-affiliation dataProtects real users while revealing data-theft and publication intent.Leak-site stagingBeaconed decoy documents (HTML/Office)If staged or opened, defenders gain telemetry about attacker infrastructure and timing.As is evident from the five threat actors, AI-enabled attackers are automating the discovery of users, credentials, applications, APIs, cloud data, and exposed services. Deception gives defenders a way to pre-position false but believable assets in those discovery paths. When attackers or their AI agents touch those assets, you get early, high-confidence alerts before real systems are damaged.&nbsp; Recommended Deception control categories mapped to threat actorsTo consolidate what type of deception works best in different situations, we’ve mapped them to the threat actors documented in Anthropic’s report.Deception typeExamplesBest-fit attacksIdentity deceptionDecoy users, admin accounts, SSO credentials and OAuth tokensGTG-20006, GTG-50020, GTG-50029Endpoint deceptionDecoy browser passwords, SSH keys and credential filesGTG-20006, GTG-50014, GTG-50021Developer deceptionDecoy GitHub PATs, CI/CD secrets, cloud keys and package tokens on internal endpoints/cloudGTG-50014, GTG-50020, GTG-50029SaaS deceptionDecoy Salesforce / ServiceNow / SharePoint login portals + planted SaaS credentialsGTG-20006, GTG-50014, GTG-50029Cloud deceptionDecoy S3 buckets, database strings, IAM users and cloud consolesGTG-50014, GTG-50020Network deceptionDecoy VPNs, RDP/SSH hosts, databases and file sharesGTG-10007, GTG-20006Web-app deceptionDecoy CMS, admin panels and SSRF/XSS surfacesGTG-50020, GTG-50029AI-stack deceptionDecoy AI API keys, LLM gateways and MCPGTG-50020, GTG-50021, GTG-50014Data deceptionSynthetic customer records, decoy donor lists, beaconed decoy documents (HTML/Office)GTG-20006, GTG-50014, GTG-50029Note: We’ve included GTG-50021 and GTG-30005 in the table above as secondary or specialized deception opportunities, but these attacks are not discussed in this analysis because deception is not the primary front-line control for those scenarios.For the attacks described in Anthropic’s report, deception is not a replacement for patching, identity hardening, ZTNA, DLP, SaaS control, or threat prevention. It is a preemptive detection layer that changes the attacker’s operating environment. By placing decoy credentials, applications, APIs, data, and services in the paths that AI agents are likely to enumerate, you can increase attacker uncertainty, pollute automated decision-making, and generate high-confidence alerts before real systems are damaged.Learn more about Zscaler Deception&nbsp;here.&nbsp;If you’re already a Zscaler customer and would like to deploy Zscaler Deception, please reach out to your account manager.]]></description>
            <dc:creator>Amir Moin (Principal Product Manager)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Enhancing Application and Threat Detection in Zero Trust Firewall]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/enhancing-application-and-threat-detection-zero-trust-firewall</link>
            <guid>https://www.zscaler.com/blogs/product-insights/enhancing-application-and-threat-detection-zero-trust-firewall</guid>
            <pubDate>Tue, 15 Sep 2026 16:02:25 GMT</pubDate>
            <description><![CDATA[Modern enterprises don’t run on a defined perimeter anymore. Users connect from everywhere, applications live across SaaS and public cloud, and attackers ever increasingly hide in encrypted traffic. In this environment, security teams need more than “IP + port” controls—they need&nbsp;application-aware enforcement&nbsp;and&nbsp;always-on threat inspection&nbsp;that follows users and traffic wherever it goes.Zscaler Zero Trust Firewall&nbsp;is designed for exactly that: cloud-delivered protection for&nbsp;web and non-web traffic, centralized policy, and deep visibility—without the operational drag of appliance sprawl. Two new capabilities that significantly improve this security outcomes are:Custom Application Service Groups (Custom App Services)&nbsp;for precise, reusable application/service controlsCustom IPS Signature Rules (Cloud Custom IPS)&nbsp;for organization-specific threat detections enforced through IPS ControlThis post focuses on what they do, why they matter, and how customers can put them into practice quickly.Why application and threat detection needs a zero trust approachLegacy firewalls were built for a world where:applications stayed in the data center,“Inside the perimeter” was trusted,and deep inspection (especially SSL/TLS) was optional.Today, that model breaks down:SSL/TLS is the default, and turning on TLS inspection at scale can be painful in appliance architectures.Attackers don’t just attack servers—they target&nbsp;users, endpoints, and “normal” protocols.Policy sprawl grows fast when you try to emulate zero trust through endless network segments and distributed rulebases.A&nbsp;Zero Trust Firewall&nbsp;addresses these challenges by enforcing in the cloud and adding richer context for decisions such as identity, application/service constructs, and integrated IPS.What Zero Trust Firewall (ZTFW) deliversCustomer outcomes typically map to three capabilities:Consistent protection everywhere: The same security posture for users at HQ, branches, and remote.Better precision than “network-only” controls: Policies can incorporate user context and (where licensed) process-level awareness via Endpoint App Control.Inline inspection + visibility: Built-in security services (including IPS) and centralized logging/insights so security teams can investigate and respond faster.That foundation is what makes Custom App Services and Custom IPS signatures so impactful: they become building blocks you can reuse and scale across your environment. Custom Application Service Groups: enforce policy on application services, not just IPsApplication Service Groups&nbsp;are policy objects you can use as criteria in&nbsp;Firewall Filtering and Forwarding&nbsp;rules. They’re defined using service metadata such as:IP addresses (single IP, subnet, or range)FQDNs and wildcard FQDNs (e.g.,&nbsp;*.example.com)TCP/UDP destination portsZscaler provides both:Predefined application service groups (AU / “Authoritative”): These are application&nbsp;service groups for popular SaaS and cloud providers based on their metadata; broadly applicable; updated over time.Custom application service groups (CU)&nbsp;: Created by&nbsp;you, in your tenant, for&nbsp;your&nbsp;specific service definitions and policy needs.&nbsp;Predefined Application Service GroupsZscaler maintains and updates a list of predefined application services based on information published by the respective providers. These predefined services help customers:Reduce operational overhead: less manual IP-list maintenance as providers evolve.Write cleaner firewall policy: rules read like business intent (“Allow Microsoft 365”) rather than brittle networking trivia.Improve accuracy: service identification is built to reflect provider-published metadata. Zscaler also continuously updates provider-published metadata for many predefined groups, reducing the effort of tracking SaaS IP changes over time. Custom Application Service Groups: add flexibility when predefined isn’t enoughPredefined services are intentionally generalized and provider-driven. But real customer environments often need something more specific, such as:a privately hosted API with known FQDNs and portsa partner integration endpoint seta SaaS app that isn’t in the predefined cataloga subset of destinations within a larger provider footprintThat’s where&nbsp;Custom Application Service Groups&nbsp;come in.A custom application service group can be built using combinations of:IP addresses&nbsp;(single IP / subnet / range)FQDN / wildcard FQDN&nbsp;(e.g.,&nbsp;api.example.com&nbsp;or&nbsp;*.example.com)TCP/UDP destination portsThis gives you&nbsp;service-aware control for apps that are unique to your business, not just what’s common among all customers.Where custom services deliver the most valueModel your own apps like “first-class services” in firewall policy:&nbsp;Instead of falling back to generic destination IP groups and ports.Limit a large, predefined service footprint to only what you intend:&nbsp;Example: define a custom group representing only a narrow set of AWS-hosted endpoints your engineering org should reach.Create reusable objects:&nbsp;Use the same custom service group across Firewall Filtering, Forwarding rules, and (where applicable) IPS control targeting.Custom Application Service Groups help you:Reduce rule fragility: Instead of chasing shifting IPs and endpoints, define the service once and reuse it.Improve least privilege: Narrow access to&nbsp;exactly&nbsp;the destinations and ports that matter.Simplify operations: Build cleaner policies using reusable objects rather than repeating the same destinations in many rules.A key advantage: first-packet identificationA key benefit of application service groups is they can be used to identify applications&nbsp;on the first packet, which can allow policy action to apply immediately. Operationally, this also influences rule design: application service-based policies often belong higher in a higher priority rule than similar “network application” rules to ensure deterministic matching.Example use cases:Tight SaaS allowlisting: Allow Microsoft 365 or Zoom-related service traffic only for intended users and conditions.Controlled cloud access: Allow AWS/GCP service traffic, but only for specific departments (and ideally with multiple conditions).Partner/API segmentation: Create a custom service group for partner API hosts and required ports, then enforce strict allow + logging. IPS Control&nbsp; with Cloud Custom IPS: always-on threat prevention, inlineEven the “right” application traffic can carry threats. That’s why Zero Trust Firewall pairs application control with inline intrusion prevention.IPS Control&nbsp;in ZIA provides signature-based detection across&nbsp;web and non-web traffic&nbsp;(including HTTP/HTTPS/FTP/DNS/TCP/UDP and IP-based traffic) and supports granular policy conditions such as users/groups/departments/locations and more. It also supports actions such as:AllowBlock/DropBlock/ResetBypass IPSDefault threat signatures vs. Custom IPS signatures (what’s included vs. what you add)IPS Control policies can be configured to enforce signatures from two sources:Signatures available with IPS Control by default:&nbsp;Zscaler’s IPS Control uses IPS signature rules&nbsp;built and updated by Zscaler’s security research team (ThreatLabz), as well as&nbsp;signatures from industry-leading vendors. These signatures provide broad baseline coverage and are maintained by Zscaler.Custom IPS Signature Rules (customer-defined):&nbsp;In addition to the default signatures, you can&nbsp;create and deploy custom IPS signatures&nbsp;that are specific to your organization’s requirements&nbsp;without requiring any additional infrastructure, and inspect your traffic using these signatures. These custom signatures are authored by your team and remain specific to your tenant.In either scenario, with Zscaler Cloud IPS Control, you no longer have to hairpin the traffic back to the DC via VPNs. Instead, the traffic can go directly to the cloud, no matter where the user, device, or workload is globally. Custom IPS Signature Rules: tailor threat detection to your environmentCustom IPS Signature Rules&nbsp;let your security team define organization-specific detections using&nbsp;Snort-like syntax, deploy them in the Zscaler cloud (no additional infrastructure), and enforce them through&nbsp;IPS Control&nbsp;via an assigned&nbsp;Threat Category. Additionally, the signature only stays in your tenant, enabling you to comply with TLP:amber/red guidelines.This is especially valuable when:You have a&nbsp;unique internal application&nbsp;or API surfaceYou receive new threat intel and want to&nbsp;respond independent of Zscaler's ThreatLabz.You need&nbsp;custom detections for compliance&nbsp;or for telemetry/signals into your SOC via Zscaler logging. Quick example: why you’d use a custom signature even when defaults existScenario:&nbsp;Your SecOps team receives threat intel about a pattern targeting&nbsp;your&nbsp;environment. That pattern may not exist in the default global signature set (yet), and you can’t wait for a broader industry signature release cycle.What you do:Keep&nbsp;default IPS signatures&nbsp;enabled (so you retain broad protection immediately).Create a&nbsp;Custom IPS signature&nbsp;that matches the environment-specific pattern.Assign it to a threat category and enforce it via an&nbsp;IPS Control&nbsp;rule scoped to the relevant users/locations/services (for example, the Application Service Group representing that app/service).Choose the IPS Control action (e.g., block/drop for high-confidence attempts) and activate the policy.Outcome:&nbsp;You get the best of both:continuously updated default coverage&nbsp;from Zscaler, andfast, precise, tenant-specific detection&nbsp;when your environment needs something unique—without deploying additional IPS infrastructure.In practice: write signatures that are&nbsp;specific,&nbsp;testable, and&nbsp;scoped&nbsp;(then monitor hits and adjust). ConclusionA Zero Trust Firewall isn’t just “a firewall in the cloud.” The real advantage comes from&nbsp;higher-fidelity policy objects&nbsp;and&nbsp;embedded threat prevention&nbsp;that move at the speed of modern environments.Custom Application Service Groups&nbsp;reduce policy fragility and increase enforcement precision by modeling services the way the business uses them.Custom IPS Signature Rules&nbsp;close detection gaps by letting you encode organization-specific threat intelligence and enforce it through IPS Control—without deploying separate IPS infrastructure.Together, they turn firewall policy from a static ruleset into a living control plane for application-aware access and threat detection in a zero trust architecture.&nbsp;Join an upcoming hands-on Zero Trust Firewall workshop where Zscaler experts walk you through building real policies for non-web traffic including IPS rules, DNS controls, and application-aware enforcement in a live, interactive environment.Reserve your spotSeats are limited and sessions fill quickly so register early.]]></description>
            <dc:creator>Siddhartha Aggarwal (Staff Technical Product Specialist - Firewall)</dc:creator>
        </item>
        <item>
            <title><![CDATA[The Latest in Risk360: Agentic AI and Integration Support]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/latest-risk360-agentic-ai-and-integration-support</link>
            <guid>https://www.zscaler.com/blogs/product-insights/latest-risk360-agentic-ai-and-integration-support</guid>
            <pubDate>Tue, 15 Sep 2026 12:15:07 GMT</pubDate>
            <description><![CDATA[Security and risk teams are under pressure to do more than just identify issues—they need to understand what matters most, explain business impact clearly, and act more quickly across a growing set of tools and stakeholders. That’s the challenge&nbsp;Risk360 is built to solve. By helping organizations quantify cyber risk, prioritize remediation, and communicate posture in business-relevant terms, Risk360 gives customers a clearer view of where they stand and what they should do next.As part of this mission, Zscaler now has two new ways to help customers get even more value from Risk360: a Risk360 agent and support for Risk360 in&nbsp;OneAPI.The Risk360 AgentAs security environments become more complex, admins need more than dashboards and static workflows. They need a faster, more intuitive way to investigate issues, understand what is driving risk, make the best choices possible, and take the next right action. That’s where agentic AI can make a real difference. It can reduce the time it takes to navigate tools, interpret data, and translate technical findings into decisions that the business can act on.&nbsp;Zscaler’s new Risk360 agent brings the above benefits to risk analysis for each customer’s Zscaler environment. It helps admins quickly understand their overall risk posture, identify the most important issues that need to be addressed, and assess the financial exposure tied to those risks. Through natural-language interactions, customers can drill into specific categories and risk factors, investigate what is driving change, and uncover root causes. The result is faster analysis, more confident prioritization, and clearer communication with executives, compliance teams, and other stakeholders.The Risk360 agent is part of Zero Trust Exchange Agentic Operations, which enables agentic AI to manage Zscaler—whether that’s the Zscaler platform’s built-in agent (ZAgent) or, in the near-term future, third-party AI agents. Either way, the service allows agentic AI to leverage specialized product agents so that customers can interact with Zscaler services in a more cohesive, streamlined, and intelligent fashion. In other words, Risk360 can now be managed alongside other Zscaler solutions in a single conversational chat with an AI agent.Risk360 OneAPI SupportCustomers need the data from their security solutions to work beyond the boundaries of each individual tool. As such, application programming interfaces (APIs) are essential. They enable practitioners to integrate insights from their solutions into other tools for broader operational, reporting, and partner workflows—without relying on manual exports or disconnected processes.With Risk360 support now available for OneAPI, customers can leverage the same unified API endpoint that is used across the rest of the Zscaler platform for Risk360. Conceptually, this makes it easier to bring Risk360 into the systems and processes you already have in place. Practically, it supports workflows such as pulling historical risk scores and peer comparisons into internal dashboards, retrieving risk factor and financial exposure data for analysis, and automating report generation and access for downstream use. It creates a cleaner path for integration with GRC tools, SIEM workflows, service providers, and cyber insurance ecosystems that depend on timely risk data.By extending Risk360 through OneAPI, we’re helping customers turn risk insights into action far more efficiently—whether that means building custom workflows, feeding external systems, or scaling automation across teams.Wrap-UpTo learn more about our in-product AI experience and how it connects users to specialized product agents, read our&nbsp;ZAgent blog. To explore how OneAPI helps customers automate and integrate across the Zero Trust Exchange, visit our&nbsp;OneAPI webpage.]]></description>
            <dc:creator>Jacob Serpa (Sr. Product Marketing Manager)</dc:creator>
        </item>
        <item>
            <title><![CDATA[What&#039;s New in ZDX: Broader Reach, Smarter Remediation]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/what-s-new-zdx-broader-reach-smarter-remediation</link>
            <guid>https://www.zscaler.com/blogs/product-insights/what-s-new-zdx-broader-reach-smarter-remediation</guid>
            <pubDate>Mon, 14 Sep 2026 14:24:36 GMT</pubDate>
            <description><![CDATA[ZDX is the experience layer of the Zscaler SASE platform. It shares the same client connector, the same data plane, and the same global infrastructure that powers ZIA and ZPA. That means every improvement to digital experience monitoring simultaneously strengthens the security and networking fabric customers already rely on.This summer, based on what we're hearing from customers operating large-scale SASE deployments, we shipped two capabilities that make the platform even more valuable for customers. Here's what landed and why it matters. Remediation Scripts: Now Available for ZDX Standard and AdvancedWhen dev tools don't pick up the ZIA root certificate from their expected path, developers hit SSL errors that block their workflow entirely. The common workaround today is to bypass those dev tools from ZIA SSL inspection. That gets developers back to work, but it punches a hole in the zero trust architecture. Traffic that should be inspected flows uninspected. The security posture the SASE platform is designed to enforce gets undermined at the endpoint level.Customers told us this was one of their most persistent friction points: a recurring tension between developer productivity and maintaining zero trust coverage. They needed a way to fix the root cause, not route around it.Pre-written, ready-to-use scripts that resolve the root cert path issue and restore zero trust postureWe've introduced 20 pre-written remediation scripts available to ZDX Standard and Advanced customers and will continue to add more. These scripts fix the ZIA root certificate path configuration in dev tools so they work properly through ZIA SSL interception, eliminating the need to bypass.The result: developers stay productive and traffic stays inspected. Zero trust stays intact.Because remediation runs through Zscaler Client Connector (the same agent already deployed for ZIA and ZPA), there's no additional deployment, no second agent, and no separate tool. IT identifies the issue in ZDX, runs the fix from the console, and the endpoint is back in compliance with the SASE policy.Here's how the remediation capabilities break down by tier:CapabilitySTD / ADVADV+Support custom scripts❌✅Import any type of prewritten script❌✅Import dev tool scripts✅✅Set parameters, confirmation popup &amp; configurations✅✅For decision-makers, this is a signal of where ZDX is headed: not just visibility into experience issues, but the ability to resolve them in a way that reinforces the security architecture rather than working against it. 19 Global Vantage Points for Synthetic Monitoring (Up from 6)Synthetic monitoring tells you whether applications and network paths are healthy before users report problems. But that signal is only representative if probes originate close to where users actually work. As our customer base expanded into more regions with hybrid and remote workforces, we heard a consistent request: monitoring that reflects the geographies where their people sit, not just the geographies where our original probe infrastructure happened to be.When probes originate far from the user population, latency baselines skew, regional ISP issues take longer to surface, and the data becomes less useful for root-cause isolation or SLA reporting.13 new cities across Americas, EMEA, and APACWe've expanded from 6 to 19 data centers for synthetic monitoring, adding 13 locations in major global cities:Americas: New York, Los Angeles, Dallas, Atlanta&nbsp;EMEA: London, Paris&nbsp;APAC: Mumbai, Delhi, Chennai, Singapore, Tokyo, Osaka, SydneyThese locations align with Zscaler's existing global data center footprint, which means synthetic probe data and real-user telemetry flowing through the SASE platform can be correlated in the same infrastructure. Synthetic baselines and live traffic data reinforce each other.Performance baselines that reflect real geography, and SLA confidence to matchWhat this unlocks in practice:Representative performance baselines per region and office, derived from probes that originate locally rather than extrapolated from distant locationsFaster root-cause isolation because hop-by-hop tracing starts closer to where the issue livesMonitoring that matches how global and hybrid workforces actually operateSLA and experience reporting to leadership backed by geographically accurate dataFor practitioners, your synthetic test results now reflect what users in those cities actually experience. For leadership, the reports you present are grounded in local measurement, not inference. What's NextBoth of these capabilities reinforce the same principle: the experience layer of a SASE platform should make the entire architecture more operationally complete. Remediation that restores zero trust posture. Monitoring that matches the global footprint the platform already serves.As ZDX continues to evolve, every capability we ship is designed to strengthen the Zscaler platform, not just the monitoring console. Better detection, broader coverage, and faster resolution reduce operational friction across the entire SASE deployment.Want to see these in action? Schedule a personalized ZDX demo or explore the latest at zscaler.com/zdx]]></description>
            <dc:creator>John Jones (Sr.Marketing Manager–Digital Experience Monitoring)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Operate Zscaler Zero Trust Exchange with the Agentic AI tool of Your Choice]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/operate-zscaler-zero-trust-exchange-agentic-ai-tool-your-choice</link>
            <guid>https://www.zscaler.com/blogs/product-insights/operate-zscaler-zero-trust-exchange-agentic-ai-tool-your-choice</guid>
            <pubDate>Mon, 14 Sep 2026 12:40:06 GMT</pubDate>
            <description><![CDATA[Introducing&nbsp;Zero Trust Exchange Agentic Operations, which enables customers to use their preferred AI agents to interact with Zscaler through a secure, governed, and auditable operational layer.Enterprise teams are rapidly moving from experimenting with AI to putting it to work. AI assistants are already helping administrators find information, summarize incidents, and answer operational questions about their various solutions. The graphical interface will remain important. APIs, SDKs, and infrastructure-as-code will continue to be essential.&nbsp;The next step is agentic: enabling AI not only to provide an answer, but to help carry a task through to completion.There is a growing demand for these agent-driven use cases. Practitioners of all stripes want agents that can investigate why a user cannot access an application, retrieve relevant configuration details, recommend remediation tactics, and, when authorized, take action. And they want all of this functionality to be available for the specific AI assistants, models, and development frameworks that best fit their organizations.AI agents are emerging as another operational interface—one that allows admins to express desired outcomes in natural language and have agents achieve them.Zscaler is evolving to support this shift.&nbsp;&nbsp;From predefined automation to agent-driven operationsTraditional automation works best when the process is known in advance. A team defines a sequence of API calls, encodes the logic in a script or workflow, and runs it when a specific event occurs.Agents introduce a more flexible model. An admin can describe the intended outcome, and an agent can interpret the request, determine which tools are relevant, identify the steps it should take, and perform the relevant action(s).For example, “Why can’t this user reach our finance application?” is not a single API request. Answering it may require gathering context, checking multiple signals, evaluating configuration, and determining whether the issue is caused by policy, identity, device posture, connectivity, or the application itself. An agent can help coordinate that investigation rather than requiring an administrator to manually navigate every step.As customers explore agentic workflows in a platform, they need a consistent way for agents to interact with the different services within that platform. Giving an agent access to a collection of raw administrative APIs is not enough. The platform needs to expose useful operational capabilities while still controlling how each agent connects, what it can discover, which actions it can perform, and how those actions are recorded.That is the role of&nbsp;Zero Trust Exchange Agentic Operations.&nbsp;Introducing&nbsp;Zero Trust Exchange Agentic OperationsAgentic Operations&nbsp;enables first-party and third-party AI agents to securely perform supported Zscaler operations.Customers can access these capabilities directly through&nbsp;ZAgent, Zscaler’s native agentic experience within the Experience Center. An administrator can describe an objective in natural language, and ZAgent interprets the request, engages the appropriate specialized Zscaler agents and skills, and returns a coordinated response. This gives customers an integrated way to investigate issues, obtain insights, and perform supported administrative tasks without navigating multiple products or manually coordinating each step.Zero Trust Exchange Agentic Operations extends these capabilities beyond the Experience Center through the Agentic Operations Gateway and its hosted&nbsp;Model Context Protocol (MCP) server. MCP is an open standard that gives AI applications a consistent way to discover and use tools provided by external systems. Through the hosted MCP server, commercial AI clients such as Claude and ChatGPT, as well as agents built by customers, can access supported Zscaler capabilities without requiring customers to deploy and maintain their own Zscaler MCP server.Rather than simply exposing individual APIs as tools, the Agentic Operations MCP server is designed around operational intents. An intent represents the outcome a user wants to achieve, such as investigating an access issue, validating a policy, or resolving a connectivity problem. Zscaler coordinates the underlying tools, API calls, validation, and sequencing needed to fulfill that intent.This makes agentic workflows easier and more reliable because the agent does not need to understand every Zscaler product or independently assemble a complex sequence of low-level API calls.Throughout the interaction, the&nbsp;Agentic Operations Gateway provides the routing, identity, authorization, approval controls, and auditing required for enterprise operations. Customers retain the flexibility to choose where their agents and reasoning models run, while Zscaler manages and governs the connection to its services.Meeting customers where they areWe recognize that different teams will adopt different assistants, models, orchestration frameworks, and deployment patterns. Some customers will use commercial AI experiences. Others will build specialized agents for their own service desk, security operations, or administrative workflows. Many will use both.Zscaler’s Agentic Operations is designed for that reality.Use the agent experience that fits the organization. Customers can connect supported Zscaler capabilities to the AI clients their teams already use rather than moving every workflow into another interface.Make Zscaler capabilities understandable to agents. Raw APIs are optimized for developers, not necessarily for models interpreting human intent. Governed tools and Zscaler-authored skills can give agents clearer, task-oriented ways to retrieve information and perform supported operations.Support commercial and customer-built agents. Customers can connect approved commercial AI clients such as Claude and ChatGPT, as well as their own custom agents, through an OAuth 2.1 authorization flow. After signing in, users review and choose which of their assigned administrative roles to grant to the client, and can later revoke that access.The goal is not to prescribe how customers adopt AI. It is to make Zscaler ready to participate securely in the agentic ecosystems they choose.Governance built into the operational pathAs agents take on more operational work, the actions they perform must remain subject to the same enterprise controls that customers expect elsewhere in their environment. The Agentic Operations Gateway is designed to provide those controls as part of the interaction itself:Customer-controlled client authorization: Administrators control which AI clients can connect to their Zscaler tenant, including predefined clients such as ChatGPT and Claude. Zscaler’s authentication service (formerly ZIdentity) uses standards-based client metadata to establish the client’s identity and configuration.User authentication and consent: When an admin connects to an approved AI client, the authentication service authenticates the admin through the customer’s existing sign-in process and presents the administrative roles available to that admin. The admin can choose which roles to authorize for the client, ensuring that access is both user-bound and explicitly granted.Visible and revocable access: Admins can review the applications they have authorized and revoke access when it is no longer needed. Super Administrators can review and revoke authorization grants across the organization.Auditable authorization lifecycle: Client registration, authorization requests, grants, denials, token refreshes, and revocations are recorded in Zscaler audit logs.These controls allow customers to expand the scope of their agentic use cases without creating an unmanaged path that circumvents established operational safeguards.What agentic operations can look likeConsider a user who reports that a business-critical application is not working.Today, a support or security team member may need to move between a ticket, multiple consoles, logs, policy configuration, and documentation to diagnose the issue. Even when the remediation is straightforward, collecting the context and determining the correct action can take time.With&nbsp;Agentic Operations, the customer’s preferred agent could invoke an intent to investigate the access issue. The hosted MCP server could route the request to the appropriate Zscaler capabilities, gather the relevant context, and return a likely cause and recommended remediation. If the proposed action requires approval, the agent could pause for confirmation. Once approved, the supported operation could be executed and the workflow recorded for auditing.&nbsp;The agent provides the experience and coordinates the interaction with the admin. Zscaler provides the trusted operational capabilities and governs how they are used.This model can extend across a growing range of use cases: retrieving configuration and posture information, investigating incidents, validating policy, responding to service desk requests, coordinating change workflows, and carrying out approved remediation.The value is a more intuitive and governed path from intent to operational outcome.Building the next interface to ZscalerThe move toward agent-driven operations will not replace existing consoles or automation tools. It simply expands the ways customers can work with Zscaler.Just as APIs enabled developers to build integrations, agents create a new interaction model for operational work. Customers can begin with simple tasks like using natural language to obtain information about their policies and gradually adopt more advanced workflows as their needs and governance models mature.Zero Trust Exchange Agentic Operations provides the foundation for that evolution: a hosted service, intent-based tools and skills, standards-based connectivity, intelligent routing, strong identity, least-privileged authorization, approval controls, and end-to-end auditability.Here's an example demo of how it works:&nbsp; By providing this foundation, Zscaler can continue supporting new agentic use cases while giving customers a consistent and controlled way to adopt them.Join the Early Access ProgramZero Trust Exchange Agentic Operations is opening for early access, and we are inviting customers and partners to help shape what comes next.Early access participants will be able to explore agent-driven Zscaler operations, validate priority use cases, and provide direct input into the intents, tools, skills, workflows, and governance capabilities we develop.We are particularly interested in hearing from organizations that are already using commercial AI assistants, building their own enterprise agents, or identifying operational workflows that could benefit from a more natural, agent-driven experience.AI agents are becoming a new interface for enterprise operations. Our goal is to make Zscaler capabilities available through that interface while preserving the control, visibility, and trust our customers require.Talk to your Zscaler representative to learn more and request participation in the&nbsp;Zero Trust Exchange Agentic Operations Early Access Program.]]></description>
            <dc:creator>Puja Wheeldon (Senior Product Manager)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Navigating India&#039;s DPDP Rules 2025]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/navigating-india-s-dpdp-rules-2025</link>
            <guid>https://www.zscaler.com/blogs/product-insights/navigating-india-s-dpdp-rules-2025</guid>
            <pubDate>Fri, 11 Sep 2026 13:35:06 GMT</pubDate>
            <description><![CDATA[India's Digital Personal Data Protection mandate is no longer on the horizon—it's here, and it demands action. With the official notification of the DPDP Rules 2025 and potential penalties reaching up to ₹250 crore, the mandate for "reasonable security safeguards" has moved from a legal clause to an urgent technical priority for security and privacy teams.The core challenge for CISOs, DPOs, and compliance teams is clear: how do you translate these strict, complex regulatory requirements into a modern, effective security architecture?While the DPDP framework introduces stringent legal obligations, the technical path to compliance can be straightforward with the right strategy and platform. The key is to map the specific operational rules to actionable technology controls.This post provides a mapping of the DPDP Rules 2025's key information security and privacy provisions to the capabilities of the&nbsp;Zscaler Data Security Platform. The goal is to provide a clear, unambiguous guide on how you can leverage Zscaler's powerful platform to address your compliance obligations and secure your organization's data in this new era. The DPDP Rules 2025 and Zscaler: A Comprehensive Compliance MappingThe following table serves as a practical blueprint for security and privacy professionals. It breaks down the most critical provisions from the officially notified DPDP Rules in sequential order, identifies the necessary technology controls, and maps them directly to the specific Zscaler components that help you achieve compliance. The "Justification" column explains precisely&nbsp;how&nbsp;each Zscaler tool addresses the regulatory mandate.    Conclusion: From Legal Obligation to Security ConfidenceThe DPDP Rules 2025 present a clear mandate for businesses operating in India: protect personal data by design or face severe consequences. As we've seen, achieving compliance is not merely an exercise in drafting policies; it requires a robust, integrated technical foundation.&nbsp;By leveraging the comprehensive capabilities of the Zscaler Data Security Platform—from&nbsp;Zero Trust Network Access (ZTNA) and Data Security Posture Management (DSPM) for visibility, to inline Data Loss Prevention (DLP) for enforcement, and Workflow Automation for incident management—organizations can build the "reasonable security safeguards" required . Zscaler provides not only the tools to protect data but also the critical visibility, evidence, and auditability required by&nbsp; the Data Protection Board of India.In this era of stringent data privacy, reactive measures are a liability. A proactive, platform-based approach to data security is essential. With Zscaler, you can move from a state of compliance uncertainty to one of security confidence, helping to ensure that your organization is secure by design.&nbsp;Is your business ready for the DPDP mandate?Talk to a Zscaler expert today to explore how the Zscaler Data Security Platform can streamline your compliance journey.&nbsp;&nbsp;&nbsp;This blog post has been created by Zscaler for informational purposes only and is provided "as is" without any guarantees of accuracy, completeness or reliability. Zscaler assumes no responsibility for any errors or omissions or for any actions taken based on the information provided. Any third-party websites or resources linked in this blog post are provided for convenience only, and Zscaler is not responsible for their content or practices. All content is subject to change without notice. By accessing this blog, you agree to these terms and acknowledge your sole responsibility to verify and use the information as appropriate for your needs.]]></description>
            <dc:creator>Rohit Gambhir (Principal Specialist Sales Engineer)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Encrypted Client Hello Is Here to Stay]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/encrypted-client-hello-ech-here-stay</link>
            <guid>https://www.zscaler.com/blogs/product-insights/encrypted-client-hello-ech-here-stay</guid>
            <pubDate>Fri, 11 Sep 2026 00:51:47 GMT</pubDate>
            <description><![CDATA[Encrypted Client Hello (ECH), standardised by the IETF in&nbsp;RFC 9849, is rapidly becoming a normal part of Internet connectivity.Google’s introduction of platform support for&nbsp;ECH in Android 17 is an important milestone. ECH itself is not new: Chrome enabled it starting with Chrome 117 in September 2023, followed closely by Firefox 119 in October 2023. Chromium-based browsers such as Microsoft Edge subsequently gained support as well. The vast majority of modern desktop browsers are therefore already ECH-capable. Android 17 confirms that ECH is moving beyond a browser-specific feature and becoming part of the mainstream application networking platform.This is good news for Internet privacy.TLS has long protected application data, including the URI being accessed, credentials, HTTP headers and content. But one particularly useful piece of metadata has traditionally remained visible: the Server Name Indication (SNI) extension in the TLS ClientHello, which normally identifies the hostname the client intends to contact.ECH protects the real SNI, along with other sensitive ClientHello information, from passive network observers.For enterprises, however, this deliberately changes an assumption that many security architectures have relied on for years: the SNI visible in a TLS ClientHello can no longer be assumed to identify the service the client is actually accessing.Fortunately, protecting user privacy and maintaining strong enterprise security are not mutually exclusive. From SNI to ECHSNI was created to solve a very practical problem.With HTTP, multiple websites can share the same IP address because the HTTP Host header tells the server which site the client wants. With HTTPS, TLS takes place before the HTTP request, so the server needs to know which certificate to present before it can read that encrypted Host header.Assigning a unique IPv4 address to every HTTPS service was not practical, and universal IPv6 deployment was nowhere close when the problem needed to be solved. SNI provided an elegant solution: put the hostname into the TLS ClientHello, allowing the server to select the correct certificate before establishing the encrypted connection. The inevitable consequence was that the hostname remained visible.Over time, SNI became useful for much more than virtual hosting. Enterprise security products used it for traffic classification and access control. Parental-control services used it for filtering. Security proxies used it to decide whether a connection should be decrypted or bypassed, for example when dealing with certificate-pinned applications. Censorship systems discovered the same signal.The first attempt to address the privacy issue was Encrypted SNI, or ESNI. The IETF work subsequently evolved into ECH, protecting the sensitive ClientHello rather than only one extension.That broader design also incorporated ECH GREASE. An ECH-capable client can send a realistic-looking dummy ECH extension even when it is not actually using ECH. This prevents the mere presence of the ECH extension from becoming a reliable signal for classification or blocking.This matters because both real ECH and GREASE ECH normally still contain a visible SNI. With real ECH, that SNI is normally a cover name while the actual destination is protected. With GREASE, the visible SNI is normally the real destination. An observer cannot simply see the ECH extension and assume it knows what the visible SNI means. How ECH Works, in BriefECH-capable services normally advertise their configuration using HTTPS or SVCB DNS records. This does not require DNS over HTTPS or DNSSEC; those provide different and complementary protections.The ECH configuration includes a public key and a public_name identifying the client-facing service.The client then constructs two TLS ClientHello messages:ClientHelloInner contains the real SNI and the TLS parameters the client actually wants to use.ClientHelloOuter is visible on the network. It normally contains the ECH public_name as its SNI and carries an encrypted representation of ClientHelloInner.If the destination successfully processes ECH, the TLS connection proceeds using the Inner ClientHello. The Outer ClientHello is therefore not an authoritative description of the actual connection.ECH is also deliberately downgrade resistant. If a server cannot process ECH, the client does not simply retry in plaintext. The rejection first has to be authenticated. In particular, the client authenticates the TLS peer against the ECH public_name. Only an authenticated peer can provide updated ECH configuration or securely indicate that ECH is unavailable.This distinction is important for enterprise environments. An arbitrary device on the network cannot simply strip ECH and make the client reveal its real SNI. A legitimate TLS inspection proxy explicitly trusted by a managed endpoint has a different relationship with the client and can participate in this authenticated fallback. What Changes for Enterprise Security?ECH intentionally makes visible SNI less trustworthy. That matters particularly where enterprises use SNI to decide which connections should bypass TLS inspection.Consider a certificate-pinned application. Because the application may reject certificates generated by a TLS inspection proxy, an enterprise might historically create an exception such as:If SNI is updates.pinned-app.example.com, bypass TLS inspection.That rule assumes the SNI proves that the connection actually belongs to the pinned application. It does not.With ECH, the visible SNI may be a cover name rather than the true destination. A malicious client can also deliberately construct an Outer ClientHello containing an SNI chosen to influence network policy. A broad SNI exception intended for one application can therefore become an attractive evasion mechanism for unrelated traffic.There is a second, subtler risk. A malicious client can put deliberately unsuitable TLS parameters into&nbsp;ClientHelloOuter, for example unsupported&nbsp;supported_groups values or a&nbsp;key_share that an inspection proxy cannot use. At the same time, it can place completely valid TLS parameters inside the encrypted&nbsp;ClientHelloInner.An ECH-capable destination that decrypts the Inner ClientHello can establish the connection normally. The enterprise proxy, however, sees only an Outer ClientHello that it cannot successfully inspect.If the security policy responds to that situation by classifying the connection as “undecryptable” and allowing it through without inspection, the attacker has achieved precisely the desired result.The important lesson is not that ECH is a security problem. It is that ECH makes security policies based on unauthenticated network hints increasingly fragile. Handling ECH Safely with Zscaler Internet AccessZscaler Internet Access uses multiple complementary controls to address these scenarios. The objective is not to weaken ECH, but to avoid depending on visible SNI as the sole source of truth.Control ECH discovery through DNSThe most straightforward place to prevent ECH negotiation when TLS inspection is required is before the TLS connection begins.Clients normally obtain ECH configuration through the&nbsp;ech parameter of HTTPS or SVCB DNS records. ZIA DNS Control can inspect DNS over UDP and TCP, as well as DNS over HTTPS when that traffic traverses ZIA and is decrypted.Zscaler recommends blocking HTTPS and SVCB resource-record queries where ECH needs to be suppressed and returning DNS response code 2,&nbsp;SERVFAIL. Ordinary A and AAAA resolution remains available, so the application can continue by establishing a conventional TLS connection without having obtained an ECH configuration.An ECH-capable client may still send ECH GREASE. That is expected and does not mean genuine ECH is being used.The current approach blocks the complete HTTPS/SVCB response and therefore also removes other information the record might contain. A future enhancement will make this more surgical by removing only the&nbsp;ech parameter while preserving other service hints.Use authenticated ECH fallback with trusted TLS inspectionDNS control alone is not sufficient. A client may already have an ECH configuration cached, or it may have obtained one through another mechanism.In that case, ZIA can make use of ECH's own authenticated fallback behaviour.When ZIA terminates the Outer TLS connection, the client does not receive a valid ECH acceptance confirmation and considers ECH rejected. ZIA then presents a certificate for the visible ECH&nbsp;public_name.On a managed endpoint configured to trust the Zscaler inspection CA, that certificate can be authenticated successfully. If no usable replacement ECH configuration is supplied, the client can securely disable ECH, close the first connection and establish a new one without ECH. The real SNI is then visible for TLS inspection.This is fundamentally different from stripping ECH in transit. The client itself chooses to retry without ECH only after an authenticated TLS exchange. An arbitrary network intermediary that is not trusted by the endpoint cannot do the same thing.Bind the SNI to the destination with Optimize DNS ResolutionEven after genuine ECH has been suppressed, blindly trusting SNI can still be dangerous.A malicious client might connect to an attacker-controlled IP address while putting the SNI of a trusted or inspection-exempt application into the ClientHello.Optimize DNS Resolution provides another layer of protection. ZIA can independently resolve the hostname visible in SNI or HTTP and, where appropriate, use its own resolution result rather than the destination IP supplied externally by the client.The client can therefore no longer freely combine a trusted-looking SNI with an attacker-selected destination IP address.Zscaler specifically identifies mitigation of ECH-based domain-fronting evasions as one of the security benefits of this capability. DNS Optimization can also operate when SSL/TLS inspection itself is bypassed, because the visible SNI remains available as an input to resolution.Replace broad SNI bypasses with Endpoint ContextThere is an even stronger answer to the problem of certificate-pinned applications.Instead of assuming that any connection carrying a particular SNI must have originated from the trusted application,&nbsp;Zscaler Endpoint Context can provide information about the process that actually created the connection.Endpoint Context collected through Zscaler Client Connector can include application name and publisher, cryptographic hashes, and code-signing certificate information. That context can be incorporated into SSL/TLS Inspection and other security policies.This allows an inspection exception to become much more precise.Instead of:If SNI is updates.pinned-app.example.com, bypass TLS inspection.a policy can effectively say:If the originating process has a cryptographic signature of expected certificate-pinned application and SNI is updates.pinned-app.example.com, bypass TLS inspection.Traffic using the same SNI but originating from a browser, an unknown process or malware does not automatically inherit the exception.This is a stronger policy model even without ECH. ECH simply makes the limitations of destination-only exceptions much more visible.Do not fail open on an unusable Outer ClientHelloFinally, a client should not be able to escape inspection simply by deliberately constructing an Outer ClientHello that the proxy cannot process.ZIA SSL/TLS Inspection policy provides a&nbsp;Block Undecryptable Traffic option. When enabled, traffic that cannot be processed for inspection is blocked instead of automatically being allowed through.Legitimate applications that cannot tolerate TLS inspection should receive explicit, narrowly scoped exceptions, ideally based on Endpoint Context where possible.The principle is simple: failure to inspect must not itself become a credential for bypassing inspection. ECH Is Here to StayECH fixes a genuine privacy weakness in TLS. Users should not have to disclose every hostname they access to every network that happens to forward their packets.Its growing deployment should be welcomed.At the same time, ECH means enterprises can no longer build security policy around the assumption that a plaintext SNI is authoritative. Fortunately, managed enterprise environments have stronger signals available.DNS visibility can control ECH discovery where inspection is required. Trusted TLS proxies can use ECH's authenticated fallback rather than attempting to circumvent the protocol. Optimize DNS Resolution can bind visible hostnames more closely to their real network destinations. Endpoint Context can make certificate-pinning exceptions application-aware. Fail-closed handling prevents intentionally unusable TLS handshakes from becoming a bypass.SNI was never intended to be a universal application identity mechanism. It became one because it was convenient, visible and usually accurate enough.ECH deliberately changes that.Encrypted Client Hello is here to stay. Enterprise security needs to evolve with it.]]></description>
            <dc:creator>Yaroslav Rosomakho (Chief Scientist)</dc:creator>
        </item>
        <item>
            <title><![CDATA[How to Enforce Zero Trust Policies Using Endpoint Application Context]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/how-enforce-zero-trust-policies-using-endpoint-application-context</link>
            <guid>https://www.zscaler.com/blogs/product-insights/how-enforce-zero-trust-policies-using-endpoint-application-context</guid>
            <pubDate>Thu, 10 Sep 2026 23:57:54 GMT</pubDate>
            <description><![CDATA[How to Enforce Zero Trust Policies Using Endpoint Application ContextOne of the core tenets of the Zscaler Zero Trust Architecture is least-privilege access: securely connecting users, workloads, and devices only to the applications they are authorized to use, and not to the broader network.To enforce least privilege, security controls must accurately identify&nbsp;what application a user or device is attempting to reach. For this, Zscaler supports multiple application-identification mechanisms for both web and non-web traffic.In this blog we’ll cover how SOC and IT teams can answer two key questions about any application or process running on an endpoint: “Which endpoint application generates certain traffic, and what is the associated risk context?” Answering these questions requires end-to-end visibility across endpoint activity, sanctioned and unsanctioned applications, and network sessions. How Zscaler Identifies Endpoint Applications Across Web and Non-Web TrafficBecause over 95% of global web traffic is encrypted1, TLS/SSL inspection is essential to completely identify the application and detect threats inside encrypted flows. These types of applications are URL categorizations and Cloud Apps.For non-web traffic, TLS/SSL inspection is typically not applicable. In these cases, Zscaler Zero Trust Firewall (ZTFW)—which secures traffic across all ports and protocols—can identify applications using approaches such as:FQDN / wildcard FQDN (wFQDN) matchingNetwork Services (protocol + port combinations)Network Applications (DPI-based identification)Application Services (groups of destinations + ports/protocols)1&nbsp;Google Transparency Report Comparing Application Identification Methods: Deep Packet Inspection (DPI), TLS/SSL Decryption, Network Services and MoreEach application identification method has distinct advantages and prerequisites. TLS/SSL decryption provides complete visibility into traffic contents, but primarily applies to encrypted web&nbsp;DPI-based identification works well for non-web traffic whether encrypted or not, though it may require multiple packets to accurately determine the application. Destination-based L3/L4 matching, such as Network Services and Application Services, enable first-packet classification but its effectiveness can be reduced when applications are delivered through CDN networks.Despite these strengths, all of these approaches share a common behavior:&nbsp;they identify traffic at the network/protocol level but do not identify the application on the endpoint that generated the traffic.&nbsp;For example, DPI may classify traffic as SSH, but it cannot indicate which specific client side application initiated the SSH session. Similarly, TLS/SSL decryption can reveal full web or FTP content, but it does not necessarily identify the browser (e.g. Chrome vs. Tor browser), version, or specific application responsible for generating that traffic. Why Endpoint Visibility Is Critical for Stopping Living off the Land (LOTL) AttacksToday’s attackers, whether AI-driven or human, rarely follow a single playbook. Instead, they increasingly rely on Living off the Land (LOTL) techniques—blending traditional malware with legitimate tools like WMI, and RDP. Because this activity often resembles normal operations, it can slip past detection methods based solely on signatures or destinations.As a result, it’s no longer sufficient to ask, “What application traffic is this?” You also need to know, “Which endpoint application generated this traffic, and what is the associated risk context?”Answering these questions requires end-to-end visibility across endpoint activity, sanctioned and unsanctioned applications, and network sessions. How Zscaler Delivers Ground-Truth App Visibility with Endpoint Application InventoryTo address gaps in reliable application identification and to help customers respond to LOTL techniques, Zscaler recently released Endpoint Application Inventory (powered by Zscaler Client Connector). Endpoint Application Inventory provides application-level visibility and risk assessment across endpoints and the cloud, enabling customers to understand:What applications are installedWhere they are installedWho is using themWhether the application has unresolved vulnerabilities and risk signalsUsing Endpoint Applications and Risk Signals as ZIA Security Policy CriteriaWe’re now extending this capability to beyond monitoring and classification, customers can now use Endpoint Applications and related risk signals directly in:Advanced Zero Trust Firewall policiesDNS Control policiesTLS/SSL inspection policiesAdvanced Threat ProtectionIPS Control (future)&nbsp;This enables policies to match not only on network attributes (e.g., like network app, IP, FQDN, port, protocol), but also on the&nbsp;originating endpoint application name, tags and risk level. For example, you can detect when risky or compromised applications initiate traffic and enforce policy based on the application’s risk level.&nbsp;Note:&nbsp;Some functionality may not be available immediately at launch and will be enabled in phases. Availability and feature scope may also vary depending on your license.&nbsp;&nbsp; Key Use Cases for Endpoint Application as Policy Criteria&nbsp;&nbsp;Use caseWhat it enablesAllow or block based on endpoint applicationApply policy actions—such as allow or block—based on the endpoint application that generated the traffic. This is especially valuable in Advanced Firewall policies, since Firewall can evaluate all traffic, both web and non-web, when it reaches ZIA.Canonical application identificationEndpoint applications provide the most authoritative (“ground truth”) application identity when Client Connector is present, reducing reliance on continual DPI-only detection expansion.Precision policy enforcement across Firewall/DNS/IPSCreate policies based on true endpoint application, not just destination or port/protocol.IPS integration with endpoint application dataThreatLabz and customer SecOps teams can create detections that incorporate endpoint application data even when traffic is encrypted or not decrypted.Richer logs for faster investigationsEndpoint application data (such as application name, risk level and type) in Firewall, DNS and Web Insights logs provides earlier, more actionable signals in the kill chain.Better visibility into encrypted communicationsHelps correlate encrypted cloud-bound communications to the originating endpoint application, augmenting endpoint categorization and response.&nbsp; ZIA Policy Examples: Block or Allow Traffic by Endpoint Application and Risk LevelZero Trust Firewall example:&nbsp;To block all traffic originating from Brave browser, you can apply a policy such as:&nbsp;If Endpoint Applications == brave.exe (Brave Browser), then Block.&nbsp;&nbsp;DNS Control example (application-specific allowance):If DNS Protocol == DNS over HTTPS and Endpoint Applications == Chrome, then Allow.This demo video provides more examples of using Endpoint Context application data used as policy criteria in ZIA. Conclusion: Elevate Security Accuracy with Endpoint Application IntelligenceBy including endpoints applications and risk as criteria in ZIA security policies —&nbsp; across Firewall, DNS Control, TLS/SSL Inspection and ATP policies — organizations can improve enforcement accuracy and strengthen early detection and prevention for modern threats, including Living off the Land (LOTL) techniques.Below is a quick summary of the available application identification techniques. Depending on the policy type you can combine multiple conditions within a single policy to increase accuracy for both targeting and control.Application identification methodBenefitsURL and Cloud App&nbsp;Good for identifying where the web traffic is destined to but not what is generating the web traffic (e.g. Chrome vs. Brave browser).Network ServicesGood for identifying ports and protocols being used but can miss applications on non-standard ports (e.g. SSH on port 2200).Application ServicesGood for knowing the L3/4 destinations on the first packet.Network Application (DPI-based identification)Good for identifying the application irrespective of the L3/L4 destination.Endpoint ApplicationsGood for identifying the endpoint application sending the traffic.]]></description>
            <dc:creator>Brendon Macaraeg (Principal Product Marketing Manager)</dc:creator>
        </item>
        <item>
            <title><![CDATA[The Containment Tax: When OT Outages Aren&#039;t OT Attacks]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/containment-tax-when-ot-outages-aren-t-ot-attacks</link>
            <guid>https://www.zscaler.com/blogs/product-insights/containment-tax-when-ot-outages-aren-t-ot-attacks</guid>
            <pubDate>Thu, 10 Sep 2026 20:39:10 GMT</pubDate>
            <description><![CDATA[Quick answer: Boston Scientific disclosed on September 8, 2026 that a cyberattack detected on August 25 disrupted manufacturing and order fulfillment for roughly two weeks, enough that the company no longer expects to meet its third-quarter and full-year guidance. The company has said the intrusion was limited to on-premises IT systems. Production stopped anyway, because several systems a plant depends on to run a shift - order release, scheduling, quality, identity - sit in enterprise IT and were taken offline to contain the incident. Many OT security programs secure the controllers but never fully map those dependencies. That gap is the containment tax.&nbsp; What actually stopped at Boston ScientificBoston Scientific&nbsp;detected unauthorized activity on its IT systems on August 25 and responded the way most companies would: it took affected systems offline while it investigated. That decision cut employees off from the applications they use to process and ship orders, and the effect reached the plants the same day. Staff at the company's Cork, Ireland site were&nbsp;sent home on August 25 because the systems their shift depends on were unavailable. Two weeks later, on September 8, the company&nbsp;told investors in a Form 8-K that it no longer expected to meet its third-quarter and full-year 2026 net sales growth and adjusted EPS guidance, with a revised outlook to follow with its third-quarter results on October 28. It added that it does not expect a material impact on its long-term financial condition. On September 9 it reported that manufacturing, order fulfillment and shipping were fully restored.What makes this incident worth studying is how little the attacker appears to have done relative to what it cost. In an&nbsp;August 30 update the company said the unauthorized activity was limited to certain on-premises systems, that its cloud systems were unaffected, and that investigators had found no indication of unauthorized activity in its environment after August 25. The attacker was contained within a day. The outage ran for two weeks and forced a revision to guidance.The company's own description of what went down is the most useful sentence in the record. It listed the affected systems as operational technology support functions and the business applications required to manufacture products, process customer orders, and ship devices. Nothing in the public record says a controller, an HMI, or anything on the plant network was touched. On the record this is not an OT compromise; it is an OT outage, caused by an IT containment decision. For the people running the line, that distinction did not change what the outage cost. It does change what would have prevented it. Two halves of securing a plantMost of the conversation about OT security, including a good share of what we have published, is about one problem: protecting the equipment that touches the physical process. Segmenting the controllers, brokering vendor remote access, inventorying devices that cannot take an agent, watching the engineering workstations that program the PLCs. That work is still needed and most plants are nowhere near done with it. But it is one half of securing a plant floor, and it addresses only one of the two ways a plant fails. The other half is staying available. Boston Scientific's outage came from the second half, while the first half, as far as anyone has said, held.Consider what a plant needs to run a single shift. An order has to be released from the ERP and a schedule has to reach the MES. Materials are issued and lots are traced. In a regulated medical device plant, sterilization and quality release have to be scheduled and recorded before anything ships. Labels print from a system that pulls from the ERP, and operators log in against a directory service. It is very common for all of these services to live in, be operated by, and be connected to the IT space. They serve the plant floor, though not always solely, and they are serviced by internal IT resources rather than the plant team. Boston Scientific called them "OT support functions."&nbsp;CI Fortify, the joint isolation guidance CISA and its international partners published in July, calls them enabling systems. Either name is fine; what matters is that they get counted.In the&nbsp;Purdue reference model that most OT architectures still map to, the physical process and its controllers sit at Levels 0 through 2, plant operations systems like MES and historians at Level 3, and the enterprise systems above them at Level 4. OT security programs are usually scoped to the lower levels, and for good reason: that is where the safety and integrity risk lives. The systems at Level 3 and above play a dual role that is easy to miss. To the IT organization they are business applications with an uptime SLA. To the plant they are production infrastructure, and when one is offline the line stops just as surely as if a controller had failed. Neither team is wrong about its scope. The gap is a shared understanding of which systems play both roles, and what the plant looks like when one of them is deliberately switched off. The half of CI Fortify that gets overlookedCI Fortify, published July 28, 2026 by CISA, ASD's ACSC, the FBI, NCSC-UK, and the Canadian Centre for Cyber Security, is titled&nbsp;Advice for Isolating Vital Systems. Its scope, stated on the first page, is vital OT and enabling systems. Operators are asked to record every interconnection between those systems and the corporate network, vendors, and cloud services, to mark the isolation points, and to test isolating all vital systems together, because testing one system at a time will not surface the dependencies between them.Much of the industry's response, including our own&nbsp;When "Prepare to Disconnect" Becomes Official Guidance, concentrated on the first half of that scope. We wrote about flat plant networks that have no pre-built isolation points to execute, and about making isolation a tested policy rather than an emergency improvisation. That post also drew a boundary we can now put a name to: isolating quickly and operating in isolation for an extended period are two different capabilities, and while a kill switch answers the first, the second depends on knowing which enabling systems the plant needs and whether it can run without them.The Boston Scientific outage is the problem that second capability exists to solve. The guidance itself warns that disconnecting will stop equipment that was never damaged if authentication, name resolution, or other required services sit outside the isolation boundary. That is a fair description of a medical device plant with the ERP and the directory turned off. The enabling-systems half of CI Fortify is the half that would have mattered here, and it gets overlooked partly because there is no sensor or appliance that addresses it. It is an architecture and dependency-mapping problem, which makes it harder to sell as a product and easier to postpone. The containment tax, measuredBoston Scientific is one instance of a pattern that has been visible for years. Set aside the genuine OT compromises - the 2017 Triton attack on safety controllers at a petrochemical plant, or the&nbsp;December 2025 wiper attack on Poland's energy sector that damaged remote terminal units at more than thirty wind and solar sites - and look at the incidents that made "OT" headlines without any operational technology being attacked. They sort into two groups.Precautionary shutdown, OT untouched.&nbsp;Colonial Pipeline in 2021 shut the pipeline for about six days, reportedly over concern about its billing systems rather than its control systems.&nbsp;Toyota idled fourteen plants for a day in 2022 because a parts supplier, not Toyota, had been hit.&nbsp;Nucor in May 2025 disclosed that, in an abundance of caution, it had proactively halted certain production operations at various locations while it took potentially affected IT systems offline.Dependency collapse: plants fine, product can't ship.&nbsp;Clorox in 2023 fell back to manual order processing, reported significant product outages, and booked $49 million in costs by year end.&nbsp;Asahi in 2025 lost its ordering and shipping systems in Japan; a company spokesperson told AFP that production was not directly affected but had been halted because shipments were suspended, and shelves ran short of beer.&nbsp;Jaguar Land Rover in 2025 stopped production for roughly five weeks after an IT shutdown and needed a £1.5 billion government-backed loan guarantee to stabilize its supplier base. Boston Scientific joins this group.In each case the number that showed up in the disclosure was not dwell time or the attacker's reach. It was the gap between how long the intrusion lasted and how long the outage lasted. At Boston Scientific that gap is roughly one day against fifteen: the last unauthorized activity the company has reported was on August 25, and it declared operations fully restored on September 9.That gap is the containment tax: the cost of the only containment option the architecture allowed, which took plant availability down with it even though the attacker never caused that directly. The tax has several line items. Lost production days are the visible one. Behind them sit the cost of running manual processes, the backlog and expedite costs once systems return, the rebuild and validation effort in a regulated environment, and in this case a public revision to guidance. Every one of those was paid whether or not the attacker ever intended to reach a plant, because the architecture gave responders one option, and it disconnected the plant along with the compromised systems. Isolating the enterprise without isolating the plantThe tax is paid because containment in most environments is binary. Once an intrusion is confirmed in enterprise IT, responders have one action that is guaranteed to work, and it takes the plant's dependencies down as a side effect. More detection on the plant network does not change that calculus; a sensor there would have reported a healthy, idle plant for two weeks.What changes the calculus is enforcement at the seam where the plant meets the enterprise. In Purdue terms that seam is Level 3.5, the industrial DMZ, and in most plants it is a firewall pair with a route table behind it. Once an enterprise incident is confirmed, the only containment available is to close that boundary, and every Level 3 system that depends on Level 4 goes down with it.&nbsp;Zero Trust Branch replaces that boundary with policy. Deployed at Level 3 and 3.5, it brokers each flow between the plant's operations systems and the enterprise - MES to ERP, quality release to the directory, label printing to the order system - as an explicit, identity-based connection through the Zero Trust Exchange rather than an implicit path across a DMZ. Two things follow. A containment action can be scoped to the tier that is actually affected, because there is a specific policy to revoke rather than a whole boundary to close, and the plant's paths to the enabling systems it still needs are defined connections that can be kept open while the rest of the enterprise is cut off.&nbsp;Zero Trust Segmentation applies the same principle inside Level 3 and below, so a compromise that does reach an operations system cannot spread to the controllers, and&nbsp;Privileged Remote Access brokers the contractor paths into both layers, one of the most common entry points in industrial incidents. None of this maps the dependencies for you or decides which enabling systems are vital; that remains the operator's work under CI Fortify, and it is the input that makes scoped containment possible.&nbsp; Run the dependency testPick one plant and one shift. List everything that has to be up for that shift to release product, then mark each item as living on the plant floor or in enterprise IT, and for each enterprise item write down what happens to the line if it is offline for a day. The list is usually longer than expected, and the enterprise items on it have often never been in scope for the OT security program, not through anyone's neglect but because the dual role of those systems was never written down. That list is your CI Fortify connection map, and it is also the scope of your next containment decision.If you would rather work through that exercise with someone who has done it before, request an&nbsp;OT architecture workshop and we will map vital systems, enabling systems, and isolation points against the CI Fortify model with your team. Or, hear from our customers directly on how they use Zscaler for OT security.&nbsp;]]></description>
            <dc:creator>Bryan Ashley (Zero Trust Networking, Principal Architect)</dc:creator>
        </item>
        <item>
            <title><![CDATA[The Modern Admin Experience Comes to GovCloud]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/modern-admin-experience-comes-govcloud</link>
            <guid>https://www.zscaler.com/blogs/product-insights/modern-admin-experience-comes-govcloud</guid>
            <pubDate>Thu, 10 Sep 2026 19:00:00 GMT</pubDate>
            <description><![CDATA[GovCloud customers can now administer, automate, and authenticate across their entire Zscaler deployment from a single management plane. This release brings together Experience Center, OneAPI, and Authentication Service into one operational layer, closing the longstanding separation between products at the admin level.This isn't three separate product launches. It's one story: government and defense industrial base customers now have a unified platform for managing their entire deployment with programmable automation and a consolidated identity foundation underneath it.Since earning FedRAMP Moderate authorization in 2018, Zscaler has steadily expanded GovCloud capabilities. This release brings that trajectory to the management layer: one policy engine, one API surface, and one identity integration, all built within a FedRAMP authorized boundary. Why Separate Portals Create Compounding RiskGovernment security teams have historically managed their Zscaler environments across multiple portals. ZIA, ZPA, and ZDX each had their own admin interface, their own login, and their own workflows. That fragmentation creates operational overhead, increases the risk of policy drift between products, and makes it harder to respond quickly during incidents.Every product with its own admin interface introduces a separate login, a separate policy engine, and a separate audit trail. Three places where policy can drift out of alignment without anyone noticing until a compliance review surfaces the gap. Manual changes require the same update repeated across interfaces with no version control, no programmatic validation, and multiplying IDP integration points to rotate and audit.For agencies pursuing continuous ATO or operating under tight staffing constraints, this overhead directly slows the pace at which teams can respond and scale. Experience Center: Centralized Administration and VisibilityExperience Center is the operational hub. It consolidates the management, configuration, and monitoring of your entire Zscaler deployment into a single console.What this means for your team:Unified policy management. Configure and enforce security policies across ZIA, ZPA, and ZDX from one console. Policies stay consistent because they are managed in one place, reducing the risk of configuration gaps between products.Correlated telemetry in a single timeline. Reporting, dashboards, and operational telemetry are consolidated across products. Your team can diagnose cross-product issues without switching interfaces during an active incident.Simplified audits and provisioning. A single administrative record across all products with zero-touch workflows means fewer places to pull evidence from during compliance reviews and faster onboarding of new locations and connectors.One RBAC model. Platform administrators onboarding new team members need one set of workflows to train on, not three separate permission systems with divergent terminology.For lean government IT teams managing complex multi-product deployments, this consolidation is a meaningful operational improvement. OneAPI: Programmable Policy and IntegrationA unified console is the starting point. OneAPI extends the management experience through a unified API gateway that provides programmatic access to supported management, configuration, analytics, and event-monitoring capabilities across Zscaler products.What this means for your team:Automated management at scale. Use supported product APIs to automate recurring policy and configuration workflows, reducing manual effort and improving consistency during large scale rollouts.&nbsp;Integration with existing systems. Incorporate supported Zscaler APIs and event notifications into existing CI/CD, SOAR, SIEM, and custom automation workflows.Reduced operational risk. In high-compliance environments, manual changes carry risk. Automation with proper change controls is safer, faster, and auditable by design.For agencies running DevSecOps pipelines, OneAPI provides a consistent foundation for integrating supported Zscaler capabilities into their existing operational workflows.&nbsp; Authentication Service: One Identity Across the PlatformUnified management requires unified identity. Today, ZIA, ZPA, and ZDX each maintain their own identity federation with your IDP, meaning your team is likely managing 5-6 separate integration configurations just for admin access. Authentication Service replaces all of them with a single OpenID/SAML-based authentication layer.What this means for your team:Consolidated Federal ICAM. One integration replaces multiple per-product federations. Fewer integration points to audit, fewer configurations to rotate, and a smaller surface overall.Native FIDO2 key enrollment. Admins can enroll FIDO2 keys directly within Zscaler, independent of IDP provisioning timelines.Identity-aware access controls. Authentication Service distinguishes between human administrators, API-driven service accounts, and automated tools, providing visibility into who and what is accessing your management plane.Safe, customer-controlled migration. The migration is wizard-guided with automatic policy carryover and a revert option during the transition window. Your team validates before committing.Once complete, your IDP team can decommission the legacy per-product configurations. User-side identity consolidation will follow in a subsequent phase. Government customers will have additional runway before any legacy portal changes take effect. Getting StartedAll three capabilities are available now for GovCloud Moderate and High tenants with no additional deployment required. To begin enablement, contact your Zscaler Federal account team or visit zscaler.com/federal.One platform. One identity. Fully programmable.]]></description>
            <dc:creator>Michael Clark (Director, Product Management)</dc:creator>
        </item>
        <item>
            <title><![CDATA[ChatGPT Desktop App Includes an In-App Browser: How Do You Secure Embedded Browsers?]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/chatgpt-desktop-app-includes-app-browser-how-do-you-secure-embedded-browsers</link>
            <guid>https://www.zscaler.com/blogs/product-insights/chatgpt-desktop-app-includes-app-browser-how-do-you-secure-embedded-browsers</guid>
            <pubDate>Wed, 09 Sep 2026 16:34:36 GMT</pubDate>
            <description><![CDATA[Zscaler Zero Trust Browser Extension runs inside the embedded browser of the ChatGPT desktop app. The same policies, detections, and enforcement your users get in Chrome, Edge, Firefox, and Safari is now available for the browser in ChatGPT desktop app. These security controls are for the web pages ChatGPT opens on the user’s behalf.&nbsp; Whereas the conversation/prompt the user does with ChatGPT is secured by&nbsp; Zscaler’s AI Security products. I hope the distinction between the two is clear and both are important.&nbsp;We will discuss and demonstrate three scenarios: monitoring every website ChatGPT opens, blocking paste on a specific site, and blocking a whole URL category. All three use policies can be configured from the Zscaler Zero Trust Browser admin console. The Gap: AI Apps Now Ship Their Own BrowsersThe ChatGPT desktop app is a native application, but it isn’t only that. Since OpenAI folded its Atlas browser into the unified desktop app in July, ChatGPT ships with a full Chromium browser inside itself, so its agent can open web pages, fill forms, look things up, and click through sites on the user’s behalf. Other AI applications are shipping the same pattern. This is very useful. It also opens a door most enterprises haven’t noticed is there.When an AI app opens a page inside its own embedded browser, that page is running on your user’s machine, under your user’s identity, with the user’s cookies and access. But it’s doing that in a browser your controls may never touch. IT hasn’t deployed anything into it. The policies you rely on in your standard browsers don’t automatically reach it. If someone wants to do something they wouldn’t be able to do in their normal browser, "just ask ChatGPT to open it for you" starts to look like the shortest path around your controls.We didn’t want the AI-app embedded browser to become that path. Where The Control SitsThe good news is that the embedded browser in the ChatGPT desktop app is Chromium. Our Zero Trust Browser Extension already runs across every browser our customers use: every Chromium-based browser (Chrome, Edge, and the rest), plus Firefox and Safari. That means the moment the extension is loaded inside ChatGPT’s embedded browser, it behaves the same way it does in any of those browsers.That includes page-level monitoring, clipboard and paste controls, URL category matching, DLP inspection, file upload and download policy, and any other rule the extension already enforces. There is no separate rulebook for the embedded case. The same policy engine that decides what a user can do in Chrome decides what the ChatGPT agent can do when it opens the same page inside itself. And because the embedded browser is Chromium, everything above works whether the user is on macOS or Windows.Figure 1. The Zero Trust Browser Extension already runs across Chromium-based browsers, Firefox, and Safari. The embedded browser inside the ChatGPT desktop app is Chromium, so the same policies apply there too.Deploying the extension into the embedded browser uses the same MDM-based method you already use for your other browsers, with one addition: the deployment script needs an explicit change to target the ChatGPT desktop app’s embedded browser. Installing the extension for Chrome does not cover it automatically. Once that change is in place, your existing policies apply the moment the embedded browser loads a page. See It In actionThe demo below runs on the ChatGPT desktop app on macOS. The user prompts the assistant, ChatGPT’s in-app browser control skill opens the embedded browser, and the Zero Trust Browser Extension enforces policy on whatever the page tries to do. We walked through three scenarios that map to controls IT teams already use in mainstream browsers. 1. Monitor Every Website the Agent OpensThe starting posture is visibility. In this scenario, a policy called&nbsp;Monitor All Website Visits is attached to a test user, with a single&nbsp;catch_all rule that fires whenever&nbsp;page.url exists. Effect:&nbsp;Allow. Severity:&nbsp;Informational. Nothing gets blocked. Everything gets logged.The user asks ChatGPT to open google.com in the embedded browser. ChatGPT replies "I’m using the in-app browser control skill to open Google in the embedded browser," waits for approval, and opens Google in a new tab inside the ChatGPT window. The extension records it. In the admin console, a new detection lands for that page load with all the usual context: user, device posture, extension version, browser (Chrome), IP, geolocation, and the URL itself. From the SOC’s point of view, ChatGPT opening a page looks the same as any other browser tab opening a page.1.1 The user asks ChatGPT to open google.com in the embedded browser. ChatGPT uses its in-app browser control skill to handle the request, and asks for approval before opening the page.1.2 Google.com loads in a new tab inside the ChatGPT window.1.3 The detections list in the Zscaler admin console shows the page-open events flowing in under Monitor All Website Visits, effect Allow.1.4 A single detection carries the full record: policy, rule, effect, user identity, and device posture.Monitor mode is where most teams should start when they turn this on. Before you write block rules for ChatGPT, you want to know what your users are actually doing with the embedded browser.2. Block Paste on a Specific SiteThe second scenario shows a paste block. The policy is called&nbsp;Block Paste on DLP Test Site, with a rule&nbsp;block_paste_dlptest_domain that matches when&nbsp;page.url.domain is equal to dlptest.com. Effect:&nbsp;Block. Severity:&nbsp;Medium.Inside the ChatGPT embedded browser, the user opens dlptest.com, copies a line of text from the ChatGPT conversation, and tries to paste it into the HTTP POST form. The rule doesn’t care what the text is: on this domain, any paste is blocked. The extension catches it, shows the Zscaler "Paste Blocked" modal directly in the page, and drops a detection into the admin console with the rule that fired and the clipboard text that was blocked. The user sees a clear reason. The SOC sees the event and the content. Nothing reaches dlptest.com.2.1 The Zscaler Paste Blocked modal renders inside the ChatGPT embedded browser, directly over the dlptest.com form.2.2 The detection for Block Paste on DLP Test Site carries the user, the device posture, and the blocked clipboard text itself, captured inside the ChatGPT embedded browser.This is a normal DLP control. It just happens to work in a browser most enterprises don’t realize their users have.3. Block a URL Category (Gambling)The third scenario is a category-based block. The policy is called&nbsp;Block Gambling websites, and its rule matches whenever&nbsp;page.url.category is one of Gambling. Effect:&nbsp;Block. Severity:&nbsp;Medium.The user asks ChatGPT to open a gambling website in the embedded browser. ChatGPT tries pokerstars.com. The extension recognizes the category and replaces the page with the Zscaler&nbsp;Content Blocked interstitial. ChatGPT then narrates its own failure back to the user: "That site didn’t load in the embedded browser, so I’m retrying with another established gambling site." That attempt gets blocked too. The block isn’t silent. The user sees why. The SOC sees the events.Notice what the agent did, though: it treated the block as a transient failure and went looking for another site that would satisfy the request. A domain blocklist would have lost that race. A category rule catches the second attempt exactly as it caught the first, and every attempt lands in the console.3.1 The Zscaler Content Blocked page inside ChatGPT’s embedded browser. The blocked URL, pokerstars.com, is shown alongside a "Request For Exception" button.3.2 Detection detail for Block Gambling websites: reason page.url.category is one of Gambling, effect Block, severity Medium.These three scenarios are a small slice of what’s available. Because the extension is running inside a Chromium browser, whatever policies you already enforce in your other browsers can be enforced here: DLP, file upload and download policy, credential protection, tenant restrictions, and so on. The point is not the specific rules we demonstrate in this demo. The point is that the embedded browser is no longer a blind spot. Why This Couldn’t WaitAI apps that ship an embedded browser are becoming common. ChatGPT is the loudest example, but it isn’t alone. Every AI product that runs an agent on the desktop has an incentive to give that agent a browser it can drive, and these apps reach mainstream users, not just the developers who adopted agent tools early. Every one of them is a second browser on the machine that the user didn’t install and IT didn’t configure. Closing that gap while the pattern is new is much easier than closing it once it’s widespread.Agents will use the embedded browser to do work under the user’s identity. That’s the whole point of embedding a browser in an AI app. It means the same audit and governance questions we ask about human web activity, and about WebMCP tool calls, now apply to page loads driven by an agent inside an AI app: which agent opened this page, on whose behalf, and what happened next. Today the extension answers the last two. Every page the agent opens is logged and enforced under the user’s identity, and what happens next is in the console, where it looks like any other Chromium page load. Telling agent-driven activity apart from the user’s own browsing is the next step, and it’s what the agent-aware policy work below is for. What’s NextThe Zero Trust Browser Extension is available today for the ChatGPT desktop app’s embedded browser, on both macOS and Windows. If you already run the extension in your other browsers, update your deployment to cover the embedded browser and your existing policies carry over. Reach out to your account team for a demo, or visit the product page to learn more.We’re working on the same coverage for other AI applications shipping their own embedded browsers, and on tighter, agent-aware policy primitives for cases where the caller is a model rather than a human.&nbsp;Zero Trust Browser is a must have security tool for every enterprise.&nbsp; The flexible deployment options it provides Extension, Enterprise Browser, Cloud Browser Isolation and natively integrated with ZTE for application access and advanced data and cyber controls is unmatched.]]></description>
            <dc:creator>Joby Menon (SVP, Product Management | Zscaler)</dc:creator>
        </item>
        <item>
            <title><![CDATA[A Practical Framework for Secure AI Adoption in Federal Civilian Agencies]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/practical-framework-secure-ai-adoption-federal-civilian-agencies</link>
            <guid>https://www.zscaler.com/blogs/product-insights/practical-framework-secure-ai-adoption-federal-civilian-agencies</guid>
            <pubDate>Wed, 09 Sep 2026 03:53:02 GMT</pubDate>
            <description><![CDATA[This is the second post in a three-part series on AI security and governance for Federal Civilian agencies. The first post examined why M-25-21 changes the operating landscape and why AI risk is broader than public GenAI.Bottom line up front: Federal Civilian agencies need more than policy language to govern AI responsibly. They need an operating model. This post outlines a six-part lifecycle, Discover, Classify, Control, Test, Monitor, and Report, that connects M-25-21 requirements to enforceable, repeatable execution.A workable model for Federal Civilian agencies has six parts:DiscoverClassifyControlTestMonitorReportEach one addresses a specific governance gap. Taken as a whole, they give agencies a way to move from policy intent to day-to-day execution.&nbsp; 1. Discover: You can't govern what you can't seeThe first step is visibility.M-25-21 requires agencies to maintain AI use case inventories. But building an accurate inventory is hard when AI use is spread across users, endpoints, SaaS tools, code repositories, cloud environments, applications, APIs, and models.Security and governance teams may know about the officially approved AI pilots. They may not know about shadow AI use, embedded AI in existing SaaS platforms, developer AI tools, or AI dependencies inside application code.Zscaler AI Asset Management helps agencies identify AI usage and AI assets across multiple layers of the environment. This includes public GenAI destinations, embedded AI in SaaS, AI-enabled desktop tools, browser extensions, developer tools, code repositories that invoke models or agents, and cloud AI services connected to agency data.An AI inventory can't just be a list of tools. Agencies also need context: whether a tool is approved, who is using it, whether sensitive data is involved, whether it connects to internal systems, whether an external model is being called, and whether an agent can access agency data or invoke tools. They also need to understand whether the AI asset touches PII, CUI, financial data, health data, law enforcement data, benefits data, inspection data, regulatory data, or source code.Without that context, governance is mostly guesswork. With it, agencies can start making risk-based decisions. 2. Classify: Not every AI use case has the same riskM-25-21 puts special emphasis on risk, especially for high-impact AI.High-impact AI refers to uses where AI output serves as a principal basis for decisions or actions that have a legal, material, binding, or significant effect on rights or safety.For Federal Civilian agencies, this could apply to eligibility or benefits support, grants and loans, healthcare or public health workflows, immigration or travel-related services, regulatory oversight, inspections and enforcement, fraud detection, safety-related determinations, housing assistance, employment-related actions, law enforcement support, emergency management, or other citizen-facing services.Not every use case will be high-impact. A tool that summarizes internal meeting notes is very different from an AI system that influences a benefits decision, inspection outcome, enforcement action, or citizen service determination. Classification is how agencies draw that line.Agencies need to classify AI use cases based on mission impact, data sensitivity, user population, external exposure, model provider, autonomy, human oversight, connected systems, and potential effects on rights, safety, benefits, or services. They also need to consider whether the system is public-facing and whether it uses authoritative agency data.Zscaler helps provide the technical context behind these decisions. It can help identify whether an AI application is connected to sensitive data, whether users are sending protected information to AI tools, whether AI assets exist in cloud environments, and whether an agency-built AI system should be prioritized for testing and guardrails.Zscaler doesn't replace agency judgment. The CAIO, AI Governance Board, CIO, CISO, privacy officials, legal teams, and mission owners still own the governance decisions. But better evidence leads to better decisions. 3. Control: Enable AI use with policy-based guardrailsAI security can't be limited to "allow everything" or "block everything."Federal agencies need policy-based AI enablement. They need a way to allow approved AI tools, restrict risky tools, protect sensitive data, coach users, isolate higher-risk sessions, and apply different controls based on user role, mission function, data type, and destination.For example, an agency may allow approved GenAI tools for general productivity while blocking prompts that contain PII, CUI, source code, credentials, or procurement-sensitive information. It may apply stricter controls for users handling benefits, grants, healthcare, tax, law enforcement, or regulatory data. It may isolate higher-risk AI destinations in the browser, log AI activity for governance review, inspect AI responses for harmful content, or coach users when they attempt risky behavior.Zscaler helps apply these controls inline through the Zero Trust Exchange. For user access to public and embedded AI tools, Zscaler can inspect traffic, enforce access policy, apply data loss prevention, and use AI Guard to inspect prompt inputs and response outputs.Some of the highest-risk AI behavior can happen before an agency has formally reviewed a use case. An employee may paste citizen PII into a public AI tool to summarize a case note. A grants specialist may upload procurement-sensitive information into an AI assistant. A developer may paste source code or configuration secrets into an external coding tool. A regulator may use a public AI tool to summarize inspection records. Or an employee may use an embedded AI feature in a SaaS application without realizing data may be processed by an AI service.Zscaler can detect sensitive content and enforce policy before the data leaves the agency-controlled path. This is how agencies can support AI productivity while reducing unmanaged exposure. 4. Test: AI applications need assurance before they go liveEmployee use of public GenAI is one type of risk. Agency-built AI applications are another.As Federal Civilian agencies mature, many will build or operate their own AI systems. These may include citizen-facing AI assistants, internal knowledge assistants, program support chatbots, benefits guidance tools, regulatory support applications, inspection support tools, fraud detection workflows, cybersecurity copilots, research assistants, data analysis systems, AI-enabled case management, or agentic workflows connected to internal systems.For these systems, access control alone isn't enough. Agencies need to test whether the AI application behaves as intended.AI systems can fail in ways traditional applications don't. They can be vulnerable to prompt injection, jailbreaks, hallucination, data leakage, unsafe tool use, off-mission responses, toxic output, or manipulation across multi-turn conversations. For public-facing or mission-sensitive systems, those failures can damage public trust.Consider an AI assistant giving incorrect guidance about disaster assistance, student aid, veterans services, taxpayer obligations, public health recommendations, immigration processes, small business loans, housing assistance, food safety, benefits eligibility, regulatory compliance, or grants requirements. The issue isn't only technical accuracy. It's fairness, accountability, mission integrity, and trust.Zscaler's AI red teaming capabilities help agencies test AI applications before deployment. Red teaming can evaluate systems for prompt injection, jailbreaking, data leakage, hallucination, trustworthiness, toxicity, bias, code execution, phishing, unsafe responses, RAG precision, URL validation, mission alignment, and custom agency-specific risks.Agencies can also create custom probes that reflect their own mission language, policies, authoritative sources, and risk scenarios.A benefits agency could test whether an assistant avoids making unauthorized eligibility determinations. A regulatory agency could test whether an assistant stays aligned to approved regulatory guidance. A public health agency could test whether responses remain grounded in authoritative medical or scientific sources. A grants agency could test whether an assistant provides accurate application guidance without exposing applicant data. A law enforcement or investigative agency could test whether the system refuses inappropriate requests for sensitive information. A citizen services agency could test whether the system escalates to a human when confidence is low.Red teaming helps agencies find weaknesses before citizens, employees, or adversaries do. 5. Monitor: AI risk doesn't stand stillAI governance isn't a one-time approval.Models change. Prompts change. SaaS platforms add new AI features. Developers introduce new dependencies. Users find new tools. Agents gain new capabilities. Data sources evolve. Attack techniques change.M-25-21 emphasizes ongoing governance, risk management, and accountability. For AI security leaders, this means agencies need telemetry that shows how AI is actually being used over time.Zscaler helps monitor AI interactions by showing which AI tools are being accessed, who is using them, which prompts trigger data protection policies, which responses violate policy, which embedded AI tools appear in SaaS workflows, which AI assets exist in cloud, which applications connect to sensitive data, and how usage trends change across the agency.It can also help track policy actions, red team findings, guardrails, and changes in AI behavior over time.This helps agencies move from static governance to continuous governance. It also gives governance teams a clearer view of actual behavior, not just intended use. The distinction is important, especially when AI adoption moves faster than formal review cycles. 6. Report: Governance needs evidenceFederal AI governance requires evidence.CAIOs, CIOs, CISOs, Chief Data Officers, privacy officials, legal counsel, acquisition officials, mission leaders, and AI governance boards all need different views of AI risk.A CAIO may need to understand AI adoption across the agency. A CISO may need visibility into data leakage and threat exposure. A privacy officer may need evidence of controls around PII. A Chief Data Officer may need to understand data access and data quality implications. A mission owner may need assurance that an AI system behaves within scope. Legal, civil rights, and acquisition leaders may need insight into fairness, third-party services, embedded AI risks, or documented control decisions.Zscaler helps provide operational evidence for those governance conversations. That evidence can include AI usage trends, AI application inventories, user and group activity, sensitive data exposure attempts, prompt and response policy actions, embedded AI discovery, AI assets in cloud environments, model and agent relationships, connected data resources, red team results, guardrail status, and policy enforcement history.This is how agencies make AI governance measurable instead of purely procedural.To learn more about how Zscaler supports the AI security lifecycle for Federal Civilian agencies, reach out to your Zscaler account team for a detailed overview of our AI Security capabilities.Next in this series: Extending Zero Trust to AI: What Federal Civilian Agencies Can Do Now]]></description>
            <dc:creator>Jose Arvelo Negron (Manager, Sales Engineer)</dc:creator>
        </item>
        <item>
            <title><![CDATA[ZPA and AI Guard in Action]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/zpa-and-ai-guard-action</link>
            <guid>https://www.zscaler.com/blogs/product-insights/zpa-and-ai-guard-action</guid>
            <pubDate>Fri, 04 Sep 2026 17:18:57 GMT</pubDate>
            <description><![CDATA[In a&nbsp;previous blog, we discussed how AI models too often have broad, unsecured lateral access to company resources.&nbsp;Zscaler Private Access (ZPA) solves this problem by brokering direct, identity-verified connections to specific applications rather than the entire network. This is critical for organizations to safely deploy and run private on-premises AI infrastructure without exposing adjacent environments, which cannot be achieved with VPNs.Want to see how it works?Check out the below video, which details how Zscaler Private Access (ZPA) and AI Guard secure organizations as they adopt artificial intelligence and machine learning (AI/ML) technologies. The video demonstrates the interaction between ZPA and AI Guard using a private LLM hosted on Amazon Bedrock:Segmentation:&nbsp;Administrators can tag sanctioned AI applications, enabling them to apply specific access policies and guardrails based on business context, user groups, and risk levels.Real-time Blocking: If a user attempts to input restricted data, such as PII or prohibited formats, AI Guard triggers a block.Diagnostics:&nbsp;ZPA diagnostics allow administrators to view traffic details and confirm that policies were correctly applied, while the AI Guard dashboard provides visibility into why specific transactions were blocked.ZPA provides the necessary application-level categorization and access control, while AI Guard handles content-level security and policy enforcement to enable safe AI adoption.This approach provides multiple benefits:Visibility and Classification:&nbsp;ZPA uses an application fingerprinting engine to identify and classify AI/ML applications without requiring deep packet inspection. This allows administrators to discover usage, segment applications, and monitor user activity.Access Control:&nbsp;By treating AI models as private application segments, organizations can use zero-trust policies to restrict access, reducing the overall attack surface.Content Security:&nbsp;Once access is granted, AI Guard inspects traffic for risks such as data leakage, PII exposure, and prompt injection.To learn more,&nbsp;visit our website or&nbsp;request a custom demo.&nbsp;]]></description>
            <dc:creator>Joby Menon (SVP, Product Management | Zscaler)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Zscaler and OpenAI: Bringing Frontier AI-Powered Security to the Enterprise]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/zscaler-and-openai-bringing-frontier-ai-powered-security-enterprise</link>
            <guid>https://www.zscaler.com/blogs/product-insights/zscaler-and-openai-bringing-frontier-ai-powered-security-enterprise</guid>
            <pubDate>Fri, 04 Sep 2026 00:01:55 GMT</pubDate>
            <description><![CDATA[The security industry has been adapting to AI faster than any previous technology shift, and Zscaler has been at the forefront of that effort. But the nature of the challenge keeps evolving. Attackers are deploying AI to reason over complex environments and find paths that traditional tooling doesn't see. Meeting that requires more than faster detection or broader coverage. It requires security that can reason the same way: understanding how an enterprise can be compromised, not just flagging that something looks wrong.That's why our partnership with OpenAI matters. Through OpenAI’s Daybreak Defense Network, Zscaler built two new capabilities using OpenAI GPT cyber models, and today, I'm excited to showcase what enterprise security can do and what it should look like in an AI-first world.We presented both of these at OpenAI Intelligence at Work: Cyber on September 3, and you can learn more about them below. Innovation Showcase 1: Endpoint AI Security — Attack Chain AnalysisAI agents, assistants, and AI coding IDEs are now part of the standard developer workflow. They're powerful. They're also a new and largely unmapped attack surface, one that now extends to local and web MCP servers, locally-run models, and AI running directly inside the browser. Our new Endpoint AI Security Attack Chain Analysis capability, powered by OpenAI GPT cyber models, changes how organizations understand device risk. Instead of surfacing a flat list of misconfigurations and CVEs, it reads the full state of an endpoint — AI agents, coding assistants, IDE and browser extensions, installed software, packages, and system configuration — and reasons over all of it to construct a realistic attack chain.What does that mean in practice? It means the output isn't, "you have a vulnerable extension." It's: here is the path from an initial lure, to code execution under this user's account, to credential and source code theft, to persistence, to re-entry, and here is what you need to close first.Findings are backed by evidence, and all steps are labelled, confirmed on the host, inferred from state, or flagged for verification. The result is a prioritized remediation roadmap that gives security teams something unique: a defender's view of their own devices that resembles potential paths of an attacker.This capability runs as an endpoint agent, either independently or as a module within the current Zscaler client running on more than 70M devices, fully controlled and policy-scoped. Zscaler controls the policy-scoped endpoint context submitted for analysis. It simply does something that has historically been very hard to do at scale: performs authorized analysis of potential attack paths so your defenders don't have to. Innovation Showcase 2: Identity Risk Analysis in the Zscaler AI Access GraphThe other major attack surface that's grown faster than security teams can manually track is identity, specifically, non-human identities. Service accounts, AI copilots, and agentic workloads now outnumber human users in many enterprise environments. Their permissions sprawl across cloud, SaaS, and on-prem systems in ways that no human team can reason over at speed.Our second integration embeds OpenAI GPT cyber models directly into the AI Access Graph to perform Identity-Permission Risk Analysis at enterprise scale.The AI Access Graph already maps identities across the enterprise (human, service account, and AI agent) to data objects throughout the environment and model endpoints they can reach across Azure, AWS, OCI, and GCP. What OpenAI GPT cyber models add is the reasoning layer: they trace the paths through that graph, identify risky combinations — overprivileged access, toxic permission pairings, excessive inherited scope — and rank them not by a generic severity score but by business impact, blast radius, confidentiality, integrity, and availability of what's actually reachable.Critically, the graph distinguishes agent and bot behavior from human behavior. That distinction matters for agentic identity governance: you need to know not just what access exists, but who or what is using it, and whether that behavior matches the role and peer baselines you'd expect.Remediation is deliberately decoupled from the model's reasoning. All remediation actions run through a human-approval workflow. The model surfaces the risk and explains it; humans decide what to do. That's the right design. What This Means for Our Partnership with OpenAIBoth of these capabilities required a model that could reason about how systems get compromised; not abstractly, but concretely and at the specific context of a customer's environment. Standard models weren't up to that task. OpenAI GPT cyber models are purpose-built for this kind of security reasoning, and it's the foundation that makes both of these innovations possible.Our partnership with OpenAI is about building the AI security infrastructure that enterprises actually need: deep, specific, evidence-grounded, and human-reviewed before anything consequential happens. That's what we’ve showcased on September 3.The pace of change in this space isn't slowing down. Neither are we.]]></description>
            <dc:creator>Dhawal Sharma (Executive Vice President, AI Security and Strategic Initiatives)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Microsoft Exchange Vulnerability CVE-2026-62911: What Administrators Should Do and How Zscaler Can Help]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/microsoft-exchange-vulnerability-cve-2026-62911-what-administrators-should</link>
            <guid>https://www.zscaler.com/blogs/product-insights/microsoft-exchange-vulnerability-cve-2026-62911-what-administrators-should</guid>
            <pubDate>Thu, 03 Sep 2026 20:19:43 GMT</pubDate>
            <description><![CDATA[Microsoft's August 2026 Patch Tuesday&nbsp;included a fix for CVE-2026-62911, a high-severity authentication bypass vulnerability affecting Exchange Server 2016, 2019, and Subscription Edition. The severity has a CVSS score of 8.0 from Microsoft.&nbsp;As of September 1, threat intelligence group Shadowserver has identified around 22,000 Exchange servers that remain unpatched and exposed to the internet, including roughly 6,200 in the United States and 5,100 in Germany alone.&nbsp;According to Microsoft, successful exploitation allows an attacker with basic privileges to take over all mailboxes on the targeted server, including reading and sending email and downloading attachments. The Netherlands National Cyber Security Centre (NCSC-NL) has confirmed that working exploit code is already publicly available.If you're running an on-premises Exchange server, this post outlines practical steps you can take now, and a longer-term architectural approach worth considering.&nbsp; First: Apply the PatchThe August 2026 Patch Tuesday update addresses CVE-2026-62911 directly. If you haven't applied it yet, that's the first priority.A few important notes for older versions:Exchange 2016 and 2019 are on the Extended Security Update (ESU) program, which ends in October 2026. If you're on either version, confirm you're enrolled in ESU and apply the update. After October, these versions will no longer receive security fixes.If patching isn't immediately possible, NCSC-NL's guidance is to ensure the Exchange server is not reachable from the open internet until the patch can be applied. The Structural Issue: Internet ExposurePatching is essential, but it's worth understanding why private application servers such as Exchange are repeatedly in this position. On-premises Exchange runs as an internet-facing service by design. Outlook Web App (OWA) needs to be accessible to users, which typically means it's reachable from the public internet. That reachability is what makes each new CVE a high-stakes race between patching and exploitation.The NCSC-NL guidance to ensure Exchange is "accessible only internally" points at the right solution, but doesn't prescribe how to get there for organizations that still need to support remote access. Why This Matters More in 2026 Than It Did in Prior YearsAt the time of writing, CISA has not reported exploitations in the wild as of yet. But there's a meaningful shift in the threat landscape that makes this type of exposure a more pressing issue than it once was.Earlier AI models gave attackers tools to automate reconnaissance. Today's frontier models, such as Anthropic's Mythos, represent a step change beyond that. They can identify a known vulnerability, develop a working exploit, and execute an attack in minutes, not days.The practical implication: the window between a CVE being disclosed and exploitation at scale has compressed significantly. Our&nbsp;ThreatLabz 2026 Frontier AI Readiness Report&nbsp;showcased how the mean-time-to-exploit has actually gone negative – with attackers finding and exploiting vulnerabilities before they’re even disclosed. With CVE-2026-62911, exploit code is already public. An organization's ability to outpace exploitation through patching alone is less reliable than it used to be, particularly for internet-exposed infrastructure. A Zero Trust Approach: Don’t Expose Exchange to the InternetZscaler Private Access (ZPA) allows organizations to eliminate the exposure of all private apps to internet-based attacks. This includes services like Exchange, which remain fully accessible to your users while being completely invisible to the internet. The way it works:Managed devices: The Zscaler client routes OWA traffic through an encrypted ZPA tunnel to the Exchange server. There's no inbound connection to the server from the internet, and nothing for an attacker to probe or target.Unmanaged devices: ZPA Clientless Access provides a secure, authenticated, browser-based path for users on personal or partner devices, without requiring a VPN or opening any inbound ports.The fundamental difference from a traditional VPN is how and when access is granted. A VPN establishes a persistent, always-on network tunnel — once connected, a user has broad network-level access regardless of what they're actually doing. ZPA works differently: rather than maintaining a standing tunnel, it brokers short-lived, application-specific connections on demand, and only after identity and policy checks pass. Each session is purpose-built for a specific application, time-bound by policy, and torn down once the session ends — there's no residual network foothold. A VPN gateway or concentrator is itself exposed to the internet and a frequent attacker target; ZPA has no equivalent surface, because there's nothing listening for inbound connections to begin with.If your Exchange server is behind ZPA, CVE-2026-62911 is effectively not exploitable from the internet, regardless of whether you've patched, because the authentication bypass requires reaching port 443 on the Exchange server in the first place. For Servers That May Already Be CompromisedIf you have reason to believe a server may have been compromised before patching, additional controls are worth considering:Zscaler Data Security (DLP) can inspect outbound traffic from Exchange infrastructure, helping detect data exfiltration or other malicious activity that might indicate a server has been compromised.Zscaler Deception places honeypots throughout your environment that provide high-fidelity signals that an attack is underway. With their multi-path reasoning, frontier AI models are particularly likely to trip over these decoys.Zscaler Cloud Workload Segmentation limits lateral movement, preventing an attacker who has gained a foothold on an Exchange server from moving to other parts of your environment. Longer-Term: The Case for Migrating to Microsoft 365On-premises Exchange has been one of the most consistently targeted enterprise applications over the past several years. CISA has added 20 Exchange Server vulnerabilities to its Known Exploited Vulnerabilities catalog since November 2021; 14 of those have been linked to ransomware. With Exchange 2016 and 2019 losing security update support in October 2026, the risk profile for organizations still running those versions is only going to grow.Whether an organization utilizes on-premise solutions like Exchange or SaaS environments like Microsoft 365, private applications will always remain a baseline necessity for maintaining data confidentiality, restricted access, and regulatory compliance.For organizations evaluating their options, migration to Microsoft 365 removes the on-premises attack surface entirely. It's not the right move for everyone on every timeline, but it's worth including in the planning conversation while investing in architectures that would empower them to respond to vulnerabilities in real-time.&nbsp; PriorityActionImmediateApply the August 2026 Patch Tuesday updateImmediateIf patching is delayed, ensure Exchange is not internet-accessibleNear-termDeploy ZPA to broker all OWA access (managed and unmanaged devices)Near-termEnable outbound inspection on Exchange trafficConsiderDeploy Workload Segmentation to contain potential lateral movementConsiderDeploy Deception to contain potential lateral movementConsiderDeploy AppShield to virtually patch exploitsStrategicEvaluate Microsoft 365 migration, especially if running Exchange 2016/2019To learn more about how Zscaler can help you reduce exposure and prevent exploitation by frontier AI models, watch our&nbsp;on-demand webinar.&nbsp;]]></description>
            <dc:creator>Mark Brozek (Senior Director, Product Marketing)</dc:creator>
        </item>
        <item>
            <title><![CDATA[M-25-21 Changes the AI Conversation for Federal Civilian Agencies]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/m-25-21-changes-ai-conversation-federal-civilian-agencies</link>
            <guid>https://www.zscaler.com/blogs/product-insights/m-25-21-changes-ai-conversation-federal-civilian-agencies</guid>
            <pubDate>Wed, 02 Sep 2026 15:59:53 GMT</pubDate>
            <description><![CDATA[This is the first post in a three-part series on AI security and governance for Federal Civilian agencies.Bottom line up front: OMB Memorandum M-25-21 makes AI adoption an agency operating priority. But the memo also makes clear that speed without governance, security, and public trust isn't acceptable. For Federal Civilian AI leaders, the practical challenge is broader than most realize. AI risk extends well beyond employees using public GenAI tools.AI is quickly becoming part of how Federal Civilian agencies work.Used well, it can improve citizen services, reduce manual work, modernize legacy processes, strengthen cybersecurity operations, support research and analysis, assist with fraud detection, speed up software development, and help employees work more efficiently.But AI adoption in government is different from AI adoption in the private sector.Federal agencies have to account for public trust, privacy, cybersecurity, civil rights, records management, procurement integrity, transparency, data protection, and mission accountability. When AI touches citizens, benefits, grants, inspections, regulatory processes, healthcare, financial data, enforcement activity, or other sensitive workflows, the risk profile changes.OMB Memorandum M-25-21,&nbsp;Accelerating Federal Use of AI through Innovation, Governance, and Public Trust, speaks directly to this tension.The memo makes a clear point: agencies should move faster with AI, but not by setting aside governance, safeguards, or public trust. They need to innovate while making sure AI is secure, accountable, privacy-aware, risk-managed, and aligned to mission outcomes.For AI technology executives and AI security leaders, the practical question is: How do we help the agency use AI faster while still maintaining the visibility, control, and evidence needed to govern it responsibly? More than a compliance memoM-25-21 signals that AI adoption is now an agency operating priority.The memo directs agencies to promote responsible AI adoption while putting safeguards in place for privacy, civil rights, civil liberties, cybersecurity, and public trust. It also reinforces core responsibilities: designating or retaining a Chief AI Officer, convening AI governance bodies, updating internal policies, developing generative AI acceptable-use policies, maintaining AI use case inventories, implementing risk management practices for high-impact AI, and documenting governance decisions.For Federal Civilian agencies, this means AI governance can't live only in strategy documents, governance boards, or spreadsheets.It has to be enforceable.Agencies need to answer basic but difficult questions. What AI tools are people using? Who's using them? Which use cases are approved, experimental, or unmanaged? What data is being shared? Which SaaS applications have embedded AI? Which developer tools are using AI? Which cloud workloads are calling models or agents? Which AI applications are connected to sensitive government data? Which systems may qualify as high-impact AI? Which systems have been tested before deployment?These aren't just policy questions. They're operational questions. Federal Civilian AI risk is broader than public GenAIA lot of AI security conversations start with public GenAI tools, specifically employees pasting sensitive information into ChatGPT, Gemini, Claude, or similar services.That risk is real. But it's only one part of the picture.AI is now showing up across the agency technology environment: public GenAI applications, SaaS platforms with embedded AI, desktop tools, browser extensions, coding assistants, IDE (Integrated Development Environment) plugins, cloud AI services, foundation models, agency-built AI applications, RAG (Retrieval-Augmented Generation) systems, agents, MCP (Model Context Protocol) servers, API-based model integrations, and automation workflows.AI may appear in places that aren't obvious to security, governance, or mission leaders.An analyst might use a public AI tool to summarize a report. A grants office might rely on an AI-enabled SaaS workflow. A benefits program might experiment with an AI assistant. A developer might use an AI coding assistant to modernize a legacy application. A cloud team might deploy a model in AWS GovCloud or Azure Government. A program office might pilot an AI-powered citizen service experience. A security operations team might use AI to support triage and investigation.Those use cases don't carry the same risk. They shouldn't all get the same controls. And they may create different governance obligations under M-25-21.Agencies need a lifecycle approach to AI security and governance, one that connects M-25-21's policy direction to enforceable, repeatable execution. We'll lay out that operating model in the next post in this series.To learn more about how Zscaler helps Federal Civilian agencies secure AI adoption, reach out to your Zscaler account team for a detailed overview of our AI Security capabilities.Next in this series: A Practical Framework for Secure AI Adoption in Federal Civilian Agencies]]></description>
            <dc:creator>Jose Arvelo Negron (Manager, Sales Engineer)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Rethinking OT Boundaries: Sandworm&#039;s Cellular Breach of a Polish Power Plant]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/rethinking-ot-boundaries-sandworm-s-cellular-breach-polish-power-plant</link>
            <guid>https://www.zscaler.com/blogs/product-insights/rethinking-ot-boundaries-sandworm-s-cellular-breach-polish-power-plant</guid>
            <pubDate>Mon, 31 Aug 2026 16:50:04 GMT</pubDate>
            <description><![CDATA[Executive SummaryModern industrial operators are rapidly connecting remote infrastructure — wind turbines, solar arrays, water pumps, and distribution substations — using cellular networks, private APNs, and SD-WAN. Historically, these private cellular networks have been treated as trusted, secure, "walled-off" perimeters.A&nbsp;Landmark Investigation disclosed by CERT Polska in August 2026 shattered this assumption. In a highly coordinated campaign, threat actors breached a combined heat and power (CHP) plant in Poland, successfully shutting down a steam turbine and its process-water treatment system.This blog provides a highly technical analysis of this historic cyberattack, maps the step-by-step technical pathway of the pivot, explains why traditional cellular and SD-WAN setups create a catastrophic blast radius, and outlines how Zscaler's Zero Trust Exchange platform significantly mitigates these vectors. The Incident — What HappenedThe incident occurred on December 29, 2025, and was publicly disclosed after a comprehensive investigation on August 8, 2026. This was a highly targeted, state-sponsored campaign designed to impact physical operations. The attack began at an unmanned remote wind farm and ultimately resulted in the forced shutdown of a steam turbine at a central combined heat and power plant — a facility supplying municipal heat to 50,000 residents.The attack chain followed a precise, multi-stage path: a remote wind farm firewall was compromised, granting the attackers footing on the facility's local network. From there, they accessed an on-site Teltonika cellular router via SSH, which opened a tunnel into the grid operator's private APN. Traversing that APN, they scanned the entire private cellular IP space and discovered a WAGO PLC at the CHP plant configured with default credentials. That PLC served as a bridge into the core OT network, and from there the attackers issued unauthorized stop commands to the Siemens PLCs controlling the steam turbine — achieving physical disruption.Incident at a GlanceMetric / AspectIncident DetailsTarget FacilityCombined Heat and Power (CHP) Plant (Poland) supplying municipal heat to 50,000 residents.AttributionSandworm (also known as the Russian state-sponsored threat group Electrum).Campaign ScopeCoordinated, simultaneous attacks targeting over 30 other Polish renewable energy and power distribution sites.Physical ImpactComplete temporary shutdown of a steam turbine and its process-water treatment system.Primary VectorLateral movement through a local grid operator's private cellular Access Point Name (APN). Anatomy of the Attack — Step by StepThe following table reconstructs the precise six-stage attack chain executed by Sandworm. Each step built directly on the last, exploiting a combination of internet-exposed management interfaces, flat private cellular network topology, and default device credentials to achieve full OT impact.#Attack StageDescription1Initial AccessSandworm exploited an internet-facing unpatched firewall at a remote, unmanned wind farm.2Device ControlThe attackers accessed the wind farm's on-site Teltonika cellular router via Secure Shell (SSH).3APN TunnelingUsing the compromised router, the attackers established a tunnel into the grid operator's private APN.4Lateral ReconnaissanceDue to a lack of client isolation on the private APN, the attackers scanned the entire private cellular IP space.5PLC ExploitationThe scan discovered a WAGO PLC at the central CHP plant, which was exposed to the APN with default administrator credentials.6Operational DisruptionThe attackers used the WAGO PLC as a network bridge to access the core OT network, issuing unauthorized stop commands to the Siemens PLCs controlling the steam turbine.&nbsp; Why Traditional Defenses FailedThis breach highlights a fundamental security misconception: the belief that carrier-provided private APNs or corporate SD-WAN networks provide a secure, isolated boundary. In reality, these technologies deliver connectivity and no security. Both APNs and SDWAN systems are built to connect devices.&nbsp;The moment a single endpoint on that shared network is compromised, the entire flat address space becomes an attacker's reconnaissance playground. The attacker leveraged the lack of controls on the APN to get into the flat network to pivot to the PLC.&nbsp;The following comparison maps the legacy assumptions that enabled this attack against the modern cyber reality — and demonstrates how Zscaler's Zero Trust paradigm would have eliminated the attack path entirely.Attack StageTraditional VulnerabilityHow Zscaler Eliminates The ThreatStage 1: Initial Perimeter Breach(Exploited Remote Firewall)Exposed public-facing IPs and open SSH management ports on cellular gateways are easily scanned and targeted by brute-force attacks.Zero Public Attack Surface: Zscaler Cellular makes all remote gateways completely invisible to the internet. Outbound-only connections to the Zscaler Zero Trust Exchange mean there are zero public-facing IPs or open inbound ports to scan.Stage 2: Lateral APN Reconnaissance(Scanned Private Cellular Grid)A flat APN permits any compromised cellular device to discover, ping, and compromise other remote terminals and power plants.Total Peer Isolation: Zscaler prevents device-to-device visibility on the cellular network. Connected devices can only communicate outbound to the Zscaler broker, completely blocking attackers from scanning the APN.Stage 3: Credential Exploitation(Brute-forced WAGO PLC)Exposed local administrative portals are highly vulnerable to default credential harvesting and unauthorized access.Identity-Centric Access Proxy: Zscaler acts as a secure identity broker. Even if an attacker physically accesses the local APN, they cannot see or communicate with the WAGO PLC's login portal without first passing MFA-backed identity policies.Stage 4: Core Network Bridging(Pivoted from PLC to Turbine)Flat internal routing allows a compromised edge controller to act as a bridge into the plant's core OT control network.Agentless Device Segmentation: Zscaler isolates legacy assets at the application layer without requiring software agents on the PLCs. It blocks lateral traffic between the edge PLC and the core OT network, restricting communications to pre-approved paths.Stage 5: Industrial Disruption(Issued Stop Commands to Siemens PLCs)Plain-text industrial protocols (like Modbus or S7comm) lack cryptographic authentication, enabling unauthorized physical stop commands.Ransomware Kill Switch &amp; Protocol Isolation: Administrators can instantly trigger a global isolation protocol to quarantine compromised zones. Zscaler also enforces granular protocol-level access without deploying any agents.&nbsp;Read More&nbsp; The Zscaler SolutionTo comprehend how Zscaler secures OT environments, we must first examine the core principles of the&nbsp;Zero Trust Security Model . Traditional network security relies on a "castle-and-moat" design, where perimeter firewalls secure the border, but everything inside is implicitly trusted. Once an intruder like Sandworm breaches the outer defense (the moat), they enjoy free lateral movement across the flat interior (the castle)Securing distributed OT infrastructure requires moving from a network-centric approach to an application-centric Zero Trust architecture. Zscaler delivers native security capabilities designed to eliminate the exact attack path used by Sandworm. Each capability below maps directly to a stage of the incident, removing the preconditions the threat actors depended on at every step of the kill chain.&nbsp;&nbsp;Zscaler Security CapabilityTechnical FunctionIndustrial ValueZscaler CellularSecures both inbound and outbound cellular communications. Devices do not have public IPs or open listening ports.Hides the Attack Surface: Eliminates the ability for threat actors to scan the cellular network or discover exposed remote terminals.Zscaler Zero Trust Device SegmentationImplements agentless, identity-based micro-segmentation for legacy PLCs and RTUs without requiring software on the endpoints.Inhibits Lateral Movement: Even if a remote router is compromised, Zscaler blocks it from communicating with the central plant's controllers.Ransomware Kill SwitchAllows administrators to instantly sever all lateral network connections with a single command during an active incident.Grid Protection: Limits the blast radius of a breach to a single segment, keeping the broader municipal utility online. Protect Your OT Infrastructure TodayZscaler Zero Trust Exchange™ eliminates lateral movement, hides your OT assets from attackers, and gives you instant incident response — all without disrupting operations.→&nbsp; Learn more at&nbsp;https://resources/security-terms-glossary/what-is-operational-technology-ot-security/products-and-solutions/zscaler-cellular&nbsp;Act Fast. Stay Secure.&nbsp;]]></description>
            <dc:creator>Hitesh Chhabra (Architect, Solutions Consulting)</dc:creator>
        </item>
        <item>
            <title><![CDATA[The Hugging Face Breach: Key Questions Every Security Leader Must Answer]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/hugging-face-breach-key-questions-every-security-leader-must-answer</link>
            <guid>https://www.zscaler.com/blogs/product-insights/hugging-face-breach-key-questions-every-security-leader-must-answer</guid>
            <pubDate>Mon, 31 Aug 2026 07:29:58 GMT</pubDate>
            <description><![CDATA[On July 11, during an internal cyber capability evaluation, OpenAI’s GPT-5.6 Sol and a more capable, unreleased model broke out of their sandbox, reached the open internet, and attacked Hugging Face's production systems.No human operator. No phishing email. No insider. Reconnaissance, exploitation, escalation, lateral movement, exfiltration — the full kill chain, executed by an agent system with no one at the controls, in what is possibly the first publicly disclosed incident of its kind.Strip away the science fiction and you get something far more boring, and far worse: a system doing precisely what it was told it could. Your Allowlist Is Your Attack SurfaceOpenAI described the environment as highly isolated, with network access constrained to a single function: pulling packages through an internally hosted proxy that cached the public registries.That single permitted path is how the models got out.&nbsp;The models found an unknown zero-day in the proxy software, exploited it, escalated privileges, and moved laterally across the research environment until they hit a node with open internet access.The vendor’s own analysis attributes the escape to a chain of at least eight weaknesses, including server-side request forgery in remote-repository proxying, an authentication-bypass privilege escalation, path traversal, and several others.And that’s an uncomfortable lesson. When the thing inside the sandbox can study its environment, probe its defenses, and spend effectively unlimited compute looking for a way through, your allowlist becomes a map of the attack surface. Inherited Trust CompoundsInside Hugging Face's production environment, the agent moved on trusted credentials, APIs, and workloads — from a compromised production pod into Kubernetes, then cloud metadata, then internal systems, and finally the source-control supply chain.It broke almost nothing. At each step it inherited the permissions already granted to the identity it had taken over.That is the fundamental weakness of implicit trust: once inside, access compounds.&nbsp; A New Operating Assumption: Every Workload Is a Potential AdversaryAn AI agent is a workload with intent. It authenticates like a service and moves like a service, but reasons like an operator. It spawns sub-processes, assumes ephemeral identities, and exercises every permission it holds — including the ones no one remembers granting.The operating assumption has to change accordingly. Treat every workload as untrusted until verified, on every connection, every time.Not trusted because it's sandboxed. Not trusted because it's on the internal network. Not trusted because the model is aligned.Alignment is a property of the entity. Containment is a property of the architecture. This evaluation deliberately removed the classifiers that normally block models from pursuing dangerous cyber activity, because researchers wanted to see the ceiling. With the entity's restraint switched off by design, the architecture is what got graded. What That Architecture Actually RequiresMap the stages of this attack onto the controls that would have contested them and a coherent model emerges. Five controls, each with a corresponding enforcement point in the Zero Trust Exchange.&nbsp;1. Deny-by-default egress, inspected inlineA research sandbox, an evaluation cluster, an agent runtime — none should have a route to the open internet that isn't explicitly granted, fully inspected including TLS, and logged. Get this right and "the models reached a node with internet access" stops being a sentence anyone has to write. Egress control isn't a compliance checkbox. It's the outermost wall of AI containment.2. Inline analysis of everything a pipeline ingestsThe Hugging Face entry point was a dataset upload carrying code. Packages, datasets, model artifacts — anything entering an automated pipeline needs detonation in isolation before execution, held until analysis completes, not signature matching after the fact. ML-specific formats are threat vectors: serialized objects, model weights, dataset archives. Attackers already treat them that way.3. Identity-based access instead of network reachabilityEvery pivot in this chain — sandbox to proxy, node to node, pod to cluster, cluster to database — depended on network-level reachability. Application-level segmentation inverts it: no workload connects to any service without an identity-verified, policy-approved reason, and applications not published to a workload don't exist for it. A vulnerability only matters relative to what it can reach.4. Least-privilege data posture, continuously enforcedHarvested credentials powered the final stages. Credentials found on a compromised node reached cloud metadata and the internal supply chain; under enforced least privilege, they would have reached that node's blast radius and stopped. Continuous discovery makes that enforceable: where sensitive data lives, which identities can touch it, and which credentials are over-scoped. It determines whether a stolen credential is a skeleton key or a dead end.5. Governance for the agents themselves.&nbsp;Autonomous agents communicating over MCP and agent-to-agent channels are invisible to controls built for human users and predictable service traffic. That needs a policy enforcement point between agents and everything they touch: a registry of which agents exist, what each is permitted to reach, and inline enforcement when behavior leaves the defined envelope. An agent that starts probing a package proxy should trip a wire, not a headline.&nbsp;&nbsp; Why the Capabilities Only Work TogetherHere's the asymmetry. The attack needed every link in its chain to hold. The defense needs one — egress denied, payload detonated, segment closed, credential scoped, agent flagged — and the chain breaks.So why insist on all of them?&nbsp;Because an autonomous agent isn't a one-shot attacker. It retries. It searches. Hugging Face's forensic timeline groups the agent’s 17,600 recorded actions into roughly 6,280 distinct clusters across four days, and OpenAI describes the escape as consuming substantial inference compute. Against an adversary whose patience is measured in compute rather than hours, one control is a puzzle. Layered controls are a wall.Egress control assumes the sandbox will eventually be escaped. Segmentation assumes inspection will eventually miss a payload. Data posture assumes a workload will eventually be compromised. Each layer exists because the one before it is permitted to fail.This is also why the capabilities belong on a common platform rather than in a stack of point products. Stitched-together tools each see one frame. A unified enforcement plane sees the film. The Questions To Ask This QuarterThe July incident was, in a strange way, a gift: a full-fidelity&nbsp;red-team exercise run by a frontier lab, disclosed transparently, with limited damage. Enterprises deploying AI agents will not always get the benign version.Security leaders should be able to answer four questions with specifics, not aspirations.&nbsp;What governs internet egress for your AI training, evaluation, and agent runtime environments — is it deny-by-default, and can you name every external endpoint those environments reached last week?What inspects the datasets, packages, and model artifacts your pipelines execute — and does that inspection complete before execution, or after?If a workload in that stack is compromised today, how far does it get — pod, cluster, cloud account, database — and can you prove it stops early?Do you know, right now, which AI agents exist in your environment, what each one is permitted to touch, and what happens the moment one steps outside that envelope?Two frontier AI companies just learned the answers to those questions the hard way, in public, with the world's most capable models as the pen-testers. The rest of us get to learn from their disclosure instead.Want to learn more? Speak to our experts here.]]></description>
            <dc:creator>Paul Aiuto (Director, Commercial Sales Engineering - Americas)</dc:creator>
        </item>
        <item>
            <title><![CDATA[It No Longer Takes an Expert to Attack a Factory]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/it-no-longer-takes-expert-attack-factory</link>
            <guid>https://www.zscaler.com/blogs/product-insights/it-no-longer-takes-expert-attack-factory</guid>
            <pubDate>Thu, 27 Aug 2026 16:32:03 GMT</pubDate>
            <description><![CDATA[Factories have never lacked attackers. Manufacturing has sat at or near the top of the&nbsp;attacked-industry rankings for years, and every plant leader has seen the ransomware headlines. But nearly all of it lands on the business side of the company - email, file servers, the systems that run the enterprise rather than the line.The factory floors themselves were a different story. Writing a working exploit for an industrial controller - the small computers that open valves, run motors, and keep production lines moving - was specialist work. You needed to understand the protocol, the firmware, the quirks of a product family most software people have never touched. That knowledge was scarce, and the scarcity was a form of protection. An attacker who got into the business network usually stopped there - not out of restraint, but because going further took skills few people had.That protection is dissolving. In April,&nbsp;Anthropic disclosed that its Claude Mythos model could take on much of the work of finding security flaws and turning them into working attacks - a capability the company restricted to vetted organizations rather than releasing broadly. Since then,&nbsp;published research has shown AI turning a released patch into a working exploit in hours. And open-weight models that anyone can download are&nbsp;estimated to trail that capability by only a few months.On August 19, this stopped being a research story. A joint advisory from NSA, CISA, FBI, DOE, and EPA -&nbsp;AA26-231A - documented an active campaign using AI-generated scripts against Siemens S7 series controllers, disguised as monitoring tools. It is the first federal confirmation of AI-assisted exploit development targeting operational technology. CISA is explicit that the targeting is broader than one vendor: everyone running these controllers should assume they are in scope.Put those together and the trend is hard to miss. The scarce skill that stood between the attacker in the business network and the machines on the floor is no longer scarce. What used to require a specialist now requires merely a subscription. Why the plant can't just patch fasterFor years, the standard answer to faster attackers was faster patching. Shrink the time between a fix coming out and the fix being installed. Whole industries organized themselves around that race - automatic updates, staged rollouts, patch Tuesdays.AI is ending that race even where it was winnable. When a fix published on Monday can be a working attack by Tuesday, no patch cycle is short enough - and IT teams with modern tooling and weekly change windows are feeling that squeeze right now.The plant floor was never in the race to begin with, and the reason is physical, not cultural. Walk through a factory and much of what you see has been running for ten or twenty years. It runs reliably in large part because nobody touches it. Change one piece and you put the whole line at risk, because everything downstream depends on it. "If it ain't broke, don't fix it" is the operating rule out there, and it earned its place.And keep in mind what these places actually do. They make our food and medicine. They deliver our power and water. They build our cars. Stopping a line for an afternoon costs real money. A change that goes wrong and stops it for a week is the kind of event careers end over. So changes wait for planned maintenance windows, a handful of times a year, when the line is already down. Plants do patch - they simply patch on that schedule. If attackers have found a faster way to write exploits, changing that schedule is not a simple ask; every added window is a negotiation with production, with vendor support terms, and weighing the risk of stopping the line.So the gap is widening from both ends. Attacks are getting faster everywhere, and the plant was never built to move fast at all. Any defense built on the plant getting quicker is built on something that won't happen. "But our plants aren't on the internet"Mostly true - but it still misses where the risk lives.The plant as a whole is usually isolated, and deliberately so. But individual pieces of it often aren't, and almost always for a reason that made sense at the time. The chiller vendor needed remote access for service calls, so a connection was set up. A machine builder shipped equipment with a cellular modem for support monitoring. An integrator left a remote link in place after commissioning and nobody took it out. Each one was a practical decision. Nobody was keeping the list.Some of those pieces end up directly visible from the internet.&nbsp;Research Forescout published on August 5 counted 4,407 Rockwell/Allen-Bradley controllers answering directly from the internet worldwide, 65% of them in the US - one vendor's platform, counting only the directly visible end of the problem.The rest of the risk arrives indirectly. A controller doesn't need its own internet connection to be reachable - it needs a path from something that does. Most plant networks are flat - one big open floor where everything can talk to everything - a sensible choice when it was made: simple networks are predictable, predictable means dependable, and dependable means always up. The cost shows up when something hostile gets in and inherits that same simplicity. The scripts described in AA26-231A were disguised as monitoring tools - software that would look routine on exactly these networks.So the question that matters isn't whether the plant is on the internet. It's how many of those connections exist, where they lead, and what happens when a bad actor gets access to them. Won't AI help defenders too?If controllers can't be fully isolated, the next hope is that the technology creating this problem can help solve it. Partly, it can.NIST's SP 1353, a quick-start guide released in draft on August 19, shows how to use AI for Cybersecurity Framework 2.0 analysis, planning, and reporting. It is genuinely useful. It will help teams find gaps faster, document faster, report faster. What it does not do is solve for the maintenance window.Defender-side AI, so far, speeds up the parts of the job that were never the bottleneck in a plant. The bottleneck is that fixing things means touching production, and touching production carries downtime risk that no analysis tool removes. AI hands attackers the thing they were short of - the skill to write exploits. It does not hand factory defenders the thing they are short of, which is safe chances to touch the machines.Both sides get AI. Only one side's constraint dissolves.&nbsp; The defense that doesn't care how fast the exploit was writtenYou cannot slow down how fast exploits get written. You cannot safely speed up how fast the plant changes. What you can control is the number in between: how many things can reach a controller in the first place.An exploit written in hours and an exploit written over months have identical value against a controller they cannot reach. Shrink that set and you have cut your exposure to every exploit against it - the ones published, the ones being generated right now, and the ones that don't exist yet. It is the rare defense whose value goes up as attacker capability goes up, because it doesn't compete on speed. It removes the race entirely.The two problems named earlier are the two places to shrink it. The flat network is answered by shrinking each machine's world. The traditional way to do that meant carving the plant into zones - a project that touches everything. What's possible now is finer and far lighter. Picture a switchboard on the plant floor: every device connects to it and to nothing else. When one machine needs to talk to another, the request goes to the switchboard, which checks who is asking and whether an approved reason exists for that conversation - and connects them only if one does. Every device starts with what amounts to a network of its own, able to reach the handful of systems it has an explicit reason to reach and nothing else. All of it happens locally, on the floor - no rewiring, no new addresses, nothing installed on the machines. A foothold - an infected workstation, a compromised vendor laptop - lands in a room of one instead of an open floor.The one-off connections are answered by the same switchboard, taking calls from outside. The chiller vendor no longer holds a standing line into the plant: they call in, the switchboard verifies who they are, and it connects them to the one system they service - for that session, and nothing else. No direct inbound path to a controller exists at all. This is easier on everyone, not harder. The vendor has nothing to install or maintain; access simply works when they need it. And because every connection now passes through one place, the list nobody was keeping starts keeping itself - every vendor, every link, visible and auditable by the security team. The floor keeps everything it legitimately needs; what changes is what those connections can reach, and who can see them. Neither move requires taking a line down, which is exactly why they work at plant change speed.&nbsp;&nbsp;This is the thinking behind Zscaler's approach to OT - my colleague Amit Aneja's recent post,&nbsp;Securing the Unsecurable: OT, IoT, and the Factory Floor, walks through what it looks like in practice on the plant network.None of it fixes a vulnerable controller. The flaw is still there, and patching within the windows the plant can support still matters. What architecture changes is the size of what's left - fewer paths for an exploit to use, fewer places a stolen credential can go, and a record of every connection when something needs investigating.The hard part of the attack got easy. The hard part of the defense - changing a running plant - did not, and will not. And you cannot decide what the switchboard should allow until you know what talks to what today - so the place to start is knowing what can reach your controllers, and that is a map, not a plant change.&nbsp; It is the work we do in an&nbsp;OT architecture workshop. You can also hear from our customers directly on how they use Zscaler for OT security.&nbsp;]]></description>
            <dc:creator>Bryan Ashley (Zero Trust Networking, Principal Architect)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Zscaler WebMCP Security Controls: Bringing Zero Trust to the Agentic Web]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/zscaler-webmcp-security-controls-bringing-zero-trust-agentic-web</link>
            <guid>https://www.zscaler.com/blogs/product-insights/zscaler-webmcp-security-controls-bringing-zero-trust-agentic-web</guid>
            <pubDate>Thu, 27 Aug 2026 00:08:36 GMT</pubDate>
            <description><![CDATA[We are excited to announce&nbsp;WebMCP Security Controls&nbsp;(Web Model Context Protocol)&nbsp;in the Zscaler Zero Trust Browser. This solution extends the zero-trust framework, traditionally applied to human web activity, to secure the automated tool calls made by AI agents directly within the browser via the emerging WebMCP standard.WebMCP is a proposed web standard available in&nbsp;Chrome Origin Trials. WebMCP lets websites expose structured, typed JavaScript functions and annotated HTML forms as callable tools for AI agents.&nbsp;&nbsp;An in-page AI agent can then list those tools and invoke them programmatically, i.e.&nbsp;get_cart,&nbsp;update_cart,&nbsp;search_flights,&nbsp;submit_payment. No clicking, no navigating, no leaving the page. It’s a useful primitive, which is why we started paying attention to it.This post covers why we built the product, where the control point needs to sit for this new interface, how it works, and three short demos from a real customer scenario. Where the Control Point SitsThe Zscaler Zero Trust Browser Extension runs inside the Chrome browser, on the same layer as the WebMCP APIs themselves. That placement is deliberate. It lets us evaluate every tool call&nbsp;before the site’s handler ever runs.There are two points in the WebMCP lifecycle where this matters. The first is registration: when a site declares its tools, the extension enumerates them before the agent has any way to invoke them. The second is invocation: when the agent actually calls a tool, we inspect the full argument payload and evaluate its policy . If the policy says block, the site’s function is never called at all. Nothing runs, no state changes, nothing goes out. The agent is then told the call failed in a way the user can see, so there’s no silent failure.Because The Zscaler Zero Trust Browser Extension sits at that point in the flow, the outcome doesn’t hinge on what’s in the path. There’s no downstream tool to depend on and no cooperation required from the site. The decision happens at the moment the tool call is being made, on the layer before anything else has a chance to react to it. How WebMCP Security Controls workWebMcp security was specifically developed for this in-page layer, using the same zero-trust principles as the rest of the Zscaler platform. The Zero Trust Browser Extension that customers are using to secure their Chrome browsers now also secures the WebMCP layer, and gives customers three additional capabilities on top of it.1. WebMCP Capability DiscoveryThe moment a user (or their agent) loads a WebMCP-enabled site, the The Zero Trust Browser Extension enumerates every tool the site registers, before a single one can run. Seven attributes are captured on each tool:webmcp.tool.name: the identifier the site exposedwebmcp.tool.description: the natural-language description the site declaredwebmcp.tool.arguments: the JSON payload passed at invocation timewebmcp.tool_count: how many tools the site registered in totalwebmcp.tool.provider_origin: the origin that actually registered the toolwebmcp.tool.is_cross_origin: whether that origin differs from the top-level sitewebmcp.tool.has_untrusted_content_hint: a signal that the tool’s output may contain untrusted contentThis creates a structured inventory of the agentic surface, specific to every site and user. This is a view security teams simply haven’t had before, mostly because the layer it describes is new.2. WebMCP Runtime MonitoringWhile discovery tells you what a site can do, Runtime Monitoring tells you what it actually did. While the user is on the page, the extension captures every tool invocation with full context: the seven attributes above, plus user identity, device posture, extension version, browser, IP, geolocation, and URL. Each event lands in the Zscaler admin console as a detection, in the same event stream as the rest of the platform’s telemetry. Searchable, filterable, exportable.That’s what makes agent activity&nbsp;auditable. If something anomalous happens, you know which agent made the call, on whose behalf, on which device, and what it passed as arguments. Not just that&nbsp;someone’s browser touched the site.3. WebMCP Policy EnforcementVisibility on its own doesn’t change outcomes, which is why inline policy enforcement is so critical. Policies apply in real time, match to any of the seven WebMCP attributes, and land on one of three effects:Allow: Call proceeds normally.Monitor: Call proceeds, but is logged as a detection with full context. This is a good starting posture.Block: Call is stopped at the point of invocation. The agent is told the call failed, and that message shows up in the agent’s own reply to the user.Rules can match on tool identity (kill a whole capability), on argument content (kill specific payloads that carry restricted data), on provider origin (be stricter about cross-origin tool providers), or on the untrusted-content hint (treat outputs from lower-trust sources differently).Figure 1. Registration and invocation are both intercepted inside the page. Every attribute is captured, every call is policy-evaluated inline, every decision is logged with full user and device context.Together the three capabilities cover the questions we usually get from security teams the first time they see WebMCP: what tools are on our sites, what are agents actually doing with them, and what do we want to allow? Zero trust has always been about answering these kinds of questions. Now we get to answer it for agents on the web too.Figure 2. The seven attributes on the left are what every policy rule can match against. The two rules on the right are the ones used in the demos below. See it in ActionThe three short demos below all run against the same site, a retailer with an in-page AI shopping assistant, and the same user. The only thing that changes between them is the policy. This is roughly the sequence we recommend to our customers– start in monitor mode, learn what’s actually happening, then add targeted blocks where you need them.1. Monitor mode: see the surface before you change itMost teams start here. In monitor mode, every tool registration and invocation is captured and logged without blocking a single action. While your users won't notice a thing, your security team gets two key benefits: a complete inventory of the agentic surface across every site visited, and a fully searchable audit trail of every tool call that occurs.In the demo below, the assigned policy is called&nbsp;Monitor WebMCP and runs in passthrough mode with all seven&nbsp;webmcp.* attributes enabled. The user opens the retailer’s site, launches the in-page agent, and asks “what’s in their cart”. The agent calls&nbsp;get_cart and answers in real time. On the admin side, each interaction shows up as a new detection with severity&nbsp;Informational and effect&nbsp;Allow. Clicking into one gives you the full record, including user identity, device posture, IP, geolocation, URL, tool name, tool description, and tool count. The Monitor WebMCP policy in the Zscaler admin console: all seven webmcp.* attributes wired up as monitor rules, default effect Allow.The Detections view streams every WebMCP interaction as an Informational / Allow entry, in the same stream security teams already use for user activity.A single detection carries the full forensic record: user identity, device posture, IP, geolocation, URL, and the Webmcp Tool Name, Description, and Count the site declared.Monitor mode is not designed to immediately block threats. Instead, it establishes an essential baseline of "ground truth" before security teams begin enforcing block rules. By first understanding exactly which tools users are invoking, on which domains, and with what arguments, organizations can make highly informed policy decisions rather than blocking traffic blindly.2. Blocking a tool: kill the capabilityOnce you know what agents are calling, the next step is deciding what you don’t want them calling. The simplest kind of block rule targets a tool by name. In this demo, the policy switches to&nbsp;Block WebMCP with a single condition:&nbsp;webmcp.tool.name is equal to update_cart. Any invocation of that tool, with any arguments, on any site the policy covers, gets stopped at the point of call.On the user side, this is&nbsp; visible in real time. The user asks the agent to add an item to their cart. The agent tries to call&nbsp;update_cart. The extension intercepts it, matches the rule, and returns a block. The agent then tells the user directly: "The Zscaler Zero Trust Browser blocked this action for security reasons." Nothing is silent. The user knows what happened, and the SOC sees a new detection show up with severity&nbsp;Low, effect&nbsp;Block, and the exact rule reason:&nbsp;webmcp.tool.name is equal to UPDATE_CART. The block surfaces inside the agent’s own reply, so the user gets a clear reason instead of a mysterious failure.A new Low-severity Block WebMCP row appears at the top of the Detections list, alongside the ongoing Informational / Allow stream from Monitor mode.The detection detail carries the exact rule that fired: Reason: webmcp.tool.name is equal to UPDATE_CART. Analysts get the "why" without leaving the console.Blocking by tool name is the right control when a capability is just out of scope for a given user group. A marketing team’s agent does not need to invoke&nbsp;submit_payment. A support team’s agens does not need to invoke&nbsp;export_customer_pii. One rule per capability, applied to the right group.3. Blocking on arguments: DLP for the agentic layerSometimes the tool itself is fine and the problem is the payload. That’s what argument-level inspection is for. Instead of matching on tool name, this rule matches on the JSON arguments the agent passes to the tool:&nbsp;webmcp.tool.arguments contains "book". Every&nbsp;update_cart call is still evaluated. Only the calls whose payload contains the restricted keyword get blocked.In the demo, the user asks the agent to list available products. The agent calls&nbsp;browse_store, which is allowed, and returns a catalog. Two items in it are relevant here: a&nbsp;Hammer Time Graphic Tee and a&nbsp;Book Cat Graphic Tee. The user asks to add the Hammer Time tee first. The argument payload contains&nbsp;hammer-time-graphic-tee, no match on the rule, the call goes through. Then the user asks to add the Book Cat tee. Now the payload contains&nbsp;book-cat-graphic-tee-apple-blossom-26f12103, which does match on&nbsp;book. The call gets blocked, and the agent tells the user: "The Zscaler Zero Trust Browser blocked this action for security reasons, so I am unable to add the ‘Book Cat Graphic Tee’ to your cart." Meanwhile the detection in the console has captured the entire argument payload, verbatim. Same tool, different payload, different outcome. The user asks for the Book Cat Graphic Tee; the argument matches the deny rule; the agent surfaces the block inline.The console captures the argument payload verbatim: {"cart":{"line_items":[{"handle":"book-cat-graphic-tee-apple-blossom-26f12103","quantity":1}]}}. That’s what makes agent activity correlatable with the actual data flow, not just the tool that was called.Argument-level inspection is what makes WebMCP Security Controls feel like DLP for the agentic layer. Regex patterns for PII, deny-lists for customer names or project codenames, structural checks on JSON payloads: the same primitives enterprises already trust for traditional DLP, now applied to what agents are passing into websites. The full round-trip of a blocked call looks like this:Figure 3. The full round-trip of a blocked call. The extension inspects arguments in flight, blocks the invocation, surfaces the failure back to the user through the agent’s reply, and logs the exact rule reason. Why We Didn’t Want to Wait on ThisA few things convinced us this had to ship now rather than later.WebMCP adoption will move faster than governance. The standard is already adopted in Chrome Origin Trials . Every site running an in-page AI assistant has a fairly short path to shipping WebMCP tools. Every agent that talks to those sites has an incentive to use them. When a new web capability lands in a mainstream browser, adoption usually compresses from years to months. It’s much easier to put controls in place before that curve as opposed to waiting until after the first incident.Agents act under user identity. A tool call inherits the user’s session, cookies, and authorization, but the intent behind it comes from a model. That’s an audit and governance problem long before it’s a security one. Which agent made this call, on whose behalf, with what payload? Those questions become answerable at the WebMCP layer, at runtime, using the attributes and context the extension already captures.Productivity can’t be the tradeoff. Blocking in-page AI assistants outright isn’t really a viable answer. Employees are already using them and are going to use them, and the productivity gains are real. A control that lives at the WebMCP layer means users keep the benefits of agentic browsing while the enterprise still gets a say in what those agents are actually allowed to do.We’ve seen this pattern before. Zero trust replaced castle-and-moat once perimeters started dissolving. Zero trust followed the work again as it moved to cloud and SaaS. Agentic browsing is the same story one layer deeper, and it’s a lot easier to put controls in place while the agentic surface is measured in a handful of tools per site rather than dozens. What’s NextWebMCP Security Controls are available today in the Zscaler Zero Trust Browser. If you want to see your own users’ agentic surface,&nbsp;reach out to your account team for a demo or visit the&nbsp;product page. Most teams are surprised by what their first monitor-mode report turns up.This is just one of many innovations for the Zero Trust Browser for securing AI and AI Agents. Stay tuned for more and frequent innovations introduced in Zero Trust Browser , the most comprehensive and complete Zero Trust Browser Security product in the market.]]></description>
            <dc:creator>Joby Menon (SVP, Product Management | Zscaler)</dc:creator>
        </item>
        <item>
            <title><![CDATA[What to Look for in a Deception Technology Solution]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/what-to-look-for-deception-technology</link>
            <guid>https://www.zscaler.com/blogs/product-insights/what-to-look-for-deception-technology</guid>
            <pubDate>Wed, 26 Aug 2026 17:06:19 GMT</pubDate>
            <description><![CDATA[Modern security teams face an uncomfortable reality: perimeter defenses are no longer sufficient. According to the 2026 Verizon Data Breach Investigations Report (DBIR), stolen credentials remain a primary breach vector, and modern attackers move laterally with extreme speed once inside. Compounding this, traditional security tools generate noisy alerts, resulting in severe alert fatigue.To detect threats early, organizations are adopting deception technology. A deception technology solution is a proactive approach that places decoys, lures, and traps across the environment to detect malicious activity early. Rather than replacing EDR, NDR, or Zero Trust controls, deception acts as a critical complementary layer. This guide outlines the key features and evaluation criteria to help you select the right solution. What Is a Deception Technology Solution?Cyber deception is a defensive strategy that deploys realistic, non-production assets, such as fake credentials, servers, files, shares, and applications, to mislead attackers. Legitimate users should never touch these assets. If they do, it signals credential compromise or malicious insider activity, both of which merit investigation.This proactive defense is supported by frameworks like and NIST guidelines, which advocate for adversary engagement to build enterprise resilience. MITRE Engage Framework recommends deploying decoys on trusted systems; NIST SP 800-61 calls for detection techniques beyond signatures.Deception AssetDescriptionExampleDecoysSimulated systemsFake database serverLuresBaits placed on endpointsFake credentialsAD TrapsDirectory objectsDecoy administrator accounts&nbsp; How Deception Technology WorksDeception platforms automatically distribute lures across endpoints using policy-based rules; no manual deployment per device."When an attacker compromises a device and searches for lateral paths, they discover these lures (e.g., deceptive mapped drives or SSH keys). Engaging with a lure directs them to a decoy system. Probing the decoy triggers a high-fidelity, context-rich alert, minimizing dwell time and stopping lateral movement before production assets are impacted.Further emphasizing the need for deceptive traps, the Zscaler ThreatLabz 2026 Phishing and Initial Access Report found that 95.2% of phishing and initial access attempts now hide inside encrypted (TLS/SSL) traffic. Because legacy security tools often lack visibility into encrypted channels, placing high-fidelity decoys and lures across endpoints and cloud assets creates an unmissable alarm system when adversaries attempt to leverage compromised access.&nbsp;Deception Technology vs. Traditional HoneypotsModern deception evolved from honeypots, but they are fundamentally different:FeatureHoneypotsModern DeceptionScaleStatic, manualDistributed, automatedScopeNetwork segmentsEndpoints, cloud, identityManagementHigh maintenanceCentralized, policy-drivenIntegrationSiloedIntegrated with SIEM, SOAR, EDR&nbsp; Why Organizations Use Deception TechnologyDetect Attackers EarlyDeception catches attackers during reconnaissance, privilege escalation, and lateral movement. It is uniquely suited to detect "living off the land" techniques where attackers use built-in administrative tools that bypass traditional signature-based EDR, dramatically improving containment times.Reduce Alert FatigueDeception alerts are high-fidelity when decoys are placed in zones where legitimate traffic never flows. A decoy SMB share in a vaulted segment has zero false positives; one on a general subnet may not.Improve Visibility Into Lateral Movement and RansomwareDeception detects file share scanning (a precursor to encryption) by triggering alerts when attacker-controlled processes probe decoy shares, alerting security teams within minutes of reconnaissance.This early-stage visibility is critical given the sheer volume of adversary probing. According to the Zscaler ThreatLabz 2026 Phishing and Initial Access Report, deception telemetry recorded 89.9 million hostile interactions from 1.37 million unique attacker IPs in a six-month span alone. This highlights that attackers are actively scanning identity and collaboration platforms to map potential paths long before launching a targeted intrusion. Core Features to Look for in a Deception Technology SolutionWhen evaluating deception technology, prioritize the following foundational capabilities:Key FeatureDescriptionEvaluation CheckBelievable DecoysMust run realistic services to deceive advanced attackersDo decoys respond dynamically?Broad CoverageMust protect hybrid endpoints, cloud, and Active DirectoryDoes it support SaaS decoys?AutomationAutomated deployment, updates, and low overhead are essentialCan it deploy endpoint lures automatically?Rich ContextAlerts must provide deep telemetry (user, process, and timeline)Does it map to MITRE ATT&amp;CK?IntegrationsMust connect natively to SIEM, SOAR, and EDR platformsCan it trigger an automated response?Low OverheadMust not degrade endpoint performance or cause noiseIs it agentless?&nbsp; Evaluation Criteria: Comparing SolutionsTo select a platform that scales, use these five key criteria:Evaluation CriterionDescriptionKey FocusEase of DeploymentSoftware-defined or agentless deliveryDeploys globally in minutes without complex hardwareCoverage DepthProtects hybrid endpoints, AD, and cloudAddresses surfaces where credential abuse is prevalentDetection QualityEnriches alerts with rich telemetryDistinguishes automated scanning from targeted movementEnterprise ScalabilityCentralized policy administrationSeamlessly supports remote workforces and cloud growthExecutive VisibilityMeasures risk reduction and metricsShows how deception shortens MTTD and MTTR&nbsp; Common Use Cases &amp; What to AvoidModern enterprises leverage deception to solve critical security challenges while avoiding costly operational pitfalls:Common Use CasesCritical Pitfalls to AvoidCredential Protection: Surfacing stolen admin credentials used to access fake directory servicesStatic Decoys: Easily fingerprintable decoys are quickly bypassed by sophisticated actorsLateral Detection: Catching attackers as they probe decoy file shares or scan network segmentsNetwork-Only Focus: Solutions lacking cloud and remote endpoint coverage leave massive blind spotsRansomware Defense: Tripping decoy shares to flag encryption behaviors before damage occursSiloed Alerting: Solutions without native SOAR/SIEM integrations slow down responseThreat Hunting:&nbsp;Providing high-fidelity leads that analysts can pivot from to uncover threatsHigh Maintenance: Platforms requiring constant manual updates drain valuable resources&nbsp; How Deception Fits Into a Zero Trust StrategyZero trust restricts access; deception detects when that access is abused. A compromised admin account passes zero trust's authentication check, but fails the moment it tries to access a decoy admin share.This is where Zscaler Deception excels. Integrated directly into the Zscaler Zero Trust Exchange™, it allows organizations to deploy high-fidelity decoys and lures effortlessly without adding operational complexity. Combining Zero Trust access controls with active deception enables enterprises to achieve a powerful defense-in-depth posture that proactively stops lateral movement.&nbsp; ConclusionThe ideal deception technology solution must be highly realistic, automated, and deeply integrated into your existing security stack. Rather than introducing noise, it provides the high-fidelity signals needed to neutralize advanced threats. By aligning deception with a Zero Trust framework, you can minimize attacker dwell time and protect your most critical assets.]]></description>
            <dc:creator>Matt McCabe (Senior Web Content Writer)</dc:creator>
        </item>
        <item>
            <title><![CDATA[What’s New in GovCloud:  August 2026 Zscaler Product Updates]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/what-s-new-govcloud-august-2026-zscaler-product-updates</link>
            <guid>https://www.zscaler.com/blogs/product-insights/what-s-new-govcloud-august-2026-zscaler-product-updates</guid>
            <pubDate>Wed, 26 Aug 2026 08:14:46 GMT</pubDate>
            <description><![CDATA[Product releases move fast, and carving out time to review what's changed across multiple platforms is rarely at the top of anyone's to-do list. Here is a curated roundup of notable Zscaler GovCloud updates from August, with quick context and scan-friendly takeaways you can share across security, network, and operations teams. Highlights include WebSocket traffic inspection in ZIA, new ThreatParse detection rules for actively exploited CVEs in Deception, BGP route filtering and DNS-over-HTTPS support in Zero Trust Branch, and customizable password policies in the Authentication Service. Zscaler Internet Access (ZIA)Zscaler Internet Access (ZIA) is Zscaler's secure internet and SaaS access service, providing policy-based protection and visibility for users wherever they work. For many federal environments, ZIA is central to enforcing acceptable use, protecting sensitive data, and maintaining consistent security controls across a distributed workforce.This month's ZIA updates expand inspection coverage to WebSocket traffic, introduce resilience controls for partial configuration scenarios, and add new search filters to simplify management of large firewall rule sets.HighlightsPartial Configuration Handling Mechanism: A new "Behavior When Partial Configuration Available" setting lets admins choose how policy is enforced if a Service Edge is operating on incomplete or cached tenant/user/location data. Options include Fail Open, Fail Close, or Best Effort Policies, giving teams control over the tradeoff between availability and security posture during edge cases.WebSocket Inspection Enhancements: ZIA now inspects bidirectional WebSocket traffic for supported content, extending security and data-protection controls to these communications. This closes a visibility gap for applications that rely on persistent WebSocket connections.New Search Filters for Firewall Filtering Policy Rules: New filters have been added to the Firewall Filtering Policy page, including Rule Status, Network/Application Service Groups, Source/Destination Country, and IPv6 Groups. These make large rule sets easier to search and manage at scale.For full release notes:&nbsp;https://help.zscaler.us/zia/release-upgrade-summary-2026 Zscaler Private Access (ZPA)Zscaler Private Access (ZPA) provides secure, zero trust connectivity between users and private applications without exposing those applications to the internet. It helps organizations reduce attack surface while improving access experience, which is especially important for distributed users, mission partners, and hybrid work environments common across federal agencies.This month's ZPA updates deliver a recommended Manager software release and security-fix updates for both Private Service Edge and Private Cloud Controller.HighlightsManager Software Updates: Released updated App Connector, Private Service Edge, and Private Cloud Controller RPM packages for RHEL 8.x/9.x (Manager software version 26.54.6). Packages are downloadable from the Zscaler repository.Private Service Edge Version 26.54.6: A security-fix update for Private Service Edge, applied per your configured software update schedule.Private Cloud Controller Version 26.54.6: A security-fix update for Private Cloud Controller, applied per your configured software update schedule.For full release notes:&nbsp;https://help.zscaler.us/zpa/release-upgrade-summary-2026 Zscaler Client ConnectorZscaler Client Connector is the unified endpoint agent that steers traffic to ZIA, ZPA, and ZDX services. It ensures consistent policy enforcement regardless of where users connect from, which is critical for agencies supporting remote and hybrid workforces.This month's update addresses several Admin Console usability and functionality issues.HighlightsZscaler Admin Console 4.5.5: This release fixes device-search pagination, a device-details export timeout, a blank protocol dropdown in Experience Center, and a policy-sync issue affecting Private Access entitlement assignment. These fixes improve day-to-day administrative workflows and entitlement accuracy.For full release notes:&nbsp;https://help.zscaler.us/client-connector/release-upgrade-summary-2026 Zero Trust BranchZscaler Zero Trust Branch helps modernize branch security and connectivity by bringing zero trust principles to branch offices, remote sites, and OT/IoT environments, reducing reliance on legacy appliances while maintaining consistent policy enforcement.This month's Zero Trust Branch update introduces BGP route filtering, DNS-over-HTTPS support, and FIPS enablement improvements, continuing to strengthen both routing flexibility and compliance alignment.HighlightsZero Trust Branch 8.2.1P1: This release adds BGP route filtering with import/export maps, DNS-over-HTTPS configuration for Hub sites and custom DoH endpoints, FIPS enablement with NTP fixes, additional BGP policy filters, and improved App Connector auto-recovery status reporting. These enhancements give network teams more control over routing policy and encrypted DNS resolution at the branch.For full release notes:&nbsp;https://help.zscaler.us/zero-trust-branch/release-upgrade-summary-2026 Zscaler DeceptionZscaler Deception deploys decoys and lures across environments to detect lateral movement, credential theft, and attacker reconnaissance. For federal organizations, deception adds an active defense layer that can identify adversary activity early in the kill chain without relying solely on signature-based detection.This month's Deception updates deliver new detection rules for actively exploited vulnerabilities, enhanced network fingerprinting in event logs, and an expanded decoy dataset for network appliances.HighlightsNew ThreatParse Rules: Added detection rules for several actively relevant CVEs, including unauthenticated RCE in Langflow, an unauthenticated file-write flaw in Splunk, a PHP code-injection issue in Everest Forms Pro, and vulnerabilities affecting Fortinet FortiClient EMS, Ivanti Endpoint Manager, Ivanti Sentry, and Cisco Secure Firewall Management Center. These rules help identify adversaries leveraging current exploit techniques.Admin Portal Enhancements: Event logs now support JA3/JA4 network fingerprints for web decoys, and web server banners for network and Threat Intelligence decoys were updated for improved accuracy. This strengthens forensic context and decoy realism.New Datasets: Added a new high-interaction Cisco ASA dataset, expanding decoy coverage for network security appliances and improving detection fidelity for attackers targeting perimeter infrastructure.For full release notes:&nbsp;https://help.zscaler.us/deception/release-upgrade-summary-2026 Authentication Service (Zidentity)The Zscaler Authentication Service (Zidentity) provides centralized identity and access management for the Zscaler platform. It supports authentication policies, MFA enforcement, and user lifecycle controls that help agencies meet identity-centric zero trust requirements.This month's update introduces customizable password policies for stronger credential hygiene.HighlightsCustomize Password Policy: Admins can now configure account deactivation after a set number of unsuccessful login attempts and reject a configurable number of previously used passwords. Both settings are customizable from 3 to 10, supporting compliance with organizational and federal password policy standards.For full release notes:&nbsp;https://help.zscaler.us/zidentity/release-upgrade-summary-2026 ConclusionWant the full details? Use the links above to review the complete release summaries, and check back next month for the next GovCloud update roundup.Zscaler continues to invest in a robust GovCloud roadmap and remains committed to supporting the unique security, compliance, and operational requirements of the federal market. We'll keep delivering enhancements that help agencies and federal partners strengthen resilience, simplify operations, and advance mission success.]]></description>
            <dc:creator>Jose Arvelo Negron (Manager, Sales Engineer)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Zero Trust or Bust: Winning Compliance in an AI-Driven Multicloud World]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/zero-trust-or-bust-winning-compliance-ai-driven-multicloud-world</link>
            <guid>https://www.zscaler.com/blogs/product-insights/zero-trust-or-bust-winning-compliance-ai-driven-multicloud-world</guid>
            <pubDate>Tue, 25 Aug 2026 21:45:52 GMT</pubDate>
            <description><![CDATA[The compliance problem isn't new. But the environment it has to operate in is.Not long ago, achieving regulatory compliance was largely a documentation exercise. You mapped your controls to a framework — HIPAA, PCI-DSS, SOC 2, GDPR — ran an annual audit, and filed the results. It wasn't glamorous, but it was manageable.That model is broken. And the culprits are two technologies that every organization has embraced: AI and multicloud.&nbsp; The Compliance Headache You Didn't Sign Up ForToday, the average enterprise runs workloads across 2.1 public cloud providers and manages 85 different SaaS applications (Thales 2025 Data Threat Report). Every one of those environments holds data. Every one of them has its own access controls, logging formats, and security configurations. And increasingly, none of them talk to each other in a coherent way.The result? A staggering 54% of all cloud-stored data is now classified as sensitive — but only 8% of enterprises encrypt 80% or more of it (Thales 2025 Data Threat Report). That's not a gap. That's a chasm.AI has made it worse. A 2025 survey found that 66% of organizations discovered AI tools accessing sensitive data they were never authorized to see. Only 9% could monitor those interactions in real time (Cyera + Cybersecurity Insiders 2025 State of AI Data Security Report). Employees are sharing confidential customer information, financial data, and regulated records with unsanctioned AI tools — creating what security teams call "shadow data" that regulators call a liability.The stakes are real: the average cost of a data breach in the U.S. hit a record $10.22 million in 2025 — and globally, breaches involving non-compliance cost $4.61 million on average, 4% above the global mean. (IBM Cost of a Data Breach 2025). And 50% of organizations failed to pass their most recent compliance audit — and those relying on manual methods were twice as likely to fail. (Hyperproof 2026 IT Risk &amp; Compliance Benchmark Report).For compliance officers and risk executives in financial services, healthcare, and critical infrastructure, this isn't an abstract problem. It's a quarterly board conversation.&nbsp; Why Legacy Approaches Can't Keep UpHere's the uncomfortable truth most vendors won't say out loud: the tools most organizations use for compliance were built for a different era. They assume your data lives in known places, moves in predictable ways, and can be governed through point-in-time audits.None of those assumptions hold anymore.When a cloud workload generates and moves patient data — exporting it to object storage, syncing it to a SaaS endpoint, then piping it into a generative AI summarizer — all in minutes, legacy on-prem DLP never touches the path. And when a non-prod workload spins up with an open bucket or overly permissive IAM, configuration drift can go undetected for weeks; by then, the data—and the compliance violation—are already out.Fragmented tools create fragmented visibility. And fragmented visibility is the enemy of compliance.&nbsp; What Compliance Actually Requires&nbsp;Strip away the legal jargon, and most compliance frameworks are asking for the same foundational capabilities:Know who's accessing what (identity-based access controls, least privilege)Inspect and log everything (continuous monitoring, audit trails)Segment sensitive environments (prevent lateral movement of data)Enforce policy consistently (same rules everywhere, every time)Prove it all to an auditor (centralized reporting and evidence)The problem? Delivering these capabilities across a hybrid, multicloud, AI-enabled enterprise with traditional network security is like trying to enforce speed limits on roads you can't see. That's not a technology problem. That's a data security architecture problem.&nbsp; How Zero Trust Architecture Changes the EquationThis is where Zero Trust—done right—fundamentally shifts the compliance conversation from "audit dread" to "audit ready." The results speak for themselves—organizations that have deployed zero trust architecture save $1.76M on average per breach compared to peers who have not.3&nbsp;&nbsp;Zscaler—the pioneer of zero-trust security—helps simplify compliance by reimagining network security with zero trust principles from the ground-up across users and workloads. Zero trust operates on a simple but powerful principle: never trust, always verify. Instead of relying on network perimeters (which don't exist in multicloud), Zscaler brokers secure connections based on identity, context, and policy—regardless of where users, workloads, or applications reside.Zscaler&nbsp;Zero Trust Cloud is a unified Zero Trust platform that provides secure connectivity for workloads across public and private clouds, fundamentally reducing the attack surface and preventing lateral movement. Instead of exposing networks, it makes apps invisible and connects identities directly to applications. Every connection applies least-privilege access based on identity and context. Traffic is inspected bidirectionally at cloud scale, with TLS decryption governed by privacy controls and inline DLP to detect and prevent data loss or exfiltration. App-to-app and in-app microsegmentation stops lateral movement and dramatically reduces audit scope. And all of it is automatically logged in one place—immutable, consistent, and ready for auditors.&nbsp;&nbsp;&nbsp;Here's what that means for compliance:Unified policy across every cloud. One security policy engine extends Zero Trust principles across AWS, Azure, and GCP. Instead of managing fragmented rules across environments, compliance teams get consistent enforcement—and consistent evidence.Continuous logging and audit trails. Every connection, every data flow, every access decision is logged. When an auditor asks for evidence of access controls or segmentation, it's already there—centralized and searchable.Least-privilege access by default. Users and workloads only connect to what they're explicitly authorized to reach. No lateral movement. No broad network access. This maps directly to what HIPAA, PCI DSS, and NIST frameworks require.Inline data protection. Sensitive data is classified and protected in motion—including traffic flowing to and from AI applications—with TLS/SSL inspection at cloud scale. This addresses GDPR's data protection by design principle and emerging AI governance requirements.Reduced attack surface. Because resources are never exposed to the internet, there's simply less to audit, less to protect, and less that can go wrong.The result is a shift from reactive compliance — scrambling to prove you were compliant at a point in time — to continuous, demonstrable compliance that your team, your auditors, and your board can see in real time. Research backs this up:&nbsp;enterprises that integrate compliance and security analytics into a single platform experience 30% fewer regulatory violations.&nbsp; Proof in PracticeOne of Brazil's largest digital banks, processes over 33 petabytes of customer and financial data across AWS, Azure, and Google Cloud. Facing intense regulatory scrutiny and a fragmented patchwork of siloed DLP tools that couldn't scale, they adopted Zscaler's Zero Trust platform to unify data security everywhere—from cloud workloads to AI models. The result:&nbsp;$4.25 million per year in reduced risk exposure, remediation times cut from days to minutes, and the visibility and control needed to meet regional financial regulatory requirements across their entire multicloud footprint.A leading global financial investment firm transformed compliance from a complex, manual audit burden into a&nbsp;continuous, automated state&nbsp;of verified protection&nbsp;with Zscaler. They&nbsp;were able to directly address the stringent network security controls mandated by&nbsp;PCI DSS 4.0 by leveraging Zscaler’s identity-asserted microsegmentation that replaces traditional IP-based rules with workload identity across Azure and AWS workloads. Furthermore, our unified egress model was specifically engineered to align with the evolving mandates of the&nbsp;SWIFT Customer Security Programme (CSP). By utilizing Zscaler Cloud Connector within our hub-and-spoke architectures to secure back-office and transactional data flows, we established a "Secure Zone" that fulfills SWIFT’s Principle 1 by enforcing granular data flow policies between the customer environment and the SWIFT infrastructure.&nbsp;&nbsp; Compliance Is a Data Security ProblemIf there's one thing the past few years have made clear, it's that compliance and data security are no longer separate disciplines. You cannot be compliant without knowing where your sensitive data is, controlling how it moves, and proving both to regulators who are increasingly sophisticated in what they demand.AI and multicloud aren't going away. The regulatory frameworks governing them — the EU AI Act, DORA, updated HIPAA rules, PCI-DSS 4.0 — are only going to get more rigorous. The organizations that will navigate this well aren't the ones with the most compliance tools. They're the ones with the right architecture underneath.&nbsp; Ready to turn audit dread into audit readiness?Read this&nbsp;solution brief to learn more about how Zero Trust Cloud helps achieve continuous compliance.Explore the&nbsp;Zscaler Compliance Center to see how Zero Trust Cloud maps to your regulatory framework or request for a customer compliance reportSchedule a meeting with a Zscaler compliance expert to walk through your specific requirements — whether that's HIPAA, PCI-DSS, DORA, or all of the above.&nbsp;]]></description>
            <dc:creator>Nikitha Omkar (Senior Product Marketing Manager)</dc:creator>
        </item>
        <item>
            <title><![CDATA[The Fix Has Been Out for a Year. The Controller Is Still Exposed.]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/fix-has-been-out-year-controller-still-exposed</link>
            <guid>https://www.zscaler.com/blogs/product-insights/fix-has-been-out-year-controller-still-exposed</guid>
            <pubDate>Thu, 20 Aug 2026 17:49:11 GMT</pubDate>
            <description><![CDATA[Quick answer: A gap exists between when OT vendors fix vulnerabilities and when operators can actually patch. In food, pharma, and cold-chain sites the update waits for a rare maintenance window because a bad one costs product, not just uptime - a discarded batch, a broken cold chain, a quality deviation that has to be investigated. Two of the most common refrigeration controllers, the Copeland XWEB Pro and Danfoss AK-SM 800A, have serious documented flaws; both vendors shipped firmware fixes months ago, yet thousands of management interfaces remain reachable from the public internet. The practical fix for the gap is reachability: restricting which systems and people can reach the controller lets operators take the update on their own schedule without leaving it exposed in the meantime. Two of the most common supervisory controllers in commercial refrigeration have serious, publicly documented vulnerabilities. Both were fixed by their vendors months ago - Danfoss shipped a fix for the AK-SM 800A in 2025 (CISA advisory), Copeland for the XWEB Pro in February (CISA advisory). A Shodan query on August 19, 2026 returns 3,726 of the Danfoss management interfaces reachable from the public internet - Team82 counted roughly 2,800 via Censys during its research. Different engines, so not a trend line, but the order of magnitude has not moved.If you run a cold-storage warehouse, a food plant, a pharmaceutical distribution site, or a supermarket chain, one of these boxes is probably what tells your compressors and evaporator fans what to do. This piece looks at the gap between "the fix is available" and "the fix is applied": why that gap is wider on the equipment that keeps product cold than almost anywhere else on a plant floor, and what an operator can do inside it.&nbsp;&nbsp; What the researchers showed, and why the vendor names matter less than they lookTeam82's XWEB Pro research, published August 9, is the bigger set: 23 vulnerabilities, 21 rated high. Two of them do the heavy lifting. The administrator password on affected firmware is derived from the date, the device's hardware address, and a fixed value in the firmware, so anyone who can reach the management page can work out today's password without guessing. And once in, an attacker has 19 separate ways to run their own commands as root. The&nbsp;Danfoss AK-SM 800A had fewer flaws - three, all in its web management interface - but one was a hidden "code-of-the-day" login that also bypasses authentication.The demonstration is the part worth remembering. The researchers connected an XWEB Pro to a field controller and a small test refrigerator, held the temperature reading on the display steady at the correct value, and quietly switched off the cooling fans. The fridge warmed. The screen said everything was fine. On a real unit, the temperature log that a food-safety auditor or a pharma quality team would pull to prove the product stayed in range lives on the same controller - in food or pharma, that gap is a discarded batch at best, and a product-integrity question that reaches the market at worst.Both vendors did what vendors should: took the report, shipped fixes, told customers. The more interesting problem sits with the operator, because the position the disclosure puts them in looks the same whatever logo is on the controller. Why the fix sits unappliedIn most manufacturing, a bad maintenance window costs throughput. You lose a shift, you catch up. In food and beverage, pharmaceuticals, and temperature-controlled consumer goods, a bad window can cost the product itself. A refrigeration excursion - the industry's word for temperature drifting outside its allowed band - is a discarded batch, a quality deviation that has to be investigated and written up under the manufacturing quality rules (GMP) that food and pharma operate under, or a food-safety record that follows the product through the supply chain. We wrote about this asymmetry last year in&nbsp;Why Uptime Is the New Cybersecurity KPI in Manufacturing; cold chain is where it bites hardest.To be fair to the equipment, a firmware update on a supervisory controller is not the same as flashing a PLC mid-shift. Copeland even lets you update from the controller's own menu, provided the controller can reach Copeland's servers outbound - which is a very different thing from being reachable inbound by anyone. But the risk that schedules a maintenance window is the perceived risk, and no one likes to hear "usually straightforward" about the box holding a vaccine warehouse between 2 and 8 degrees Celsius. So the advisory gets read, the update gets queued for the next planned outage, and the next planned outage is months away.There is a quieter reason too, and anyone who has tried to find the owner of a refrigeration controller will recognize it. These units often belong to facilities, or to the refrigeration contractor under a service agreement - not to IT, and not to whoever owns OT security. The vendor's advisory email lands in an inbox that does not read CISA advisories, if it lands anywhere. Nobody in this chain is refusing to patch; the request just never reaches someone who could schedule it.And in the meantime the controller cannot simply be unplugged, because the same interface the attacker wants is the one the business depends on. The refrigeration OEM's technicians connect to diagnose and tune it. The operator's own maintenance team watches it from wherever they happen to be sitting. The researchers' guidance - keep the management interface off the internet, restrict it to trusted networks or a VPN - is sound, and it is where most standard advice stops. It also leaves the controller reachable by every device on the plant network and every account on the vendor's VPN. Is "patch now or stay exposed" really the choice?That is the choice operators are usually handed: a risky window now, or a known exposure until the next outage. Both options treat the vulnerability as the risk. The real risk is what can reach it.A serious flaw on a controller that nothing unnecessary can reach is a backlog item. The same flaw on a controller reachable from any laptop on the plant network, any compromised office workstation, or any account on the vendor's VPN is a different situation entirely, and the difference has nothing to do with the CVE list. Every step in the published attack chains, on both platforms, starts with network access to the management interface. Remove that access and the 23 CVEs are still there, but the path to them is not.That is the third option, and it is the one that rarely gets priced: shrink who and what can reach the controller until you can take the update on your schedule instead of the attacker's. It does not replace the firmware. It makes the firmware a planned event rather than an emergency, and it limits the damage when the next disclosure lands the week after your outage window closes. What "shrink reachability" looks like on a real plant floorThree attributes describe the target state:The controller can be reached only from specific, explicitly authorized endpoints and users - the monitoring server, the two engineers who own it, the OEM's support group - not from an entire network segment.When a third-party technician needs access, they get a session to that one device for the duration of the job, with no standing presence on the plant network before or after.None of it requires re-addressing the controller, installing anything on it, or rebooting it. If the security control means touching the device, you are back to the maintenance-window problem you were trying to avoid.That last attribute pays off twice - once for the operator, once for the vendor. For a pharma site, the device itself is not modified, so its qualified state is not disturbed; the network change still goes through change control, but that is a lighter lift than requalifying a controller after new firmware. And for the refrigeration OEM, brokered access is easier than a VPN, not harder - no client to install, no shared credentials to rotate, no waiting on the customer's IT to open a port. Vendors are how these controllers get installed and kept running. This should make their technicians' lives simpler, not treat them as the threat.That third property is also the one that has historically made&nbsp;segmentation&nbsp;policy fail in practice. Eaton's security team described exactly this in&nbsp;their write-up from earlier this month: written segmentation policy across more than two hundred manufacturing sites that could not be enforced, because enforcing it with VLANs and NAC meant touching legacy devices they could not afford to touch. Eaton is electrical manufacturing, not cold chain, so the transferable part is the constraint rather than the vertical - agentless legacy equipment that cannot be re-addressed or restarted is the norm on any plant floor, and enforcement has to work around it.&nbsp;&nbsp; Where Zscaler fitsThree capabilities map to this - two that close the paths above, and a third for the gap that closing paths cannot address.Zero Trust Device Segmentation isolates a controller like an XWEB Pro or AK-SM 800A from the rest of the plant network without agents, without re-addressing, and without changing the physical network - each device gets its own enforcement boundary, reachable only by the endpoints you authorize and the users you admit through policy. Lateral movement from a compromised laptop or workstation toward the controller stops at that boundary.Zero Trust for 3rd Party Access gives the OEM's technician a brokered, recorded session to that one controller for that one job, with no VPN and no network presence. When the session ends, so does the access. It also removes the most common reason these interfaces end up on the public internet in the first place - if the vendor's path is brokered, there is nothing to expose.Closed paths do not vet the traveler - a compromised monitoring host or a misused authorized account arrives with legitimate access.That is where&nbsp;Zscaler Deception fits: a decoy that looks like one more controller on the same plant network, which no legitimate system has any reason to touch, so the first wrong move is the alert. Two things make that more than a tripwire. Because nothing legitimate ever talks to the decoy, a hit arrives already interpreted - an authorized source doing something it should not - rather than one more line for an analyst to triage. And because the real controller already sits behind a policy-enforced boundary, the response can be as narrow as the alert - drop the monitoring host's path to the controller, end the account's session - without touching the controller itself. The decoy asks nothing of the real device - no agent, no load, no change - which is the same property that made the boundary workable in the first place. It is still detection: someone, or a policy, has to act on it.None of this replaces the firmware update, and no one should read it that way. Copeland's 1.13 and Danfoss's R4.3.1 still need to be applied. And none of it helps a controller nobody has pulled behind the boundary yet - the thousands of exposed interfaces are exposed because that step has not been taken, not because it is unavailable. What changes is when you have to apply the update and what happens to you in the meantime - a Tuesday you chose rather than a Saturday someone else did.With the boundary in place, the next advisory lands differently. You check what can reach the controller - one monitoring host, two engineers, a brokered vendor path - schedule the firmware for the next planned window, and go back to work. The picture to keep from the demonstration is a display that says everything is fine while the fans are off. The controllers that keep product in spec are the ones with the least tolerance for a bad patch day, and that is why they need the fewest things able to reach them.If you want to work through what this looks like for your own sites, our&nbsp;OT architecture workshop maps the controllers, the vendors who reach them, and the enforcement points you already have. Or, hear from our customers directly on how they use Zscaler for OT security.&nbsp;&nbsp;]]></description>
            <dc:creator>Bryan Ashley (Zero Trust Networking, Principal Architect)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Aligning ITAR Compliance to Zscaler’s Zero Trust Exchanges]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/aligning-itar-compliance-zscaler-s-zero-trust-exchanges</link>
            <guid>https://www.zscaler.com/blogs/product-insights/aligning-itar-compliance-zscaler-s-zero-trust-exchanges</guid>
            <pubDate>Wed, 19 Aug 2026 22:56:05 GMT</pubDate>
            <description><![CDATA[Navigating When to Purchase Commercial, FedRAMP Moderate, and FedRAMP High Platforms to Support ITAR ComplianceITAR violations carry criminal and civil penalties that can result in debarment from federal contracts. This guide maps ITAR compliance requirements to Zscaler's three platform tiers:&nbsp;1)&nbsp;Zscaler Commercial,&nbsp;&nbsp;2)&nbsp;Zscaler FedRAMP Moderate, and&nbsp;3)&nbsp;Zscaler FedRAMP High.Zscaler's FedRAMP Moderate and High platforms support a customer’s ITAR compliance program, with ITAR reports publicly available at zscaler.com/compliance/overview. Organizations handling ITAR-regulated data should understand which platform tier aligns to their specific compliance posture and that, overall, controls remain a customer responsibility regardless of platform selection. Understanding ITAR RequirementsThe International Traffic in Arms Regulations (ITAR), administered by the U.S. Department of State's Directorate of Defense Trade Controls (DDTC), governs the manufacture, export, and brokering of defense articles and related services listed on the United States Munitions List (USML). Before evaluating any cloud security platform, organizations must understand what ITAR demands at the operational level:DDTC Registration:&nbsp;&nbsp;Organizations that manufacture, export, or broker defense articles or defense services must register with the Directorate of Defense Trade Controls (22 CFR Part 122 and Part 129).Access Restricted to U.S. Persons:&nbsp; ITAR-controlled technical data may only be accessed by U.S. persons (citizens, lawful permanent residents, or certain protected individuals) and entities incorporated in the U.S. unless specific DDTC authorization has been granted (22 CFR § 120.62).Deemed Exports: Disclosing or transferring ITAR-controlled technical data to a foreign person, even within the United States, is treated as an export (a 'deemed export') and requires prior DDTC authorization. This is the primary regulatory basis for restricting access to U.S. persons (22 CFR § 120.50).Prohibition on Unauthorized Export:&nbsp; ITAR-controlled technical data may not be exported without prior authorization from the DDTC (22 CFR § 127.1).Release of Technical Data: Under ITAR, technical data is "released" through visual or other inspection of a defense article that reveals technical data to a foreign person, oral or written exchanges with foreign persons, or the use of access information (such as decryption keys or network credentials) that enables a foreign person to access unencrypted technical data. A release to a foreign person constitutes an export under 22 CFR § 120.50 and requires prior DDTC authorization. Organizations using cloud security platforms that inspect, process, or store unencrypted ITAR-controlled technical data must ensure that platform personnel who can access that data in unencrypted form are U.S. persons or that appropriate DDTC authorization is in place (22 CFR § 120.50, 120.55, 120.56).Audit and Continuous Monitoring:&nbsp;&nbsp;DDTC expects organizations to maintain records demonstrating compliance with access controls, data handling policies, and export authorizations. Zscaler's Three Platform TiersZscaler operates three distinct platform environments, each with different compliance postures relevant to ITAR-regulated workloads. Choosing which tier to operate in is a customer responsibility based on their compliance risk tolerance.Zscaler Commercial Platform&nbsp;Zscaler's commercial platform delivers the full Zero Trust Exchange capability set for enterprise customers worldwide. It is cloud-native, operates across a global network of 160+ Points of Presence (PoPs), and is designed to support the security requirements of commercial and multinational companies and organizations.Key Attributes for the Commercial Platform:Compliance:&nbsp;ISO 27001, SOC2 Type 2, CSA STAR Level 2 and other industry and regional compliance certifications, attestations and standards. Please visit Zscaler’s&nbsp;Customer Compliance Center for more information.&nbsp;Locations:&nbsp;US &amp; International.&nbsp;U.S.-person operational support coverage: Support personnel access may include non-U.S. persons, and the platform is not restricted to the U.S.-based infrastructure.Data Types:&nbsp;Suitable for non-ITAR/non-CUI workloads.Zscaler Commercial Platform ITAR PostureOrganizations handling ITAR-regulated technical data should not route that data through commercial-tier nodes without applying additional compensating controls.&nbsp;Organizations that do not handle ITAR-regulated technical data can leverage the commercial platform's full capability set without compliance exposure&nbsp; Zscaler FedRAMP Moderate PlatformZscaler Internet Access (ZIA) and Zscaler Private Access (ZPA) on the FedRAMP Moderate authorized platform are designed for U.S. federal agencies and government contractors processing Controlled Unclassified Information (CUI) at the Moderate baseline. This platform is physically separated from commercial infrastructure and operated with U.S. persons in support roles.Key Attributes of FedRAMP Moderate:Compliance:&nbsp;FedRAMP Moderate, CJIS, IRS 1075 FTI RequirementsLocations: US &amp; International&nbsp;International locations are not enabled by default and require an additional configuration and purchase.&nbsp;U.S.-person operational support coverage:&nbsp;&nbsp;Tier 1 and Tier 2 support personnel accessing government platform environments are subject to screening controls consistent with federal requirements.&nbsp;&nbsp;Technical support provided by personnel from Tier 3 and above may be provided by a mixed population of US- and non-US personnel and may include OCONUS access. Entities managing ITAR-regulated technical data must assess if this operational support coverage aligns with regulatory prohibitions on foreign person access within their unique risk profile.Data Types:&nbsp;Controlled Unclassified Information (CUI) Zscaler FedRAMP High PlatformZscaler's FedRAMP High authorized platform represents the most rigorous compliance posture available within the Zero Trust Exchange. It is designed to protect the government's most sensitive unclassified data and is the recommended environment for organizations with ITAR-regulated technical data, or contractual requirements that demand the highest cloud security baseline.Key attributes of the FedRAMP High platform:Compliance:&nbsp;FedRAMP High, CJIS, IRS 1075 FTI RequirementsLocations:&nbsp;CONUS-only&nbsp;U.S.-Screened Personnel:&nbsp;All access to systems processing customer data on this platform is restricted to screened U.S. persons, consistent with ITAR's foreign person access prohibition.Data Types:&nbsp;Controlled Unclassified Information (CUI)Zscaler FedRAMP High ITAR PostureZscaler's FedRAMP High platform is designed to align with organizations with ITAR-regulated technical data. It is the only Zscaler platform tier for which complete US-person coverage is available. Hundreds of federal agencies and DIB customers currently use Zscaler's FedRAMP authorized platforms to secure their missions.&nbsp; Platform Compliance ComparisonCompliance &amp; CapabilitiesCommercialCloudFedRAMPModerateFedRAMPHighFedRAMP Authorization LevelN/AModerateHighFedRAMP 20x Classification ClassN/AClass CClass DITAR Compliance Report AvailableX✓✓Complete US-person CoverageX/✓U.S.-Person Access Controls&nbsp;(Support Staff)/✓✓U.S. Data SovereigntyX/✓Recommended for ITAR-regulated technical dataXX✓✓ = Supported / Customer Responsibility &nbsp;&nbsp;X = Not Available / No Commitment&nbsp;&nbsp; / = Partial / Risk Acceptance Required&nbsp; Zscaler Capabilities That Can Support ITAR ComplianceThe following capabilities are available across FedRAMP Moderate and High platforms with customer-driven ITAR-relevant configurations.Zero Trust Network Access (ZPA)Unlike legacy VPN architectures, Zscaler Private Access does not expose network topology to users or attackers. ZPA verifies every user and device before access is granted, enforcing least-privilege access to applications, not networks. This eliminates the risk of lateral movement to ITAR-regulated systems and prevents foreign-person attribution through network traffic analysis. ZPA's application-level access model means ITAR technical data remains siloed within authorized application boundaries.Secure Web Gateway (ZIA) with 100% SSL/TLS InspectionZscaler Internet Access performs complete SSL/TLS inspection, including encrypted traffic, without performance degradation. This is operationally critical for ITAR compliance: without full inspection, encrypted exfiltration channels remain a blind spot. ZIA's AI/ML-driven threat detection analyzes over 119 trillion annual transactions to identify and block emerging threats, including those targeting defense-sector organizations.&nbsp;Data Loss Prevention (DLP)Zscaler's DLP capability performs AI-driven content inspection to detect and classify ITAR-regulated technical data, including CAD files, engineering specifications, and defense-related documentation. Inspecting encrypted traffic at scale ensures no blind spots exist for data exfiltration through SSL channels. DLP policies can be configured to block, warn, or log transfers of ITAR-sensitive content, and telemetry feeds directly into audit records required for DDTC compliance demonstration.Cloud Access Security Broker (CASB)Zscaler CASB provides visibility and control over cloud application usage, enabling organizations to detect when ITAR-regulated data is being uploaded to unauthorized cloud services. On FedRAMP Moderate and High platforms, CASB applies ITAR-aware policies, generating the audit record necessary to demonstrate that ITAR technical data is not being transmitted to unauthorized cloud environments or accessed by foreign-person-operated services.Advanced Threat ProtectionNation-state actors routinely target defense contractors handling ITAR-regulated technical data. ZIA blocks an average of 1,700 threats daily and 4.5 billion threats monthly using behavioral analysis and threat intelligence from Zscaler's global sensor network. For DIB organizations, this threat protection layer is the first line of defense against the APT campaigns most likely to pursue ITAR-covered defense technology.FIPS-Validated EncryptionZscaler supports FIPS-validated encryption across all platform tiers. FIPS-validated end-to-end encryption is a primary mechanism to reduce residual risk. However, FIPS-validated encryption should not be used as a substitute for the contractual commitments available on FedRAMP Moderate and High platforms. While properly encrypted data in transit may fall outside the export definition, the carve-out does not eliminate the need for U.S.-person access controls on decryption keys and the underlying data. (22 CFR § 120.54(a)(5))ITAR "Release" Considerations for Cloud Security FeaturesSeveral Zscaler capabilities involve inspecting, analyzing, or processing customer traffic in unencrypted form. When that traffic contains ITAR-controlled technical data, these activities may constitute a "release" of technical data under 22 CFR § 120.56 if platform personnel who are foreign persons can access the unencrypted content. On Zscaler's FedRAMP Moderate and High platforms, support personnel with access to customer environments are screened U.S. persons, which mitigates this risk. On the commercial platform, support personnel may include foreign persons, and Zscaler does not contractually restrict access on a nationality basis. Customers routing ITAR-controlled technical data through any Zscaler platform are responsible for evaluating whether the platform's access controls are sufficient to prevent an unauthorized release under their specific compliance posture.&nbsp; ITAR Requirement MappingTo support customers in leveraging Zscaler to implement ZTNA to meet ITAR requirements, Zscaler provides the following table mapping Zscaler capabilities to some of ITAR’s requirements. This mapping applies to FedRAMP Moderate and High platform deployments.ITAR RequirementZscaler Platform CoverageCustomer ResponsibilityAccess Restricted to U.S. Persons (22 CFR § 120.62)ZIA and ZPA verify identity and device posture before granting application access.FedRAMP Gov platform support staff restricted to screened U.S. persons.ZPA enforces least-privilege access policies.Customers must screen internal users for U.S. person status. Customers must configure ZPA policies to enforce ITAR data access restrictions.Prohibition on Unauthorized Export (22 CFR&nbsp;§&nbsp;127.1)CASB detects and blocks uploads of ITAR data to unauthorized cloud services.DLP identifies and prevents transmission of ITAR-regulated content.ZIA enforces outbound traffic policies.Customers must define DLP policies aligned to their ITAR technical data categories. Customers must obtain and document any required DDTC export authorizations.Data Residency and Transmission ControlsFedRAMP High platform restricts data processing to CONUS infrastructure.FIPS-validated encryption for in-transit data protection.Customers must select FedRAMP Moderate or High platform (not commercial) for ITAR workloads. Customers must document data flows and residency requirements.Audit and Continuous Monitoring (DDTC recordkeeping)ZIA and ZPA generate detailed session logs for audit review.DLP telemetry provides evidence of policy enforcement.CASB reports document cloud application governance posture.Customers must retain logs in accordance with DDTC record retention requirements. Customers must establish continuous monitoring processes aligned to their ITAR compliance program.DDTC Registration and Contractual CommitmentsZscaler provides contractual ITAR commitments on FedRAMP Moderate and High platforms.ITAR compliance reports available at zscaler.com/compliance/overview.Customers must register with DDTC independently.&nbsp; Customers must execute appropriate contractual agreements with Zscaler via the FedRAMP Gov platforms.&nbsp; Choosing the Right Zscaler PlatformThe decision framework for platform selection is straightforward: the nature of the data and the contractual requirements of the organization determine the appropriate platform tier.Select Zscaler FedRAMP High If:Your organization handles ITAR-regulated technical data in the course of normal operations.Your organization handles CUI in the course of normal operations.Your prime contract or government agreement requires a cloud platform with US-person contractual requirements.You need the Zscaler platform that provides the strongest available audit evidence for DDTC compliance demonstration.Select Zscaler FedRAMP Moderate If:Your organization handles ITAR-regulated technical data in the course of normal operations.Your organization handles CUI in the course of normal operations.You are pursuing CMMC Level 2 compliance.You need FedRAMP authorization for civilian agencies or lower-sensitivity government workloads.You are migrating from commercial toward higher compliance posture.Admin Note:&nbsp;Depending on the supported product, technical support provided by personnel from Tier 3 and above may be provided by a mixed population of US- and non-US personnel and may include OCONUS access.Select Zscaler Commercial Platform If:Your organization does not handle&nbsp;ITAR-regulated technical data or&nbsp;CUI at the Moderate or High baseline.You are a commercial enterprise&nbsp;without federal contracting requirements that trigger FedRAMP or ITAR requirements.You require the full commercial capability set, including integrations with the global Azure commercial or AWS commercial ecosystems, and your workloads are not ITAR-restricted. ConclusionITAR compliance in a cloud security context is not a checkbox. It is a continuous operational discipline that begins with selecting the right platform and extends through policy configuration, access governance, audit, and documented risk management.Zscaler's Zero Trust Exchange provides the security architecture and platform tiers necessary to support compliance at every level of the Defense Industrial Base:Zscaler FedRAMP High platform:&nbsp;The highest available unclassified security posture, with contractual ITAR commitments, and FedRAMP authorization. It provides the strongest available controls for organizations processing ITAR-regulated technical data.Zscaler FedRAMP Moderate platform:&nbsp;U.S. government-grade security with ITAR compliance reports for DIB and civilian agency workloads.Zscaler Commercial platform:&nbsp;Full Zero Trust Exchange capabilities for non-ITAR enterprise workloads.Choosing the right platform, and configuring it correctly, is a risk decision that belongs to the customer. Zscaler's Federal and Defense segment is positioned to support that decision through platform guidance, compliance documentation, and field advisory engagement with CISOs, CIOs, and compliance officers across the Defense Industrial Base.This guide is for informational purposes only and does not constitute legal or export-control advice. Information is current as of&nbsp;August 19, 2026 and subject to change. Zscaler makes no representations or warranties regarding the applicability of this guide to any organization’s specific compliance requirements. Consult qualified export-control counsel before making platform or compliance decisions based on this guide.]]></description>
            <dc:creator>Jeffrey Adorno (Director, Emerging Technology)</dc:creator>
        </item>
        <item>
            <title><![CDATA[Securing the Unsecurable: OT, IoT, and the Factory Floor]]></title>
            <link>https://www.zscaler.com/blogs/product-insights/securing-unsecurable-ot-iot-and-factory-floor</link>
            <guid>https://www.zscaler.com/blogs/product-insights/securing-unsecurable-ot-iot-and-factory-floor</guid>
            <pubDate>Mon, 17 Aug 2026 21:57:14 GMT</pubDate>
            <description><![CDATA[Modern manufacturing is undergoing a massive shift toward connected operations. We are seeing a flood of advanced IoT sensors and diverse OT systems that drive everything from real-time vibration monitoring to predictive maintenance. This connectivity is the engine for growth, faster supply chain fulfillment, and the kind of innovation that keeps a manufacturer competitive.However, in this environment, uptime and availability are the only metrics that matter. This is the primary lens through which operators are evaluated and plant managers justify their budgets. Operational resilience is the ultimate win, which means security often takes a backseat to anything that might stop the line.&nbsp;This gap has made manufacturing the&nbsp;top target for ransomware. The recent release of Anthropic’s Claude Mythos has fundamentally changed the math for industrial security. Any connected device can be exploited; if it’s reachable, it’s breachable. In OT, you can’t simply "auto-update" to stay ahead of zero day vulnerabilities; patching requires planned outages and rigorous vendor validation to ensure a "fix" doesn't accidentally shut down the plant.&nbsp; How Attacks Move from IT to the Factory FloorMost factory breaches don’t start on the factory floor. In reality, they almost always start in IT. Attackers look for the low-hanging fruit, i.e. a weak VPN, an exposed service, or through remote access. Once they have that foothold, they don't need to break into your OT network; they just use the connectivity you’ve already built. Whether your plants are connected via MPLS, VPNs, or an SD-WAN mesh, the underlying problem is the same: these technologies&nbsp;extend trust,&nbsp;not just connectivity. You might have intended to give a vendor access to one specific machine, but by advertising a subnet over a routed tunnel, you made that entire vlan or zone routable.&nbsp; The Two Highest Impact Ways to&nbsp;Defend Against AI AttacksMinimize your external attack surface - Zscaler Zero Trust Branch (ZTB) creates helps your branches go dark. We remove all inbound listeners. All the traffic comes in and goes out through Zero Trust Exchange ensuring that there is nothing for an attacker to find. If they can’t find you, they can’t exploit you. Period.Kill lateral movement with microsegmentation: You have to assume a threat will eventually get inside, maybe through a compromised vendor laptop. Most factory networks are flat allowing attackers to laterally move within the VLAN.&nbsp;This makes your attack surface as wide as your subnet mask.&nbsp;For example, a /20 subnet mask puts 4000+ devices at risk.&nbsp;&nbsp;Zscaler Zero Trust Branch handles this by creating a&nbsp;"Network-of-One" for every asset. This isolates every device so one compromised machine can't trigger a plant-wide shutdown.&nbsp; Microsegmentation On the Factory FloorSegmentation has been a long-held elusive goal for many OT architects. Compliance and critical infrastructure safety directives make this mandatory to prevent lateral movement of threats. In this blog series, we will examine how microsegmentation can help you eliminate lateral threat movement in complex OT environments where traditional IT tools just won’t work..&nbsp;There are three strategic pillars to doing microsegmentation right:Bridging the Asset Visibility Gap on a Factory FloorMapping the threat landscape and defining your policy framework.Operations and Incident response with Ransomware Kill Switch First Pillar: Asset Visibility&nbsp;Let’s look at the visibility capabilities in four parts:Asset Inventory: Defending OT systems starts with knowing what you have and its risk profile. Zscaler Zero Trust Branch (ZTB) provides AI-powered device discovery and classification that allows you to inventory OT/IoT devices without the need for endpoint agents, scanners, or traffic mirroring. By sitting natively inline, we fingerprint every asset in real-time as traffic flows through the gateway. By combining DHCP fingerprinting, JA3 TLS hashes, and HTTP User Agent analysis with other L2 and L3 data, ZTB builds a multi-dimensional profile of every asset in real-time.Signature-less AI Discovery: Traditional tools usually fail when they hit a device they haven’t seen before because they’re stuck relying on a pre-built signature database. We’ve moved past that. Using AI/ML logic, Zscaler identifies new IoT and OT devices in real-time—even those we’ve never seen before. By analyzing behavioral patterns through DNS names and weblog data, we classify assets based on where they are going and how they behave.&nbsp;Industrial/OT Context: This is where we speak the language of your IoT/OT assets.&nbsp; ZTB decodes the specific protocols used in your environment to understand exactly what a device is. This context allows us to provide vertical-specific intelligence:Industrial &amp; Heavy Equipment: By inspecting OPC UA, Modbus, and ENIP communications, we can fingerprint specific PLCs or SCADA servers.&nbsp;Life Sciences &amp; Medical Manufacturing: We look into DICOM and HL7 traffic to identify sensitive medical imaging systems like MRI, X-ray.Building Automation: We parse BACnet broadcasts to profile HVAC, lighting, and access control systems.Partnership Ecosystem:&nbsp;We know some of you have already invested in specialist visibility tools. We further enrich this discovery by ingesting data from partners like Armis, Ordr, or CrowdStrike. While Zero Trust Branch sees the Rockwell HMI on the wire, a partner like Armis can add deep-layer context such as the OS (Windows CE), and a Risk Level (80). This enriched data becomes the foundation for building precise, automated security policies without doubling your workload.Intelligence via System-Generated Tags All of this data is distilled into System-Generated Tags, which create the base for your microsegmentation policy. This is where you move away from old-school networking constructs like IPs and subnets and start using security context. We tag assets with its Manufacturer, model, and Device Category.By using these tags, your policy becomes human-readable and automated. Instead of writing a complex rule for a specific IP address, you write a policy for "All Rockwell PLCs at Purdue Level 1."In the next blog, we will dive into how Zscaler turns this asset visibility into actionable intelligence starting with Visualization, Threat Mapping, and finally, how to define dynamic groups for creating policies.&nbsp;]]></description>
            <dc:creator>Amit Aneja (Director, Product Management, SD-WAN)</dc:creator>
        </item>
    </channel>
</rss>