Containing Rogue Devices on the Network: Microsoft Defender for Endpoint’s New IP Containment and How It Stacks Up

Hey Checkyourlogs Fans,

Unmanaged and rogue devices lurking in a corporate network pose a security risk. These could be personal laptops, IoT/OT devices, or compromised systems that lack a security agent, making them “invisible” to traditional endpoint protection. Attackers often exploit unmanaged devices as a foothold to move laterally and spread malware. In response, Microsoft Defender for Endpoint (MDE) has introduced a new capability to “contain IP addresses of undiscovered devices.” This feature essentially allows Defender for Endpoint to quarantine a device by its IP address, even if it is not onboarded to MDE, halting its communication with other endpoints.   More info here: ​learn.microsoft.com.

In this deep dive, we will explain how Microsoft’s IP containment works, when to use it, and the real-world scenarios it addresses (like isolating rogue devices and preventing lateral movement). We will then compare Microsoft’s approach with similar network containment and microsegmentation features from other leading vendors – including Akamai Guardicore, Illumio, CrowdStrike, SentinelOne, and Cisco – and summarize their capabilities in a comparison table. Finally, we’ll use a use case example of isolating a suspicious device using Microsoft Defender for Endpoint’s contain IP feature.

Microsoft Defender for Endpoint: Containing Undiscovered Devices by IP

Microsoft Defender for Endpoint’s new contain-by-IP feature is designed to stop threats from unmanaged or “undiscovered” devices – devices on the network but not onboarded into Defender for Endpoint. Here’s how it works and when to use it:

• How the IP Containment Works: When Defender for Endpoint detects malicious activity from an IP address that does not correspond to any onboarded device, it can automatically apply a “Contain IP” action. This causes all Defender-for-Endpoint-managed hosts (Windows 10 and later, Windows Server 2012 R2 and above) to block incoming and outgoing network traffic to that specific IP. In effect, the rogue device at that IP is virtually isolated from the rest of the protected network – it cannot talk to, or be talked to by, any system defended by MDE. This containment is enforced by the security agent on each managed endpoint, which inserts the necessary firewall rules or filters to drop traffic to/from the malicious IP.
• Automatic Trigger via Threat Detection: MDE’s IP containment is part of Microsoft’s Automatic Attack Disruption capabilities. The system will automatically issue a Contain IP policy when it detects that a specific IP address (unmanaged device) acts maliciously. For example, if telemetry from managed endpoints indicates an unknown IP scanning them or attempting lateral movement, MDE can flag that IP and trigger containment without waiting for manual intervention. This real-time response is crucial in containing fast-moving threats like ransomware. (Administrators can also leverage custom indicators to manually block known bad IPs using MDE’s network IOC feature, which similarly causes endpoints to reject traffic to those IPs. However, the new Contain IP feature is focused on automated containment during active incidents.)
• When to Use It & Best Scenarios: This feature is best suited for scenarios where a suspicious or compromised device is detected on the network that does not have the MDE agent installed. Everyday use cases include:
  • Rogue or Unknown Devices: If an employee plugs in an unauthorized personal laptop or an attacker introduces a rogue device (e.g. a Raspberry Pi or Wi-Fi Pineapple) inside the network, MDE can contain its IP to prevent that device from communicating with corporate assets.
  • Unmanaged Infrastructure Devices: Network devices (like IP cameras, printers, or HVAC systems) infected with malware can start scanning or attacking other systems. Containing the device’s IP halts the attack’s spread, even if you cannot immediately shut down that device.
  • Lateral Movement Prevention: During an incident, security might discover an attacker-controlled system that wasn’t onboarded to any EDR. Defenders cut off the attacker’s ability to pivot to other endpoints by containing its IP, effectively boxing the threat in. This is particularly useful in ransomware scenarios, where isolating the infected machine (even if it’s not managed by the security tool) can protect the rest of the network.
  • Incident Response “Air Gap”: Traditionally, isolating a non-managed device might require network-level actions like disabling switch ports or VLAN ACL changes. MDE’s approach provides software-defined isolation—quickly implemented by endpoints themselves—that can be faster and more granular (and easily reverted). It’s a form of micro segmentation on the fly, applied only to the malicious actor.
