Nieuwe Defender XDR features vanaf april 2026, met praktische impact op attack disruption, identity security, AI agents, hunting en de nieuwe ISOC richting.
Microsoft Defender XDR verandert in 2026 sneller dan veel SOC teams bijhouden. Sinds Q2 zijn er niet alleen losse features bijgekomen. Microsoft trekt incident response, threat intelligence, identity security, AI agent security en delen van SIEM steeds dichter naar elkaar toe in dezelfde Defender portal. Dat klinkt als een portalverhaal, maar in de praktijk verandert het vooral hoe je triage, hunting en response inricht.
Ik zie dit vaak bij klanten. Defender XDR staat technisch goed aan, maar het SOC proces is nog gebaseerd op de situatie van een jaar geleden. Analisten werken vanuit dezelfde incident queue, gebruiken dezelfde hunting queries en hebben dezelfde alert tuning regels. Nieuwe platformmogelijkheden worden dan wel uitgerold, maar leveren weinig op omdat niemand het proces eromheen aanpast.
Vanaf april 2026 zie je drie duidelijke lijnen. Automatische response wordt agressiever en beter zichtbaar. Identity wordt een volwaardig onderzoeksperspectief binnen Defender. Security for AI groeit van inventarisatie naar posture, detection en runtime protection. Daarbovenop kwam in september de preview van Integrated Security Operations Center, ISOC, waarmee Microsoft XDR en SIEM nog verder in dezelfde werkomgeving trekt.
In deze blog loop ik door de wijzigingen die er voor een technisch SOC echt toe doen. Niet alleen wat Microsoft heeft toegevoegd, maar vooral wat jij moet controleren in je tenant, welke queries je moet aanpassen en waar je operationele proces kan breken als je niets doet.
Waarom dit onderwerp nu speelt
De klassieke scheiding tussen endpoint, identity, email, cloud en SIEM wordt kleiner. Defender XDR was al een correlatielaag, maar in 2026 zie je dat de portal steeds meer de plek wordt waar signalen worden verrijkt, acties worden uitgevoerd en nieuwe typen assets worden onderzocht. Microsoft positioneert dat niet meer alleen als XDR. Met ISOC wordt het expliciet een geïntegreerde SecOps omgeving waarin XDR, SIEM, threat intelligence, automation en AI samenkomen.
Dat heeft gevolgen voor architectuurkeuzes. Als je Sentinel al actief gebruikt, blijft dat in deze fase gewoon je bestaande route. De ISOC preview die op 23 september 2026 is aangekondigd, is juist bedoeld voor in aanmerking komende Microsoft Defender Suite, Microsoft 365 E5 en Microsoft 365 E7 klanten zonder actieve Microsoft Sentinel workspace. Voor workspace afhankelijke functies heb je ook een Azure subscription nodig. Tijdens de preview is er voor bepaalde Defender data 30 dagen inbegrepen retentie, maar extra Microsoft en niet Microsoft data kan ingestiekosten veroorzaken.
Mijn advies is daarom om Defender XDR niet meer te beoordelen als een set losse producttabbladen. Kijk naar je complete SOC flow. Welke signalen komen binnen. Welke context wordt automatisch toegevoegd. Welke acties kan Defender zelf uitvoeren. Welke data wil je huntbaar houden. Welke alerts worden door tuning of behavior omzetting uit de queue gehaald. En welke licenties zijn nodig om nieuwe agent security functies in stand te houden.
De belangrijkste wijzigingen vanaf Q2 2026
| Periode | Feature | Status | Praktische impact |
| April 2026 | Built in alert tuning rules | GA | Minder benign alerts zonder AIR en mailnotificaties uit te schakelen. |
| April 2026 | Status van attack disruption en predictive shielding in incident Activities | Preview | Analisten zien containment acties direct in incidentcontext. |
| Mei 2026 | Automatische device isolation door attack disruption | Preview | Gecompromitteerde foothold kan automatisch van het netwerk worden geïsoleerd. |
| Mei 2026 | Identity scenarios in hunting graph en Defender Chat | Feature update en Preview | Sneller attack paths onderzoeken en vragen stellen in natuurlijke taal. |
| Juni 2026 | Threat Intelligence Insights op entity pages | Preview | Reputatie, threat reports, relaties en sandbox context in dezelfde onderzoekspagina. |
| Juni 2026 | Local AI agent discovery en runtime protection | Preview | Lokale agents op Windows endpoints worden zichtbaar en riskante agentacties kunnen worden geblokkeerd. |
| Juni 2026 | DisruptionAndResponseEvents | GA | Attack disruption events zijn direct huntbaar in Advanced Hunting. |
| Juni 2026 | AgentsInfo vervangt AIAgentsInfo | Preview en schemawijziging | Externe queries en API integraties moeten zijn gemigreerd. |
| Juli 2026 | AI agent posture risk | Preview | Agents krijgen risiconiveau op basis van configuratie, toegang, runtime context en actieve alerts. |
| Juli 2026 | Domain investigation page | GA | AD domeincontext, service accounts, GPOs, trusts en aanbevelingen in één onderzoekspagina. |
| Juli 2026 | Threat detection voor Microsoft Agent 365 agents | Preview | Runtime signalen van agentinteracties worden onderdeel van incidenten en hunting. |
| Juli 2026 | Real time protection voor Agent 365 tooling servers | GA | Tool calls via Work IQ MCP en ondersteunde customer MCP tools kunnen worden toegestaan of geblokkeerd. |
| September 2026 | Identity Security dashboard en Coverage and Maturity | GA | Identity posture en coverage worden centrale operationele stuurinformatie. |
| September 2026 | ISOC in Microsoft Defender | Preview | XDR, SIEM, threat intelligence, automation en AI komen verder samen in Defender. |
| Begin oktober 2026 | Built in DLP alert tuning | Uitrol | Bepaalde DLP signalen worden behaviors in plaats van alerts en verdwijnen uit de incident queue. |
April en mei, minder ruis en snellere containment
De GA release van built in alert tuning rules in april lijkt klein, maar heeft veel impact op een drukke incident queue. Defender kan bekende benign activiteiten uit Defender for Endpoint en Defender for Office 365 onderdrukken zonder AIR onderzoeken en e mailnotificaties uit te schakelen. Als AIR later alsnog malicious of suspicious activity vindt, kan de alert opnieuw actief worden. Dit geeft je een andere manier om ruis te verlagen dan een eigen regel die alles simpelweg wegfiltert.
Controleer deze regels wel actief. In de praktijk gaat dit vaak mis bij teams die alertvolume als enige KPI gebruiken. Minder alerts is niet automatisch beter. Je wilt weten welke signalen naar behaviors verschuiven, welke detections nog incidents maken en welke hunting data beschikbaar blijft. Built in tuning geldt ook niet voor alles. Custom detections en Custom TI vallen er bijvoorbeeld buiten.
In mei werd automatic attack disruption uitgebreid met automatische device isolation in preview. Dit is een stap verder dan een device contain actie. Als Defender met hoge confidence bepaalt dat een device als actieve foothold wordt gebruikt, kan het systeem het device tijdelijk van het netwerk isoleren. De verbinding met noodzakelijke security services blijft bestaan. Een operator kan de isolatie weer vrijgeven.
Dit klinkt klein, maar heeft impact op je SOC proces. Zodra een platform zelfstandig een device isoleert, moet je runbook drie dingen afdekken. Je analist moet kunnen zien waarom de actie is uitgevoerd. Je moet weten wie de actie mag terugdraaien. En je moet kunnen onderzoeken wat er vlak voor en na de isolatie gebeurde. De Activities tab in het incident en de DisruptionAndResponseEvents tabel helpen juist bij die uitlegbaarheid.
De architectuur verschuift naar een geïntegreerde protection loop
Onderstaand diagram laat zien hoe de nieuwe features samenkomen. Het gaat niet om één feature, maar om de keten van signalen, context, hunting en automatische response.

