Upwind Adds Windows Server VM Runtime Protection on AWS, Azure, and Google Cloud

Upwind announced on May 5, 2026, that its runtime protection and visibility platform now supports Windows Server virtual machines running Windows Server 2016 or later across Amazon EC2, Google Cloud Compute, and Microsoft Azure VMs. That is a product update, but it lands in a market argument that has been building for years: cloud security cannot keep treating Windows Server as the awkward legacy appendix to a Linux-and-container story. The move matters because the workloads least likely to look fashionable are often the ones most likely to hold identity, databases, and internal business logic. Runtime security is becoming less about cloud-native purity and more about admitting what enterprises actually run.

The Cloud Never Stopped Running Windows​

For all the industry’s Kubernetes triumphalism, the public cloud is still full of Windows Server. It runs Active Directory-dependent services, .NET Framework applications, SQL Server back ends, scheduled jobs, file services, and commercial software that refuses to disappear just because platform teams discovered Helm charts. If anything, cloud migration often preserved these systems by lifting them into virtual machines rather than forcing painful rewrites.
That history matters because security tooling has frequently followed the hype curve rather than the estate. Linux hosts, containers, Kubernetes clusters, and serverless services became the proving ground for modern cloud detection and response. Windows Server VMs, meanwhile, were often covered by a mixture of endpoint agents, vulnerability scanners, cloud posture checks, and institutional memory.
Upwind’s expansion is therefore less surprising than overdue. The company is not claiming Windows Server suddenly became important; it is acknowledging that runtime visibility has to follow enterprise gravity. If a cloud security platform cannot see a Windows VM’s process activity, network connections, and DNS behavior, it is not seeing the whole cloud.
This is the uncomfortable middle ground many security teams occupy. Their architecture diagrams say “cloud-native,” but their incident response plans still contain servers with names that look like they were coined during a datacenter consolidation project in 2014. The operational reality is hybrid, multi-cloud, and deeply uneven.

---

Runtime Context Is the New Security Boundary​

The old cloud security model prized inventory and configuration. Find the assets, inspect the settings, compare them to benchmarks, and generate a backlog. That model remains useful, but it has a fatal limitation: it tells defenders what an environment could do, not what it is doing.
Runtime security tries to close that gap. It asks whether a workload is making unusual outbound connections, resolving unexpected domains, launching suspicious processes, or communicating with systems it has no business touching. In a breach, those signals are often more meaningful than another static misconfiguration finding buried in a dashboard.
Upwind’s Windows Sensor is aimed squarely at that gap. The company says it collects host activity from Windows servers, including process execution, network connections, and DNS requests, and feeds that telemetry into its Runtime Map, detections, and sensor management workflows. It also adds continuous assessment for vulnerabilities and configuration issues.
The important phrase here is not “Windows Sensor.” It is same workflow. Security teams do not need yet another isolated console that knows only about one class of machine. They need Windows workloads to appear beside Linux hosts, containers, and cloud resources in the same operational picture.
That is the promise, at least. The risk is that “single pane of glass” becomes the oldest cliché in enterprise software: a bigger pane with more cracks. The value of Upwind’s Windows support will depend on how well it correlates Windows telemetry with cloud context, identity context, exposure, and reachable attack paths.

Windows Server Is a Blind Spot Because It Is Familiar​

The industry tends to call unfamiliar things risky. In practice, familiar systems are often more dangerous because everyone assumes someone else is watching them. Windows Server has lived inside enterprise security programs for decades, which can create the illusion that coverage is already solved.
But cloud-hosted Windows VMs are not simply datacenter servers with a different billing model. They inherit cloud identity, cloud networking, ephemeral infrastructure patterns, snapshotting, automation, and internet-adjacent exposure. A VM that once sat behind layers of corporate network convention may now live inside a sprawling multi-account or multi-subscription estate.
That shift changes the defender’s problem. Knowing that a Windows Server exists in Azure, AWS, or Google Cloud is the beginning of the story, not the end. Security teams need to understand whether it is talking to a database, an identity provider, a suspicious external address, or a forgotten application tier nobody owns anymore.
Runtime telemetry gives that conversation evidence. Process activity can show whether a service account is being abused. DNS activity can expose command-and-control patterns or misconfigured applications. Network connections can reveal lateral movement paths that configuration review alone may miss.
This is why Windows visibility matters even when endpoint detection and response tools are already deployed. EDR products are built around endpoint and host defense; cloud runtime platforms are trying to connect host behavior to cloud topology and risk prioritization. The overlap is real, but so is the difference in perspective.

