In a Microsoft 365 tenant, user accounts are commonly disabled during offboarding, investigations, or when an account is suspected of compromise. When you need to answer “who disabled this account and when,” the most reliable approach is to query audit data rather than relying on manual change history.
In this guide, you’ll learn how to find the actor (who performed the change), the timestamp, and the target user by using Microsoft Purview Audit (Unified Audit Log). I will also show you an additional method using Microsoft Entra audit logs for quick checks.
Mainly, you will get the answers to the below queries in this post:
- Who disabled a user account in Microsoft 365?
- When was the user account disabled (date/time)?
- How to handle cases where the event is logged as Update user instead of Disable account.
Contents
Before you start
Confirm if auditing is enabled
Audit logging is on by default for many Microsoft 365 organizations, but it is not enabled by default for SMB licenses (Business Basic, Business Standard, and Business Premium) and some trial/unmanaged tenants. To verify auditing status, install Exchange Online PowerShell module and connect using Connect-ExchangeOnline, then run below command:
Confirm if auditing is enabled
Get-AdminAuditLogConfig | Format-List UnifiedAuditLogIngestionEnabled

If you need to enable auditing, run below command:
Enable auditing
Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true

Understanding Retention
- Audit (Standard): default retention is 180 days for logs generated on/after October 17, 2023 (older logs remain 90 days).
- Audit (Premium): typically provides longer retention (commonly 1 year baseline for many E5 scenarios) and can be extended with add-ons and retention policies.
Step 1: Search Audit Logs in Microsoft Purview
Follow below steps to start a search in the audit logs:
- Sign in to the Microsoft Purview portal.
- Click on Audit under Solutions.

- Start a Search:
- Set the date range that covers the suspected disablement window.
- Under Workloads, select AzureActiveDirectory.
- Use filters (Activities, Users) if you already know the likely actor or target.
- Wait for the search job to complete, then open results.

- When ready, select Export to download results.

- The export job may take a few minutes to complete. Once the download is ready, a Downloads file link will appear. Click it to download the search results.

Step 2: Filter Search Results for Disable Account and Update User Operation
Open the exported audit Excel file and apply a filter to the first row. Then filter the Operations column for Disable account. Also add a filter for Update user as well. In practice, many user-disable actions show up as Update user where the property AccountEnabled changes.
- Open the CSV in Excel.
- Filter the Operations column for Disable account.

Additionally, filter the Operations column for Update user data (and keep Disable account filtered too if available). Inspect AuditData and look for ModifiedProperties showing:
- Name: AccountEnabled
- OldValue: true
- NewValue: false
This is the most reliable way to catch “disablement” events that do not surface as “Disable account” in the Operations column.

Step 3: Confirm Who Disabled the Account and When
For each matching record, review key fields such as CreationDate, which shows when the event was recorded; UserIds/Actor, which identifies who performed the action (for example, an administrator, automation, or sync account); and AuditData, which contains detailed information about the target resource and the change payload. When the Update user approach is used, the authoritative indicator of a disable action is found in ModifiedProperties, where AccountEnabled has NewValue = false (and typically OldValue = true).
After filtering the Operations column for Disable account entries and locating the user you want to audit, examine the AuditData column to confirm the account disablement. This column provides comprehensive details, including the timestamp of the action. Refer to the UserId column to identify who disabled the account. For further analysis, copy the AuditData value into Notepad to review the full operation details.

- After copying the AuditData record to a notepad, you’ll discover various details about the operation, including the following:
- TimeStamp of when a user account was disabled in Microsoft 365.
- Which Operation was performed on the user account
- The User’s ObjectID / account which was disabled.
- Who disabled a Microsoft 365 user account.

