Identity Inventory
The page updates the Hybrid identity description, corrects the Risk score link, and points investigation guidance to non-human identities.
Daily Defender NewsA cross-product view of Microsoft Defender changes related to Identity protection.
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 what's new documentation now uses the table name `GraphAPIAuditEvents` when describing Microsoft Entra ID API requests to Microsoft Graph API.
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’s DevRel metadata links were updated, and the “AADInternals private key extraction attempt” alert entry was removed.
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 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 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.
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 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 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 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 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 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 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.
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 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 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 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 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 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 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.
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 page now documents assessments for excessive local-group privileges granted by GPOs and reversible passwords stored in Group Policy Preferences, including risks, user impact, and remediation steps.
The alert catalog now includes updated descriptions and fields, plus entries for several OAuth, Okta, Kerberos, AD CS, and DPAPI-related alerts. The malicious MFA device registration severity is shown as High.
The health alerts page revises the entry describing a missing or incorrectly applied Unified Sensor RPC Audit configuration tag and its resolution steps.
The prerequisite changed from the July 2026 to the September 2026 or later Windows Server cumulative update. Post-migration guidance now covers manually removing workspace DSA or gMSA configuration and retiring unused gMSA accounts after verifying they have no other users.
The documented prerequisite changed from the July 2026 or later cumulative update to the September 2026 or later cumulative update.
The FAQ now states that offboarding a server from Defender for Endpoint stops Defender for Identity v3.x sensor reporting, including sensors migrated from v2.x, and does not automatically enable identity-only mode.
The October announcement adds 19 alerts covering Entra ID, Active Directory, and other identity providers, including Okta, with links to detailed alert information.
The archive entry for “Suspicious network connection over Encrypting File System Remote Protocol” now links to the “Suspected PetitPotam coercion attack” section.
The documentation now explains that some identity and access recommendations can appear without the Azure CSPM standard assigned, but those recommendations don't support exemptions unless the standard is assigned. It also links to assignment instructions.
The Defender for Identity remediation-actions table now lists Security Operator among the roles for the Revoke session action.
The documentation now states that automatic sensor activation and automatic Windows auditing require an active license that includes Microsoft Defender for Identity. The domain-controller onboarding heading no longer labels the process as preview.
Automatic sensor activation and automatic Windows auditing now require an active license that includes Microsoft Defender for Identity.
The page date was updated, and the “Offboard a domain controller without Defender for Endpoint deployment” heading no longer includes “(Preview).”
The documentation adds sensor v3.x activation without Defender for Endpoint for eligible Windows Server 2019 or later domain controllers. It applies only to new sensor v3.x deployments, and automatic activation and Windows auditing require an active license that includes Microsoft Defender for Identity.
The page now specifies that the method supports new sensor v3.x deployments on eligible domain controllers without sensor v2.x, and that the standalone package activates sensor v3.x on Windows Sense in restricted identity-only mode.
The changelog now lists sensor versions 0.11.7, 0.10.10, 0.9.68, and 0.8.61 as GA releases from September 2026, each containing security vulnerability fixes and dependency updates.
Microsoft Defender for Identity will auto-enable sensor v3.x activation and Windows event auditing for eligible tenants starting late October 2026, easing setup for security admins. A portal banner allows opt-out before rollout; manual control remains afterward. Review configurations and update guidance accordingly.
Automatic activation applies to eligible Defender for Endpoint-onboarded domain controllers, AD FS, AD CS, and Microsoft Entra Connect servers running Windows Server 2019 or later. It activates the existing capability, does not install a separate package, and excludes servers that already have a Defender for Identity sensor.
The documentation now explains that enabling both automatic sensor v3.x activation and automatic Windows auditing configures eligible onboarded servers automatically.
The documentation now specifies that a directory service account (DSA) is required for the listed features and functionality when using sensor v2.x.
The page now documents inventory insights for new, highly privileged, risky, unused, overprivileged, externally unverified, and AI-agent-used identities. It also clarifies that Salesforce inventory includes Connected Apps and External Client Apps.
The guidance now says sensor v2.x deployments should configure a Directory Service Account for full security coverage. A DSA is required to access the DeletedObjects container and for certain cross-domain and non-domain-controller scenarios.
The troubleshooting documentation now states that migrating from sensor v2.x to v3.x is unsupported when the Defender for Identity workspace and Defender for Endpoint onboarding for the same server belong to different Microsoft tenants. The server may appear ready, but v3.x activation fails.
Eligible new Defender for Endpoint customers may receive automatic Defender for Identity sensor v3.x activation and Windows auditing. Existing Defender for Identity customers will see a portal notice before these settings are enabled; eligible non-domain-controller AD FS, AD CS, and Microsoft Entra Connect servers are now covered. A sensor update with security improvements is also listed.
The health alerts article revision date changed, and the Sensor v3.x RPC Audit Misconfigured entry now includes resolution guidance, including verifying the Unified Sensor RPC Audit configuration.
The article was retitled and expanded with guidance for adding, editing, and removing account correlation rules, plus a settings screenshot and clearer license and role prerequisites.
The page adds assessments for privileged external or guest accounts, WriteDACL permissions on sensitive groups, and highly privileged service accounts. It also updates anchors and removes “(Preview)” from several existing assessment headings.
The documentation now covers eligible domain controllers and non-domain-controller AD FS, AD CS, and Microsoft Entra Connect servers. Activation on the latter servers is in preview and currently requires manual activation; automatic activation and migration aren't supported.
The article now uses the heading “Compare OT device programming files,” includes a named anchor, simplifies wording, updates metadata, and presents the device-information import link as a next-step callout.
The documentation now specifies that SMB credentials authenticate with the shared backup folder and updates the description of GUI-based sensor maintenance tasks. Page metadata was also updated.
The page now explicitly identifies the ESC11, insecure IIS endpoints/ESC8, and ESC7 assessments, clarifies the AD CS sensor prerequisite, and presents the testing warning as a caution callout.
The client analyzer overview now links unexpected Endpoint Data Loss Prevention behavior to the `/purview/endpoint-dlp-learn-about` page instead of the previous `/microsoft-365/compliance/endpoint-dlp-learn-about` path.
The documentation now describes Microsoft Defender for Identity assessments for Okta, CyberArk Identity, and SailPoint Identity Security Cloud, including connection prerequisites and revised remediation guidance.
The instructions now cover multi-domain and multi-forest deployments, require Enterprise Admin permissions when using a root-level group and single gMSA, and document KDS root-key replication timing and group-scope options.
The documentation adds a warning that deleting a sensor setting permanently removes it and requires recreation. It also clarifies disconnected-sensor editing, ICS subnet behavior, and backup server setup and troubleshooting.
The proxy configuration guidance now requires outbound HTTPS traffic on port 443 from the sensor to Defender for IoT endpoints. Section links and documentation metadata were also updated.
The article now opens with an Overview section, with minor wording updates. Its publication date and custom metadata were also updated.
The article title, publication date, authoring metadata, and wording introducing related articles were updated.
The documentation now states that sensor v3.x can be used in preview on eligible AD FS, AD CS, and Microsoft Entra Connect servers running Windows Server 2019 or later. Sensor v2.x procedures remain documented for other applicable servers.
The documentation now describes automatic Windows event auditing for sensor v3.x on domain controllers, AD FS, AD CS, and Microsoft Entra Connect servers. Sensor v2.x and opted-out v3.x deployments still require manual configuration. AD CS requires an existing CA audit filter.
Updated the page metadata, corrected the Step 3 heading level, and clarified wording for selecting a subscription and verifying forwarded events.
The Defender for Identity–CyberArk Identity article updates its prerequisites and RBAC terminology. It now states that users tagging identities as privileged accounts in the Microsoft Defender portal must also have the Privileged Cloud Auditors role.
The page title capitalization, publication date, custom metadata, and the “For more information, see” section heading were updated.
The documentation now explicitly instructs administrators to create a custom Okta role named Microsoft Defender for Identity, assign it with the Read-Only Administrator role, and remove Super Admin after confirming both roles are assigned.
The article now describes connecting SailPoint Identity Security Cloud through the Defender portal API connector, updates role-based access terminology, and instructs administrators to create a dedicated SailPoint user before generating a personal access token.
The documentation now explains how to use the deployment executable to configure or clear an authenticated proxy, including the required URL and credentials, and how to test connectivity afterward.
The article now clearly covers creating, editing, and removing sensor users, Active Directory integration, and privileged-access recovery. Prerequisites are presented as notes, and headings, links, metadata, and related-content formatting were updated.
The page now specifies that an OT sensor displays reports for OT sensors connected to the same management console. It also updates the title, formatting, metadata, and related-content links.
The guide’s title and metadata were updated, and its incident-triage guidance was streamlined. It continues to recommend reviewing the Global and Sensor Health Issues tabs and setting up service-issue email notifications.
The changelog now documents seven sensor releases with security and dependency updates. Several also improve Kubernetes pod inventory reliability when processing pod deletion events.
The documentation now states that existing exclusions do not automatically carry over when detections move to the Microsoft Defender XDR detection engine. Once moved, those exclusions stop applying and previously suppressed alerts can reappear.
Added a Sentinel how-to guide for creating a Security Copilot workspace and an IdentityDrift investigation agent that correlates Entra ID, Defender for Endpoint, and Defender for Cloud signals.
The page now uses updated report and section names, describes monitoring sensor health, antivirus status, OS platforms, and Windows version trends, and clarifies Current state and filter behavior across all three cards.
The article updates its title and terminology, clarifies Okta and Microsoft prerequisites, and specifies that the saved token is used when creating an integration profile in the Defender portal. The prerequisite link text and documentation metadata were also updated.
Updated metadata, corrected possessive grammar, and reformatted the related links section as a bulleted list.
The article now uses Microsoft Defender terminology, clarifies sensitive, Exchange server, and honeytoken tagging guidance, and notes that Entra ID and SailPoint Identity Security Cloud roles are used for sensitive entity tagging.
The article date and metadata were updated, an explicit dashboard heading was added, and the risky lateral movement path table entry was synchronized.
The article now distinguishes Microsoft Entra device conditions from client-certificate options and specifies uploading root or intermediate CA certificates before creating policies based on Device tag or Valid client certificate.
The article now clarifies the OT sensor prerequisite, adds the need for a CSV-capable editor, restructures the import steps, updates terminology, and specifies that devices omitted from an authorized-devices import are marked not authorized and can generate new traffic alerts.
The page now links to prerequisites and explicitly directs administrators to verify that Helm and curl are installed before deploying Defender for Containers.
The installation page now clarifies sensor package download steps, formats endpoint lists, and adds tables and examples for silent and proxy installations. It also updates the post-installation next steps.
The page title now identifies Microsoft Defender for Cloud, and the CloudTrail warning clarifies that disabling ingestion removes data from the one-time historical collection while re-enabling it starts a new collection. The next-step heading and anchor were also updated.
The page now refers to Microsoft Defender instead of Microsoft Defender XDR for automatic PAM-managed identity tagging and password resets for high-risk privileged accounts.
The guide now requires at least one connected, healthy Defender for Identity sensor version 2.x to receive RADIUS accounting events. It also reiterates that FIPS environments aren't supported and updates Microsoft Defender terminology and navigation.
The article now refers to the alert details side pane, identifies Defender for Identity as the capability tuned by alert classification, and clarifies the tabs and Related Entities data in exported Excel alert reports. The metadata and date were also updated.
The page now documents connector-dependent remediation actions, including that Confirm safe resets both the identity risk score and Microsoft Entra risk level. It also expands the identity timeline to include sign-ins, audit events, risk signals, Conditional Access evaluations, correlated accounts, and additional data tables.
The article now highlights prerequisites, including an activated sensor and required permissions, and warns that deleting a device permanently removes it from inventory. It also refreshes wording and navigation labels throughout the device map and notification guidance.
Documentation now describes a Security recommendations (Preview) view for scoped users on domain pages. Users can access it from the Identity dashboard and review recommendation names, statuses, update times, details, and remediation guidance.
The page now clarifies supported SIEM event types, required message syntax, and examples for RSA Security Analytics, MicroFocus ArcSight, Splunk, and QRadar, including required CEF keys and timestamp guidance.
The page now clarifies prerequisites, certificate-validation wording, interface update behavior, analytics-engine guidance, and related links. An alert callout was also added.
The article title, wording, and screenshot descriptions were updated. It now explicitly introduces configuring a dedicated gMSA action account and clarifies the security rationale for separating action and Directory Service accounts.
The documentation now includes domain controllers running AD FS, AD CS, or Microsoft Entra Connect, and states that v3.x sensors update through Windows Update. It also clarifies that the per-sensor Delayed update option applies only to v2.x sensors and expands migration-state descriptions.
The page now highlights Defender for Identity data enrichment, advanced hunting for policy changes, and undoing shielding actions. It also clarifies alert investigation steps and refines the example scenario.
The article now explains manual account linking and automatic correlation through account correlation rules, including the Microsoft Defender portal path and a link to the rule-management procedure.
The Defender for Identity reports article updates its metadata and clarifies that administrators should repeat the linked report-scheduling steps to change scheduled times or recipients.
The article now describes viewing, filtering, editing, exporting, merging duplicate devices, and deleting inactive devices. It also clarifies that deletion applies to devices matching the current Last Activity filter and updates export time-zone guidance.
The page now refers to Microsoft Defender instead of Microsoft Defender XDR and updates the alert-tuning description to say it improves threat detection coverage throughout your system.
The alerts documentation now explains that some vulnerability alerts may still trigger after the relevant security update. When all affected systems are patched, applicable alerts have Low severity and may show patch status in the evidence. Documentation for Group Policy Tampering was also added.
The article adds context for Configuration-container auditing, clarifies the no-traffic alert wording, and makes minor metadata and RPC audit text updates.
The page now uses Microsoft Defender naming, refreshed navigation wording, and updated SIEM guidance that instructs automation authors to use the permanent externalId field. The event-collection link text was also updated, and the TLS certificate tip was removed.
The page date changed to July 23, 2026, and wording was corrected and clarified, including “non-human” and examples of high-value targets.
The page now describes six assessment categories, clarifies AD CS and Microsoft Entra Connect sensor prerequisites, and updates formatting, images, and related-content navigation.
The prerequisites page now recommends sensor v3.x for Windows Server 2019 or later and clarifies that CPU, memory, and disk requirements are additional to resources used by the operating system and domain controller services.
The page adds entries for AADInternals private-key extraction, malicious or suspicious MFA-method registration, and updates several existing alert descriptions. It removes entries for Honeytoken Activity, stolen session-cookie replay, suspicious Entra device join or registration, and adds guidance on Classic versus Defender-format alerts and alert tuning.
The article now uses a shared ATA end-of-life notice, adds a Defender for Identity prerequisites link, identifies the final ATA release, and updates product names and links to Microsoft Defender.
Migration is unsupported on non-domain-controller servers running AD FS, AD CS, or Microsoft Entra Connect, while domain controllers running these roles are included. RPC auditing is automatic from sensor 3.0.8, and v3.x updates through Windows Update without the v2.x delayed-update option. Readiness reasons now appear in the Sensors page tooltip.
The monitored activities page now refers to Microsoft Defender’s Advanced Hunting page instead of Microsoft Defender XDR’s Advanced Hunting page; the link destination is unchanged.
Updated the page title capitalization, publication date, custom metadata, and Persona formatting. An incomplete “For more information, see:” line was removed.
The page title and heading were updated to remove the “Preview” label. The documentation date and custom metadata were also updated.
The article’s title, metadata, role-prerequisite wording, connectivity-team responsibilities, direct-connection context, and endpoint-download heading were revised.
The guide’s title, description, date, heading, and authoring metadata were updated. The Test-MDIConfiguration guidance was shortened while retaining its purpose and warning about incorrect audit policies.
The hybrid security posture assessments page now documents the assessment for privileged SaaS accounts outside identity-provider control, including its impact and implementation steps. Other edits update headings, formatting, metadata, and links.
The article now explains that remediation actions depend on the connector managing an identity and includes connected apps through Microsoft Defender for Cloud Apps. Enable is listed for CyberArk Identity, SailPoint Identity Security Cloud, and Salesforce, while Force password change is listed for Microsoft Entra ID as well as Active Directory.
The documentation standardizes table separators, uses a dash for the empty vendor description cell, and updates the details field guidance and link.
The role-groups documentation was updated for permissions to perform Defender for Identity response actions, including the custom Response (manage) role and listed Microsoft Entra roles.
The page now explains that sensor versions can contribute to either classic or Defender-format alerts. During the transition, detections may appear in both lists with different names; Detection source identifies the format. Tuning and exclusions are format-specific.
The guidance changes references from Microsoft Defender XDR to Microsoft Defender and updates the Security operations overview link.