On August 19, Palo Alto Networks announced the Frontier AI Critical Defense Program, a coalition spanning operational technology, healthcare, commercial software, and open source communities. The stated mechanism is deploying proactive virtual patches that neutralize vulnerabilities at the network level before attackers can exploit them. Existing collaborations include IBM and Red Hat, Microsoft through MAPP, Siemens, and Idaho National Laboratory, with Anthropic, OpenAI, Mitsubishi, Axis Communications, Health-ISAC, EPRI, and others joining.
The number in the release is significant: Frontier AI models identified more than 14,000 previously unknown vulnerabilities across open source projects.
Every one of those was unknown the day before someone found it. That is why this program exists, but also the reason virtual patching cannot be the only control in the environment.
Virtual Patching Is a Real Answer for Operational Technology
Virtual patching is a security technique that protects systems from exploits without modifying source code. Rather than changing the vulnerable software, it intercepts incoming traffic and blocks malicious payloads targeting a known flaw. Implementation typically runs through a web application firewall or an intrusion prevention system, a form of network virtualization technology that applies rules recognizing exploit attempts before they reach the vulnerable component. Security teams get coverage for software vulnerabilities without touching the software.
The value is timing: traditional patching requires extensive testing and usually a reboot, which means downtime. Virtual patching provides immediate protection while an official patch is tested and staged, and it mitigates the risk of immediate exploitation for zero-day vulnerabilities where no vendor fix exists yet.
For operational technology, that timing difference is the difference between having a control and having nothing. OT assets often have lifecycles of 15 to 30 years or more. Programmable logic controllers, distributed control systems, and SCADA systems handling supervisory control and data acquisition run physical processes on firmware that may predate the security team. Many no longer receive official updates from vendors at all. Taking a production line down to patch a controller is a scheduling negotiation measured in quarters instead of afternoons.
Virtual patching works in that environment because it does not touch the vulnerable system. Anyone selling OT security without an answer here is not serious, and Palo Alto's program is a serious answer.
Where Virtual Patching Holds in Critical Infrastructure
OT systems control critical infrastructure like power grids, water utilities, and emergency services. The consequences of a successful intrusion go beyond the exposure of sensitive data. Cyberattacks on OT can disrupt operations, cause significant revenue losses, and create physical safety risks that no amount of incident response will undo after the fact.
Fortinet's 2026 State of Operational Technology and Cybersecurity Report, based on more than 700 OT professionals, found 71% of respondents reporting between one and nine attacks in the past year, up from 47%. Phishing appeared in 76% of reported intrusions and ransomware in 50%. Fortinet attributes much of the increase to better detection rather than a genuine rise in volume, which is its own kind of finding: security teams are seeing more because they were previously seeing less.
When a vulnerability is known, a signature exists, and network traffic routes through the inspection point, virtual patching stops the exploit without touching the vulnerable equipment. That is a good outcome, and for legacy systems it is frequently the only outcome available. It buys the window that the vulnerability management process needs.
The Sequence Virtual Patching Depends On
Vulnerability management comprises five overlapping workflows. Discovery assesses IT assets for known security vulnerabilities. Prioritization ranks them, typically using the Common Vulnerability Scoring System maintained by FIRST, which is what risk-based vulnerability management uses to decide which critical vulnerabilities move first. Resolution applies patching, configuration changes, or mitigation to resolve vulnerabilities; reassessment confirms the fix worked; reporting tracks metrics like mean time to detect.
Virtual patching sits inside resolution as a mitigation, and it inherits everything upstream of it. Somebody has to identify vulnerabilities first, and confirmed exploitation has to surface somewhere like CISA's Known Exploited Vulnerabilities catalog before it drives prioritization. Vulnerability scanners have to reach the asset. A vulnerability assessment has to produce intelligence specific enough to write a rule against. Someone has to deploy that rule to the right enforcement point, and the malicious traffic has to cross that point.
These are the five dependencies, and any one of them failing means the virtual patch is not there. Palo Alto's release describes the approach as combining Frontier AI threat discovery with trusted vulnerability intelligence, which is an accurate description of a process that starts with knowing.
There is a second cost. Virtual patching requires monitoring and configuration to avoid false positives affecting legitimate user traffic. Rules written broadly enough to catch exploit variants will sometimes catch production systems doing normal work, and in an OT environment a false positive that blocks a control message is not a nuisance. Network security teams tune these rules continuously, which is real operational overhead on top of every other demand on their security efforts.
And virtual patching does not remove the underlying vulnerability in the source code. The flaw is still there; the exploit path to it is filtered.
Network Security for the Vulnerabilities Nobody Has Found Yet
Return to the 14,000 number. Frontier AI found those in open source projects that thousands of engineers had already read. They were not hidden, but nobody had looked with the right tool.
If AI-assisted discovery works that well for defenders, it works for attackers running the same technique against the same code. Lee Klarich, Palo Alto's chief product officer, said in the release that the reactive patching race is "a losing battle." He's right, and the observation goes further than the program does. Virtual patching runs faster in that race, but it does not leave it.
Network security that depends on recognizing an exploit can only recognize exploits somebody has already characterized. New vulnerabilities are discovered every day, and the gap between what exists and what has been catalogued is where an attacker operates. Threat detection, threat intelligence, and vulnerability scanners all share that constraint. They are looking for security flaws that have names, which leaves evolving threats and newly written exploits outside what any of these security solutions can recognize.
The alternative is a control that does not need the name.
Network Segmentation and the Question of Reach
Network segmentation asks a different question than any detection control. Not whether this traffic is malicious, but whether this system should be able to talk to that system at all.
Microsegmentation isolates workloads with custom security policies, which limits lateral movement of threats once something is inside. It provides visibility into all network traffic across clouds and allows dynamic adaptation of security policies in real time as the environment changes, so teams can enforce security policies that track the network infrastructure rather than lagging behind it. It works in cloud native architectures like Kubernetes, in data centers, and across cloud environments where virtual machines, cloud workloads, and containers all coexist.
The property that matters is that it holds against unknowns. A compromised system that cannot reach the historian, the engineering workstation, or the safety instrumented system causes limited damage regardless of which vulnerability let the attacker in. Nobody needed to know the CVE; policy never opened the path.
That is the half virtual patching does not cover, and the two are complementary. Virtual patching shrinks the exposure window on vulnerabilities you know about. Containment governs what happens with the ones you do not.
Access Management, Identity, and the OT Network
Identity-based segmentation is where this becomes practical. Traditional access control lists and firewall rules bind policy to IP addresses, which works until addresses change. In cloud environments, they change constantly. In an OT network, they are often assigned by equipment vendors in ways nobody documented.
Writing security policies against workload identity rather than address means the policy survives the change. Access management for OT should follow the same least privilege access principle applied everywhere else: a device gets exactly the connectivity its function requires. A pressure sensor reports to its controller. It does not need to reach the domain controller, and there is no legitimate condition under which it should. Multi-factor authentication protects remote access for engineers and vendors, and the segmentation policy protects everything after authentication succeeds. These are the key principles security leaders should be applying regardless of which vendor supplies the enforcement.
This connects directly to how cloud environments handle the same problem. Aviatrix Zero Trust for AI Workloads resolves Kubernetes pod labels, service accounts, cloud tags, and Lambda ARNs into workload identity, then enforces at every egress point across cloud providers without installing software on the workload. The principle transfers to industrial networks: enforce on what a system is, not where it currently sits.
Network Traffic, Continuous Monitoring, and Industrial Control System Visibility
You cannot segment what you cannot see. An up-to-date inventory of network devices, control systems, and virtual devices is the precondition for any of this, and it is the thing most organizations are missing.
Continuous monitoring of industrial control system traffic serves two purposes here. It builds the dependency map that makes segmentation policy writable, showing which systems actually communicate rather than which ones somebody assumed communicate. And it feeds event management and incident response with the data needed to analyze an intrusion: what this system reached.
Security tools that only inventory at a point in time will drift. Production systems change, vendors add equipment, and the network architecture from the last audit stops matching the network in front of you.
The Industrial Internet Expanded the Attack Surface
The industrial internet connected systems that were designed with the assumption that nobody could reach them. Cloud service provider analytics pull telemetry from plant floors. Remote access lets vendors service equipment without a site visit. Cloud resources process data that used to stay inside the fence.
Each connection is a business decision with a real return, and each one enlarges the attack surface. The consistent security model that worked when OT was isolated does not extend to an environment where IT and OT converge and cloud applications touch physical equipment. Fortinet's 2026 data shows 24% of organizations reporting intrusions in both IT and OT systems, down from 60% the year before, which is progress and still means a quarter of respondents saw an attacker cross that boundary.
Segmentation between IT and OT zones has become a baseline control precisely because that crossing is the pattern. Security best practices from ISA and IEC 62443 have said so for years, and segmentation has the useful property of supporting compliance while improving security posture at the same time. The industrial internet made it urgent.
OT Security Needs Both Halves
Palo Alto built something valuable, and the coalition behind it, with Siemens, Idaho National Laboratory, and industry partners across healthcare and open source, gives it reach that a single vendor could not achieve alone. For organizations running equipment they cannot patch, virtual patching is a genuine control where they previously had none.
Their own research defines the other half. 14,000 unknown vulnerabilities in one effort, in code that was already public. Whatever fraction of those gets a signature written, the rest remain, and new ones arrive continuously.
The question for any OT environment is not which approach to pick, but what a compromised system can reach after something gets through, and whether the answer to that question depends on anyone having identified the vulnerability first. Blast radius is a property of architecture rather than response time.
Frequently Asked Questions
Virtual patching is a security technique that protects a system from exploitation without modifying its source code. It intercepts incoming traffic and blocks payloads targeting a known vulnerability, typically through a web application firewall or intrusion prevention system. The underlying flaw remains in the code. The path to reaching it is filtered.
It protects against exploitation of vulnerabilities that have been discovered, characterized, and turned into a detection rule deployed on a path the traffic actually crosses. It misses vulnerabilities nobody has found yet, exploits for which no signature exists, and any traffic that routes around the inspection point.
Virtual patching evaluates traffic and blocks what matches a known exploit pattern, which requires knowing the vulnerability first. Network segmentation evaluates whether a connection between two systems should exist at all and blocks anything policy did not permit, which does not require knowing anything about the attack.
They address different failure modes and work best in combination. Virtual patching reduces the window during which a known vulnerability is exploitable. Segmentation limits what a compromised system can reach, whether the compromise came through a known vulnerability, an unknown one, or stolen credentials.
OT assets often have lifecycles of 15 to 30 years or more, run physical processes that cannot tolerate unplanned downtime, and frequently run software that no longer receives vendor updates. Patching windows are scheduled around production, not around disclosure timelines, which leaves long periods where a known vulnerability is present with no fix applied.
Assume the vulnerability stays. Build an accurate inventory of what each system communicates with, apply identity based segmentation so every device reaches only what its function requires, and use continuous monitoring to confirm actual network traffic matches policy. Virtual patching then covers the known exploit paths on top of that baseline rather than serving as the only control.
Ready to see Aviatrix in action?
Get a personalized live demo walkthrough or explore our latest deep-dive cloud threat research intelligence.
Gartner Strategic Roadmap for Zero Trust Security Programs 2025 Report
Download and gain actionable insights to advance your cloud security strategy.
