Microsoft Defender for Business: keep it, and let Qorionix act through it

If your Microsoft 365 subscription is Business Premium, you already own Microsoft Defender for Business, and on Windows it collects more from the kernel than our own sensor does. We are not going to ask you to switch it off. Instead, Qorionix reads the alerts Defender raises, turns them into incidents in the same queue as everything else, and — when a person approves it — asks Defender to isolate a machine or scan it. Our sensor stays useful for what Defender does not cover: Linux, macOS, and hosts that were never onboarded.

This article is for the person who administers Microsoft 365. It covers what to do in the Entra portal, exactly which permissions we ask for and why every one of them needs admin consent, what a Defender alert looks like once it is here, which response actions travel through Defender, and — because you will be asked — what data leaves the EU.

What the integration does

• Alerts become incidents. Every alert Defender raises for your tenant is read from Microsoft Graph and stored as a Qorionix alert. Alerts that Defender groups under one incident become one Qorionix incident. The import is keyed on Defender's alert id, so a re-read updates the record rather than duplicating it, and an alert Defender resolves as a false positive is closed here with a reason that says so.
• Devices are matched to your sensors. The list of machines Defender protects is read alongside the alerts and matched to any host running the Qorionix sensor by hostname. On the Endpoints screen a matched host carries a Protected by Defender label with a link into the Defender portal. Hosts Defender covers that have no sensor are listed on the Defender card under Integrations → Catalog.
• Three response actions run through Defender. Isolate, release from isolation, and a Defender Antivirus scan. They use the same ticket queue, the same approval, the same stop button and the same audit trail as an action on our own sensor. Qorionix never talks to a Defender-managed machine directly; it asks Defender.
• Defender alerts reach the SIEM. Each imported alert is published on the same path our sensor's detections use, so it is searchable under Logs and visible to Sentinel-Q triage like any other detection, with microsoft_defender as its source.

Setting it up in Microsoft Entra

You need one app registration. It is the same shape as the one the Microsoft 365 connection uses, but it holds different permissions, and two of them are on a different API. Five steps, all in the Microsoft Entra admin center.

1. 1

   Register an application

   Open App registrations → New registration. Any name; accounts in this organisational directory only. From the Overview page copy the Application (client) ID and the Directory (tenant) ID.

2. 2

   Add the four application permissions

   Under API permissions → Add a permission, choose Microsoft Graph → Application permissions and add SecurityAlert.Read.All. Then choose APIs my organization uses, search for WindowsDefenderATP, pick Application permissions and add Machine.Read.All, Machine.Isolate and Machine.Scan. Application, not delegated — there is no signed-in user behind a background poller, and a delegated grant authenticates cleanly and then reads nothing.

3. 3

   Grant admin consent

   Press Grant admin consent for <your tenant> and confirm. Every one of the four permissions requires it. Until it is granted the connection test names each missing permission by name, and nothing is imported.

4. 4

   Create a client secret

   Under Certificates & secrets → New client secret, choose an expiry and copy the Value column immediately — it is shown once. The Secret ID next to it is not the secret. Put the expiry date somewhere the renewal will be noticed; the connection stops on that day with an AADSTS7000222 error, not a warning.

5. 5

   Connect it in Qorionix

   Under Integrations → Catalog → Microsoft Defender for Business press Configure, paste the three values, choose Full or Selective isolation, and press Test and save. The test mints both tokens, reads the permissions off them, and then performs one real alert read and one real device read, so a licence problem or a Defender workload that is switched off is reported now rather than as an empty feed later.

The four permissions, and why

There is no Machine.ReadWrite.All requirement, no Machine.LiveResponse, no Machine.CollectForensics, and nothing on Graph beyond alert reading. The connection reads the roles claim off each token Microsoft issues — which is what Microsoft's own setup guide tells you to check — and refuses to act before any request is made if the role a verb needs is absent. A missing permission is a named setup error on the card, never a silent gap.

Vulnerability findings, as of 2026-09-21

If your Defender licence includes Threat & Vulnerability Management, the same connection can also pull vulnerability data: the org-wide CVE catalogue Defender has found across your fleet, and per-device findings, both exported into the same exposure screen the Qorionix sensor's own scanning and any connected vulnerability scanner feed. This needs one more permission on the existing app registration.

1. 1

   Add the Vulnerability.Read.All permission

   On the same app registration you already created above, go to API permissions → Add a permission → APIs my organization uses → WindowsDefenderATP → Application permissions, and add Vulnerability.Read.All.

