Which hosts do you exempt from EDR auto-isolation, and what risk are you accepting by exempting them?

### The criterion The wrong question is "which hosts are important?" - by that test you exempt everything. The right question is a comparison of two blast radii: > Exempt the host when the damage done by the **action**, if the verdict is wrong, exceeds the damage done by the **intrusion** in the minutes it takes a human to decide. That framing does two useful things. It makes exemption a statement about the *action*, not about the host's value, and it makes the exemption conditional on how fast a human really can decide - which forces you to be honest about 03:00 staffing. ### The classes that usually qualify - **The tier-0 identity estate.** Domain controllers, the certificate authority, the identity provider's own infrastructure, and the PAM system. Isolating a domain controller can take authentication down for everything that depends on it, and if the verdict was wrong you have caused the outage the adversary wanted. - **Safety-critical and revenue-critical systems.** Plant and process control, medical devices, a trading floor. Some of these cannot be network-isolated without physical consequences, and some carry a regulatory objection to an unattended machine cutting them off. - **Shared jump hosts and bastions.** Isolating one cuts off every responder using it, including the responders working the case. - **The security tooling itself.** The SIEM, the response platform's own servers, the log collectors. Contain those and you have contained your ability to contain, and blinded the investigation at the same moment. - **Single points of failure with no redundancy.** A build agent in a pool of forty is a fine candidate for automation; the one host running an unclustered legacy service is not. ### What you are accepting Three things, and a good answer names all three. 1. **Your highest-value hosts are exactly the ones a machine will not defend at machine speed.** That is a coherent choice only if you actually staff the human path - a page that reaches a named person, a pre-agreed decision, and out-of-hours coverage. 2. **The exemption list is a map.** It says, precisely, where response is slower. An adversary who learns it learns where to land and where to stage. That makes the list sensitive material, tightly access-controlled, and it argues for compensating depth on exempt hosts: richer telemetry, lower alert thresholds, hunts targeted there. 3. **Exemptions rot.** Host roles drift, machines are rebuilt and renamed, a service moves. A list of hand-typed hostnames silently stops covering the thing it was written for. ### Making it hold up - **Derive membership, do not type it.** Bind the exemption to an authoritative source of role - a tier-0 security group, a CMDB or cloud tag, an asset-inventory class - so a rebuilt domain controller is still exempt on the day it comes back. - **Alert on the gaps in both directions.** A tier-0 asset that is *not* covered by an exemption is a finding; so is an exempt host that no longer has the role that earned the exemption. - **Substitute rather than subtract.** Exempt hosts should not fall out of automation entirely. Replace the destructive action with reversible ones and with a page. - **Review on a cadence, with the owning team present.** Every exemption should have an owner, a reason and a date. An exemption granted once because a team complained, and never revisited, is how the list becomes most of the estate. - **Test it.** The only way to know a host is genuinely exempt is to see the automation decline to act on it - either in a controlled test or in a review of real actions taken over the last quarter. ### The trap The most common failure is treating the exemption list as a safety feature that needs no maintenance and no compensating control, so it becomes both stale and, once it leaks, a target list. Exemption is not an absence of decision; it is a decision to spend human time instead of machine speed, and it has to be funded like one.