Diagramvoorstel, Defender XDR als geïntegreerde SecOps flow vanaf Q2 2026.
Microsoft gebruikt in de ISOC positionering het idee van een integrated protection loop. Voor een SOC betekent dat dat signalen niet alleen naar een incident leiden. Context uit threat intelligence en exposure management kan bepalen welke actie relevant is. Response acties leveren vervolgens nieuwe telemetry op. Die telemetry kun je weer gebruiken voor hunting en verdere bescherming.
Attack disruption is daar een goed voorbeeld van. Defender gebruikt meerdere signalen om een lopende aanval te herkennen en kan vervolgens devices, users of netwerktoegang beperken. Vanaf juni 2026 is de DisruptionAndResponseEvents tabel GA. Daarmee kun je een deel van de resultaten van Defender for Endpoint gebaseerde disruption controls direct onderzoeken in Advanced Hunting.
Let op de grens van die tabel. DisruptionAndResponseEvents laat niet elke uitvoeringsactie zelf zien. Microsoft noemt expliciet dat acties zoals contain user of disable user niet als uitvoering in deze tabel staan. De tabel toont vooral outcomes en policy events voor Defender for Endpoint controls. Voor het volledige actieverloop blijft het Action Center belangrijk.
KQL voorbeeld, attack disruption onderzoeken
Met deze query krijg je een operationeel overzicht van recente disruption events. Gebruik hem als startpunt en pas ActionType filters aan op je eigen tenant.
DisruptionAndResponseEvents
| where Timestamp > ago(7d)
| summarize Events=count(),
FirstSeen=min(Timestamp),
LastSeen=max(Timestamp),
SourceDevices=dcount(SourceDeviceId),
TargetDevices=dcount(TargetDeviceId)
by ActionType
| order by Events desc
Voor een incident kun je daarna filteren op DeviceId, SourceDeviceId, TargetDeviceId of DeviceName. Combineer de query met incidenttijdlijn, Action Center en device timeline. Zo voorkom je dat je alleen ziet dat er iets is geblokkeerd, maar niet begrijpt welke aanvalsketen Defender probeerde te stoppen.
Identity Security wordt een volwaardig onderzoeksperspectief
Identity kreeg in 2026 een veel prominentere plek in Microsoft Defender. In maart begon de preview van het Identity Security dashboard en Coverage and Maturity. Vanaf september 2026 noemt Microsoft beide mogelijkheden GA. Dat is belangrijk, omdat identity risk hiermee niet meer alleen een verzameling Defender for Identity alerts en Entra signalen is. Het wordt ook posture en coverage management.
Het Identity Security dashboard geeft een centrale weergave van identity gerelateerde risico’s en posture. Coverage and Maturity helpt je zien hoe goed je omgeving is afgedekt over on premises identity, cloud, SaaS, identity providers en ondersteunde partnertechnologie. In juni kwam daar een Human identities kaart bij die human identities per bron groepeert. In juli werd de Domain investigation page GA.
Die Domain investigation page is vooral nuttig voor hybride omgevingen. Je ziet er domeineigenschappen, deployment health, identity samenvattingen, service accounts, sensitive entities, aanbevelingen, group policies en trust relationships. Daarmee kan een analist bij een identity incident sneller van een user of host naar de domeincontext gaan zonder direct meerdere consoles te openen.
In mei kreeg ook de hunting graph nieuwe identity scenarios. Denk aan Kerberoast en AS REP roast paths, routes richting domain compromise, OAuth application risk en guest access naar cloud resources. Mijn advies is om deze grafische hunts niet als vervanging van KQL te zien. Gebruik ze om relaties en attack paths te vinden. Gebruik KQL daarna om tijd, volume en concrete eventdetails te valideren.
Security for AI gaat van inventarisatie naar runtime control
De snelste verandering zit bij AI agents. In april werd AIAgentsInfo uitgebreid met meer velden en ondersteuning voor meer agenttypen. In juni kondigde Microsoft de overgang naar de nieuwe AgentsInfo tabel aan. Die tabel moet uiteindelijk het uniforme schema worden voor agent inventory en governance voor Copilot Studio, Microsoft Foundry, Microsoft 365 Copilot, third party agents en endpoint discovered agents.
Die schemawijziging had een harde datum. AIAgentsInfo bleef volgens Microsoft toegankelijk tot 1 juli 2026. Queries die in Defender zelf zijn opgeslagen, inclusief custom detections, worden bij naming changes automatisch aangepast. Queries via API’s en queries die buiten Defender zijn opgeslagen, moet je zelf aanpassen. Dit is precies het soort wijziging dat een SOC pas merkt als een workbook, Logic App of externe hunting pipeline ineens geen data meer krijgt.
Vanaf 1 juli 2026 veranderde ook de licensing. Security capabilities voor Microsoft Copilot Studio en Microsoft Foundry agents vereisen een Microsoft Agent 365 eligible license. Bestaande dekking vanuit Defender for Cloud Apps of Defender for Cloud is hiervoor niet meer genoeg. Zonder geschikte licentie verlies je agent level discovery, posture en delen van threat detection en runtime protection. Defender CSPM kan Foundry accounts en projects nog steeds ontdekken, maar agent level functies schuiven naar Agent 365.
Er zit nog een belangrijk operationeel punt in die overgang. Microsoft waarschuwde dat bestaande Agent 365 rules die op Block stonden vanaf 1 juli 2026 stoppen met blokkeren. Om blocking te behouden moet je de rules opnieuw definiëren in de nieuwe real time protection policy experience onder Settings, Security for AI, Policies and rules, Real time protection. Als je dat niet hebt gecontroleerd, kun je denken dat je runtime enforcement actief is terwijl je in feite alleen observability overhoudt.
In juni kwam local AI agent discovery op Windows endpoints in preview. Defender kan ondersteunde coding agents, IDE extensions, desktop assistants, lokale runtimes en agent platforms detecteren op onboarded Windows devices. Die agents verschijnen als assets in inventory, exposure map en Advanced Hunting. Ook local AI agent runtime protection kwam in preview. Defender kan delen van de agent loop inspecteren, waaronder prompts, tool calls en responses, en riskante activiteit blokkeren voordat die wordt uitgevoerd.
In juli volgden drie stappen. AI agent posture risk kwam in preview. Threat detection voor Microsoft Agent 365 agents kwam in preview. Real time protection voor Microsoft Agent 365 tooling servers werd GA. Defender kan bij ondersteunde Agent 365 scenario’s tool invocations en responses tegen security policies beoordelen en interacties toestaan of blokkeren. De dekking hangt af van de agent en tooling. Voor Work IQ MCP en ondersteunde customer MCP tools is er directe integratie. Niet elke tool of agent valt automatisch onder dezelfde bescherming.
| Praktijkpunt. Maak AI agent security onderdeel van je asset en identity governance. Een agent is niet alleen een app. Hij kan een identity hebben, permissions krijgen, data benaderen, tools aanroepen en autonoom acties uitvoeren. Dat betekent dat discovery zonder ownership en policy niet genoeg is. |
KQL voorbeeld, je AI agent inventory controleren
De AgentsInfo tabel is nog preview. De onderstaande query gebruikt alleen velden die Microsoft in het schema documenteert. Hij geeft per agent de meest recente record terug en laat zien welke platformen, modellen, permissions en tools je moet beoordelen.
AgentsInfo
| where Timestamp > ago(30d)
| summarize arg_max(Timestamp, *) by AgentId
| project Timestamp,
AgentName,
Platform,
Model,
ToolsAuthenticationType,
Permissions,
DeclaredDataSources,
DeclaredTools,
McpServers
| order by AgentName asc
Gebruik deze output niet als compliance rapport zonder verdere normalisatie. Meerdere velden zijn dynamic en kunnen per platform verschillen. Voor governance is het nuttiger om een baseline te maken met toegestane platformen, verwachte permissions en bekende MCP servers, en daar afwijkingen tegen te controleren.
Threat intelligence komt dichter bij je onderzoek
Vanaf juni 2026 kunnen entity pages voor IP adressen, domains, URLs en files in preview een Threat Intelligence Insights tab tonen. Daarin brengt Microsoft threat intelligence context direct naar de entity die je onderzoekt. Voorbeelden zijn reputation scores, attributed threat reports, infrastructure relationships en sandbox analysis.
Voor een analist scheelt dit context switching. Het belangrijkste voordeel is niet dat er meer data is, maar dat dezelfde entity in incidentcontext, observatie in je eigen omgeving en externe intelligence naast elkaar kan worden beoordeeld. Bij een IP adres wil je niet alleen weten dat het malicious is. Je wilt weten welke devices ermee hebben gecommuniceerd, in welke incidents het voorkomt, welke infrastructuurrelaties bekend zijn en of het gedrag past bij de rest van de aanval.
Ik zou deze enrichment daarom ook verwerken in je triage checklist. Laat analisten bij high severity incidents niet alleen naar de alert evidence kijken. Laat ze relevante IP, URL, domain en file entities openen en de threat intelligence context controleren voordat ze een indicator blokkeren of een incident sluiten.
Defender Chat helpt, maar verandert je kwaliteitscontrole niet
In mei verscheen Defender Chat in preview. Dit is een open prompt chat experience in Microsoft Defender waarmee analisten incidenten kunnen verkennen en securityvragen in natuurlijke taal kunnen stellen. Het verlaagt de drempel voor een analyst die niet direct weet welke view of query nodig is.
Ik zou dit vooral gebruiken voor versnelling, niet als eindbeslisser. Een junior analyst kan sneller de juiste onderzoekshoek vinden. Een senior analyst kan context laten samenvatten en daarna zelf de onderliggende evidence controleren. Voor detectie engineering blijft het belangrijk dat je querylogica, tabellen en filters begrijpt. Als een query uit een assistent komt, moet je nog steeds controleren of de tijdsrange, joins en entity mapping kloppen.
Hetzelfde geldt voor triage agents. In juni beperkte Microsoft de e mail permission van de Phishing Triage Agent en Security Alert Triage Agent. In plaats van toegang tot alle e mailcontent gebruiken deze agents nu een least privilege permission voor e mails die aan alerts zijn gekoppeld. Dat is een goede security verbetering en een nuttige reminder. AI in je SOC moet niet alleen slim zijn. De permissions moeten ook zo klein mogelijk blijven.
De oktoberwijziging voor DLP verdient extra aandacht
Een actuele wijziging die makkelijk tussen de release notes verdwijnt, zit bij Microsoft Purview DLP alerts in Defender XDR. Microsoft documenteert dat begin oktober 2026 een built in alert tuning rule voor DLP signals ingaat. Die rule zet de betreffende signals als behaviors in plaats van alerts. Daardoor genereren ze geen alerts en verschijnen ze niet in de incident queue. De data blijft wel beschikbaar voor Advanced Hunting in BehaviorInfo en BehaviorEntities.
Dit is precies waarom je incident queue niet je enige bron van waarheid mag zijn. Als een SOC rapport alleen telt hoeveel DLP alerts in Defender zijn verschenen, kan je trend na de tuning wijziging ineens dalen terwijl het onderliggende gedrag niet is verdwenen. Wil je DLP signals als alerts blijven zien, dan kun je de built in rule uitschakelen via Settings, Microsoft Defender XDR, Alert tuning.
Voordat je die rule uitschakelt, bepaal eerst waarom je DLP signals als alerts nodig hebt. Als je SOC alle data loss signalen handmatig behandelt, kan het logisch zijn. Als je Purview team de primaire workflow doet en Defender vooral voor cross domain correlation wordt gebruikt, kan behavior data juist voldoende zijn. Maak die keuze bewust en leg hem vast in je operating model.
KQL voorbeeld, DLP gerelateerde behaviors volgen
De exacte service waarden kunnen per tenant en data source verschillen. Gebruik deze query als discovery query en verfijn daarna de filters op basis van de waarden die je in jouw tenant ziet.
BehaviorInfo
| where Timestamp > ago(7d)
| where DataSources has “Purview”
or Title has “DLP”
or Description has “data loss”
| project Timestamp,
Title,
Categories,
AttackTechniques,
AccountUpn,
DeviceId,
ServiceSource,
DetectionSource,
AdditionalFields
| order by Timestamp desc
ISOC in Defender is meer dan een nieuwe naam voor Sentinel
Op 23 september 2026 kondigde Microsoft Integrated Security Operations Center in Microsoft Defender aan. ISOC is op dit moment preview. Het brengt XDR, SIEM, threat intelligence, automation en AI verder samen in de Defender portal. Voor organisaties die al Microsoft Sentinel gebruiken is het belangrijk om niet zomaar een bestaande productie workspace los te koppelen. Microsoft zegt expliciet dat klanten met een actieve Sentinel workspace in deze fase hun bestaande Sentinel experience moeten blijven gebruiken.
Voor in aanmerking komende tenants zonder actieve Sentinel workspace kan ISOC een andere startpositie geven. Case management, workbooks, natural language playbook generation en enhanced automation rules kunnen onderdeel van de ervaring zijn. Voor functies zoals extra Microsoft en non Microsoft data ingest, UEBA, Content hub, repositories en bepaalde threat intelligence mogelijkheden is een ISOC workspace nodig.
Mijn advies is om dit in 2026 vooral als architectuurontwikkeling te volgen. Ga niet migreren omdat er een nieuwe knop staat. Breng eerst in kaart welke Sentinel data connectors, analytics rules, workbooks, automation rules, Logic Apps, repositories en retention requirements je nu hebt. Vergelijk die met wat ISOC in jouw tenant en licentie werkelijk ondersteunt. Preview is geen productiegarantie.
Voor teams die nog geen Sentinel hebben, is de vraag interessanter. Je kunt nu een deel van de SIEM workflow dichter bij Defender krijgen zonder direct met dezelfde traditionele scheiding te starten. Dat kan beheer vereenvoudigen, maar je moet nog steeds goed naar data ingest, retention, billing en use cases kijken. Een SOC architectuur wordt niet eenvoudiger alleen omdat de portal één geheel lijkt.
Zo pas je je SOC operating model aan
De features vanaf Q2 2026 vragen vooral om procesaanpassingen. Ik zou niet beginnen met het aanzetten van alles. Begin met het zichtbaar maken van veranderingen die invloed hebben op detection en response. Daarna pas je runbooks en ownership aan.
Stap één is alert tuning governance. Exporteer of documenteer je built in en custom alert tuning regels. Leg vast welke signalen worden verborgen, resolved of omgezet naar behaviors. Controleer specifiek de DLP wijziging in oktober. Koppel hier een eigenaar aan. Een tuning rule zonder eigenaar blijft vaak jaren staan terwijl de detectielogica eromheen verandert.
Stap twee is automatic response governance. Controleer attack disruption prerequisites, rollen en settings. Leg vast wie device isolation mag releasen en wanneer. Laat analisten in runbooks de incident Activities tab en Action Center controleren. Bouw daarnaast hunting queries rond DisruptionAndResponseEvents om trends in automatische disruption te volgen.
Stap drie is identity coverage. Gebruik Coverage and Maturity niet alleen als dashboard voor management. Koppel openstaande coverage gaps aan concrete technische acties. Denk aan ontbrekende sensors, niet ondersteunde identity sources, service accounts zonder duidelijke owner en trusts die extra onderzoek nodig hebben.
Stap vier is AI agent inventory. Zoek uit welke agents je al hebt, wie eigenaar is, welke permissions ze gebruiken, welke data sources ze kunnen benaderen en welke tools of MCP servers ze aanroepen. Controleer je Microsoft Agent 365 licensing en verifieer dat real time protection policies na 1 juli opnieuw correct zijn ingesteld waar blocking nodig is.
Stap vijf is hunting lifecycle management. Zoek niet alleen naar queries in Defender. Zoek ook in Git repositories, Logic Apps, notebooks, APIs, workbooks en scripts die oude schemanamen gebruiken. De overgang van AIAgentsInfo naar AgentsInfo is een goed voorbeeld. Microsoft kan saved Defender queries automatisch aanpassen, maar je externe code niet.
Veelgemaakte fouten die ik nu zou voorkomen
- Alle preview features behandelen alsof ze productie klaar zijn. Preview kan veranderen en heeft vaak tenant of platform beperkingen.
- Aannemen dat minder alerts betekent dat je minder risico hebt. Alert tuning en behavior omzetting kunnen de queue rustiger maken terwijl data nog steeds aanwezig is.
- Attack disruption aanzetten zonder duidelijke release procedure. Automatische isolation is krachtig, maar operationeel moet iemand weten wat te doen als een business critical device wordt geraakt.
- Alleen de Defender portal controleren op oude schemanamen. Externe API queries en scripts worden niet automatisch gemigreerd.
- AI agents als gewone apps behandelen. Agents kunnen identities, permissions, tools, data en autonome acties combineren.
- ISOC zien als directe vervanger van elke Sentinel architectuur. In september 2026 is ISOC preview en de eligibility is beperkt.
- Identity dashboards alleen als reporting gebruiken. De meeste waarde zit in coverage gaps, service account exposure, domain context en concrete remediation.
- Threat intelligence context bekijken maar niet verwerken in de response beslissing. Een enrichment tab heeft pas waarde als die bepaalt of je verder hunt, blokkeert of escaleert.
Praktische checklist voor je Defender XDR tenant
- Controleer built in alert tuning rules en documenteer welke signalen niet meer als alert in de queue verschijnen.
- Controleer de DLP tuning rule die begin oktober 2026 wordt uitgerold en bepaal of DLP signals alerts of behaviors moeten zijn in jouw operating model.
- Controleer automatic attack disruption settings, prerequisites en rollen voor release van containment of isolation.
- Maak minimaal één Advanced Hunting query op DisruptionAndResponseEvents en voeg die toe aan je incident response toolkit.
- Controleer of AIAgentsInfo nog ergens buiten Defender wordt gebruikt. Migreer naar AgentsInfo waar nodig.
- Valideer Microsoft Agent 365 licensing voor agent discovery, posture, threat detection en runtime protection.
- Controleer real time protection policies voor Agent 365 en bevestig dat gewenste Block rules na 1 juli 2026 opnieuw zijn ingericht.
- Open het Identity Security dashboard en Coverage and Maturity. Maak een backlog van echte coverage gaps.
- Test de Domain investigation page op je belangrijkste Active Directory domains en verwerk deze view in identity incident runbooks.
- Test Threat Intelligence Insights op IP, domain, URL en file entities en update je triage checklist.
- Evalueer Defender Chat in preview met duidelijke analyst guidance. Laat altijd onderliggende evidence en queryresultaten controleren.
- Als je geen actieve Sentinel workspace hebt, beoordeel of je tenant voor ISOC preview in aanmerking komt. Maak eerst een use case en kostenanalyse voordat je data aansluit.
Mijn advies voor de komende maanden
Als ik één prioriteit moet kiezen, dan is het niet ISOC en ook niet Defender Chat. Begin bij de features die direct je detectie en response gedrag veranderen. Dat zijn alert tuning, automatic attack disruption en de Agent 365 migratie. Die drie kunnen invloed hebben op wat je analisten zien, wat Defender automatisch doet en welke controls na een licensing of policy wijziging nog actief zijn.
Daarna zou ik Identity Security en Security for AI als vaste werkstromen inrichten. Niet als losse projecten. Identity blijft de verbindende laag in veel moderne aanvallen. AI agents worden nieuwe assets met eigen permissions en runtime gedrag. Beide horen daarom in dezelfde SOC governance als endpoints, apps en service principals.
ISOC is de ontwikkeling om te volgen voor je langere termijn architectuur. Microsoft maakt de richting duidelijk. Minder losse security operations eilanden, meer gedeelde context, automation en response in Defender. Maar preview blijft preview. Maak beslissingen op basis van je huidige use cases, retention, data ingest en operationele afhankelijkheden, niet op basis van productpositionering alleen.
Conclusie
Defender XDR vanaf Q2 2026 is vooral interessant omdat meerdere lijnen tegelijk volwassen worden. Attack disruption wordt actiever. Identity wordt centraler. Threat intelligence schuift de onderzoekspagina in. AI agent security krijgt inventory, posture, detection en runtime controls. Hunting krijgt nieuwe schema’s en datasets. En ISOC laat zien dat Microsoft XDR en SIEM nog verder naar één operationeel model wil brengen.
Voor je SOC zit de winst niet in het aantal nieuwe features dat je kunt aanzetten. De winst zit in het aanpassen van je runbooks, hunting content, permissions, licensing checks en ownership. Controleer wat automatisch verandert. Controleer welke preview features je echt nodig hebt. En zorg dat je analisten begrijpen waar data blijft bestaan als een signal niet meer als alert in de incident queue verschijnt.
Volg ITCowboys voor de volgende technische deep dive. In de komende blogs pak ik meer Microsoft Security, XDR, Sentinel, Identity en Purview onderwerpen op vanuit de praktijk.