The platform owner won't rebuild 291 servers you can't prove are clean — how do you declare eradication complete?

## Why this is a decision and not a measurement There is no observation that returns 'the adversary is gone'. Detections produce evidence when they fire; their silence is produced equally by an empty estate, a dormant intruder, a technique nobody modelled, and a sensor that stopped reporting. So the honest form of 'eradication is complete' is never a proof — it is a documented decision, made against criteria, with the remaining uncertainty named and owned by somebody who can act on it. That reframing is also what gets you out of the deadlock with the platform owner. They are refusing to rebuild 291 servers on a maybe, which is a reasonable position to hold about an unbounded demand. What they cannot refuse is being told, precisely, what is unknown and what happens next. ## Criterion one: every host lands in exactly one column The deliverable is an accounting where nothing defaults. Each host in scope is either **rebuilt** from verified sources; **cleaned**, with the mechanism fully enumerated and the privilege reached bounded and evidenced; or **accepted as unverified**, meaning nobody claims it is clean and the decision to leave it in service is recorded as such. The silent fourth category — 'no report, therefore fine' — is the one that turns an incident into a recurrence. If 187 hosts produced no sweep data because their agent had not checked in, those 187 belong in the accepted column with their names attached, not in the swept total. ## Criterion two: the way in is closed and the closure verified Eradication that removes footholds without closing the entry vector produces a clean estate that is re-entered through the same route. 'Verified' means someone other than the person who applied the change confirmed it independently — the exposed service no longer reachable, the vulnerable version actually replaced, the exposed key no longer accepted anywhere. ## Criterion three: compensating controls for the accepted column Accepted risk is only defensible when it is reduced. What you propose for the un-rebuilt hosts is concrete and mostly cheap: constrain what they can reach and what can reach them, so a surviving foothold has a much smaller blast radius and a much noisier path out; force on the telemetry that was missing, which converts the same hosts from unknowable to monitorable within days; re-run the sweep on a schedule rather than once; and put a funded rebuild into the next maintenance window so 'accepted' has an expiry date rather than becoming permanent. ## Criterion four: the acceptance is signed by the right person The SOC does not accept this risk, because the SOC neither owns the systems nor controls the budget that would remove the risk. The accepting party is the executive who owns that estate — and the value of the signature is not blame, it is that a named person now holds a decision with a review date, which is what makes the funded rebuild happen later. Your job is to state the residual risk in language they can weigh without a security background: something like 'on 187 servers we have no record of what ran during the eleven days the intruder held access; we did not find persistence there, and we could not have found it if it were present.' ## The watch: tripwires, not vigilance 'We'll keep an eye out' is not a control. A 30-day watch is a set of specific detections, each with an owner and each tested before you rely on it, aimed at the behaviour and access this actor demonstrated: authentication or connections involving the infrastructure seen in the incident; new keys appearing in `authorized_keys` anywhere in the fleet; new or modified systemd units and package hooks on hosts that should be static; an agent on the accepted hosts going silent again; use of the credentials that were exposed. Each tripwire gets a defined response, and the response is escalation to the incident lead rather than a ticket in a queue. Define in advance what reopens this incident instead of opening a new one — typically any signal tied to the same access, credentials, or infrastructure — because that distinction decides whether the second event is treated as a continuation with all the context, or as a fresh low-severity alert triaged by someone with none of it. ## What thirty quiet days does and does not tell you At the end of the window you know that no tripwire fired. Given that the tripwires were tested and aimed at behaviour this actor actually used, that is real information — it is evidence against the hypothesis of an active foothold using the known techniques. It is not proof of absence: a patient adversary can simply wait out a watch they can see coming, and a tripwire only detects what it was built to detect. Say that out loud when you close the incident, because the alternative is an organisation that believes it has certainty it never bought, and defunds the rebuild on the strength of it.