EDR Rollout on Legacy Endpoints
You must deploy a new EDR agent to 4,200 endpoints. Inventory shows: 2,800 Windows 11 (fully patched), 900 Windows 10 21H2 (out of support in weeks), 300 Windows 7 SP1 machines running a line-of-business app the vendor will not certify past Win7, and 200 macOS 12/13 laptops. The EDR vendor supports Win10 1809+ and macOS 12+, and explicitly does not support Win7. The CFO's office runs three of the Win7 machines. Change policy requires a pilot ring before broad rollout, and any agent causing >0.5% crash rate in a ring must be halted. Budget allows either (a) an extended-support contract for Win7 or (b) compensating controls plus accelerated app replacement - not both.
1. How do you sequence the rollout across the four populations, and what do you do about the 300 Win7 machines?
Read the worked answer
Sequencing (pilot ring must be representative, not just easy):
- Ring 0 (pilot, ~150 hosts): include a spread - 60 Win11, 40 Win10 21H2, 30 macOS, and 20 Win7 if we go the compensating-control route (see below). A pilot of only patched Win11 proves nothing about the risky populations.
- Ring 1: Win11 broad + macOS. Lowest risk, builds coverage fast.
- Ring 2: Win10 21H2 - pair with the OS upgrade plan, since these hosts leave support soon anyway.
- Win7: handled separately (below), not in the main wave.
The Win7 decision - choose (b) compensating controls + accelerated replacement, with a caveat.
- The vendor does not support Win7. Deploying an unsupported agent to 300 production machines (including CFO's office) means no vendor backing when it bluescreens - and the 0.5% crash halt rule would then force a rollback we can't support.
- Extended support (a) keeps Win7 alive, which is the wrong direction: it funds the risk instead of removing it.
- Compensating controls for the 300: network micro-segmentation so Win7 hosts can only reach the LOB app and patch relay; application allow-listing; restricted browsing/email on those hosts; heightened logging forwarded to the SIEM; and a hard replacement deadline tied to the LOB vendor's roadmap.
- CFO's three machines get the same controls plus a documented risk acceptance signed by the CFO - not a silent exception.
Halt rule: define 'crash' precisely (BSOD/kernel panic attributable to the agent, not all reboots) and measure per-ring before promoting.
2. Two weeks into Ring 1, macOS crash rate hits 0.7% but Windows is at 0.1%. What do you do, and how do you keep the project on schedule?
Read the worked answer
Apply the rule literally: halt the macOS track at 0.7% (>0.5%), continue Windows.
- The halt rule is per-population; a macOS driver/kext issue says nothing about Windows. Halting everything would be an over-reaction that burns schedule for no safety gain.
- Triage the macOS crashes: pull crash reports, check macOS version correlation (12 vs 13), check for third-party security agents already installed (common conflict), check whether crashes cluster on a specific hardware model. Open a vendor ticket with the crash dumps same day.
- Keep schedule: the Windows track keeps moving; the macOS ring is frozen at its current size (no new hosts) pending a fix or a version pin. If the vendor ships a patched build within the window, re-pilot on a small macOS ring before resuming.
- Communicate: tell leadership the macOS number, the halt decision, the triage owner, and the revised macOS date - with the Windows date unchanged. Do not quietly lower the threshold to 'keep moving'; that defeats the rule's purpose.
- If no fix in the agreed window: escalate to vendor management / consider an alternate agent for macOS only, and document the gap so macOS coverage risk is visible rather than hidden.