• Visibility and Identification of Unmanaged Devices: You might wonder how Defender for Endpoint even knows about devices that aren’t onboarded. The answer lies in its device discovery capabilities. MDE can passively discover endpoints and network devices on the corporate network by observing traffic from onboarded endpoints (among other methods)​. These “unmanaged” or “discovered” devices are listed in the Defender console (often showing as “Can be onboarded” in the device inventory). When one of these devices exhibits malicious behavior, MDE correlates the IP with the discovered device entry. The security team will see alerts or incidents referencing the IP address (and any info gathered about that device). The Contain IP action can then be applied to that IP address entity.
• Granular Containment and Critical Assets: Microsoft has designed this feature to be granular, to avoid disrupting business-critical devices unnecessarily. Only the malicious device’s IP is contained – meaning onboarded endpoints will drop traffic to/from that one IP but continue normal operations otherwise. Additionally, if the compromised system happens to be a “critical asset” (like a domain controller or DNS server that must stay online), Defender for Endpoint is smart enough to apply granular containment. In such cases, rather than blocking all traffic to a critical server (which could cause downtime), it will block only specific malicious communication patterns (e.g. certain ports or directions) to stop the spread while allowing the asset to function. This ensures business continuity for essential services even when the threat is contained.
• Lifting Containment: Containment is not permanent – once the IT team remediates the rogue device or determines it was a false alarm, they can lift the containment. In the Microsoft 365 Defender portal, the Action Center provides a history of response actions. Administrators can find the “Contain IP” action in the history and select Undo, which will restore the IP’s connectivity on all endpoints. This undo action propagates the removal of the blocking rules, reconnecting the previously isolated device to the network (so it should be used only after the device is verified safe or removed). All such actions are logged for auditing.

Supported Environment: Currently, the IP containment capability is supported on Windows endpoints running the Defender for Endpoint sensor (Windows 10 client OS and Windows Server 2012 R2, 2016, 2019 and above). These are the systems that will enforce the blocking. Currently, other platform agents (Linux, macOS) are not mentioned as supporting the contain-IP action, so organizations should ensure that most of their devices are Windows/onboarded to leverage this containment fully. (Microsoft may extend support to more platforms over time as the feature matures beyond preview.)

In summary, Microsoft’s “contain IP of undiscovered device” feature brings a valuable capability to EDR: agentless device containment. It uses the strength of your already-deployed endpoint agents to shield the rest of your network from an unmanaged, potentially hostile device. This fills a gap in zero-trust strategy—unmanaged nodes no longer have free rein to communicate just because they lack an agent. Next, we’ll see how this approach compares to what other vendors are offering in terms of network containment or micro-segmentation.

Comparing Microsoft’s IP Containment with Other Vendors

Is Microsoft’s approach unique? In recent years, security vendors have been converging on using endpoints and network intelligence to contain threats beyond just the managed hosts. Some EDR/XDR vendors have added network isolation features, and specialized microsegmentation companies have long tackled the problem of restricting communications to prevent the spread of ransomware. Below, we examine similar capabilities from several key players and how they stack up against Microsoft Defender for Endpoint’s IP containment:

Akamai Guardicore Segmentation (Guardicore)

Overview: Guardicore (now part of Akamai) is a zero-trust microsegmentation platform traditionally used in data centers and cloud environments to isolate workloads. It deploys lightweight agents on servers or VMs to enforce east-west traffic policies. For devices where an agent can’t be installed (such as legacy systems or IoT), Guardicore can switch to an agentless enforcement mode. According to Akamai, Guardicore Segmentation “seamlessly extends its Zero Trust policy enforcement by offering network-based segmentation specifically designed for IoT and OT systems that cannot run host-based security software”. In other words, if a device can’t have the agent, Guardicore can still enforce rules at the network level (for example, via integrations with switches, routers, or by using collectors on the network) to contain that device.

Agentless Containment: This agentless approach means Guardicore can isolate unmanaged devices by automatically implementing access control rules in the network. Signals like DHCP, DNS, NetFlow, etc., are used to identify and classify all devices on the network, managed or not. An admin can create segmentation policies for an IoT/OT device through the same interface as any server. For example, if a security camera or an HVAC controller is not supposed to talk to any endpoint except its server, a policy can be set to block all other communications. In a breach scenario, if an IoT device is compromised, the team can quickly apply a stricter policy to limit communications with the infected asset, effectively containing it. Akamai emphasizes that policies can be enforced “in just a few clicks” to limit the blast radius of a breach – akin to how MDEs contain IP in one click in the incident response workflow.

