The Deployment Sequence That Matters

Phase 1 — Visibility first, enforcement later (Weeks 1–2)

The first two weeks focus exclusively on visibility. Every action in Phase 1 has zero production impact — nothing is blocked, nothing is enforced, nothing changes the user experience. The goal is to establish a baseline: what does the environment look like before you start changing it?

Complete MDE onboarding to 100%. Resolve the 85 devices at NE that are not onboarded — the co-managed SCCM devices need the Intune EDR profile extended to the co-management workload, the BYOD exclusions need the profile scope updated to include personal devices with compliant enrollment, the offline devices need removal from the target group until they return to service, and the legacy McAfee conflicts need the third-party agent uninstalled. You cannot secure what you cannot see. 100% onboarding is the prerequisite for every subsequent phase.

Deploy all ASR rules in audit mode across the entire fleet. Audit mode generates event data showing what would have been blocked if the rules were in block mode — without actually blocking anything. This data is essential: after 2–4 weeks of collection, you can classify each rule into three categories. Rules that generate zero audit events are either not triggered by your environment's activity (safe to enforce immediately) or are targeting techniques your users never encounter. Rules that generate audit events exclusively from known malicious patterns are also safe to enforce. Rules that generate audit events from legitimate LOB applications require exclusions before enforcement — and the audit data tells you exactly which applications and which processes need those exclusions.

Raise AV cloud protection from default to High+. This is a low-risk change that immediately improves detection of unknown malware. High+ extends the cloud analysis time for suspicious files and blocks files that the cloud ML models have not yet classified as safe. The user-visible impact is occasional delays of under 10 seconds when opening unknown files for the first time — most users will not notice.

Build the device health dashboard. The KQL queries from Section 0.4 — ASR enforcement status, device health distribution, onboarding coverage — become your engineering control panel for the next 88 days. Run them daily. Automate them where possible.

Phase 1 success criteria (must be met before advancing to Phase 2). MDE onboarded on 100% of active fleet devices, excluding documented decommissioned hardware. All 18 ASR rules in audit mode on 100% of managed devices. AV cloud protection at High+ on 100% of managed devices. Device health dashboard operational with daily monitoring. Two full weeks of ASR audit data collected. Baseline metrics documented — exposure score, ASR audit event volume per rule per device group, device health distribution.

These criteria are not suggestions. If Phase 1 is incomplete, Phase 2 creates problems that are difficult to diagnose: ASR rules moved to block mode without audit data generate unknown false positives. Compliance policies enforced without 100% onboarding lock out devices the SOC cannot investigate. The visibility phase exists specifically to prevent these downstream failures. If onboarding is stuck at 95% because the co-management workload migration is complex, start Phase 2 for the 95% that are onboarded — but do not consider Phase 1 complete until the remaining 5% are resolved.

Phase 2 — Prevention with graduated enforcement (Weeks 3–6)

Phase 2 deploys prevention controls using the audit-first, graduated enforcement methodology. The ASR audit data from Phase 1 drives every enforcement decision.

Start with the "safe set" — ASR rules that generate minimal false positives across most environments. "Block credential stealing from LSASS" rarely triggers on legitimate software because very few applications need to read LSASS memory. "Block abuse of exploited vulnerable signed drivers" targets kernel-mode driver exploitation with near-zero legitimate use. "Block untrusted and unsigned processes that run from USB" blocks USB-based malware delivery. Move these to block mode across the fleet. Monitor for one week. If no legitimate business impact occurs, proceed to the next set.

Deploy LAPS. This is a hardening control with significant lateral movement prevention value and low blast radius. Each endpoint receives a unique, randomly generated local administrator password stored in Entra ID. The deployment requires identifying scripts, tools, or processes that currently use the shared local admin password — these must be updated to retrieve the LAPS-managed password from Entra ID or use a different credential before LAPS deployment. At NE, the IT helpdesk uses the shared password for remote support, and two automated deployment scripts authenticate with the local admin account. Both need updating before LAPS goes live.

Connect compliance policies to Conditional Access for a pilot group. Start with IT and security staff — people who understand why they might be temporarily blocked and know how to self-remediate their device compliance. Expand to standard users after the pilot validates the user experience and the help desk has documented the remediation workflow.

