Description
Connecting your own SentinelOne (BYO) licence to Guardz gives you detection visibility and manual response tools, but not a SOC. Human triage, autonomous containment and incident reporting come only with the Guardz MDR add-on, which is sold separately on Ultimate and Elite plans.
This article is for Manage Protect MSP partners. It explains what each SentinelOne option includes, why many "Guardz isn't working" reports are really licensing gaps, and what to check before raising a support case.
Side-by-side comparison
MDR is a separately gated add-on, sold via Ultimate and Elite plans. It is not bundled with BYO SentinelOne, however the licence was sold.
Capability | BYO SentinelOne | Guardz-Managed SentinelOne |
|---|---|---|
Licence and console ownership | MSP owns the S1 tenant, licence and native console | Guardz provisions and manages the licence |
Deployment | Done directly through S1; Guardz inherits policy settings via API token | Done through the Guardz platform |
Threat visibility | S1 detections appear as Detections/Issues in Guardz Detection & Response; devices sync to Guardz > Devices | Same visibility, plus context added by the Guardz SOC |
Manual remediation in Guardz (kill process, quarantine file, remediate) | Available, but the MSP must see the alert and act on it | Same tools, used by the Guardz SOC as part of the response |
24/7 triage of ambiguous Incidents | None. Nobody at Guardz validates whether an alert is real or noise | Follow-the-sun SOC validates, classifies and gathers context on every Incident (MDR) |
Autonomous containment (isolate device, suspend user) | None. The MSP must make and execute the call | SOC acts per the MSP's configured policy, escalating by Intercom or phone when approval is needed (MDR) |
Investigation and incident reporting | None | Evidence-based incident reports and playbooks from the SOC (MDR) |
Advanced console work (groups/sites, per-device exclusions, threat hunting, forensics) | Stays in the native S1 console | Also stays in the native S1 console; this sits outside Guardz either way |
BYO Inclusions
With BYO SentinelOne, you supply and own the SentinelOne licence and console. Guardz ingests the telemetry S1 provides, turns it into detections, and gives you manual tools to act on them.
What BYO does not include is a Guardz analyst deciding what an alert means, acting on it without being asked, and closing the loop. That layer exists only as MDR on Ultimate and Elite plans. Connecting a BYO integration never switches it on by default.
When a customer says "Guardz isn't working", the cause is usually one of two things:
1. The detection engine missed something. This is a genuine product issue. It is rare and should be escalated to Guardz support.
2. The account was never covered by a SOC. This is a licensing or positioning issue, and it is far more common on BYO accounts.
Complaints that are expected behaviour on BYO without MDR
Some Partners have expressed concerns about the performance of Guardz when utilising BYO S1. The below examples are not bugs, rather they are what BYO SentinelOne does when no MDR add-on is in place.
Concern | Why it happens on BYO without MDR |
|---|---|
"Guardz saw the threat but never isolated the device or called us." | No SOC is watching the account, so nothing acts on an Incident until the MSP does. |
"The alert just sat there for days." | Nothing separates an auto-mitigated Issue from an Incident needing a human decision. If nobody at the MSP is monitoring the Guardz console, Incidents queue indefinitely. |
"We thought we were paying for Guardz's SOC." | The account was sold or migrated to BYO without MDR named as a separate line item. |
Before you raise a support case
It is hard to pinpoint an issue without looking at the platform itself.
Please work through these checks first to ensure your issue can be dealt with promptly:
1. Open the customer in Guardz and confirm whether SentinelOne is connected as BYO or Guardz-Managed.
2. Check the customer's plan. MDR is only available on Ultimate and Elite.
3. Confirm whether the MDR add-on is active on the account, not just assumed.
4. Review the Detection & Response queue for Incidents waiting on an MSP decision.
5. If the task needs advanced console work (exclusions, groups, threat hunting, forensics), go to the native S1 console.
If the account is BYO without MDR, the fix is a licencsing conversation, not a support ticket.
If it looks like the detection engine failed to detect a threat, please contact Manage Protect so we can escalate it to Guardz support.
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article