Real-time and Use Cases: While Guardicore’s primary model is proactive segmentation (implementing Zero Trust by default), it also supports rapid response. Admins can visualize all assets in the environment (including unmanaged ones) and then quickly implement a new policy to isolate a threat. For instance, during a ransomware outbreak on a particular server, an administrator could use Guardicore to instantly block that server’s connections to the rest of the network, halting the spread of the ransomware. This is conceptually similar to containing by IP, though Guardicore would use its own labeling/policy mechanism rather than an “incident-triggered” action. Guardicore also provides comprehensive visibility – unmanaged devices show up on a central “Reveal” map alongside managed workloads. This visibility helps identify rogue devices and confirm that containment policies are effective (e.g., you can see the traffic from that device drop on the map)​.

Integration: Guardicore is not an EDR; it’s often used with EDR/XDR solutions. It doesn’t detect malware on a device by itself but enforces policies that can stop attacker movement. Integration-wise, it can take input from threat intelligence or vulnerability scans to suggest policies. Some organizations integrate Guardicore with incident response workflows – for example, an SIEM or SOAR playbook might automatically call the Guardicore API to apply a quarantine label to a host when an EDR (like CrowdStrike or Microsoft) flags it. Akamai also offers a DNS Firewall and has announced integrations with device security platforms (like Armis for unmanaged device discovery), extending its ability to react to threats on unmanaged devices. The key point is that Guardicore provides microsegmentation with both agent-based and agentless enforcement, allowing it to contain even those devices that can’t run an agent – much like MDE’s contain IP feature, but as part of a broader segmentation strategy.

Illumio Zero Trust Segmentation

Overview: Illumio is another pioneer of microsegmentation, focusing on host-based firewall control to create flexible isolation policies in hybrid cloud and data center environments. Illumio Core uses a lightweight agent (the VEN) on endpoints and servers to program the native OS firewalls (such as Windows Firewall or iptables) according to a central policy. However, Illumio also accounts for unmanaged or agentless systems in its segmentation model. Illumio’s platform can identify an unmanaged workload by its IP/hostname and include it in the policy model, even without an agent.  More info here: illumio.com.

Handling Unmanaged Devices: When Illumio discovers an unmanaged device (a database appliance or an IoT device) communicating in the environment, it can assign a label to that IP and then enforce policy from all the managed workloads toward that unmanaged workload. In practice, if you have 100 servers running the Illumio agent and an unknown device at IP X is seen, you can write an Illumio policy rule that says “no Illumio-managed server shall initiate a connection to IP X” (or vice versa). The Illumio agents will then block traffic to X on their side, effectively shielding the unmanaged device or quarantining it from the perspective of all managed assets. This is similar to what Microsoft’s contain IP does (using agents to block traffic to the rogue IP). Illumio confirms this capability: “Illumio can identify unmanaged workloads without a VEN agent… and enforce access to it from all other managed workloads.”. Because the unmanaged node has no agent, Illumio cannot directly control its behavior, but it controls everyone else’s behavior toward it, which is often enough to contain a threat. Illumio’s console will also display unmanaged devices on its network map (Illumination map) and show traffic flows involving them, providing needed visibility.

Segmentation vs. On-Demand Containment: Illumio’s approach is typically policy-driven segmentation rather than reactive containment. Companies using Illumio often segment in advance – e.g., placing all IoT devices in a restricted policy zone by default. That said, Illumio can be used during incidents by updating policies quickly. For example, if a specific unmanaged server is suddenly behaving maliciously, an admin could change its label to “Quarantine,” and Illumio’s controller would update the firewall rules on all agents to block that server’s IP. The change propagates quickly (Illumio is built for near-real-time policy updates across thousands of workloads). So, while Illumio might not call it “one-click contain,” it achieves a similar outcome via a policy update.

Integration: Illumio is often used alongside EDR solutions. A notable example is Illumio’s integration with CrowdStrike Falcon: Illumio developed an endpoint module (Illumio Edge) that can be deployed through the CrowdStrike agent to enforce Zero Trust at the endpoint level. This combination aims to stop ransomware from spreading by making every endpoint a zero-trust segment. While Illumio Edge specifically protects user endpoints from lateral movement (and could isolate a compromised endpoint), Illumio Core protects data center workloads. In either case, Illumio’s focus is microsegmentation (prevention by design), with the side benefit that any unmanaged device can be wrangled into the model if you control the communication on the other end. It may not have an automatic trigger like MDE’s “automatic attack disruption.” Still, a security team could script integrations (for instance, if a vulnerability scanner or NDR detects a rogue IP, it could call Illumio’s API to apply a quarantine label).

In summary, Illumio provides visibility into unmanaged endpoints and the ability to enforce network controls around them via its managed agents. It aligns with Microsoft’s philosophy of containing threats by cutting off their network connections. The difference is a use-case focus: Illumio is often deployed for broader segmentation strategy (compliance, reducing attack surface), whereas Microsoft’s contain IP is currently a pure threat response mechanism. Both underscore the Zero Trust idea of not trusting devices because they are on the “inside” network.

