Microsoft Defender for Office 365: Configuration Audit Checklist

The Audit Starts Before You Open the Console

A financial services client came to us after a compliance review flagged an eleven-day gap in their Office 365 threat detection. They had Microsoft Defender for Office 365 Plan 2 licensed across the tenant. They had assigned the licenses. They had never validated the configuration. The gap between “licensed” and “operational” is where most breaches find their entry point — and it is exactly what this checklist is designed to close.

This audit covers eight checkpoints across Defender Antivirus, application control, AMSI integration, Secure Score baselines, DLP policy coverage, and event log visibility. Each checkpoint includes a pass condition and a fail condition. Work through them in order. The goal is not a perfect score — the goal is to know exactly where your gaps are before an attacker finds them first.

Checkpoint 1: Defender Antivirus Service Status

Microsoft Defender Antivirus ships installed by default on Windows 10, Windows 11, and Windows Server 2022. That does not mean it is running. Before anything else, verify the service is active and the management tools are present.

# Verify the WinDefend service is running
Get-Service -Name WinDefend

# Get full operational status: definition age, scan state, engine version
Get-MpComputerStatus

Pass: Get-Service returns Status: Running. Get-MpComputerStatus shows AntivirusEnabled: True, RealTimeProtectionEnabled: True, and AntivirusSignatureAge of one day or less.

Fail: Service stopped, real-time protection disabled, or definition age exceeding three days. Any of these conditions means endpoint protection has a measurable coverage gap right now.

If Defender is not installed or the management tools are missing, install them and validate restart requirements:

$DHT = @{
    Name = 'Windows-Defender'
    IncludeManagementTools = $true
}
$Defender = Install-WindowsFeature @DHT
If ($Defender.RestartNeeded -eq 'Yes') { Restart-Computer }

A Checkpoint 1 fail requires remediation before proceeding. Everything downstream depends on the service being healthy.

Checkpoint 2: Threat Catalog Coverage

The threat catalog tells you what Defender knows. A catalog with very few entries — or a zero count — signals that definitions have not synced properly, or that the installation is in a degraded state.

# Pull the full threat catalog and count entries
$ThreatCatalog = Get-MpThreatCatalog
"There are $($ThreatCatalog.count) threats in the catalog"

Pass: Catalog count is in the tens of thousands or higher. Current Defender installations with up-to-date definitions return well above 200,000 entries. A low four-digit or sub-1,000 count warrants immediate investigation.

Fail: Zero entries, or a count that has not changed across multiple checks. This typically points to a sync failure with Microsoft Update or WSUS. Cross-reference your SIEM for Event ID 2001 (definition update succeeded) or Event ID 2003 (definition update failed) in the Microsoft-Windows-Windows Defender/Operational log.

Checkpoint 3: Windows Defender Application Control and AppLocker

Application control is one of the highest-value controls against execution-based attacks — MITRE ATT&CK T1204 (User Execution) and T1059 (Command and Scripting Interpreter). Windows Defender Application Control (WDAC) and AppLocker both provide application allowlisting to restrict what software runs in your environment. Use them.

Opinion: most organizations skip this checkpoint because rollout is disruptive. That reasoning accepts an enormous, ongoing risk to avoid a bounded configuration project. A manufacturing client we took through a WDAC deployment saw a measurable drop in malware-related incidents within 90 days. Disruption during rollout is temporary. A credential-harvesting payload executing freely is not.

# List active AppLocker policy across all rule collections
Get-AppLockerPolicy -Effective | Select-Object -ExpandProperty RuleCollections

Pass: WDAC policy is deployed and enforced, or AppLocker rules are active and covering at minimum the Script, Executable, and MSI rule collections. Policy mode is Enforce, not Audit-only.

Fail: No application control policy in place, or policy is in Audit mode with no remediation timeline. Audit mode is a valid transitional state. It should not be a permanent configuration.

Checkpoint 4: AMSI Integration and PowerShell Script Block Logging

The Antimalware Scan Interface bridges scripting engines — PowerShell, VBScript, JavaScript — directly to your Defender installation. When AMSI is functioning, Defender inspects script content at runtime, before execution. This is your primary detection surface for fileless malware and obfuscated PowerShell payloads, which map to MITRE ATT&CK T1059.001.

AMSI events appear in the Microsoft-Windows-Windows Defender/Operational event log. If you are forwarding this log to a SIEM, you can write a detection rule around Event ID 1116 that captures script-based attacks as they execute. A KQL detection for Microsoft Sentinel:

// Detect AMSI-triggered Defender alerts on script-based threats
SecurityEvent
| where EventID == 1116
| where EventData contains "AMSI"
| project TimeGenerated, Computer, EventData
| order by TimeGenerated desc

Pass: AMSI events are visible in the Defender Operational log on active endpoints. PowerShell Script Block Logging is enabled via Group Policy at Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell.

Fail: No AMSI events in a 30-day window on endpoints where scripting activity is known to occur. Script Block Logging disabled. Either condition leaves a significant detection gap for living-off-the-land techniques. See our Threat Hunting Techniques: A SOC Readiness Audit for how to build detection coverage around PowerShell activity.

Checkpoint 5: Microsoft Secure Score Baseline

The Microsoft Secure Score dashboard gives you a consolidated view of your configuration posture across the Office 365 tenant. Treat it as a prioritized remediation queue — not a certification, and not a finish line.

