Arctic Wolf is the name that comes up first in most mid-market conversations, and the reason is the delivery model rather than the technology. You get a named team who learn your environment, and the pitch is that security operations arrives as a service with a relationship attached rather than as a console you have to staff. That is a real product and it addresses a real gap. What deserves more scrutiny is what sits underneath it, because the platform question and the delivery question have different answers.
The platform is Aurora, and Arctic Wolf now owns an endpoint product to go with it. The Cylance line acquired from BlackBerry has been rebranded as Aurora Endpoint Defense, which means the company sells both the sensor and the service. At the same time it maintains an explicitly open posture, supporting more than a dozen third-party endpoint tools and adding a Microsoft Defender XDR integration in August 2025 on the stated principle that customers should get the outcome regardless of which endpoint vendor they chose.
Both things are true simultaneously, and the tension is the most useful thing to understand about this provider. They will happily operate the Defender stack you already own. They will also happily sell you theirs. Which conversation you end up in depends substantially on who is in the room, and it is worth deciding your own answer before the first meeting rather than during it.
Authority configured per playbook
Response arrives as a service component with a set of documented actions. On the identity side that means disabling an account or revoking sessions in Entra ID. On endpoints it means isolation, through their own agent or through Defender for Endpoint or a third-party tool. On the network it means pushing a denylist entry to a firewall. There is also email remediation across Microsoft 365 and Google, though it is narrower than it first sounds: the documented behaviour moves the specific message that triggered the incident to junk or deleted for the specific affected user rather than sweeping a campaign out of the estate.
The governing sentence in their documentation is that these actions execute either automatically or by their analysts, depending on customer preferences and predefined playbooks. That is a reasonable middle position: authority is neither assumed nor absent, it is configured. Independent reviewers characterise the autonomous set as bounded, covering account disable, endpoint isolation and network containment. What is not published is the threshold logic, meaning the specific conditions under which an action fires without a human on your side. That is a question for the onboarding conversation, and the answer belongs in your runbook rather than in theirs.
The credential you are handing over
Here is the part I would raise in a design review. Response integration with Defender for Endpoint and Entra ID is wired through an application registration that you create in your own tenant, with a client secret handed to Arctic Wolf. That application carries API permissions sufficient to disable accounts and isolate machines, because that is the entire point of it.
A third party holds a long-lived credential with response-grade permissions in your tenant. The rotation, the scope review and the audit are yours, not theirs.
This is not unique to Arctic Wolf; it is the standard pattern across commercial providers, and it is the specific respect in which the first-party service differs structurally rather than cosmetically. It is manageable, and managing it means treating that registration as a privileged identity in its own right: a naming convention that makes it obvious what it is, a secret expiry you actually track, a documented owner, and a periodic review of whether the granted permissions still match the service you are buying. If your organisation has a privileged access model, this belongs inside it. Most of the estates I see have the registration and none of the governance.
Seven minutes to what, exactly
The headline operational number is a mean time to ticket of just over seven minutes. It is a genuine metric, published in their own security operations reporting, and it measures the interval from signal to a human writing something down. It does not measure containment and it is not a response commitment. Arctic Wolf publishes no aggregate detection or response time alongside it, and does not take part in the MITRE managed services evaluations, so there is no independent comparative measurement to set against the figure.
To their credit the number is at least honestly named, which is more than can be said for some of the field. Their own reporting also shows it moving: a stated thirty seven percent reduction over two years, attributed partly to an automated triage layer that handled around a tenth of alerts and removed several hundred thousand manual reviews. That is a defensible use of automation and it is described with enough mechanism to be worth something.
Incident response is a separate commercial object. The retainer covers one incident of any type end to end, marketed with response commitments as fast as an hour, listed publicly from around fourteen thousand dollars for a twelve month term with actual pricing done by private offer. It is included in the top service bundle, which also carries a three million dollar security operations warranty. The design point to notice is the scope cap: one incident. If your year contains two, the second one is a commercial conversation held under duress.
The double pay, and how to avoid it
An E5 organisation that takes Arctic Wolf on Aurora endpoints is in the clearest overlap position in this series. You are licensed for Defender for Endpoint through E5 and you are paying separately for an endpoint agent that replaces it. Either you run both, which nobody enjoys, or you run theirs and continue paying for the one you are not using.
The Defender XDR integration is the escape route, and it is the version of this engagement I would push for in a Microsoft estate: keep your own endpoint stack, buy the operations layer, let their platform consume your Defender signal alongside your identity, network and cloud telemetry. Whether the commercial terms improve to reflect that is a negotiation rather than a published policy, and it is worth making the point explicitly during procurement rather than assuming the price reflects what you are actually consuming.
Identity depth and the AI question
Identity here is a telemetry source with response hooks attached rather than a discipline in its own right. They consume Entra signal, they can disable accounts and revoke sessions, and through the Defender integration they see what Defender for Identity produces. What they do not have is an identity threat product with its own detection engineering and inline prevention. Against providers that have invested specifically in the identity plane, and one in this series has invested very heavily indeed, this is the thinner side of the offering. For an organisation whose incidents mostly start with a phished credential, that gap deserves weighing.
On artificial intelligence, two separate claims need separating, and I apply the same test across this whole series. The first is whether the provider helps you govern your users’ AI usage: discovery of unsanctioned tools, control over what data reaches them. I found nothing of that kind here, and I am recording the absence rather than implying one exists. The second is whether the provider uses AI inside its own operations, and here the claim is specific and mechanised: an automated triage layer with published figures for how many alerts it handled and what it removed from the human queue. That passes the test I set. It is triage, not autonomous response, and the concierge team remains the actual product.
Where this lands
The concierge model solves a problem that is genuinely organisational rather than technical. If nobody in your business owns security operations, a named team who know your environment and will pick up the phone is worth more than a marginally better detection engine that nobody is watching. That is the honest case for Arctic Wolf and it is a strong one for a particular kind of buyer.
The case against, in a Microsoft-heavy estate, is that you may be buying a second platform to solve a staffing problem. Test that during evaluation by insisting the engagement be scoped against your existing Defender deployment and seeing what happens to the conversation and the price. The answer tells you which product you were actually being sold.
MDR
‹ Previous: [MDR 1] Managed Detection and Response: Buying Operators, Buying a Stack, or Both
Next: [MDR 3] Microsoft Defender Experts: The First-Party Answer ›
