Your MDR provider owns the overnight queue and refuses your remote-access-tool rule — what do you do?

## The constraint you are actually operating under In a co-managed estate the internal team owns the risk and the context, while the provider owns the hours nobody wants and, usually, an alert-volume-sensitive commercial model. That split creates a rule you cannot simply deploy: someone else has to work every firing, and they can say no. A refusal is not an obstacle to route around; it is the clearest signal you will get about whether the rule was ever viable. ## Read the refusal before answering it There are two very different refusals hiding behind the same word. The first is contractual: the rule is out of scope, or it would raise volume past what the agreement covers. That is a commercial conversation with a defined path — scope change, an agreed volume, a price. The second is technical, and it is the one that usually matters: the provider cannot triage this alert with what they can see. A commodity remote-support agent appearing on a workstation is indistinguishable from a service-desk deployment unless you know which deployments your own platform pushed. Asking someone to make that call at 03:00 without the deployment records is asking them to guess, and the guesses will be closed as benign because that is what they mostly are. That refusal is correct engineering judgment and it names its own fix. ## The principle that decides most of these The party that bears the alert cost must share tuning authority, and no detection should be shipped to a queue whose owner did not agree to work it. Violating that gives you the worst combination available: the false-positive load lands on someone else, the alerts get closed unread, and your coverage map says the technique is detected. You have bought a belief rather than a control, and the belief will be repeated in reviews for years. ## The options, and what each costs **Make it carryable by fixing the data.** Provide the managed-deployment records — as an enrichment lookup, a reference list, or a feed into their platform — so the rule fires only on installs the estate cannot account for. This is usually the highest-value move because it also improves everything else built on the same join. It costs integration work and an owner for keeping the list fresh; a stale allowlist is its own incident waiting to happen. **Keep it in-house, business hours only.** Sometimes the right call, especially when the triage genuinely needs someone who knows the departments and the projects. The cost is an explicit gap: an install at 22:00 is looked at the next morning. That is acceptable if you write it down, name the risk owner, and stop describing overnight coverage of this technique as existing. **Route it to a ticket instead.** Ask the platform owner to constrain what may be installed at all — application control such as Windows Defender Application Control or AppLocker, permitting only the sanctioned remote-support product by publisher. This is often the best outcome because it changes the arithmetic rather than arguing about it: the noisy behaviour becomes impossible for ordinary users, and the residual signal is a rare block event that anyone, including the provider, can triage with confidence. The cost is other people's time and an owner who can refuse, so bring the hunt's numbers with you. **Do nothing, deliberately.** If the technique is low relevance to your estate and the fix is expensive, accepting the gap with a named owner is a legitimate decision. It is only a bad one when it is made silently. ## Making the relationship work afterwards Whatever you choose, the durable fix is process rather than a single rule. A joint tuning review at a fixed cadence, a defined intake path for new detections with agreed acceptance criteria — expected volume, an enrichment contract, a triage note the provider can act on without calling you — and an explicit statement of who may retire or suppress a rule. Providers refuse rules that arrive as raw logic with no triage guidance; they accept rules that arrive with a bounded volume estimate and instructions. ## What a strong answer sounds like It separates the commercial refusal from the technical one, refuses to ship an unworked rule, treats the ticket route as a legitimate and often superior outcome rather than a retreat, and ends with either a working detection someone owns or a written, owned gap. It does not end with a rule deployed into someone else's console and a coverage map nobody re-checked.