The incident call starts with a familiar instruction: block the workload.

Block it where? Remove its role? Disable its identity? Deny its subnet? Isolate the VM? Each action sounds like containment until you ask what the other half of the path can still do—and which production dependency you just cut along with it.

When an application is compromised, the objective is not to demonstrate that someone can make a control-plane change. It is to reduce the attacker’s options without losing the services responders still need. That requires an identity decision and a network decision made against the same path.

The Mental Model

For a workload-to-resource path, identity and networking enforce different conditions:

• Identity determines which operation the principal can perform at the service.
• DNS and network policy determine how the workload locates and reaches the service.
• The service and application determine what happens to the request and whether the dependency still functions.

Changing one edge may be the right first move. It does not prove the full path is broken.

There is no universal “revoke first, block second” sequence. The right order depends on confidence, service impact, control-plane integrity, and how quickly the attacker can use the remaining path. That uncertainty should be in the runbook before the pager goes off.

Containment is not complete because a rule changed. It is complete when the tested consequence fell and the required service still behaves as intended.

How It Really Works

Identity-only containment

Removing or reducing an identity assignment can narrow what the principal is authorized to do. Disabling an identity or changing workload configuration may be appropriate when the workload itself is untrusted. These actions do not automatically establish that the process cannot reach the destination, and the operational timing of authorization changes must be verified for the specific service and request.

Identity-only action can be useful when network paths are shared by many healthy services and the suspicious workload’s authority is the clearest edge to remove. It can be less disruptive than blocking an entire subnet. But if the workload has another identity, a cached credential path, or can invoke an intermediary with its own authority, one removed assignment may leave the consequence intact.

Network-only containment

Restricting egress, isolating a VM, changing a route, or applying a narrowly scoped deny can stop a known source from contacting a target. This can buy responders time when they do not yet trust the workload or identity. It may also cut DNS, monitoring, package feeds, identity endpoints, or shared services needed for investigation and recovery.

Blocking the subnet is fast to explain and often expensive to operate. If unrelated workloads share it, the containment boundary is larger than the incident boundary. A network action also does not remove the identity’s authority from other attached resources or alternate paths.

Coordinated containment

When evidence supports it, make a paired plan: reduce the identity authority that matters and restrict the network path from the compromised source. Keep the service dependency that healthy workloads require, or move those workloads to a known-good path if that has been rehearsed.

The plan needs an owner for each action, the exact target scope, a rollback or escalation condition, and a test that will show whether it worked. Don’t improvise a broad role deletion or shared firewall policy edit during an incident if a narrower, pre-approved option exists.

Separate the control-plane action from the outcome

Record the change request and the actual outcome. For identity, capture the principal, role/action, scope, and service operation under test. For networking, capture source, resolved destination, protocol/port, route or policy change, and connection result. Then test the expected legitimate operation from a known-good workload.

Azure Activity Log or resource configuration can help show that a control-plane change was submitted or recorded. That is not the same as evidence that every affected data-plane request now behaves as intended. Use service-specific documentation and a safe test to establish the effect; avoid promising a universal propagation interval.

Real-World Impact

Suppose a compromised image-processing VM reads uploaded content from Blob Storage using a managed identity. The same subnet hosts a clean service that writes audit records to the same account.

A subnet-wide deny may interrupt both applications and remove the logs responders wanted to keep. Removing a role assignment may stop the suspicious read but leave the compromised process able to reach other services through a shared identity or an intermediary. Doing both without checking dependencies can convert a security incident into an outage and still fail to close the path.

Before the incident, make a containment decision record:

During the incident, this does not remove the need for judgment. It makes the consequences visible before a responder has to choose under pressure.

Gotchas and Edge Cases

The safest containment action on a diagram can be the most damaging one in a running service. Shared identities and shared subnets are common because they simplify operations; incidents expose the cost of that coupling.

Existing tokens and sessions complicate timing

Submitting a role or identity change does not let you claim that every in-flight operation stopped at that instant. Token lifetime, service-side checks, caches, existing connections, and application retries can affect what responders observe. Check the service’s current documentation and verify behaviour in a controlled test; do not rely on a universal “revoked in N minutes” statement.

Shared identities expand the containment boundary

Removing an assignment from a user-assigned identity can affect every workload relying on it. Disabling or detaching it from one compute resource may not change what another attached resource can request. Inventory the identity’s assignments and attachments before using it as a single-workload kill switch.

Isolation can remove the evidence you need

The compromised workload may need to be cut off from external destinations while preserving a telemetry path to a trusted collection point. If the isolation design also removes DNS, management, or logging access, responders need a separate out-of-band method. Test this before relying on it.

The control plane may be part of the incident

If the attacker can change routes, NSGs, firewall policy, or role assignments, responders need confidence in the administrative identity and control path they use to contain the workload. A containment action performed through a compromised authority path can be undone or misrepresented.

Best Practices

Design at least three rehearsed options: identity reduction, source isolation, and coordinated containment. For each, name the scope, required permissions, expected service impact, telemetry retained, and recovery trigger. Favor reversible actions with a clear owner, but do not let reversibility become an excuse to defer a needed boundary change.

During response, establish the smallest useful path first: compromised source, identity, target operation, resolver, and route. Choose containment against that path, not against the easiest resource group or subnet label. If evidence is incomplete, say so and choose a bounded action that buys time without pretending the residual risk is gone.

Afterward, repeat the original request from the affected workload or a safe equivalent and test the healthy dependency from a known-good source. Document both results. A stopped attacker path and a working business function are separate acceptance criteria; you need both before declaring recovery complete.

Learn More

• Network isolation during active compromise
• Networks that fail safely under breach conditions
• Managed identities for Azure resources
• Azure RBAC permissions for Network Watcher
• Azure Activity Log