Upwind Is Chasing the CNAPP Market’s Harder Second Act​

Cloud-native application protection platforms, or CNAPPs, spent their first act promising consolidation. Instead of buying separate tools for posture management, workload protection, vulnerability management, identity risk, and detection, enterprises could move toward a platform. That story was attractive because cloud security tooling had become as fragmented as the environments it was meant to protect.
The second act is harder. A CNAPP that finds misconfigurations is useful; a CNAPP that prioritizes them based on live runtime behavior is more valuable. The difference is whether the platform can distinguish between a theoretical risk and an actively reachable, actively used, actively suspicious asset.
Upwind has positioned itself around runtime from the beginning. Its broader documentation and messaging emphasize a shift-right model in which production behavior informs detection, prioritization, and response. The Windows expansion extends that posture into the part of the estate that many “cloud-native” tools would rather not foreground.
This also places Upwind in a competitive field where runtime is becoming a must-have rather than a differentiator. Wiz, Palo Alto Networks, CrowdStrike, Microsoft, Orca, Lacework, Datadog, and others all orbit adjacent parts of the cloud security market, though with different architectures and emphases. In 2026, simply saying “runtime” is no longer enough.
The interesting competition is not between agent and agentless as slogans. It is between platforms that can turn telemetry into operational decisions and platforms that merely generate better-decorated alert queues. Windows support is one more test of whether runtime context can scale across the messy platforms enterprises actually use.

---

The Sensor Debate Comes Back to Earth​

Runtime protection usually means installing something. That immediately reopens one of security’s longest-running arguments: agents versus agentless visibility. Agentless scanning is easier to deploy and politically easier to sell; agents can see behavior in motion but introduce operational overhead, compatibility questions, and change-management friction.
Windows Server makes that debate more pointed. Many enterprises are cautious about adding agents to production Windows workloads, particularly if those systems support identity services, databases, financial applications, or brittle vendor software. A sensor that behaves well on a fleet of cloud Linux hosts may still need to prove itself in Windows environments shaped by patch windows and application owners with long memories.
Upwind’s pitch is that Windows VM sensors appear in its Components view for monitoring, patching, and tracking, reducing the need for separate operational tooling. That is a sensible control-plane argument. But deployment is not just a UI problem; it is a trust problem.
Security teams will ask predictable questions. What privileges does the sensor require? What telemetry leaves the host? How does it behave during CPU, memory, or I/O pressure? What happens if the sensor fails? How quickly can it be updated when Microsoft changes something in Windows Server or when a new detection capability ships?
Those questions do not weaken the case for runtime visibility. They define the work required to make it credible. A runtime sensor protecting a server estate must be boring in precisely the ways production engineers value: stable, observable, controllable, and reversible.

Multi-Cloud Support Is Table Stakes, Not a Victory Lap​

Upwind says the Windows Server VM support spans AWS, Google Cloud, and Microsoft Azure. That coverage is necessary because enterprise Windows workloads are not confined to Azure, even if Microsoft’s cloud has obvious gravitational pull. AWS still hosts vast numbers of Windows applications, and Google Cloud continues to court enterprise migrations and analytics-heavy environments where Windows systems may sit beside modern data platforms.
Multi-cloud support, however, is not automatically multi-cloud usefulness. The hard part is normalizing different cloud metadata, network constructs, identity models, and asset relationships without flattening away the details that matter during an investigation. A Windows VM in EC2, a Windows VM in Azure, and a Windows VM in Google Cloud are all Windows hosts, but their surrounding control planes are not interchangeable.
Runtime mapping is where this becomes consequential. If a Windows server makes a strange outbound connection, the analyst needs more than a host name and a process tree. They need to know the cloud account or subscription, security group or network security group, identity permissions, exposed services, adjacent resources, and whether the observed behavior is normal for that workload.
Upwind’s Runtime Map is meant to visualize assets and their connections across cloud environments. Bringing Windows VMs into that map could help reduce one of the most common sources of investigative drag: the moment when analysts leave one tool to figure out whether a host is important, another to check its network path, and another to understand ownership.
That said, maps can seduce as much as they inform. A beautiful graph is not a detection strategy. The value lies in whether the map shortens the path from suspicious behavior to confident action.

