Expel is the purest expression of the operate-your-stack model. There is no agent, no platform to adopt, no console that becomes the place security happens. They connect to what you already run, work your signal from inside your own tooling, and sell judgement. What makes them worth studying, beyond that positioning, is that they have done the best job in this market of writing down exactly what their analysts are permitted to do and what happens when it goes wrong.
Independence is now itself a differentiator. Two of the notable names in this cohort have been absorbed by platform vendors in the last eighteen months, and the strategic question that raises for their customers does not arise here. That is worth something, though it is worth remembering it is a fact about today rather than a guarantee about renewal.
Authority with guardrails attached to each action
The response model here is the most granular in this series and it is the one I would hold up as the reference design. Automated remediations are licensed individually, enabled at the organisation level, and configured with customer-defined constraints attached to each one.
The documented set against Defender for Endpoint covers host containment, killing a process, deleting a malicious file, deleting a registry key, blocking a hash, removing emails, resetting credentials and disabling accounts. Each one can carry allow and deny lists. You can nominate processes that must never be killed, files that must never be deleted, hosts that must never be contained, and those exclusions convert the automated action into a task assigned to your team instead. Account disablement carries a hard exclusion that cannot be configured away: it will not act on administrative accounts or holders of privileged directory roles. Scoping can differ by asset class, so automating containment on workstations while requiring human approval for production servers or executive machines is a supported configuration rather than a special request.
Authority granted action by action, with a written list of things that must never be touched, is the shape this decision should take.
The detail that earns the most trust is what they say about irreversibility. Their own documentation states that a file deleted through the automated action cannot be undone, and that a killed process cannot be restored, and it attributes the file limitation to the underlying Microsoft API rather than blaming it on nobody. It also describes the behaviour when a machine is offline at the moment an action fires: the action does not queue silently, it becomes a manual task assigned to you. That is a vendor documenting its failure modes in public, which in this market is rare enough to be a signal about how they operate generally.
The same hybrid guard, arrived at independently
Their account disablement sequence is worth reading closely because it demonstrates that the hybrid resurrection problem is a real field issue rather than one vendor’s marketing angle.
When their analysts disable a compromised account, the platform first disables it on the domain controllers you have nominated, using Defender’s live response capability. It then attempts to force a directory synchronisation. Then, and this is the important part, it disables the account in Entra through Graph regardless of whether that synchronisation succeeded, and revokes active sessions and refresh tokens. The design assumes the sync may fail and closes the gap anyway.
Two providers in this series, with entirely different architectures and market positions, independently built a guard against the same failure. If you run hybrid identity and your own incident runbook says disable the account in Entra, that runbook is incomplete, and you now have two vendors’ engineering as evidence.
Identity coverage without an agent
For a provider that deploys nothing, the identity capability is stronger than the model would suggest. Credential resets work against Entra in both cloud and hybrid configurations. Account disablement spans Entra, Okta, Duo, Google Workspace and GitHub, which reflects the reality that most organisations have identity in more than one place. Their own reporting has put identity-based attacks at around sixty one percent of the incidents their operations centre handled in a quarter, which is consistent with what I see in the field and explains the investment.
What this is not is inline prevention. They detect and they respond, quickly, through APIs. They do not sit in the authentication path making allow or block decisions. Set against the provider in this series that does, the difference is architectural rather than a matter of quality: one composes with the access control plane you built, the other becomes part of it.
Integration follows the pattern common to commercial providers: an application registration you create, a client secret, admin consent, with permissions added per remediation as you license them. The incremental permission model is better than an all-or-nothing grant, but it is still a standing credential with response-grade access, and it belongs in your privileged access governance like any other. Account disablement in particular requires Defender for Endpoint Plan 2 or an E5-class licence, which is a concrete example of the dependency that defines this whole model.
What the thirteen minutes does not tell you
Their Microsoft-facing material carries a thirteen minute figure described as mean time to respond. The number is prominent and the definition is not, and without knowing which two events it measures between it cannot be compared against anyone else’s number. This is the recurring problem in this market rather than a criticism unique to them, and the correct move during evaluation is to ask what the clock starts and stops on and to get the answer in the contract if it matters.
Two commercial exclusions deserve flagging early because they surprise people late. Threat hunting is not included in the base service; it is a separate line item. And there is no incident response service and no breach warranty, so if an incident exceeds what remediation-in-the-course-of-monitoring covers, you need a retainer somewhere else. Reported entry pricing sits in the region of twelve thousand dollars a year, which makes the service accessible to smaller organisations than most of its peers, but read what that entry price includes before treating it as comparable.
The dependency that is also the value
There is no duplicated licensing here. You keep your Microsoft stack, they operate it, and the overlap conversation that dominates the platform profiles simply does not arise. The risk moves somewhere else, and it is worth naming precisely.
An agentless provider sees exactly what your licensing and configuration permit. On a Plan 1 endpoint estate with sparse diagnostic settings and no log export, you have hired good analysts and blindfolded them. On a well-instrumented E5 tenant with identity and endpoint telemetry flowing properly, the same provider is working with everything. The variance in outcome between those two engagements is enormous and it has nothing to do with the vendor.
That is the strongest argument in this entire series for doing the readiness work before the procurement rather than after it. It is also why the build sheet that closes this series exists, because knowing what you can see is a prerequisite for judging what anyone else could do with it.
On artificial intelligence: there is no capability here for governing your users’ use of generative AI, which I record as an absence. Inside their own operations they publish named automation and analysis features in their release notes and a human analyst remains the decision-maker before response. That is a modest, mechanised claim rather than an agentic one, and modest and mechanised is the version I trust.
MDR
‹ Previous: [MDR 5] Huntress: Operating the Licenses You Already Own
Next: [MDR 7] Red Canary Under Zscaler: When Your Zero Trust Vendor Owns Your SOC ›