CrowdStrike Falcon

Overview: CrowdStrike Falcon is a leading cloud-delivered EDR/XDR platform known for its strong threat detection and response capabilities on endpoints. Its approach to containment is primarily through endpoint isolation. When a machine is compromised or suspicious, security operators can initiate a “network contain” on that host via the Falcon console or API. This action instructs the Falcon agent on that endpoint to block all network traffic except to the CrowdStrike cloud, effectively quarantining the host. This capability is analogous to Microsoft’s traditional “Isolate device” action on onboarded devices. It is swift – as soon as the command is issued, the agent updates the host firewall settings to cut off communications, stopping data exfiltration or lateral movement from that endpoint.

Containing Unmanaged Devices: Out-of-the-box, CrowdStrike focuses on devices that have its agent. It does not natively have a feature to contain an IP address of an unmanaged device in the same way MDE now does. If an IP is not running the Falcon agent, you cannot directly issue a “network contain” to it (since there’s no agent to execute the command). However, CrowdStrike offers alternative ways to handle rogue devices:

• Custom Network Block Indicators: Falcon allows admins to create custom Indicators of Compromise (IOCs) for domains, URLs, or IP addresses, which the agent will block.  More info here: ​crowdstrike.com. This is similar to Microsoft’s custom network indicators. Using this, a security team could distribute a block for a specific IP across all Falcon-protected endpoints. For example, if an unmanaged device at 10.0.0.50 is scanning the network, an admin could add 10.0.0.50 as a blocked IOC (via API or UI). The Falcon agents would then drop any traffic to/from that IP, achieving containment. The process, however, is somewhat manual (or requires integration) compared to MDE’s automated contain IP feature. It’s typically used for known bad external IPs or to shield endpoints from a threat seen by another sensor.
• NAC and Firewall Integrations: CrowdStrike has a rich ecosystem of integrations (via its CrowdStrike Store and APIs). Many organizations specifically integrate Falcon with network access control (NAC) solutions or firewalls for unmanaged devices. For instance, CrowdStrike integrates with systems like Aruba ClearPass or InfoExpress Easy NAC to automatically quarantine devices that do not have the Falcon agent or that Falcon identifies as compromised. In such a setup, if Falcon spots a threat from an IP not in its device list, it can signal the NAC to block that device at the switch level (e.g., shut down its port or put it in a restricted VLAN)​. Similarly, CrowdStrike can work with network detection and response (NDR) tools. A partner NDR (like Vectra AI or ExtraHop) might detect a rogue device; through integration, it can ask Falcon to contain any affected Falcon endpoints and instruct a firewall to block the rogue device’s IP. CrowdStrike leverages its open API and workflow engine (Falcon Fusion) to orchestrate multi-layer containment since the Falcon agent alone can’t directly act on a device with no agent.
• Exposure Management for Network Devices: Recently, CrowdStrike introduced Falcon Network Vulnerability Assessment as part of its exposure management suite. This is more about discovering and assessing network infrastructure (switches, routers, etc.) without agents. While its focus is vulnerability scanning (finding weaknesses in unmanaged network assets), this capability indicates that CrowdStrike’s platform is becoming aware of unmanaged devices. It’s conceivable that they might integrate threat response here in the future, but currently, the announced feature is about visibility and risk, not active containment of those devices.

Use Cases and Differences: A typical containment scenario with Falcon is as follows: an endpoint triggers a high-severity alert (say, malware beaconing). Falcon can be configured (via Falcon Fusion rules) to automatically network-contain that endpoint immediately, stopping the threat from spreading. However, if the threat originates on an unmanaged device, Falcon alone might alert on suspicious traffic (if its agents observe odd connections from that IP). Still, an analyst would need to take extra steps (like blocking the IP via an IOC or using a firewall) to isolate that unmanaged device. This is where Microsoft’s new feature shines – it cuts out those extra steps by automating the IP block across managed endpoints. CrowdStrike users often address this gap with the aforementioned integrations or by deploying Falcon sensors everywhere feasible (to minimize the unmanaged footprint).

CrowdStrike Falcon provides fast endpoint isolation and can block specific IPs through custom indicators. Still, it relies on integrations for truly agentless device containment (e.g., NAC to handle devices without a Falcon sensor). It is a robust solution when all devices are covered by the Falcon agent, and via XDR integrations, it can extend containment to network infrastructure in a customizable way. The idea of microsegmentation is not native in Falcon, but CrowdStrike partners with microsegmentation vendors (like Illumio, as noted) to offer that as a combined solution.