Vulnerability Prioritization Needs Runtime More Than Ever​

Every security team knows the vulnerability backlog problem. Scanners produce mountains of findings; patching capacity is finite; business owners resist downtime; and severity scores alone rarely tell defenders what to fix first. The result is a grim ritual in which critical vulnerabilities pile up until the next audit, incident, or executive review.
Runtime context offers a more useful hierarchy. A vulnerable Windows Server VM that is active, exposed, communicating with sensitive systems, and running the affected component deserves different treatment from a dormant machine in a segmented environment. The vulnerability may be the same on paper, but the risk is not.
Upwind’s Windows support includes continuous scanning for vulnerabilities and configuration issues, with prioritization based on active cloud assets and runtime context. This is the right direction because it connects exposure to behavior. The question is whether the platform can make that prioritization transparent enough for security and operations teams to trust.
Opaque risk scores are a recurring problem in security products. They may be useful for dashboards, but they can fail in change-advisory meetings where someone asks why a patch must happen this weekend. Runtime-informed prioritization works best when it can show its work: this process is running, this port is reachable, this domain was contacted, this asset talks to that database, and this vulnerability is therefore not hypothetical.
Windows estates particularly need that clarity. Many Windows workloads carry business-critical dependencies and slower patch cycles. If runtime data can help teams patch the riskiest systems first without pretending every CVE is equally urgent, it will have practical value beyond detection.

---

The Real Rival Is Not Another Vendor, But Tool Sprawl​

It is tempting to frame Upwind’s move as another skirmish in the CNAPP wars. That is true at the market level, but less useful for practitioners. For a security team, the immediate rival is not Wiz or Microsoft or CrowdStrike; it is the sprawling set of tools already producing partial truths.
One product may know the VM exists. Another may know it is vulnerable. A third may know a process launched. A fourth may know an identity has broad permissions. A fifth may show network flow logs. During an incident, the analyst becomes the integration layer.
The promise of bringing Windows Server VMs into Upwind’s existing runtime workflows is that it reduces that fragmentation. Windows machines can appear in the same map, detection logic, and sensor management view as other cloud assets. If that works, the operational win is not merely more telemetry; it is fewer blind handoffs.
But consolidation has a cost. Platforms become powerful when they integrate signals, and dangerous when they become the only place those signals are interpreted. Mature teams will want Upwind’s telemetry to flow into SIEM, SOAR, ticketing, data lake, and incident response systems rather than remain trapped inside a proprietary workflow.
That is especially true in Windows-heavy environments where Microsoft Defender, Sentinel, Entra ID, Active Directory logs, and endpoint telemetry may already play central roles. Upwind does not need to replace those systems to matter. It needs to add cloud-runtime context they may not provide in the same way.

Windows Security Is Becoming a Cloud Posture Problem​

Windows Server security has historically been discussed in terms of patching, hardening, endpoint defense, and identity hygiene. In the cloud, those disciplines still matter, but they are no longer enough. The server’s risk is shaped by the cloud environment around it.
A Windows VM with a vulnerable service is one kind of problem. A Windows VM with a vulnerable service, a permissive security group, broad managed identity permissions, and live connections to production data is another. Runtime visibility makes those combinations harder to ignore.
This is the direction cloud security has been moving for years. The industry is slowly shifting from isolated findings to attack-path thinking. A misconfiguration is not just a misconfiguration; it is a possible step in a chain. A vulnerable package is not just a CVE; it is a possible opening if the workload is reachable and active.
For Windows Server, that shift is overdue. Traditional enterprise systems often sit at the intersection of identity, data, and business process. When they move to public cloud, they bring their importance with them, but not always the visibility that surrounded them on-premises.
Upwind’s announcement should be read in that context. It is not merely adding a supported operating system. It is making a claim that Windows VMs belong inside the same runtime risk model as containers, Linux hosts, and cloud-native services.