Begin Credential Guard deployment on a pilot group. Credential Guard uses virtualization-based security to isolate LSASS secrets, which has hardware requirements — TPM 2.0, Secure Boot, and a compatible hypervisor. Some older hardware and certain applications that depend on NTLMv1 or that interact with LSASS directly are incompatible. The pilot identifies these conflicts before fleet-wide deployment. At NE, 92% of devices meet the hardware requirements. The 8% that do not are older engineering workstations scheduled for replacement in Q3 — they receive LSASS ASR rule protection instead of Credential Guard.

The Phase 2 decision framework for each ASR rule is: review the audit data from Phase 1, classify each triggering application as legitimate or suspicious, build exclusions for the legitimate applications, and move the rule to block mode with the exclusions applied. The decision is not "block or audit" — it is "exclude the known legitimate, block everything else." A rule that generates 340 audit events per week from 12 applications might need only 2 exclusions to eliminate 95% of the false positives. The remaining 5% of events are either additional legitimate applications to investigate or genuine attack attempts the rule should block. Module ES4 walks through this analysis for every ASR rule with real audit data.

// Phase 1 audit data — ASR rule triggers by rule name and process
DeviceEvents
| where Timestamp > ago(7d)
| where ActionType startswith "Asr"
| summarize EventCount = count() by ActionType, FileName, InitiatingProcessFileName
| sort by EventCount desc
| take 20

This query is the Phase 1 output you review before any enforcement decision. Each row shows an ASR rule (ActionType), the process that was affected (FileName), and the parent process that triggered the rule (InitiatingProcessFileName). High event counts with legitimate parent processes need exclusions. Low event counts with suspicious parents are the actual attacks the rule will block. This data does not exist if ASR rules are at "Not configured" — audit mode must be enabled first to generate the decision data.

{
  "attackSurfaceReductionRules": [
    { "id": "56a863a9-...", "action": "audit",  "name": "Block Office child processes" },
    { "id": "9e6c4e1f-...", "action": "block",  "name": "Block LSASS credential theft" },
    { "id": "01443614-...", "action": "block",  "name": "Block vulnerable signed drivers" },
    { "id": "b2b3f03d-...", "action": "block",  "name": "Block USB untrusted processes" },
    { "id": "be9ba2d9-...", "action": "audit",  "name": "Block Office from creating executables" }
  ],
  "attackSurfaceReductionExclusions": [
    "C:\\Program Files\\LegacyInventory\\scanner.exe"
  ]
}

This is the Intune ASR policy structure after Phase 2. The "safe set" rules — LSASS credential theft, vulnerable drivers, USB — move directly to block because they have near-zero legitimate triggers. The Office rules start in audit because they require exclusion analysis. The exclusions list contains only the specific binaries that Phase 1 audit data confirmed as legitimate. Module ES4 builds this configuration for every ASR rule with your environment's actual audit data.

What happens when you get the sequence wrong

The deployment sequence is not theoretical — the consequences of wrong sequencing are specific and measurable.

ASR before onboarding. You deploy ASR rules to all Intune-managed devices. But 85 devices are not onboarded to MDE. The ASR rules apply — they are Intune policies, not MDE features — but MDE has no telemetry from those devices. If an ASR rule blocks a legitimate application on an unonboarded device, the block event does not appear in Advanced Hunting. You cannot see the false positive, cannot troubleshoot it, and the user reports "my application stopped working" without any security telemetry to diagnose the cause. Onboarding first ensures ASR audit and block data is visible before enforcement decisions are made.

Detection rules before AV tuning. You build custom detection rules for credential access techniques while AV remains at default cloud protection. Unknown credential dumping tools may execute without AV intervention because default cloud protection does not block unclassified files. The detection rule fires after the tool runs — the detection is reactive, not preventive. If AV were at High+, the tool might be blocked before execution, making the detection rule redundant for that specific instance. AV tuning first ensures the prevention layer catches what it can. Detection rules catch what prevention misses. Building detection before maximizing prevention is optimizing the wrong layer.