Using PowerShell
Option 1: Search Unified Audit Log and extract only disable events
This approach queries the Unified Audit Log via Exchange Online PowerShell. Some operation names include a trailing period and must be entered exactly in PowerShell.
Connect-ExchangeOnline
$StartDate = (Get-Date).AddDays(-30)
$EndDate = Get-Date
# Include both, and include trailing-dot variants because UAL operation strings can include a period.
$Ops = @("Disable account","Disable account.","Update user","Update user.")
$raw = Search-UnifiedAuditLog -StartDate $StartDate -EndDate $EndDate -Operations $Ops -ResultSize 5000
$report = foreach ($r in $raw) {
$data = $null
try { $data = $r.AuditData | ConvertFrom-Json } catch { continue }
# ModifiedProperties is where AccountEnabled changes are recorded in many disable events
$mp = $data.ModifiedProperties | Where-Object { $_.Name -eq "AccountEnabled" } | Select-Object -First 1
if (-not $mp) { continue }
$old = ($mp.OldValue | Out-String).Trim()
$new = ($mp.NewValue | Out-String).Trim()
if ($old -match "true" -and $new -match "false") {
$targetUpn = $null
if ($data.TargetResources) { $targetUpn = ($data.TargetResources | Select-Object -First 1).UserPrincipalName }
[pscustomobject]@{
TimeUtc = $r.CreationDate
Operation = $r.Operations
Actor = ($r.UserIds -join "; ")
TargetUPN = $targetUpn
RecordType = $r.RecordType
}
}
}
$report | Sort-Object TimeUtc -Descending
Option 2: Using Microsoft Entra audit logs
If you only need a recent view, Entra audit logs include the activity Disable account under UserManagement. Retention for Entra logs may be shorter than Purview audit depending on your licensing and configuration.
Connect-MgGraph -Scopes "AuditLog.Read.All"
Get-MgAuditLogDirectoryAudit -Filter "activityDisplayName eq 'Disable account'" -Top 50 |
Select-Object ActivityDateTime, ActivityDisplayName, InitiatedBy, TargetResource
FAQs
Whats type of license is required to audit user and admin activities?
- Audit (Standard): baseline auditing (most tenants): It is available broadly in Microsoft 365, and when you enable auditing in the Purview portal, it records user/admin activity with default retention based on licensing and retention policies.
- Audit (Premium): For premium audit capabilities (for example, longer default retention for key workloads and additional “high-value” auditing events/properties), Microsoft requires that the users who benefit have an appropriate E5-level license or add-on and that the Microsoft 365 Advanced Auditing service plan is enabled for those users. Audit (Premium) is included in the below licenses:
- Microsoft 365 E5/A5/G5 (includes Audit Premium)
- Microsoft Purview Suite add-on
- Microsoft 365 E5 eDiscovery & Audit (and related “eDiscovery and Audit” add-ons)
- Audit (standard) vs. Audit (premium) comparison table: Learn about auditing solutions in Microsoft Purview | Microsoft Learn.
- Auditing licensing requirements: Learn about auditing solutions in Microsoft Purview | Microsoft Learn.
How long are audit logs retained in Microsoft 365?
Microsoft 365 audit log retention depends on your auditing level: Audit (Standard) retains records for 180 days by default (note that the increase from 90 to 180 days is not retroactive, so records created before October 17, 2023, remain 90 days), while Audit (Premium) provides 1 year default retention for covered events; you can extend retention beyond these defaults using audit log retention policies, and retaining audit logs for up to 10 years requires the relevant 10-year audit log retention add-on and configured retention policies.
What permissions are required to search the audit log?
To search and export the Microsoft 365 audit log, assign the appropriate audit roles to the administrators who will perform investigations. In the Microsoft Purview portal, users typically need membership in an audit role group such as Audit Reader (read-only) or Audit Manager (read and manage) to run audit searches and export results.
If you also use Exchange Online PowerShell for auditing tasks (for example, running Search-UnifiedAuditLog or verifying unified audit log ingestion). Ensure the same administrators have the required Exchange Online permissions that include the Audit Logs or View-Only Audit Logs roles, which are commonly granted via role groups such as Compliance Management or Organization Management in the Exchange admin center. Global administrators inherit Exchange Online administrative access through the underlying directory-to-Exchange role mapping, which is why they can typically access audit search and reporting capabilities without additional role assignments.
Does the “Disable account” event always exist?
Not necessarily as a unique operation label in every tenant or in every view. The most reliable indicator is still the property change: AccountEnabled set to false in ModifiedProperties.
Why do I see “Update user” instead of “Disable account” in the audit log?
Because disabling a user is often logged as an update to the user object, where the AccountEnabled property changes from true to false. For completeness, search both Disable account and Update user, and validate the change by checking AuditData.ModifiedProperties for AccountEnabled.
Is auditing enabled by default in Microsoft 365?
Typically yes, but not always. Auditing isn’t enabled by default for SMB licenses (Business Basic, Business Standard, and Business Premium) and for unmanaged tenants using free enterprise trials.
How do I verify whether unified audit logging is enabled?
Run below command in Exchange Online PowerShell to find out if auditing is enabled in your tenant.
Get-AdminAuditLogConfig | Format-List UnifiedAuditLogIngestionEnabled
Set-AdminAuditLogConfig is not recognized
If you encounter an error, Set-AdminAuditLogConfig is not recognized when running the Set-AdminAuditLogConfig, check and confirm if you have installed Exchange Online PowerShell module and connected to Exchange Online using the Connect-ExchangeOnline cmdlet.
| Error while running Set-AdminAuditLogConfig |
|---|
| PS C:\Users\Jatin> Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true Set-AdminAuditLogConfig : The term ‘Set-AdminAuditLogConfig’ is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again. At line:1 char:1 Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true FullyQualifiedErrorId: CommandNotFoundException |

Thanks for this, Jatin. I will add, though, that the “Disable account” operation is not the only way User disablement is logged. In my experience, even more often, the disablement is shown as an “Update user” operation. As such, I find that filtering the AuditData field using the text string “ModifiedProperties”:[{“Name”:”AccountEnabled”,”NewValue”:”[\r\n false\r\n]”,”OldValue”:”[\r\n true\r\n]” will give you a more complete and accurate answer. I don’t know why some of those records are labeled “Disable account” and others are labeled “Update user,” but I suspect it could be related to which interface you use to disable the User in the first place (Microsoft 365 Admin console v. Entra ID console).