Security Teams Will Judge the Feature During Incidents​

Product announcements are written in the language of coverage. Incident response is written in the language of time. The real test for Upwind’s Windows Sensor will come when an analyst is trying to decide whether a Windows VM is compromised, what it touched, and what to do next.
In that moment, process execution telemetry is valuable only if it is timely, searchable, and correlated. Network connection data is valuable only if it can distinguish expected application behavior from suspicious movement. DNS telemetry is valuable only if it helps separate noisy enterprise software from genuinely strange resolution patterns.
The promise of real-time detections is that the platform can identify behavior indicating compromise, misuse, lateral movement, or other risk. The danger is alert inflation. Windows servers are busy, chatty, and often full of vendor agents, scheduled tasks, PowerShell automation, and legacy dependencies that can make behavioral detection messy.
Good runtime security products therefore need strong baselining and context. They must understand what is normal for a workload, not just what is generically suspicious. A PowerShell process may be routine on one administrative host and alarming on another. A DNS request may be expected for an application server and bizarre for a domain controller.
Upwind’s broader thesis gives it a plausible path here: combine runtime behavior with cloud asset context. But execution matters more than architecture diagrams. If the platform can reduce time to triage, it will win defenders’ attention; if it adds another stream of unexplained warnings, it will become shelfware with a better data model.

---

The Windows Server 2016 Cutoff Tells Its Own Story​

Support begins with Windows Server 2016 or later. That is a reasonable technical boundary, but it also underscores the age profile of enterprise infrastructure. Windows Server 2016 is now a decade-old operating system, yet it remains a practical baseline for many cloud-hosted workloads.
This is the quiet reality behind much of enterprise modernization. Organizations may talk about platform engineering and immutable infrastructure, but they still operate long-lived servers because applications, licensing, vendor support, and business risk move slowly. Security vendors that ignore this reality end up building elegant tools for only part of the estate.
The cutoff also leaves a harder problem outside the announcement. Older Windows Server versions still exist in the wild, often because the application running on them is hard to move. Upwind’s cloud scanner documentation points to scanning as an option in environments where sensors are challenging or impractical, including legacy OS versions, but runtime protection is a different level of visibility.
That distinction matters. Scanning a disk snapshot can find vulnerabilities, secrets, malware indicators, and misconfigurations. It cannot fully describe live process behavior or real-time network activity. Agentless and snapshot-based approaches are useful, but they do not replace runtime telemetry.
The lesson for IT leaders is blunt: unsupported or sensor-ineligible systems are not just compliance problems. They are observability problems. If an organization cannot monitor what a critical server is doing while it runs, it has accepted a blind spot whether or not it has documented the exception.

Microsoft’s Own Gravity Makes the Market More Complicated​

Any Windows Server security story inevitably runs into Microsoft’s ecosystem. Microsoft controls the operating system, the Azure cloud, Defender for Cloud, Defender for Endpoint, Sentinel, Entra ID, and much of the enterprise identity fabric around Windows workloads. That gives Microsoft enormous advantage in native telemetry and integrated response.
So why would a customer look at Upwind for Windows runtime visibility? The answer is not that Microsoft lacks security products. It is that enterprises rarely live inside one vendor’s clean reference architecture. They run multi-cloud estates, use third-party CNAPPs, maintain multiple SOC workflows, and want risk views that cross Azure boundaries.
Upwind’s value proposition is strongest where Windows workloads are part of a mixed environment. A platform team securing Linux containers in AWS, Kubernetes clusters in Google Cloud, and Windows VMs in Azure does not want three unrelated mental models. It wants a cloud-risk model that can cross operating systems and providers.
Still, Microsoft’s presence raises the bar. Third-party vendors must prove that they add context, speed, or clarity beyond what Microsoft-native tooling can deliver. For Windows-heavy Azure customers, “we support Windows” is not enough; the product must show why its runtime map, detections, prioritization, or multi-cloud correlation materially improves the workflow.
This is where Upwind’s expansion is strategically necessary but not automatically decisive. It gives the company permission to compete for more of the enterprise estate. It does not remove the burden of proving differentiated value.

