Gartner describes ISOC (Integrated Security Operations Center) as a converged technology approach that combines threat detection, investigation, and response (TDIR) in a single-vendor suite or cloud service.1 For Microsoft, that means Defender XDR and Microsoft Sentinel. This shift started a while ago with the move towards the unified security operations platform (USOP).
With ISOC, Microsoft 365 E5/E7 customers without Sentinel can now use features previously available only to customers using both Defender XDR and Microsoft Sentinel.
This post covers the ISOC preview. Capabilities and availability may change during the preview. See the official Microsoft Defender ISOC documentation and Microsoft’s announcement. Why Microsoft is doing this # You could already be a Sentinel customer without paying for the SIEM features: Sentinel lets you ingest some first-party Microsoft data, mainly alerts, as part of free data sources.
In my view, Microsoft is following the industry’s direction while also helping shape it. ISOC is now its own category in Gartner’s 2026 Hype Cycle for Security Operations, alongside security data lakes.2 Both are newer alternatives to a classic SIEM.
When speaking with customers and colleagues, I often encounter questions and misconceptions about Defender for Servers in Microsoft Defender for Cloud. In this post, I explore these questions:
Why should I care about Defender for Servers? How should I onboard my servers to Microsoft Defender for Servers? What happens under the hood when I onboard servers? How can I selectively deploy Defender for Servers (e.g., for a pilot)? How can I enforce and maintain full coverage of Defender for Servers? How can I monitor and query Defender for Servers coverage? Typical confusion of Defender for Servers Defender for Servers Plans and Licensing # While client devices in Microsoft Defender for Endpoint (MDE) are usually licensed through Microsoft 365 subscriptions such as Microsoft 365 E5, servers do not benefit from this licensing model. Instead, server licensing follows the Azure consumption model.
If you work with the Microsoft account team, you might also be able to obtain Microsoft Defender for Endpoint Server licenses. These are not consumption-based, so they do not require an Azure subscription and are usually part of enterprise agreements.
Uuuh, a phishing email, but actually a good one! That’s what caught my attention and led me to conduct a mini investigation into a device code phishing campaign in the wild, which turned out to be a recent version of Kali365.
Device Code Phishing Recap The attacker first starts a legitimate device code authentication request for a legitimate Microsoft first-party application. The victim is then tricked into entering the attacker’s device code on Microsoft’s real sign-in page and completing authentication, including MFA. Once approved, Entra ID issues the tokens to the attacker’s waiting session.
During a recent engagement I stumbled across an interesting observation: the Defender for Cloud Apps advanced hunting table CloudAppEvents was empty, even though the tenant had adopted Microsoft 365 collaboration and security tooling.
No events in the CloudAppEvents table The Microsoft 365 app connector was reported as healthy, with the initial connection dating back to 2022:
Healthy App Connector However, when opening the connector, none of the Microsoft 365 components were actually selected:
No components selected So either someone forgot to tick the boxes back in 2022, or Microsoft used different auto-provisioning defaults at the time.
This is also called out in the Microsoft docs 1:
In January 2026, the default values were added to support complete security coverage. If you configured your application before January 2026, make sure you select all of the default options and select Connect again to update your configuration.1
For maximum protection, we recommend selecting all Microsoft 365 components. Some threat detection and response functionalities don’t work unless all required components are properly selected.1
Interestingly, on another, more recently onboarded tenant where the connector had never been modified, all boxes were ticked except for file monitoring.
Enhanced Filtering for Connectors1 (aka skip listing) lets Exchange Online and Defender for Office 365 see the actual sender IP address instead of only the last hop. This is required so that MDO can verify message authentication attributes such as SPF, DMARC, and DKIM. Microsoft recommends it in its guides for third party mail flows2 3 to get the full value out of MDO.
Without enhanced filtering, MDO only sees your 3rd party gateway as the sender for incoming e-mails. As a result, you lose important sender metadata, which degrades your experience in Threat Explorer, Advanced Hunting, and the Tenant Allow/Block List.
The mail flow in the environment roughly looks like this, with the 3rd party gateway acting as the MX for inbound mail and as the smart host for outbound mail. Exchange Online is connected to an on-premises Exchange server via the hybrid connector:
flowchart LR Internet([Internet]) Gateway[3rd PartyMail GatewayMX record] EXO[Exchange OnlineDefender for Office 365] OnPrem[On-PremisesExchange Server] %% Inbound flow Internet --> Gateway Gateway -- "Partner connector+ Enhanced Filtering" --> EXO EXO -- "Hybrid connector" --> OnPrem %% Outbound flow OnPrem -. "Hybrid connector+ Enhanced Filtering" .-> EXO EXO -. "Partner connector" .-> Gateway Gateway .-> Internet classDef cloud fill:#e6f2ff,stroke:#0078d4,color:#000 classDef onprem fill:#fff4e6,stroke:#d97706,color:#000 classDef gw fill:#f3e8ff,stroke:#7c3aed,color:#000 class EXO cloud class OnPrem onprem class Gateway gw Following the Microsoft recommendation, enhanced filtering was enabled on both the 3rd party connector and the Exchange hybrid connectors.