SentinelOne Singularity Ranger

Overview: SentinelOne’s Singularity platform is another top EDR/XDR solution, focusing on addressing unmanaged devices through a feature formerly known as Ranger® (now Singularity Network Discovery). SentinelOne takes an interesting approach: Every endpoint agent can act as a distributed network sensor, passively and actively mapping the devices on the network around it. This means SentinelOne clients protect their host, listen for neighboring devices (via ARP, DHCP, etc.), and even perform limited scans to discover who else is out there.  More info here:   ​sentinelone.com. The outcome is an inventory of “unknown devices” in the SentinelOne console, giving visibility similar to Microsoft’s device discovery.

Isolating Unmanaged Devices: SentinelOne Ranger goes a step further by enabling admins to act on those discovered devices. Specifically, SentinelOne agents can be commanded to “isolate suspicious devices from managed endpoints with one click.”. In practice, the admin can issue a containment command if SentinelOne identifies an IP address on the network that has no agent and the security team deems it suspicious or malicious. The SentinelOne agents on all the other computers will then block any communication to or from that rogue IP – just like MDE’s contain IP feature. SentinelOne’s documentation succinctly states, “With Ranger, risk from devices that are not secured with SentinelOne can be mitigated by either automatically deploying an agent or isolating the device from the secured endpoints.”. The platform can even attempt auto-deployment of the agent to the unmanaged device if appropriate (for example, if it’s a Windows machine that just hasn’t been onboarded, Ranger can push an installer). If that’s not possible or the device is unagentable (say an IoT gadget), the containment kicks in by shielding all other endpoints from it.

This capability in SentinelOne is conceptually almost identical to Microsoft’s contain IP – both use the endpoint agents as enforcement points to protect the network from an unknown node. SentinelOne has had Ranger available for a while, so it’s a proven approach. One-click containment via Ranger can stop an active threat from an IoT device, buying time for responders to remove or remediate that device physically.

Real-time & Automation: SentinelOne’s Ranger operates continuously. It will discover devices in real time as they connect to the network. Policies can automatically classify specific devices as “rogue” (for instance, anything in a sensitive subnet that isn’t running an agent). In some cases, organizations can set up automated responses. E.g., if an unmanaged device starts scanning ports or using suspicious protocols, Ranger could flag it based on policy and immediately isolate it. Even if not fully automated, the information is at the admin’s fingertips – the console shows which managed endpoints saw the rogue device and what it’s communicating with. From that interface, an analyst can swiftly click to block it. SentinelOne also highlights that no additional hardware or network changes are required for this – it’s all done via the endpoint software you already have, making it easy to deploy.

Integration: Since SentinelOne is an XDR platform, Ranger’s information can be correlated with endpoint threat data. Suppose an alert pops up on one machine that it’s receiving attacks from IP 10.0.0.50. In that case, the security team can pivot to the Network Discovery view, see that IP’s details (maybe it’s identified as a specific printer), and isolate it immediately. SentinelOne can also integrate with firewall or NAC solutions if needed, but the native capability often suffices for endpoint-to-endpoint protection.

In summary, SentinelOne Singularity with Ranger provides agentless device containment through agent-based enforcement, much like Microsoft’s new feature. It gives visibility into unmanaged devices and the option to isolate them in real time. Organizations invested in SentinelOne get a built-in network segmentation-lite solution for threat response. In contrast, they might have previously needed a separate NAC or micro-segmentation tool. Microsoft’s Defender for Endpoint is now offering a comparable feature, which is excellent news for parity in the industry.

Cisco Secure Workload (Tetration) and Related Cisco Solutions

Overview: Cisco Secure Workload (formerly Cisco Tetration) is Cisco’s microsegmentation and workload protection platform. It is designed to protect applications across on-premise data centers and the cloud by providing deep visibility and segmentation. A secure workload can operate with agents installed on workloads or in an agentless mode by ingesting data from the network (e.g., using telemetry from switches or other Cisco infrastructure).​cisco.com. The goal is to enable zero-trust microsegmentation, which only allows necessary traffic and blocks everything by policy.