One important caveat: the 92 endpoint-specific improvement actions visible in the Defender Security Center require licensing that goes beyond a standard Microsoft 365 E5 subscription. If your tenant is E5-licensed and you are not seeing the full recommendation set, verify whether your specific SKU includes the Defender for Endpoint P2 component. Licensing gaps in this area are more common than Microsoft’s sales documentation suggests. The Azure documentation covers the tenant-level configuration prerequisites in detail.

Pass: Secure Score is above 70% of the maximum achievable for your license tier. Legacy authentication protocols — Basic Auth, NTLM where avoidable — are disabled. Identity and Device category scores are above 60%. Improvement actions have assigned owners and target dates.

Fail: Legacy protocols still active. Secure Score below 50%. No ownership assigned to remediation actions. A Secure Score that nobody is actively working to improve is just a list of known vulnerabilities with a number attached.

An account breach investigation we ran last quarter traced directly to Basic Authentication still enabled on Exchange Online — a legacy protocol that had survived three years of tenant migrations. The Secure Score had flagged it. Nobody had acted on it. That is the operational gap this checkpoint is designed to surface before it becomes an incident.

Checkpoint 6: Data Loss Prevention Policy Coverage

Microsoft Defender for Office 365 operates within a broader security ecosystem that includes DLP policies across Exchange Online, SharePoint, and OneDrive. These policies define where data can move and how. Misconfigured or absent DLP policies are a consistent finding in tenant audits — organizations assume that licensing DLP means DLP is active.

Caveat: DLP configuration is not fully automatable via PowerShell. Some tasks still require the Compliance Center UI. But you can audit current policy state with:

# List all DLP policies and their active status
Get-DlpCompliancePolicy | Select-Object Name, Mode, IsValid, Workload

Pass: Policies exist for Exchange, SharePoint, and OneDrive workloads. Policy mode is Enable, not TestWithNotifications or TestWithoutNotifications. Coverage includes PII, financial data, and credential-type patterns relevant to your industry vertical.

Fail: No DLP policies active. Policies exist but are in test mode. Workload coverage has gaps — SharePoint protected but OneDrive uncovered, for example. Test mode policies generate alerts but do not block exfiltration. This matters significantly for MITRE ATT&CK TA0010 (Exfiltration).

Checkpoint 7: Defender Event Log Visibility and SIEM Integration

Defender writes to the Microsoft-Windows-Windows Defender/Operational event log. If that log is not forwarded to your SIEM, your detection coverage exists only on the endpoint. Mean time to detect increases substantially when security events live on individual machines rather than a centralized correlation platform.

Key Defender event IDs to monitor and forward:

• 1116 — Threat detected. Core triage alert.
• 1117 — Remediation action taken successfully.
• 1118 / 1119 — Remediation failed or partially failed. Escalate immediately.
• 2001 / 2003 — Definition update success or failure. Use for definition gap alerting.
• 5007 — Configuration change. Alert on this for unauthorized policy modifications.

Pass: Defender Operational log is forwarded to SIEM. Correlation rules exist for Event IDs 1116, 1118, and 5007. The 5007 alert feeds a change management validation workflow.

Fail: Log forwarding not configured. No SIEM rules for Defender events. Event ID 5007 has no downstream alert. An attacker who disables Defender and triggers a 5007 with no SIEM coverage has silently removed your detection layer. For building IR workflows around these log sources, see our Digital Forensics for Incident Response: Field Guide.

Checkpoint 8: Endpoint Detection and Response Capability

Microsoft Defender for Endpoint provides EDR capabilities beyond antivirus — behavioral detection, attack surface reduction rules, and command-line activity monitoring. This is your detection layer for post-exploitation: credential dumping (T1003), lateral movement (TA0008), and persistence (TA0003).

EDR is only effective if it covers PowerShell and other scripting interfaces. Verify that your EDR solution is configured to capture and alert on suspicious PowerShell execution patterns. The PowerShell documentation covers configuring Constrained Language Mode as an additional execution control layer.

Pass: Defender for Endpoint is onboarded and actively reporting in the Microsoft 365 Defender portal. Attack surface reduction rules are in Enforce mode for at minimum: Block credential stealing from LSASS, Block executable content from email, and Block execution from removable drives.

Fail: EDR not deployed or reporting zero telemetry. ASR rules in Audit mode only. No coverage for suspicious PowerShell-based activity. This is a critical fail — document it and escalate to security leadership before closing this audit.

Audit Summary: Turning Findings Into Action

Assign each checkpoint a pass, fail, or partial pass. Any fail on Checkpoints 1, 4, or 8 is a critical gap — remediate within 72 hours. Checkpoint 5 and 6 failures are high severity but typically carry longer remediation cycles tied to licensing and policy configuration timelines.

A practical benchmark: if your tenant passes six of eight checkpoints cleanly, your Defender configuration is above the median for organizations of comparable size. Fewer than five clean passes means your detection and prevention posture has structural gaps that extend beyond individual settings.

Document findings. Assign owners. Set remediation dates. A checklist without follow-through is just a structured list of known vulnerabilities. If your team needs help running this audit or remediating critical findings, contact SSE directly — we work with organizations at every stage of their Defender deployment, from initial configuration through ongoing detection engineering.