Deciding not to isolate is the job

Endpoint identity gate: verify the alert host, confirm identity, then decide whether containment is eligible.

Isolating an endpoint through an API is easy. In Cisco Secure Endpoint it's a PUT to the computer's isolation resource and a DELETE to release it, one machine at a time (Cisco documents both calls). In Microsoft Defender for Endpoint it's a POST to the machine's isolate endpoint with an IsolationType of Full, Selective, or UnManagedDevice (documented here). Every EDR has an equivalent, and any orchestration layer can call it.

That's why the interesting stories aren't about the API. They're about the machine somebody isolated at 02:40 that turned out to be the wrong one, or the shared jump host, or the box running the line controller at a plant.

The hard part of automated isolation is deciding when not to call it. This is the decision space we work through with teams building this integration — every asset class, every option, and what we've learned running it for real.

The first API call should not be isolate

1. Receive alert
2. Extract device ID
3. Call isolate
4. Create ticket

1. Receive and correlate the incident
2. Resolve the device identity
3. Classify the asset and its owner
4. Check policy exceptions and maintenance state
5. Confirm the detection meets the isolation threshold
6. Check whether an action is already in progress or completed
7. Choose the isolation scope
8. Submit the action with a useful comment
9. Track the action to a final state
10. Update the existing incident and ticket

A valid device ID points to a different host than the incident describes.
A desktop branch treats a production server as an ordinary workstation.
A VIP or shared jump host is isolated without an exception check.
A network timeout causes the workflow to submit the action twice.
A 201 Created response is reported as “device isolated” before the action finishes.

Decide what kind of asset you have

“Endpoint” is a connector category, not an operational decision. The asset class changes both the benefit and the blast radius of isolation.

Asset class	Why isolation may help	Why the default is risky	Better first question
Employee workstation	Limits attacker access and outbound communication	The user may lose business access, and the endpoint may be needed for evidence collection	Is the host confirmed, non-critical, and reachable after isolation?
Executive or VIP laptop	Stops a high-value account from being used	The user may be in a sensitive meeting or dependent on the device for business continuity	Is there an approved exception or an alternate device?
Developer workstation	Can stop credential or source-code theft	Builds, package downloads, and remote administration may fail	Can containment preserve the evidence and required management path?
Shared jump host	May interrupt lateral movement	Many responders or administrators may be using the same host	Can the session be drained or the account revoked first?
Domain controller	May stop active abuse	Isolation can affect authentication, replication, DNS, and every dependent service	Is network segmentation or credential action safer?
Production server	May limit an intrusion	A wrong isolation can become an outage	Can the server be contained at a load balancer, VLAN, or firewall instead?
Virtual machine	Can stop an active attack	A virtual label says nothing about the workload’s importance	What operating system and service does it actually run?
Unmanaged device	May require a different containment path	The agent may not support the same isolation mode	Does the platform require an unmanaged-device parameter?

We do not infer the class from a hostname such as APP-01 or LAPTOP-01. Resolve it from asset metadata, operating-system data, ownership, inventory, and the incident context. If those sources disagree, produce an “unable to determine” result and require review.

A virtual Windows server is a good example. The endpoint API may return endpointType: Virtual, while the operating system says Windows Server. If the workflow only checks endpointType, it may send that host down a desktop-isolation path. The safer classification preserves both raw values and the operational result:

Raw endpoint type: Virtual
Operating system: Windows Server
Operational class: Server
Desktop isolation: not eligible
Reason: server workload requires server response policy

Isolation decision flow: identity confirmed, asset class checked, exceptions routed to a human, workstation path isolates and records, server and shared-host path opens a ticket instead.

Isolation has several meanings

Full isolation

Full isolation generally blocks external network access while allowing the endpoint security agent and selected management traffic to continue. The exact allowlist belongs to the product and policy. Do not assume that “full” means the host is invisible to every system.

Microsoft’s Defender for Endpoint documentation warns that a device behind a full VPN tunnel may not reach the Defender service after isolation and recommends split tunneling for relevant cloud traffic (Microsoft isolation API). If the management path disappears, the endpoint is harder to verify and release.

