The documentation now explains how to grant Microsoft Sentinel permissions to delegated remote tenant groups through Defender URBAC, including required permissions, role assignment, and workspace selection. It also retains the resource-group assignment option and clarifies management-plane versus data-plane access.

The user investigation documentation revises its authoring reference links and changes `GraphApiAuditEvents` to `GraphAPIAuditEvents`.

The document’s listed author changed from monaberdugo to kschwabacher.

Microsoft Defender for Cloud Apps will update App Governance permissions for select Microsoft Entra roles starting mid-November 2026. Changes include role-based access control alignment with Defender XDR, affecting Cloud App Security, Compliance Administrator, and Compliance Data Administrator roles. Admins should review and update role assignments accordingly.

The page now lists Crystal Typhoon and Storm-2380, Storm-2570, Storm-2634, Storm-2990, Storm-2992, Storm-3069, Storm-3119, Storm-3168, and Storm-3189, including available aliases, classifications, and reference links. The page date was also updated and two internal authoring links were removed.

The documentation now states that block events from Microsoft Prompt Shields for Foundry, Copilot Studio, and Copilot Agent Builder are recorded as behaviors.

Administrators can select specific detection sources within service sources when creating or editing alert tuning rules, including include/exclude choices for existing rules.

The `AadDeviceId` column is being replaced by `EntraIdDeviceId`. `AadDeviceId` will remain available for 30 days to support query updates.

The page’s author metadata changed from EdB-MSFT (edbaynash) to Karinschwabacher13 (kschwabacher).

The document’s `ms.author` value changed from `pauloliveria` to `kschwabacher`.

The table reference replaces DnsEventType and DnsEventSubType with EventType and EventSubType, and updates the request-filter example accordingly.

Updated October 19, 2026: We have identified that this message did not reach it's intended audience. You can safely disregard this message, and we apologize any confusion this may have caused.

The what's new documentation now uses the table name `GraphAPIAuditEvents` when describing Microsoft Entra ID API requests to Microsoft Graph API.

The Defender for Endpoint What's New page now lists macOS release version 20.126082.12.0 as GA and links to its enhancements and features.

The documentation now covers Windows, Linux client and server, macOS, Android, and iOS offboarding. It also distinguishes subscription-wide Azure server offboarding from manual individual-server offboarding and clarifies that offboarding does not uninstall software.

The macOS 101.26082.0012 release adds EDR support for configuring AI agent runtime protection, plus Bluetooth permission and antivirus health reporting improvements, accessibility updates, reliability fixes, and performance fixes.

The Windows Defender Antivirus documentation now lists `DefenderSessionHelper.exe` in the Details tab for Microsoft Defender Clipboard Protection, with Processes and Services marked N/A. The page date and reviewer metadata were also updated.

The article now distinguishes automatic Azure offboarding, Defender for Servers coverage changes, manual endpoint offboarding, and endpoint software removal. It adds preparation steps, verification guidance, package-handling details, and method-specific procedures for Linux and Windows.

The documentation now lists Linux release 101.26091.0003, including updated release, engine, and signature versions. It also documents a libcurl 8.22.0 upgrade addressing CVE-2026-9546 and stronger quarantine authorization and path protections.

The page now links new deployments to server onboarding guidance and on-premises server connections to Defender for Servers, including automatic or manual deployment options and onboarding verification.

The documentation now clarifies that the mobile threat defense connector is the Defender for Endpoint–Intune integration, separates assignment steps, and refers to the automatic-launch control as a switch.

The page now lists supported Defender configuration areas, clarifies the onboarding and Managed Google Play prerequisites, and updates the Intune policy creation link and wording.

The page revises privacy wording, terminology, punctuation, and descriptions of collected data. The required-data list no longer includes basic browser information.

The page now describes the refreshed Android interface, including dashboards, feature tiles, alert cards, and the Device Protection feature card. It also clarifies the separate feedback and log-submission flows and updates screenshot descriptions, wording, and formatting.

The server onboarding page now links to `offboard-machines` instead of the `#offboard-servers` fragment.

The guide now distinguishes automatic onboarding, manual deployment, and servers already reporting to Defender for Endpoint. It adds prerequisites, rollout preparation guidance, antivirus coexistence considerations, and a warning that Direct onboarding has tenant-wide scope.

The page author metadata changed from paulinbar/painbar to limwainstein. The uninstall guidance continues to direct administrators to the Offboard Mac devices documentation for cleanup requirements.

