Today we’re sharing how Microsoft is closing one of the most dangerous gaps in enterprise security: the window between the moment a vulnerability becomes known and the moment every affected system is patched. That window used to be measured in weeks, and defenders largely got away with it. It is now measured in hours — and the math no longer works in the defender’s favor.
Azure NeuroShield is our answer: an AI-driven, network-enforced virtual patching service for Azure. It continuously reads the world’s vulnerability signal — security bulletins, CVE disclosures, advisories, threat intelligence, and exploit research — and semantically understands what a new vulnerability actually is: the protocol it abuses, the conditions it requires, the blast radius it implies. It correlates that understanding with your Azure estate to determine which workloads are genuinely exposed. And it then autonomously formulates and applies targeted, Azure-native network controls that reduce exploitability — before a software patch is validated and deployed.
The strategic implication is the one that matters most right now: as AI compresses the attacker’s timeline, the durable advantage for defenders is a control plane that can act at the same speed. The network is that control plane. Azure NeuroShield is now available in a limited private preview.
The patch window has collapsed
Traditional vulnerability management rests on an assumption that no longer holds: that defenders can discover, prioritize, test, and deploy a patch before an adversary can weaponize the flaw. For years that assumption was approximately true. It is now breaking in front of us.
The same advances in AI that help defenders reason about code also help attackers. Work that once required a specialist and weeks of effort — reading a disclosure, understanding the exploit preconditions, and building a working exploit — can increasingly be compressed into a fraction of that time. The result is a structural asymmetry. Public disclosures and exploit research propagate globally within hours; remediation across thousands of heterogeneous workloads still takes days or weeks. The most dangerous moment in a vulnerability’s life — after it is known, but before it is patched everywhere — is now wider and more exposed than it has ever been.
Enterprises feel this as four compounding problems:
- Patch latency. Mission-critical systems often cannot be updated immediately. Change windows, dependency testing, and reboot coordination are real constraints, not excuses.
- Exposure sprawl. Large estates span thousands of workloads across regions, operating systems, and configurations. Simply knowing which machines are affected is a hard problem.
- Exploit acceleration. AI-assisted adversaries can operationalize a newly disclosed vulnerability faster than most security operations can triage it.
- Lateral movement risk. Even when external exposure is partially reduced, vulnerable internal systems remain reachable from already-compromised neighbors.
What customers need is not more detection or another prioritized list. They need an autonomous compensating control that can act in the gap — one that understands a new vulnerability, determines which Azure workloads it exposes, and imposes the right restrictions to contain risk with minimal disruption to the business.
Why the network is the fastest control plane
When an endpoint cannot yet defend itself, the network can defend it.
Network-enforced controls are uniquely powerful in the disclosure-to-patch window because they contain exploitation immediately, without waiting for the vulnerable software to be fixed — and even if the endpoint has no fix available at all. By governing both north-south access (traffic entering and leaving the estate) and east-west movement (traffic between workloads), the network becomes the fastest and most reliable place to shrink the blast radius: isolate the vulnerable workload, block the inbound exploit path, and deny the lateral pivot.
This is the core conviction behind Azure NeuroShield. Endpoint-only mitigations are necessary but not sufficient, because they depend on the very system that may already be at risk. The network sits around the workload. It is the control plane that can be reshaped in seconds, at scale, without touching the application — and it is already aligned with how customers architect their Azure environments.
Azure NeuroShield: an AI adaptive shield
Azure NeuroShield is an AI-native protection service for Azure virtual networks that combines three things into a single closed loop: vulnerability intelligence, network context, and Azure-native enforcement.
Think of it as a shield that continuously reshapes itself around your workloads as the threat landscape changes. Rather than relying on static signatures or hand-authored firewall rules, NeuroShield reasons over the meaning of a vulnerability and translates that meaning directly into deployable network policy. It does not stop at “which machines are vulnerable.” It answers the operational question that actually reduces risk: which machines are reachable, from where, through which protocol paths — and what is the smallest, safest control that breaks the exploit?
Enforcement spans a layered mitigation plane built from both existing and new Azure controls:
- Network Security Groups (NSGs) for precise subnet-, NIC-, or VM-level deny and allow controls.
- AgentFabric for workload micro-segmentation, isolation, and containment.
- Azure Firewall with AI/SLM-based anti-malware for unknown-threat protection on the network.
- AI/SLM-based application-layer protection for intelligent inspection above the transport layer.
- A lightweight in-guest VM extension deployed alongside the customer workload, providing the process- and syscall-level granularity needed to isolate exactly the vulnerable interface while leaving everything else running.
Together, these enforcement points let NeuroShield translate vulnerability intelligence into adaptive segmentation, targeted deny policies, quarantine patterns, and containment controls — reducing exploitability before patching is complete, while preserving business continuity as much as possible.
How it works — three semantic layers
The NeuroShield engine is structured as three semantic layers. The design principle is deliberate, and it is the most important architectural decision we made: the model is one input; the system is the product. Frontier models improve every few months. A system whose value is gated on a single model has to be rebuilt every time the frontier moves. NeuroShield’s layers are model-agnostic by construction, so the engine can ride the frontier of AI capability while a customer’s investment — scope, context, calibrations, and policy preferences — carries over.
- Layer 1 — Understand the vulnerability. NeuroShield semantically interprets disclosures from sources such as security bulletins, CVE and vulnerability databases, advisories, and exploit research to build a deterministic understanding of the flaw: affected protocols and ports, attack paths, exploit prerequisites, and likely blast radius. It does this with an ensemble of AI models rather than any single one — large, frontier models for the hardest reasoning, working alongside hyper-efficient, purpose-built small models that we engineer ourselves for high-volume, domain-specific passes — and uses them together to build and continuously refresh the semantic knowledge base that powers the rest of the engine. The goal is not to summarize the text; it is to extract the machine-actionable conditions under which the vulnerability can be reached.
- Layer 2 — Correlate with the estate. It correlates that understanding with signals from across your Azure environment — VM inventory, virtual network topology, subnets, NICs, exposed endpoints, running processes and open ports, installed software, patch state, and the relationships in the network graph — to identify the specific attack surface that needs to be reduced. This is where “a vulnerability exists” becomes “these workloads are exposed, by this path, from these sources.”
- Layer 3 — Formulate and enforce mitigation. It translates the analysis into action — and this goes well beyond emitting a command. NeuroShield determines the right network-level response for each vulnerability and enforces it directly: applying micro-segmentation and other Azure-native network security capabilities to isolate the affected workloads on the network and contain the specific exploit path, using the mitigation best matched to that vulnerability. Every action carries an associated confidence level and rollback guidance. Based on the mitigation type and confidence, NeuroShield can require explicit customer confirmation — and it lets customers express a preference between maximizing business continuity and maximizing security posture. High-confidence, low-impact controls can be applied autonomously; higher-impact actions can be staged for approval.
The in-guest enforcement substrate is built on proven, open foundations — eBPF-based runtime instrumentation from the cloud-native ecosystem — so that the same extension that maps attack surface can, over time, enforce isolation at multiple altitudes: at the network, at the process, at the virtual machine, or even at the file system and folder level.
Evidence at scale: six months of in-the-wild zero-days
Vision is easy to assert and hard to substantiate. So we tested the premise against the hardest possible evidence: vulnerabilities that were actually exploited in the wild.
We took the U.S. Cybersecurity and Infrastructure Security Agency (CISA) Known Exploited Vulnerabilities catalog for a recent six-month window — 133 in-the-wild-exploited CVEs — and ran a per-CVE triage asking a single, disciplined question: for each one, could at least one network-enforced control have meaningfully reduced exploitability before a patch was available?
| Enforcement class | What it does | Count | % of 133 |
|---|---|---|---|
| A. North-south NSG / Azure Firewall | Perimeter and management-plane segmentation, port denies, egress allowlists | 22 | 16.5% |
| B. In-guest VM extension | Local privilege escalation, sandbox escape, renderer post-stage, host-side confinement | 29 | 21.8% |
| C. Traditional WAF | Signature-tractable HTTP: command injection, SQLi, path traversal, XSS/RFI, login virtual-patch | 28 | 21.1% |
| D. AI/SLM known-threat protection | Deserialization gadgets, file-format and structural attacks, code-eval intent, inline binary analysis of tampered updates/archives/PDFs | 25 | 18.8% |
| E. East-west micro-segmentation | Intra-VNet workload pinning — pivot containment, lateral-movement denial | 7 | 5.3% |
| None — out of scope | Apple endpoints, mobile silicon, sealed non-Azure hardware | 22 | 16.5% |
| Total covered | 111 / 133 | 83.5% |
There is a forward-looking signal hidden in this distribution. The three classes that scale with the AI-era attack surface — in-guest enforcement (B), AI/SLM known-threat protection (D), and east-west micro-segmentation (E) — together account for 45.9% of every in-the-wild vulnerability in the window. As AI expands the agentic and AI-workload attack surface, this is precisely where the defense will increasingly need to live, and these are the planes NeuroShield is purpose-built to enforce. The full per-CVE analysis is available to all NeuroShield customers.
Two deep dives
Coverage statistics describe the forest. To see what semantic, network-enforced virtual patching actually does, it helps to walk two examples that look nothing alike — an application-layer denial-of-service that hides inside perfectly well-formed traffic, and a network-reachable privilege escalation. They are deliberately different, because the point of NeuroShield is that the right compensating control depends on understanding the specific exploit path, not on applying a generic rule.
An application-layer protocol abuse: HTTP/2 “MadeYouReset”
Consider a denial-of-service vulnerability in the HTTP/2 protocol of the kind disclosed as “MadeYouReset” (CVE-2025-8671) — a subtle evolution of the 2023 HTTP/2 Rapid Reset attack (CVE-2023-44487). In Rapid Reset, a client floods the server with RST_STREAM frames, cancelling streams faster than the server can free them. MadeYouReset is sneakier: the client never sends a single RST_STREAM. Instead it sends frames that are individually well-formed but violate protocol state in subtle ways — a WINDOW_UPDATE that overflows the flow-control window past 2³¹−1, a WINDOW_UPDATE with a zero increment, HEADERS or DATA on a half-closed stream, or a PRIORITY frame of the wrong length. Per RFC 9113, the server must answer each of these with a server-issued RST_STREAM — so the attacker tricks the server into resetting its own streams. Because a server-reset stream is counted as closed even while backend processing continues, the attacker drives an unbounded number of concurrent streams on a single connection, exhausting CPU and memory until the service falls over. The technique affects widely used stacks including Netty, Jetty, Apache Tomcat, IBM WebSphere, and BIG-IP.
- Vulnerability awareness. Layer 1 understands that this is not a client-side reset flood but a server-triggered one: the malicious signal is a pattern of protocol-violating frames (malformed
WINDOW_UPDATE, wrong-lengthPRIORITY, writes to half-closed streams) that coerce the server into issuing resets, while the visible stream count stays under the negotiated limit. Crucially, it understands that the defenses built for Rapid Reset — which look for a flood of clientRST_STREAMframes — do not apply here, because every frame the client sends is syntactically valid and there is no client reset to count. - Fleet correlation. Layer 2 correlates the advisory with the Azure estate to find workloads that terminate HTTP/2 — internet-facing web front ends, API gateways, and reverse proxies running affected server stacks — and maps, from the network graph, which of them accept HTTP/2 from untrusted north-south sources versus only from trusted internal peers.
- Autonomous policy generation. Because the exploit is reachable over the network and abuses protocol state rather than any single bad packet, NeuroShield combines application-layer reasoning with connection-level controls. It generates policy to: rate-limit protocol-level errors and server-issued resets per connection (not just client resets); cap the number of concurrent and newly created streams per connection; deploy AI/SLM application-layer inspection that recognizes the MadeYouReset frame pattern — anomalous
WINDOW_UPDATEincrements, wrong-lengthPRIORITYframes, and frames sent to half-closed streams — as malicious even though each frame is individually valid; and micro-segment the affected front ends so the HTTP/2 listener is reachable only from the sources that legitimately need it. - Enforcement, scoped to the workload. NeuroShield enforces this through a layered plane: Azure Firewall and AI/SLM application-layer protection inspect and rate-limit the north-south HTTP/2 path at the edge, while the in-guest extension applies connection-level limits on protocol errors and concurrent streams at the affected process — so a single misbehaving connection is throttled or dropped without penalizing legitimate clients sharing the same front end.
- Outcome. The amplification loop is broken: the server stops being tricked into unbounded self-resets, concurrent-stream growth is bounded, and the workload keeps serving legitimate traffic while administrators roll out the vendor patch on their own schedule. This is network-based virtual patching for an application-layer protocol abuse — neutralizing the exploit’s mechanics before the HTTP/2 stack itself is fixed.
A remote network vulnerability: RDP elevation of privilege
Now consider a Remote Desktop Protocol elevation-of-privilege vulnerability of the kind described in Microsoft Security Bulletin MS16-017 (CVE-2016-0036), where an attacker with an authenticated RDP connection sends specially crafted data and gains code execution with elevated privileges. Here is how NeuroShield would operate:
- Vulnerability awareness. From the bulletin, Layer 1 understands that the flaw is associated with RDP, specifically traffic over TCP port 3389, and that the exploit path depends on systems reachable via RDP.
- Fleet correlation. Layer 2 correlates this with Azure inventory and what the in-guest extension observes to find the affected Windows workloads — for example, the subset of VMs running a vulnerable RDP client/stack version that requires mitigation until patching completes. (The version threshold comes from what NeuroShield observes across the fleet plus its own reasoning; the exploit example is grounded in the real bulletin.)
- Autonomous policy generation. Because the exploit path is network-reachable, the fastest compensating control is to restrict RDP reachability to exactly those workloads. NeuroShield generates targeted policy to block inbound TCP 3389 or enforce Network Level Authentication; limit east-west RDP between peer VNets, subnets, and workload tiers to prevent lateral movement; limit north-south RDP from internet-facing or hybrid ingress paths; and preserve tightly scoped administrative exceptions where explicitly required.
- Enforcement, scoped to blast radius. Depending on scope, NeuroShield picks the right plane. It can constrain the attack surface down to a single process inside the VM using the in-guest extension — blocking inbound 3389 for only the specific vulnerable process and enforcing NLA — rather than bluntly closing the port for the whole machine.
- Outcome. External RDP exposure is removed, internal RDP pathways are restricted, lateral movement opportunities collapse, and administrators get the time to patch deliberately. This is network-based virtual patching: reducing exploitability immediately, before software remediation is complete.
Why signatures and manual rules fall short
These two examples are characteristic of what a semantic, AI-driven system does that static defenses cannot.
A traditional signature defense waits for a known-bad pattern. But on the day a vulnerability is disclosed, there is no signature — and an AI-assisted adversary may produce a working exploit before one exists. Worse, some attacks are invisible to signatures by design: in the HTTP/2 case, every individual frame the attacker sends is perfectly well-formed and within spec, and the defenses written for the earlier Rapid Reset attack — which count client resets — never fire. Catching it requires understanding the protocol state being abused, not matching a byte pattern. A manual firewall change fares no better: it depends on a human reading the advisory, reasoning about exposure, authoring the rule, and pushing it through change control — exactly the slow path the attacker is racing against.
The harder truth is that the right control is different every time, and choosing it requires understanding the vulnerability’s mechanics. The RDP case is solved by reasoning about reachability over a network port. The HTTP/2 case has a port that must stay open — you cannot simply block web traffic — and is solved only by reasoning about protocol behavior and bounding it at the connection and process level. A blunt instrument that “just blocks a port” would have been useless for one and far too broad for the other. Translating a disclosure into the smallest control that breaks the exploit while preserving the business is a reasoning problem — and it is the problem NeuroShield is built to solve, at machine speed, across an entire estate.
What this means for defenders
Three implications follow, and they generalize beyond any single product.
- The disclosure-to-patch window is now a control-plane problem, not just a patching problem. You cannot patch your way out of an asymmetry where exploitation is measured in hours and safe remediation in days. You need a compensating control that acts in the gap. The network is the most immediate, most reliable place to put it.
- The value is in the system around the model, not the model alone. Semantic understanding is necessary, but understanding without enforcement is just a better report. NeuroShield’s worth comes from the closed loop — understand, correlate, decide, enforce, and roll back — and from the fact that this loop is model-agnostic, so it absorbs every improvement in frontier AI without being rebuilt around it.
- Containment matters as much as exposure reduction. Blocking the front door is not enough when the adversary is already inside. Reasoning over the network graph — north-south and east-west — is what turns “we reduced inbound exposure” into “we isolated the vulnerable asset and denied the pivot.”
Where we’re headed
NeuroShield’s initial scope protects Azure Virtual Machines and Virtual Machine Scale Sets, with the in-guest extension first operating in an observation mode to map running processes, open ports, firewall rules, installed applications, and patch state — the foundation for understanding attack surface.
The trajectory is toward ever-finer granularity. Over time, NeuroShield evolves from protecting vulnerable workloads at the machine level to protecting specific vulnerable processes inside them — enforcing policy based on process awareness, exploit behavior, and runtime risk posture. The destination is a genuinely adaptive shield: one that reshapes itself continuously around exactly what is at risk, at exactly the right altitude, and no more.
Conclusion
We are at a moment where AI is rewriting the economics of attack. The honest response is not to pretend patching will get fast enough to compensate — it is to give defenders a control plane that can move at the same speed the threat does.
Azure NeuroShield is that control plane: an AI-powered, network-enforced adaptive shield that turns vulnerability awareness into immediate, policy-driven protection, shrinks attack surface as the threat landscape shifts, and gives security teams the one thing the collapsing patch window has taken away — time. It is our commitment to protect Azure customers pre-emptively, proactively, and at machine speed.
Azure NeuroShield is in limited private preview
Be among the first to put an AI-powered, network-enforced adaptive shield in front of your Azure workloads. Learn more and request access.
Request private previewWith thanks to the engineering, research, and design teams across Azure Core Networking who are building NeuroShield.