The Runtime Movement Is Growing Up​

The broader shift toward runtime protection reflects a maturing cloud security market. Early cloud security focused on misconfigured storage buckets, open ports, overprivileged identities, and compliance drift. Those problems did not go away, but attackers adapted to environments where credentials, workloads, APIs, and service-to-service communication define the real attack surface.
Runtime visibility is an answer to that adaptation. It watches the cloud as a living system rather than a collection of configuration files. It can show whether a workload is behaving as designed, being misused, or communicating in ways that suggest compromise.
But runtime is not magic. It can create privacy concerns, performance concerns, and operational concerns. It can overwhelm analysts if detections are poorly tuned. It can become expensive if every workload emits high-volume telemetry without careful filtering and retention strategy.
The better argument for runtime is not that it replaces posture management, vulnerability scanning, or endpoint detection. It is that it gives those disciplines a sense of proportion. Runtime tells defenders which risks are alive.
That is why Windows Server support is symbolically important. It moves runtime protection away from the narrow image of container-first startups protecting container-first companies. It says the model has to work for the boring, durable, business-critical systems that keep enterprises running.

---

The Announcement Is Small Only If You Ignore the Estate​

The practical facts of Upwind’s release are straightforward: Windows Server 2016 or later, AWS, Google Cloud, Azure, Runtime Map, detections, Windows Sensor, process telemetry, network telemetry, DNS telemetry, vulnerability and configuration assessment. None of that is revolutionary by itself. The argument is in the combination.
For WindowsForum readers, the significance is that Windows Server is being pulled more firmly into the same runtime-security conversation as Linux and cloud-native workloads. That is where it belongs. A Windows VM running a critical internal app in EC2 is not less “cloud” than a pod running a microservice in Kubernetes; it is simply less fashionable.
The more cloud security platforms acknowledge that, the better the tooling should become. Windows administrators have long lived with a split identity: central to enterprise operations, peripheral to cloud-native marketing. Runtime coverage helps correct that imbalance, provided it respects the operational realities of Windows estates.
There is also a warning here for organizations that still treat cloud Windows servers as migrated infrastructure rather than cloud assets. If a VM is running in a public cloud account, its risk is shaped by cloud networking, identity, exposure, and automation. It should be monitored accordingly.
Upwind’s announcement is not the end of that journey. It is another sign that the market is converging on a simple idea: the most important security context is often what the workload is doing right now.

The Windows Runtime Gap Narrows, But It Does Not Disappear​

This release gives security teams a clearer path to include Windows Server VMs in runtime-aware cloud defense, but it should not be mistaken for a cure-all. The operational value will depend on deployment discipline, integration quality, detection fidelity, and whether teams actually use runtime context to change prioritization and response.
The concrete implications are easy to state:

• Upwind now supports runtime visibility and protection for Windows Server 2016 or later on Amazon EC2, Google Cloud Compute, and Microsoft Azure VMs.
• Windows Server VMs can feed process, network connection, and DNS activity into Upwind’s runtime detection workflows.
• Windows workloads can appear in Upwind’s Runtime Map alongside other cloud assets, giving teams a broader view of relationships and communications.
• The Windows Sensor also supports continuous vulnerability and configuration assessment, which can help prioritize remediation around active assets.
• The release is most valuable for mixed cloud estates where Windows VMs, Linux hosts, containers, and cloud services need to be investigated in one operational context.
• Teams should evaluate sensor overhead, privileges, telemetry handling, and SIEM or SOC integration before treating the feature as production-ready at scale.

The broader message is that Windows Server is not fading quietly out of the cloud security problem. It is embedded in it. Runtime protection vendors are finally being forced to meet the enterprise where it actually lives: not in a pristine cloud-native diagram, but in a mixed estate where last decade’s servers and this year’s platform abstractions share the same attack surface. Upwind’s Windows expansion is a useful step because it treats that mess as the baseline, not the exception, and the next phase of cloud defense will belong to the tools that can make sense of it without pretending it is cleaner than it is.

---

Source: SecurityBrief UK https://securitybrief.co.uk/story/upwind-expands-runtime-protection-to-windows-server-vms/