The page now more clearly highlights Android onboarding and Xiaomi Permanent Protection issues, and refines instructions for updating Microsoft Authenticator. Wording, screenshots, links, and formatting were also refreshed.

The documentation now lists the languages supported by localized default notification templates, including English, Japanese, Spanish, Chinese, Korean, Portuguese, and others.

The page updates the Hybrid identity description, corrects the Risk score link, and points investigation guidance to non-human identities.

The article now points to two different authoring references.

The documentation now describes Defender for Identity sensor v3.x onboarding without Defender for Endpoint for eligible servers, including domain controllers, AD FS, AD CS, and Microsoft Entra Connect.

The page now links to entries covering malicious or suspicious MFA-device and method registration, organization branding changes by newly created users, and potential Certighost (CVE-2026-54121) AD CS abuse.

The guidance now applies to servers, specifically v3.x sensors deployed without Defender for Endpoint. Administrators must run the offboarding package on the server before deleting its portal entry; deleting the entry alone may leave the sensor active, sending data, and able to reactivate.

The page’s DevRel metadata links were updated, and the “AADInternals private key extraction attempt” alert entry was removed.

The documentation expands support for Defender for Identity sensor v3.x activation without Defender for Endpoint to eligible AD FS, AD CS, and Microsoft Entra Connect servers running Windows Server 2019 or later, in addition to eligible domain controllers.

Eligible organizations with an active Defender for Identity workspace receive a 30-day banner before sensor v3.x activation and Windows auditing are enabled by default, including settings currently set to Off. Windows Server 2025 sensor migration support is also documented as resolved.

The guide now says to select “Automatically use the sensor's local system account” before migrating because migration does not change this setting automatically. It also instructs admins to verify that the setting remains selected instead of using gMSA for action accounts.

The documentation clarifies automatic Windows auditing for v3.x sensors, distinguishes it from automatic sensor activation, updates the listed auditing settings, changes the System event ID from 7045 to 4697, and directs administrators to use Certification Authority for CA auditing.

The page now separates v2.x and v3.x prerequisites, ports, and connectivity procedures. It adds v3.x guidance stating that the sensor uses Microsoft Defender for Endpoint service endpoints and clarifies expected test results and troubleshooting use.

The page now explicitly scopes DSA usage, recommendations, supported options, and selection behavior to Defender for Identity v2.x sensors. It also clarifies domain synchronizer responsibilities and improves wording.

The page now uses clearer deployment wording, fixes the static IP example and links, and separates auditing guidance for AD FS and AD CS servers.

The page now describes validating Defender for Identity sensors through portal data, advanced hunting, and test alerts. It also clarifies that queries should run separately and explains which placeholders to replace.

The guidance now specifies that automatic Windows event auditing applies to v3.x sensors and tells administrators to check the health issue table for the relevant sensor version before remediation. Several alert descriptions were also clarified.

The troubleshooting page now points scheduled-task and proxy silent-installation references to the corresponding sections under `deploy/install-sensor`; page metadata was also refreshed.

The article now applies its procedures and Directory Service Account requirement specifically to Defender for Identity v2.x sensors. Administrators using v3.x sensors are directed to separate deployment and configuration guidance.

The page now covers configuration and validation for Defender for Identity v2.x sensors, while directing v3.x users to separate post-activation guidance and shared deployment validation steps.

The article now explicitly states that action accounts with the required permissions are used for remediation actions and are separate from Directory Service Accounts.

The section now refers to removing the legacy Unified Sensor RPC Audit tag and clarifies that removing it does not disable automatic RPC auditing on v3.x sensors.

The guide now specifies that eligible Windows Server 2019 or later domain controllers should follow the v3.x deployment guidance, not the v2.x installer procedures. It also links to the v3.x onboarding package for deployments without Defender for Endpoint.

Windows Server 2019 or later AD FS, AD CS, and Microsoft Entra Connect servers are now documented as supporting sensor v3.x onboarding with or without Microsoft Defender for Endpoint.

The documentation now states that eligible servers can use sensor v3.x onboarding without Defender for Endpoint deployment, replacing the previous domain-controller-specific wording.

The deployment guidance now links to v2.x server requirements and migration prerequisites. It specifies that in-place migration from sensor v2.x to v3.x is currently available only for eligible domain controllers, not other servers.

The sizing tool now applies only to v2.x sensors and is not required for v3.x. Automatic auditing for v3.x configures supported auditing settings, with additional steps specified.