Selective or restricted isolation

Selective does not mean harmless. A workflow must know which processes or destinations remain allowed, and the ticket should state the selected scope. A responder should not have to guess whether the host was fully isolated or placed in a restricted mode.

Unmanaged-device containment

Some products use a distinct mode for an unmanaged device. Microsoft documents UnManagedDevice as a separate IsolationType behavior for devices that are not managed in the normal way. Never send that value merely because a lookup failed. “Not found” and “unmanaged” are different states.

Vendor-specific modes

Other endpoint platforms may expose network containment, restricted mode, host quarantine, or an action that is queued for the agent. Translate those modes into a common internal vocabulary:

requested_scope: full | selective | unmanaged | vendor_specific
management_path: expected | at_risk | unknown
verification_state: pending | succeeded | failed | unknown

Full isolation is not the only containment instrument

Instrument	What it changes	Better when	Main risk
Full endpoint isolation	Cuts most network access from the device	A workstation is actively communicating with an attacker and business impact is acceptable	Management or user connectivity can disappear
Restricted/selective mode	Limits selected applications or destinations	You need the agent, an administrator, or a critical process to stay reachable	The attacker may still have a path through an allowed process
Process termination	Stops a malicious process	The process is clearly identified and stopping it will not destroy needed evidence	The process can restart, and volatile evidence may be lost
File quarantine	Prevents a known file from running	A specific malicious binary is confirmed	The attacker may have another execution path
Credential revocation	Invalidates tokens, sessions, keys, or passwords	The identity is the main risk or lateral movement is underway	Services can fail, and existing sessions may remain active briefly
Account disable	Prevents a user or service identity from authenticating	A compromised identity must be stopped quickly	Shared services and automation may break; it does not contain a second account
VLAN or network quarantine	Moves or filters the host at the network layer	The endpoint agent is unavailable or the host is a critical server	It can affect dependent systems and may be hard to reverse safely
Firewall block	Blocks a specific source, destination, port, or path	The malicious connection is narrow and the host must stay online	A broad rule can block legitimate traffic or miss another path
Load-balancer or service drain	Removes a server from client traffic	A production service must stay available while the host is investigated	Existing sessions, background jobs, or east-west traffic may remain
Human approval	Holds the action for an operator	Asset criticality or evidence uncertainty is high	Delay gives the attacker more time

A response can combine instruments: a domain controller may need account and token action plus a narrow network block, while a workstation with a clear malicious connection may justify full isolation. A shared jump host may be safer to drain and revoke the active account first.

Containment decision: selective isolation
Reason: shared administrative host; preserve security-agent and responder access
Alternative rejected: full isolation would terminate active response sessions

Verify identity before containment

The most dangerous input is an identifier that is valid but points to the wrong device. A stale GUID, a duplicate hostname, or a device re-enrolled after an operating-system rebuild can all produce a successful request against the wrong target.

Before isolation, resolve and retain:

Device ID used in the request
Current hostname or display name
Operating system and platform
Device group, owner, or business service
Agent health and last-seen time
Source incident and detection that triggered the request
Existing isolation state

Compare the resolved hostname with the incident asset. If the incident says HOST-A but the endpoint lookup returns HOST-B, stop. Do not “fix” the ticket after acting.

Asset resolution: confirmed
Incident hostname: HOST-A
Endpoint hostname: HOST-A
Device ID: <device-id>
Operating system: Windows 11
Asset class: employee workstation
Identity decision: eligible to continue

If the lookup returns no record, record not_found and stop that containment branch. Do not put a hostname into a device-ID field, retry with a GUID from another connector, or treat a missing record as permission to broaden the action.

The enrichment failure path is a decision tree

Can the source incident identify an asset?
  No -> no automatic containment; request analyst review
  Yes
    Can the endpoint platform resolve the identifier?
      No -> record not_found; do not guess; review stale/offboarded/re-enrolled states
      Yes
        Does resolved identity match incident context?
          No -> stop; possible stale or wrong identifier; escalate
          Yes
            Can the workflow classify the asset and owner?
              No -> choose human approval or the narrowest approved alternative
              Yes
                Is the asset under an exception or change window?
                  Yes -> skip; record policy reason and owner
                  No
                    Is the detection threshold met?
                      No -> report only; do not isolate
                      Yes
                        Is an action already pending or complete?
                          Yes -> track existing action; do not submit blindly
                          No -> submit selected containment action