Agentless Containment: Cisco Secure Workload can enforce segmentation through multiple enforcement points. It can program host-based firewalls via its agent or work with Cisco’s network security controls (like Cisco Secure Firewall, ACI, etc.) in environments where agents aren’t present. Suppose you have a device that cannot run a Secure Workload agent. In that case, you can still contain it by leveraging the network: pushing an ACL on a Cisco Nexus switch or a policy in a Cisco firewall that blocks that device’s communications. Cisco explicitly notes that using agentless enforcement with Secure Firewall (their firewall products) is an option to “contain lateral movement and any malicious activity propagation” in the data center​. In a dynamic data center scenario, if an anomaly is detected (say a workload suddenly port-scanning), Secure Workload can coordinate with Cisco Secure Firewall to quarantine that workload’s IP at the network level. This is analogous to containing by IP, though it might be called applying a quarantine policy or tag in Cisco’s terminology.

Automated Threat Containment: Cisco has a feature called Rapid Threat Containment, which often involves integration between Cisco Secure Endpoint (formerly AMP for Endpoints), Cisco Identity Services Engine (ISE), and network devices. For example, if an endpoint is compromised, ISE can automatically change its network access privileges (NAC quarantine). In the context of Secure Workload, the platform can integrate with Cisco’s Firepower Management Center (FMC) using a remediation module. A detected event (like an anomalous flow or a next-gen IPS alert) can trigger a correlation policy in FMC, telling Secure Workload to apply a quarantine label to the offending workload. Secure Workload then pushes the updated policy to all enforcement points, isolating that workload. This automation chain is quite advanced: it’s essentially the Cisco ecosystem’s way of doing what Microsoft does within a single product. The result is the same – block the malicious device’s communications – but Cisco can do it via the network fabric, which might cover non-agent devices.

Cisco Secure Workload’s agentless mode also means it can discover workloads via IP and still include them in policy (similar to Illumio). Cisco touts that it can harmonize different enforcement mechanisms (host firewall, network firewall, cloud security groups, etc.) into one unified policy. So, if a device doesn’t have an agent but is within a network segment controlled by a Cisco firewall or ACI, Secure Workload can still isolate it by pushing the policy to those controls.

Visibility: Cisco Secure Workload provides extensive visibility into application behaviors, processes, and traffic flows. When running in combined agent+agentless telemetry mode, it can map out all communications in the environment. This means unmanaged devices that talk on the network are observed. A secure workload can label discovered workloads and apply policies like those managed ones. Outside of Secure Workload, Cisco has other tools for discovering devices (Cisco ISE can profile devices, Cisco Meraki can see client devices, etc.), but those are more NAC-oriented. Secure Workload is about workload-to-workload communication (often East-West in data centers). It covers servers and VMs mainly, whereas something like Cisco ISE/NAC covers user devices and IoT on the access network.

Use Cases: A classic use case for Cisco Secure Workload is to create a Zero Trust environment in a data center – e.g., ensuring a web server only talks to the application server on specific ports and nothing else. However, for threat response, an example scenario could be: A critical server starts exhibiting unusual behavior (maybe a crypto miner or a rogue process) – Secure Workload’s behavioral detection flags it, and then automatically (or with one click), the security team applies a quarantine policy. That policy could instruct the host’s firewall (if the agent is present) to block all but whitelisted traffic and instruct the network firewall to block any traffic from that IP (covering if the host agent is missing or compromised). This dual approach ensures that the threat is contained from multiple angles. Another scenario: If an unknown IP appears in a sensitive subnet, an admin can use Secure Workload to quickly create a policy that only allows known necessary communications and blocks the rest for that IP – essentially fencing it off until it’s identified.

Integration with EDR/XDR: Cisco’s security portfolio is broad. Secure Workload can send its telemetry and alerts into Cisco’s SecureX XDR platform, correlating with endpoint and email security events. Conversely, SecureX orchestration can take an IOC (like a malicious IP) from, say, Cisco Secure Cloud Analytics (formerly Stealthwatch, an NDR) and use Secure Workload’s API to block that IP. These integrations are usually custom-made for a Cisco-heavy environment. The main difference between Microsoft’s approach and Microsoft’s is that Cisco’s solution might require multiple components working in concert (Secure Workload + Secure Firewall + maybe ISE) to achieve the same “contain unmanaged device” outcome. In contrast, Microsoft packages it into Defender for Endpoint. The upside for Cisco’s method is that it can enforce at the network layer, potentially containing traffic from an unmanaged device even to another unmanaged device if the firewall is in path (MDE’s approach only protects managed endpoints from the rogue device, but wouldn’t stop the rogue from attacking a second unmanaged device on the same subnet, for example).

