A vendor voids support if you install the EDR agent and the platform team refuses it on CPU grounds. How do you design around that?

## Why this is a judgment question, not a technical one The technical answer to "can we put a sensor on it" is often simply no, and no amount of engineering changes a support contract, a certified image, or a latency budget on a trading or clinical platform. What separates a strong answer here is that it stops trying to win the argument and starts designing for the world in which the argument is lost. ## Take the objections seriously first A vendor support clause is a commercial reality: if you install anyway and the appliance misbehaves, you own the outage and the vendor walks away. A platform owner citing a CPU budget is often right, and sometimes measured. But "the agent costs four per cent" deserves a test rather than a shrug: measure on a representative host, with the policy you would actually deploy, and see whether a scoped profile or a narrow, well-owned exclusion brings it into range. Sometimes it does, and then you are trading a known blind spot for a smaller one, deliberately. Sometimes it does not, and you have a measurement instead of an assertion, which changes the conversation with the risk owner. ## What to buy instead of the agent Work through four layers, because no single one replaces endpoint telemetry: **Make the device talk.** Almost every appliance and hypervisor can forward its own logs: authentication to the management interface, configuration changes, shell or SSH being enabled, service restarts, account creation. Insist on this at deployment, and treat inability to forward structured logs as a procurement defect. This is the single highest-value substitute, because it is the only source that sees the device's own actions. **Own the path in.** Administration only from a jump host, with MFA at the identity provider and recorded sessions. Now the *authentication* and the *session* are observable even though the host is not, and you have an identity-side trail for every human who touched it. **Own the network around it.** Put it on a segment where you collect flow, so you can establish contact, direction and volume, and place egress through a proxy or firewall you log. Remember the limits you will be asked about: a flow record proves bytes moved between endpoints and carries no payload; TLS SNI and certificate subjects are visible to a passive observer while the body is not. **Shrink the blast radius.** The unagented host should hold no credential that is reusable elsewhere, should not be reachable from general user networks, and should not be able to reach the crown jewels directly. If you cannot see it, at least ensure that what happens on it does not immediately become an estate-wide problem. ## Some refusals are best answered by removing trust, not adding visibility For a contractor or BYOD laptop, chasing telemetry on a machine you do not own is usually the wrong fight. The better design removes the device from the trust path: access through VDI or an isolated browser, conditional access that requires a managed device for anything sensitive, and no direct network reachability. You accept that you cannot see the endpoint, and you make that acceptable by ensuring nothing important depends on it. ## The organisational half, which is the part people skip A gap you cannot close becomes defensible only if it is explicit. That means a written risk acceptance naming the specific hosts, the compensating controls actually built (not proposed), the person accountable, and a date when it is looked at again. It means agreeing who is paged when the compensating signal fires, since the SOC's usual endpoint playbook does not apply. It means keeping an exception register so that one appliance's exemption does not become the default answer for the next forty. And it means agent supportability, or at minimum structured log export, appearing as a scored requirement in procurement and renewal, which is where the population of unagentable devices is actually determined. ## Why this matters more than it looks The realistic outcome on these hosts is that nothing is ever found there first. An intruder resident on a hypervisor or an appliance tends to be discovered only when they reach back onto a monitored endpoint, and the earlier residence is then reconstructed after the fact. Whether that reconstruction is possible at all, and whether it takes an afternoon or is simply impossible, is decided long before the incident, by whether somebody made the device forward its logs and put its management path behind something you record. That is the argument to make to the risk owner: you are not asking for the agent any more, you are asking for the ability to answer the question later. ## What a weak answer sounds like Installing the agent covertly, escalating to an executive as the first move rather than after a design attempt, or accepting the refusal silently and letting the coverage story stay comfortable. All three end the same way: an unmonitored host with no compensating signal, and nobody who agreed to own it.