The outcome should be one of:

eligible
skipped_by_policy
not_found
identity_mismatch
insufficient_context
already_contained
action_requested
pending_verification
action_succeeded
action_failed

Exceptions belong in policy, not comments

A workflow that isolates every matching endpoint eventually isolates something it should not. Exceptions must be machine-readable, maintained, and evaluated before the action.

Common exceptions include:

Executive or VIP workstations
Domain controllers and identity infrastructure
Production servers
Shared kiosks and jump hosts
Emergency-response and monitoring systems
Devices under a maintenance or change window
Hosts already isolated by another tool
Assets with active backup, deployment, or patch operations

An exception check must distinguish not an exception from could not check. If the owner lookup failed, the workflow cannot safely conclude that the host is ordinary. Route the case to review or use a pre-approved alternative.

A policy decision should be visible:

Containment decision: skipped
Reason: approved maintenance window
Window reference: <change-id>
Action: no isolation request sent
Next review: <timestamp>

Do not encode “never isolate the finance laptop” in a comment or in a one-off Python branch. Store the exception in a source that is owned, reviewed, and testable.

Microsoft Defender for Endpoint: what the documented call tells us

POST https://api.security.microsoft.com/api/machines/{id}/isolate
Authorization: Bearer <token>
Content-Type: application/json

{
  "Comment": "Contain device for confirmed endpoint detection <incident-id>",
  "IsolationType": "Full"
}

The documented values are Full, Selective, and UnManagedDevice. The API requires the comment and isolation type, and a successful request returns 201 Created with a machine-action object (Microsoft API reference).

The caller needs the appropriate active-remediation role or application permission.
Device-group access affects which devices the caller can act on.
Full and selective isolation have operating-system support conditions.
The API has documented rate limits.

Do not describe 201 Created as “isolation verified.” It means an action resource was created. Track that action.

Microsoft describes the machineAction resource with an ID, action type, scope, request source, and related properties. Use the action ID in the source incident and ticket, and use the product’s action/status APIs to check what happened (machineAction resource).

request = {
    "target_id": device_id,
    "scope": "full",
    "comment": f"Contain for source incident {incident_id}",
}

result = endpoint_adapter.isolate(request)

Prevent duplicate actions and duplicate incidents

A timeout may follow acceptance; blind retries can create a second action while the first runs.

Use a correlation record containing:

{
  "source_incident_id": "<incident-id>",
  "device_id": "<device-id>",
  "requested_action": "isolate",
  "requested_scope": "full",
  "request_id": "<local-action-key>",
  "provider_action_id": "<provider-action-id>",
  "requested_at": "<timestamp>",
  "verification_state": "pending",
  "ticket_reference": "<ticket-number>"
}

Before sending a new request, look for an existing action for the same source incident, device, and scope. If one exists, query its state and continue monitoring it. If the provider exposes an external correlation ID or idempotency mechanism, use it. If it does not, implement idempotency in the orchestration layer.

The same principle applies to ServiceNow. A containment retry should update the existing case, not create a second case for the same action. Ticket creation and endpoint action are separate side effects; neither should be repeated just because the other timed out.

Track asynchronous results

Distinguish endpoint states:

Request not sent
Request rejected
Request accepted
Action in progress
Isolation succeeded
Isolation failed
Status unknown after timeout
Skipped by policy
Already isolated

Poll with bounded backoff; pending is not failure:

submit action
  -> save provider action ID
  -> wait according to provider behavior
  -> read action status
  -> if pending, wait with bounded backoff
  -> if final, record result
  -> if timeout, mark pending_verification and alert

The source incident should carry the same action ID and final result. If verification is pending, say so plainly:

Isolation request: accepted
Isolation verification: pending
Provider action ID: <action-id>
Next check: <timestamp>

Respect rate limits and partial failures