The new guidance covers global or scoped plan configuration across connected Azure commercial environments, required permissions, migration behavior, and the loss of resource-level configurations after migration. The capability is in preview.

The comparison now documents Defender portal preview support for environment onboarding, plan management, and cloud security cost reporting. It also clarifies that data export remains available in the Azure portal.

The documentation introduces Defender Workload Units (DWUs), a Cloud Security Cost Estimator, and a Cloud security cost report. It also describes updated workload measurements, plan consolidations, and DNS billing treatment.

A new page explains that moving plan management from the Azure portal to the Defender portal changes billing to Defender Workload Units, shifts configuration to tenant, management-group, or subscription scope, and may replace, consolidate, or measure plans differently. Resource-level configurations are not preserved, and migrated settings become view-only in Azure portal.

The documentation now states that cloud security data supports Azure, AWS, and GCP, while onboarding and plan management currently support Azure commercial environments only. After migration, plan settings become view-only in the Azure portal, resource-level configurations are not preserved, and billing uses Defender Workload Units.

On October 20, 2026, the expanded server security experience will support automated and manual onboarding for Azure, Azure Arc-enabled, Windows, Linux, and on-premises servers. Cloud security plan management will also become available in the Defender portal, including DWU cost tracking and eligible 30-day trials.

The page now documents supported environments, scope-level-only plan configuration, replacement of resource-level settings during migration, remaining Azure portal capabilities, and daily cost fluctuations.

New documentation describes connecting Azure subscriptions and management groups to Microsoft Defender for Cloud, including prerequisites, tenant preparation, and connector setup. The capability is in preview.

The Microsoft Learn page describing eligibility, required roles, enablement steps, and expected results for Defender for Cloud preview features in the Defender portal was deleted.

The procedure now states that direct onboarding affects all eligible existing and future non-Azure servers in the same Microsoft Entra tenant. Individual-server or pilot-group selection isn't supported, and prerequisites include healthy Defender for Endpoint telemetry, a matching tenant, and specific roles.

The documentation now describes connecting Azure commercial environments at subscription or management-group level and configuring Defender for Cloud plans for selected or all connected environments. AWS, GCP, and unsupported Azure environments must still be onboarded through the Azure portal.

The FAQ now explains that existing Defender for Endpoint servers need no changes, how to onboard new servers, Direct onboarding scope, offboarding options, and why historical records may remain visible. The offboarding link was also updated.

The documentation now states that updates to cloud scopes, including subscription changes, may take about 8–10 hours to appear in portal filters and scoped data views. During the refresh, results may be incomplete or empty even when the configuration was saved.

The article now states that the calculator covers the existing plan-pricing model and links to separate guidance for estimating costs with the Defender Workload Unit (DWU) pricing model.

The article now specifies that it covers enabling Defender for Cloud on an Azure subscription in the Azure portal and links to separate instructions for connecting Azure commercial subscriptions or management groups in the Microsoft Defender portal.

The documentation now maps legacy plans to new plans, including default serverless protection in Defender CSPM, revised billing units, consolidated Databases and API plans, and discontinued DNS coverage. DNS protection can be maintained by manually enabling Defender for Servers Plan 2, with possible additional charges.

The article now clarifies that it covers using Azure Policy to enable Defender for Cloud across subscriptions in a management group, and links to separate guidance for connecting Azure environments in the Defender portal.

The documentation now lists sensor versions 0.11.8, 0.10.11, 0.9.69, and 0.8.62, all released in October 2026 with security updates to sensor components and dependencies.

The documentation adds a separate preview connector for SAP BTP Application Vulnerability Report Service findings, plus a preview analytics rule and an Application Vulnerabilities workbook tab with a vulnerability posture KPI.

The documentation now describes an optional Application Vulnerabilities workbook tab and an analytics rule correlating SAP Application Vulnerability Report Service findings with BTP audit events. The rule detects custom apps with open high or critical vulnerabilities, using a default CVSS threshold of 7.0 and a 14-day evaluation window.

The October 2026 documentation adds an analytics rule that correlates SAP Application Vulnerability Report findings with BTP audit logs to detect interactive XSUAA logins involving custom apps with open high or critical vulnerabilities.

The article now documents a connector that ingests SAP Application Vulnerability Report Service findings into Microsoft Sentinel, including setup prerequisites, credentials, polling and ingestion-delay settings, verification, and related analytics content.