Compliance enforcement before remediation. You enable the CA policy "require compliant device" without first checking how many devices are compliant. At NE, 12% of devices are non-compliant due to deferred OS updates. That is approximately 104 users immediately blocked from M365 resources. 104 help desk tickets. 104 managers asking why their team cannot access email. The remediation-first approach identifies and fixes non-compliant devices before enforcement, reducing disruption to near zero on enforcement day.

Everything at once under audit pressure. The audit is in six weeks. Management demands all controls configured before the auditor arrives. The security team deploys 18 ASR rules, compliance enforcement, LAPS, and Sysmon in the same change window. Multiple things break simultaneously. The security team cannot isolate which change caused which problem because everything changed at once. IT operations reverts everything. The auditor arrives to find the same configuration as before the project started, plus a change log showing a failed deployment that was rolled back — which is worse than having a documented phased plan in progress. What the auditor actually needs to see: a documented endpoint security program with a risk-prioritized deployment schedule, evidence that controls are being deployed and validated according to that schedule, and success criteria for each phase. An audit that finds "15 controls planned, 8 deployed and validated, 7 in progress with documented timeline" passes. An audit that finds "15 controls deployed simultaneously, 6 reverted, 3 in unknown state" does not.

The emergency exception. During an active incident, the phased approach does not apply to the specific controls that address the active threat. If the incident involves LSASS credential dumping, enable the LSASS ASR rule in block mode immediately — the blast radius of potentially blocking a legitimate application is less than the blast radius of an attacker dumping every credential on the endpoint. If the incident involves lateral movement via PsExec, enable the PSExec/WMI ASR rule on the target endpoints. Emergency deployment of targeted controls during an incident is justified because the alternative — letting the attack continue while you complete the audit phase — is worse. Post-incident, return to the phased approach for the remaining controls. Emergency does not mean "deploy everything." It means "deploy the specific control that stops this specific attack."

Phases 3–5: detection, readiness, and continuous improvement

Phase 3 — Detection (Weeks 7–10). Build custom detection rules covering the highest-priority ATT&CK techniques from the threat model: credential dumping via LSASS access by non-system processes, lateral movement via PsExec service creation and WMI remote execution, persistence via scheduled task creation from unusual parent processes and registry run key modification, and defense evasion indicators like process injection and AMSI bypass patterns. Configure AIR at the appropriate automation level per alert type — semi-automated for medium-confidence alerts, full automation for high-confidence detections on IT-managed device groups. Build the hunting query library for weekly proactive searches. Move the "careful set" ASR rules — Office child process blocking, script execution blocking — to block mode with the exclusions identified during the Phase 1 audit period. Connect MDE to Sentinel for cross-workload analytics.

Phase 4 — Forensic Readiness (Weeks 11–12). Deploy Sysmon with the SwiftOnSecurity baseline to all endpoints — pilot on 50 devices for one week to measure performance and event volume, then expand fleet-wide. Configure advanced audit policies through Intune: process creation with command-line logging, logon event auditing, privilege use auditing. Enable PowerShell ScriptBlock logging across all endpoints. Onboard the remaining Windows servers and the Linux servers to MDE. Stage KAPE targets and Velociraptor agents for rapid evidence collection. Validate the entire forensic readiness chain by executing a test scenario — run a known-benign process chain and confirm the expected log entries appear in the Windows event log, Sysmon, and MDE Advanced Hunting.

Phase 5 — Optimization (Ongoing). Operationalize vulnerability management using Defender Vulnerability Management recommendations with tracked remediation and documented exceptions. Build the monitoring dashboards — the executive view (exposure score, MTTD/MTTR, compliance rate) and the engineering view (ASR block events, detection TP rate, technique coverage). Create governance documentation: the endpoint security policy, the ASR exclusion register, the change management process, and the compliance control mapping. Deploy automation playbooks that auto-collect investigation packages on high-severity alerts, auto-isolate devices on ransomware detections above the confidence threshold, and auto-block indicators across the fleet. Run validation testing using Atomic Red Team tests mapped to each deployed control — confirming that ASR rules block what they should, custom detections fire when they should, and response automation triggers correctly.