In summary, Cisco Secure Workload provides a micro segmentation framework with both agent-based and agentless enforcement to stop lateral movement and contain threats cisco.com. It offers policy automation, recommendations, and integration with Cisco’s broader security ecosystem cisco.com. In effect, it accomplishes agentless device containment, real-time segmentation changes, and unmanaged device visibility, but it is usually part of a larger zero-trust architecture deployment.

As we see, Microsoft’s new IP containment feature aligns well with an industry trend: use whatever enforcement points you have – be it endpoint agents or network devices – to contain threats beyond your immediate visibility. Microsoft is leveraging its vast installed base of Windows Defender for Endpoint agents as a distributed firewall to stop rogue devices. Solutions like SentinelOne Ranger and Illumio have a similar philosophy, while traditional microsegmentation (Guardicore, Cisco) and EDR (CrowdStrike) provide pieces that can be orchestrated to achieve the same outcome. Next, we’ll illustrate a practical example of using Microsoft Defender for Endpoint to isolate a rogue device via IP containment in an incident.

Use Case Example: Isolating a Rogue Unmanaged Device with Microsoft Defender for Endpoint

To bring the concept to life, let’s walk through a hypothetical scenario where Microsoft Defender for Endpoint’s contain IP feature is used:

Scenario: The IT security team receives an alert of abnormal behavior on the corporate network. Several managed endpoints have reported inbound connection attempts on SMB (port 445) from an IP 10.4.5.99 that is not recognized as any known device. Defender for Endpoint’s sensors flag this as potential lateral movement – possibly an attacker on an unmanaged device trying to spread malware.

1. Detection: Microsoft Defender for Endpoint correlates the events and raises an incident in the portal. The incident shows multiple machines were probed by 10.4.5.99, and maybe even an alert like “Suspicious network activity from new device” is generated. The security team sees that the incident involves an IP entity (10.4.5.99) that is not onboarded. Thanks to Device Discovery, the portal might show the IP’s details (it was discovered on the subnet; perhaps it’s a Windows 7 machine that never got onboarded). This context clues the team that they have an unmanaged, likely compromised, host inside the network.
2. Response – Contain the IP: In the Microsoft 365 Defender portal, the responders can “Contain IP Address” for that device (since it’s identified as an unmanaged device). Given the severity of the situation, they activate this response. (If the attack is blatantly ransomware spreading, the system might have auto-triggered containment already – the portal would indicate the IP was contained as part of automatic attack disruption, and the following steps would be retrospective. But let’s assume a manual confirmation in this example.) Upon clicking contain, Microsoft Defender for Endpoint pushes a policy to all onboarded endpoints: block any traffic to or from 10.4.5.99.
3. Propagation of Containment: Within seconds, every Windows 10 PC, laptop, and server defended by MDE has adjusted its host firewall – if 10.4.5.99 tries to connect to them, it will be blocked, and if they try to initiate to 10.4.5.99 (unlikely in this case), that will be blocked too. The rogue device is effectively walled off from communicating with the organization’s managed assets. For instance, if the attacker on 10.4.5.99 was using SMB to drop ransomware on workstations, those attempts now fail. Those packets never reach their destination if they try RDP or WMI to move laterally. From 10.4.5.99’s perspective, the entire network just went dark.
4. Continued Monitoring: The security team can investigate further with containment in place. They might use network tools to scan 10.4.5.99 or physically locate it (maybe it’s a forgotten PC in a lab or an attacker’s device plugged in a conference room). Notably, if 10.4.5.99 attacks other non-onboarded devices (say a printer), MDE’s containment doesn’t protect those devices. However, since most critical assets (servers, PCs) were onboarded, the attacker’s options are minimal. In many cases, cutting off access to servers and workstations essentially foils the attack’s objectives.
5. Notification and User Impact: End-users on managed endpoints typically wouldn’t notice anything, except possibly a momentary blip if they were actively communicating with that IP (which they likely weren’t, since it was an unknown threat). The Defender action center logs the containment action so admins have a record. The incident in the portal is updated to show that 10.4.5.99 is contained – for example, the incident graph might put a “contained” label on that IP node. This informs all analysts that the threat from that node is temporarily mitigated.
6. Remediation of Rogue Device: Now, attention turns to 10.4.5.99 itself. An IT staff member finds the device – perhaps it’s an old server under someone’s desk. They disconnect it from the network and run a forensic analysis. Indeed, it was compromised with malware. They clean it up and adequately onboard it into MDE or decommission it. During this period, if the device had tried to do anything else on the network, it remained blocked by the containment policy.
7. Releasing Containment: Once the device is removed or secured, the team returns to the Defender portal’s Action Center. They locate the containment action for IP 10.4.5.99 (which will be listed with a time and the admin who initiated it). They click Undo (Release from Containment). Instantly, all those temporary firewall rules on endpoints are lifted, returning network conditions to normal. If 10.4.5.99 is truly gone from the network, this has no effect except cleaning up. If by chance it reappeared or was a false positive, the endpoints can communicate with it again (only do this when sure it’s safe!). The incident can then be closed out.