Batch isolation needs per-device results. Microsoft documents rate limits of 100 calls per minute and 1,500 calls per hour for the isolate-machine API; use them to size concurrency, backoff, and queue depth (Microsoft isolation API).

A batch result should look like this:

Containment summary: partially completed
- HOST-A: isolation succeeded
- HOST-B: request throttled; retry scheduled
- HOST-C: skipped by critical-asset policy
- HOST-D: identity mismatch; no request sent

Do not collapse that into “four devices isolated.” The roll-up is useful only when the per-device states remain available.

Use different retry policies for different failures:

Failure	Retry?	Why
DNS or connection reset before request	Usually, with backoff	The provider may not have received the request
Timeout after a request was sent	Verify before retrying	The action may already exist
Authentication failure	Stop and alert	Repeating will not fix credentials
Permission denied	Stop and alert	The caller or device group needs correction
Rate limit	Retry after provider guidance	Immediate retries increase the limit problem
Invalid device ID	Do not retry unchanged	Enrichment or identifier mapping is wrong
Action already in progress	Track existing action	A second request adds ambiguity
Provider 5xx	Bounded retry and reconcile	The server may have accepted the action

Worked scenario: VIP laptop

A high-confidence endpoint alert identifies VIP-LAPTOP and a user account. The endpoint lookup succeeds, but the ownership source marks the device as an executive asset.

The safer workflow:

Resolves the device and confirms the hostname.
Finds the VIP exception.
Does not call the isolation API.
Creates or updates the case with the reason and incident link.
Routes the incident for an approved containment decision.
Offers alternatives: token revocation, selective network restriction, or a human-approved isolation window.

Action: skipped by policy
Reason: VIP asset exception
Follow-up: analyst approval required

Worked scenario: domain controller

A credential-access detection points to a domain controller. Full isolation could interrupt authentication and replication. The correct first instrument may be credential revocation, disabling a compromised account, blocking a narrow external path, or draining a related service—depending on the evidence and the organization’s response plan.

Do not infer that “high severity” means “full isolation.” Identify the asset class, apply server policy, and require appropriate approval or an alternate action. If isolation is approved, the ticket must state scope, expected management path, and recovery owner.

Worked scenario: shared jump host

A shared jump host shows suspicious PowerShell activity. Isolating it may stop the attacker, but it can also terminate active sessions for responders and administrators.

A safer sequence may be:

Capture volatile evidence and identify active sessions.
Revoke the suspected account or token.
Drain new connections.
Apply selective isolation or a narrow network rule.
Keep the endpoint agent and response team reachable.
Escalate to full isolation if the threat persists.

Worked scenario: stale asset record

Endpoint lookup returns no record for device ID <old-id>, though inventory still has the hostname. Do not search partial names and isolate the first match.

Record not_found, retain the old ID, and investigate whether the endpoint was offboarded, re-enrolled, renamed, or moved between tenants. If a current device ID is found through an approved inventory relationship, create an explicit alias:

Previous device ID: <old-id>
Current device ID: <new-id>
Alias basis: verified inventory relationship
Containment: pending review

A name match alone is not enough when the action is destructive to availability.

Worked scenario: mid-change-window endpoint

A workstation is in a maintenance window while a software deployment runs. The alert may still be real, but full isolation could corrupt the deployment or leave the host in a partial state.

The workflow should read the change state before acting. It can record the detection, notify the owner, use a pre-approved narrow action, or queue isolation for the end of the window. The ticket should contain the change reference and the next decision time.

Clear-then-retrigger must be explicit. Do not delete the original run and pretend the later run was the first one. The original skip is part of the audit trail.

Reversibility is a workflow, not a button

Releasing a device from isolation deserves the same discipline as isolating it. The workflow should identify:

Who or what requested release
Which isolation action is being released
Why release is safe
Whether malware removal or credential action is complete
Whether monitoring is active
What verification proves the device is usable and still clean

A release record might contain:

Release decision: approved
Device: HOST-A
Isolation action: <action-id>
Reason: forensic collection complete; credentials rotated
Release method: provider unisolate action
Verification: agent healthy; expected network path restored
Owner: <team>
Timestamp: <timestamp>