2. 2

   Grant admin consent again

   Press Grant admin consent for <your tenant>. Until this is granted, the connection's vulnerability import is refused with the missing permission named — the same fail-closed behaviour as the four original permissions, exercised on the connection's health check so a missing grant is visible immediately.

3. 3

   Press Test on the existing connection

   No need to reconnect or re-enter the client secret. Testing re-reads the token's permissions and, once the fifth permission is present, pulls findings on the same poll as everything else.

What a Defender alert looks like here

On Response → Incidents, an incident that came from Defender carries a From Microsoft Defender label and an Open in Defender link. The detail view adds the hosts and MITRE ATT&CK techniques Defender named, and says plainly that Defender keeps the full alert story and device timeline — this incident holds what was imported. Resolving an incident here does not change it in Defender, and Defender resolving one is reflected here on the next poll.

Severity maps directly: Defender's high, medium and low become ours. A high alert Defender has classified as a true positive is escalated to critical so it sorts to the top. Informational alerts arrive as low. Alerts are polled every two minutes using Defender's own last-updated timestamp as the watermark, with a one-minute overlap so an alert updated in the same second as the last one read is not skipped.

The Defender card under Integrations → Catalog shows the polling health for each connection — when it last ran, what it found, and the last error if there was one — plus a Poll now button, and the counts of devices, devices also running the sensor, alerts and incidents. If the poll has not run yet the card says so rather than showing zeros as if they were an answer.

Acting through Defender

A Defender-managed device is a response target like any other. The three verbs available for it, and the path each one takes:

Isolate via Defender

Raises a live-response ticket in pending approval. A second operator approves it on Tickets. Only then does the dispatcher call Defender's isolate API in the mode set on the connection — Full, or Selective if Outlook and Teams should keep working — with your reason as the action comment. The ticket moves to dispatched, and to completed when Defender reports the isolation is in place. See Isolating a machine for what isolation costs the person at the keyboard.

Release from isolation

The same one-step reversal our sensor has: the operator pressing the button is the approver, and the release is dispatched at once. Defender confirms it in its own action centre.

Antivirus scan

Runs the tenant's Microsoft Defender antivirus scan response action, which requires approval, so it is recorded with who vouched and why. The execution stays pending until Defender reports the scan finished, then is marked complete.

Sentinel-Q's automatic responses and playbooks use the same executor. When an isolate action targets a host that Defender manages, it is carried out through Defender; when it targets a host that only runs our sensor, it goes to the sensor. The tenant stop button halts both. Commands Defender cannot perform for us — kill a process, quarantine a file, collect forensics — are refused on a Defender-only host with a message saying so, rather than left approved and undone.

What leaves the EU

This integration talks to Microsoft, so some traffic necessarily leaves your Qorionix cell. Here is exactly what, and where it goes.

Everything Qorionix stores — the imported alerts and their evidence, the device list, tickets, execution records and audit rows — stays in your EU cell, alongside the rest of your tenant. See Where your data lives for the general position. What the integration cannot change is where Microsoft keeps Defender's own data; that is governed by your Microsoft 365 tenant's data location, not by us.

When it goes wrong

The test says a permission is missing, and names it

Admin consent was not granted, or the permission was added as delegated. Open the app registration's API permissions page: each of the four must show a green tick under Status. Broader roles you already granted (SecurityAlert.ReadWrite.All, Machine.ReadWrite.All) satisfy the read permissions and are not reported missing.

Graph token acquired but the Defender API refused to issue one

The WindowsDefenderATP permissions were never added, so Entra has no resource to issue a token for (AADSTS500011). Add them under APIs my organization uses and grant consent.

Connected, but no alert visible yet

The permissions are right and Defender has nothing to report, or the alert sources filter excludes everything. Clear Alert sources to import under Advanced settings, or raise a test detection on an onboarded device.

No onboarded device visible yet

Defender's machine list is empty for this tenant. Devices must be onboarded to Defender in the Microsoft 365 Defender portal first; Qorionix does not enrol them.

The poll stopped, and the card shows AADSTS7000222

The client secret expired. Create a new one, press Edit on the connection and paste only the new secret; the other fields stay as they were.

An isolate ticket is approved but stays dispatched

Defender accepted the request and has not finished. The dispatcher checks the machine action every minute; a device that is offline stays pending on Defender's side until it next checks in. The Defender portal's action centre shows the same state.