Outcome: The threat was successfully contained with minimal impact, demonstrating the power of agent-assisted network containment. What might have turned into a widespread infection was localized to one device, which was promptly isolated. The time from detection to containment could be a matter of a minute or two – far faster than coordinating a network team to reconfigure VLANs or ACLs on switches and far more scalable if multiple such rogue devices were in play (the system would contain each as needed). Moreover, because this containment leveraged existing endpoint agents, it required no new network hardware or re-architecting – a big win for practicality.

Comparative Note: If the organization had a microsegmentation solution like Guardicore or Illumio instead of MDE, a similar outcome could be achieved but via different means. For instance, an Illumio admin could quickly create a rule to block 10.4.5.99 across all workloads, and within a minute, those would propagate. A SentinelOne shop could have Ranger automatically flag and isolate that IP from the start (perhaps even auto-contain if configured). A CrowdStrike shop might rely on a SOC analyst to notice the scanner IP and then manually add it to a block list or trigger a NAC policy. Ultimately, all roads would aim to isolate the rogue device. Still, Microsoft’s new feature makes it straightforward for those already in the Defender ecosystem – it’s a built-in, one-click solution with automatic triggers, which significantly streamlines incident response.

Conclusion

As networks grow more complex and the number of unmanaged devices increases (bring-your-own-device, IoT, contractors, etc.), the ability to contain threats at the network level is becoming just as crucial as traditional endpoint protection. Microsoft Defender for Endpoint’s introduction of IP address containment for undiscovered devices is a significant step towards integrated XDR-based microsegmentation, blurring the line between endpoint security and network security. It allows organizations to quickly erect a barrier around a threat, even when that threat originates from an asset outside of their direct control.

We’ve seen that other vendors offer analogous capabilities: SentinelOne provides it under Ranger, CrowdStrike via integrations and custom IOC blocks, and pure-play segmentation solutions like Akamai Guardicore and Illumio have been enabling this via policy for years. Cisco’s approach ties segmentation into a broader architecture, including identity and network enforcement. Each has its strengths – for example, Guardicore and Illumio excel at comprehensive, always-on segmentation (proper for compliance and reducing attack surface). In contrast, EDRs like Microsoft and SentinelOne excel at on-demand containment in the face of an active attack.

For IT professionals, the key takeaway is that agentless device containment is now a readily available tool in the incident responder’s toolkit. You no longer have to feel helpless if a rogue device pops up on your network—you can empower your existing endpoints or network to immediately quarantine that device virtually. This reduces the window of opportunity for attackers and complements zero-trust initiatives.

When implementing these capabilities, consider the following best practices:

• Ensure broad coverage of whatever agent or sensor is needed (Defender for Endpoint, SentinelOne agent, etc.) across your endpoints – the more coverage, the more effective the containment net will be. Leverage discovery features to find gaps.
• Integrate with IT processes – for example, if a device is contained by IP, have a procedure to quickly follow up (physical retrieval or deeper investigation) as containment is a temporary control, not a fix.
• Tune automatic triggers carefully. You want to contain true threats without accidentally isolating important devices due to benign misbehavior. Use the visibility tools to profile normal devices and define what “undiscovered” truly means in your environment.
• Educate your incident responders about these features—an IP-based contain action may be new to their playbooks. Make sure they know how to execute it, under what scenarios, and how to verify its effect (e.g., checking Action Center logs and device connectivity).
• Evaluate complementary tools. If you already have a micro-segmentation solution, see if it can integrate with your EDR for a layered response. If you rely solely on EDR, assess whether its containment covers all cases you care about or if adding an NAC would close any gaps (such as unmanaged-to-unmanaged device attack scenarios).

The lines between endpoint, network, and identity security are fading in the evolving landscape of XDR. Microsoft’s contain IP feature exemplifies this convergence – using endpoint agents to do network isolation traditionally handled by network security. By comparing vendors, it’s clear the industry is moving toward a more cohesive, fast-reacting security posture where the moment a threat is spotted, multiple defenses coordinate to clamp down on it. Whether you achieve that with Microsoft’s stack or a combination of others, the result is stronger resilience against breaches and a safer environment for your organization.

Dave Kawula – MVP