Microsoft publishes a separate release-device API reference, which reinforces that release is a distinct action with its own contract (Microsoft release device from isolation).

Verification after release should check more than “the API returned success.” Confirm the agent is healthy, the device is reporting, the expected network path is restored, and the source case records the release. If the device immediately reconnects to the suspicious destination, containment may have been released too early.

Blast radius of a wrong call

A wrong isolation call can cause:

Loss of user productivity
Authentication or DNS disruption
Broken deployment, backup, or monitoring jobs
Loss of the endpoint management path
Delayed forensic collection
Duplicate tickets and confusing ownership
An attacker moving through another host while responders investigate the outage

The impact is not limited to the device. A domain controller, jump host, network appliance, or build server can have a dependency graph much larger than its asset record suggests.

That is why a workflow should calculate or at least label blast radius:

Asset criticality: high
Shared role: yes
Dependent services: identity, DNS
Isolation recommendation: human approval
Preferred alternative: credential revocation + narrow network block

The more connected the asset, the stronger the evidence and approval requirement should be.

What the ticket and work note must contain

The source incident and ServiceNow record should carry the same outcome. Include:

Source incident ID and link
Device hostname and endpoint console link
Device ID used for lookup
Raw endpoint class and operational class
Owner, VIP, criticality, or exception result
Requested action and scope
Provider action ID
Request and verification timestamps
Final state
Reason for skip or failure
Next step and owner

A work note should be specific:

Endpoint containment evaluated for HOST-A.
Asset class: employee workstation
Decision: selective isolation
Provider action ID: <action-id>
Request result: accepted
Verification result: succeeded
Source incident: <incident-id>

Never write bearer tokens, client secrets, or authorization headers into a comment, ticket, or work note. The comment field is evidence about the action, not a secret channel.

Test the “do not isolate” paths

A safe test plan includes more than a confirmed malware alert. Exercise:

One eligible workstation
A VIP or critical asset
A domain controller or other high-dependency server in a lab policy
A shared jump host
A virtual Windows server that must not enter the desktop branch
A Linux or unsupported asset classification
A missing device ID
A stale or re-enrolled device ID
A hostname/ID mismatch
An existing isolation action
A device already isolated
A maintenance-window exception
A connector timeout before the request
A timeout after the request may have been accepted
A throttled batch
A pending action that later succeeds
A failed action
Release followed by endpoint-health verification
A retry of the same incident and device

For each test, verify three places: the endpoint console, the workflow run, and the source/ticket record. The desired result for an exception is not a red workflow. It is a documented skip with no enforcement call.

Troubleshooting checklist

The workflow says it isolated the device, but the device is still online

Check whether the result means “request accepted” or “action verified.” Retrieve the provider action record, confirm the device ID, and inspect the endpoint’s current state. Check agent health and VPN topology. A full tunnel can interfere with management traffic after isolation (Microsoft warning).

The wrong host was isolated

Compare the source incident hostname, resolved endpoint hostname, device ID, and lookup timestamp. Then inspect whether a stale or re-enrolled device record was used. Add an identity-match gate before the enforcement activity; do not repair this with ticket formatting.

A virtual server was treated as a desktop

Inspect the raw endpoint type and operating-system fields. Classification must happen before desktop/server branch selection. Preserve the classification decision in the run output so a reviewer can see why the branch was chosen.

The endpoint disappeared after isolation

Check the action state, agent health, VPN path, and whether the selected isolation mode permits management traffic. Do not submit a second isolation request. Route the case to endpoint support or use the documented release/recovery path.

Retries created duplicate actions

Search for an existing provider action by device and incident before retrying. Persist action IDs immediately. Separate transport retry from status verification, and add a local idempotency key when the provider does not supply one.

A critical host was skipped and nobody knows why

Check the exception source, policy version, change-window reference, and the work note. If the run only says “not eligible,” the policy output is too weak. Record the specific reason and owner.

A batch contains mixed results

Keep per-device states. Do not overwrite them with the last response. Use a roll-up such as partial, and include the retry or follow-up owner for throttled, failed, and pending items.

The Isolation Button Has a Cost