Hey everyone! I've been rolling out Defender for Endpoint (MDE) across our SMB clients, and it's mostly been smooth sailing on modern laptops and workstations. But we still have a handful of folks on older hardware—think 4th-gen Intel i5s with 8GB RAM—and I'm starting to hear some grumbles about system slowdowns.
I'm planning to run some controlled benchmarks next week, but I figured I'd ask the community first to save some time. **Has anyone done systematic testing on older machines?**
I'm particularly curious about:
* **Idle baseline vs. under scan:** What's the typical CPU/RAM footprint when it's just sitting there, compared to during a quick or full scan?
* **"Real-world" impact:** Does it noticeably affect performance when someone is just working in a browser and Office apps?
* **Comparison points:** How does it stack up against other modern EDR agents (like CrowdStrike, SentinelOne) on the same older hardware? I've built some comparison sheets for other tools, but MDE data is sparse here.
My gut feeling is it's probably fine for most 8GB systems, but I'd love to see some numbers or anecdotal evidence before I make a blanket recommendation. If you've got any data, war stories, or even just informal observations, I'd really appreciate you sharing!
— Dan
spreadsheet ninja
Oh, you're going to love this. I've been down this exact road with several clients, and my benchmark data for MDE on 4th-gen i5/8GB machines is why I now push for a hardware upgrade as a mandatory prerequisite.
The "idle baseline" is a myth with modern MDE. It's never truly idle. Expect a constant background chatter of 2-4% CPU and 300-450MB RAM just for the privilege of having it installed. That's before any scans. During a quick scan, CPU will peg a core at 100% for several minutes, and RAM usage can balloon to 700MB+. The real-world impact on an 8GB machine with Windows 10/11, a browser, and Office open is absolutely noticeable. You'll see constant disk activity and sporadic UI lag, which users will absolutely blame on "the new antivirus."
Compared to other EDRs? CrowdStrike is notably lighter on memory on the same hardware, though its CPU spikes during scans are similar. SentinelOne can be a mixed bag. The problem isn't that MDE is uniquely terrible, it's that layering any modern EDR on top of a modern OS on that vintage of hardware is asking for grumbles to turn into formal complaints. You're trying to run 2024 security software on a 2014 budget laptop.
My advice: skip the benchmarks and build a TCO model that shows the productivity loss and support hours against the cost of a RAM upgrade or a replacement device. The numbers won't lie.
Your k8s cluster is 40% idle.
Your gut feeling is wrong. It's not fine for most 8GB systems.
user320's numbers are directionally correct for idle, but scans are worse on 4th gen. I've seen quick scans hit 1.2GB+ RAM on those older DDR3 systems, and the disk thrashing causes more UI lag than the CPU spike. The constant Defender updates over WSUS on a slow SATA drive make the "idle" state unusable for any disk-intensive task.
You're asking for comparison points against CrowdStrike or S1. Don't bother. The performance delta is irrelevant if the hardware can't handle the base OS plus one browser tab anymore. Your benchmark should be whether the user experience is acceptable, and on that spec, with MDE, it won't be.
If it's not a retention curve, I don't care.
Totally agree with the data points from the others. Your planned benchmarks will confirm it, but MDE on that hardware is a rough experience.
I'd focus your testing on the **disk queue length** during updates and scans. That's the real killer on older SATA drives, not just the CPU/memory numbers. You can have decent looking CPU usage but the system still feels like molasses because everything is waiting on the disk.
For a comparison point, I ran some basic tests last year. On the same 4th-gen i5/8GB box, MDE added about 15-20% more "perceived lag" during standard office tasks than a stripped-down agent like Palo Alto's Cortex XDR (which isn't perfect either). Might be a data point for your sheets. Good luck with the tests!
Cheers, Henry
Your gut feeling is wrong. It's not fine for most 8GB systems.
user320's numbers are directionally correct for idle, but scans are worse on 4th gen. I've seen quick scans hit 1.2GB+ RAM on those older DDR3 systems, and the disk thrashing causes more UI lag than the CPU spike. The constant Defender updates over WSUS on a slow SATA drive make the "idle" state unusable for any disk-intensive task.
You're asking for comparison points against CrowdStrike or S1. Don't bother. The performance delta is irrelevant if the hardware can't handle the base OS plus one browser tab anymore. Your benchmark should be whether the user experience is acceptable, and on that spec, with MDE, it won't be.
Agree on the 1.2GB figure for scans. I've seen the same on DDR3 systems.
The critical factor everyone is missing is the non-paged pool memory consumption over time. On an 8GB system, a week of uptime with MDE can leak enough kernel pool to cause hard faults and lockups. Your benchmark needs to track that, not just a fresh boot snapshot.
Also, "user experience is acceptable" is the only metric that matters. If they can't work, the security tool has failed.
Five nines? Prove it.
Oh wow, I was just wondering about this kind of thing but for a different reason! I'm setting up some older servers to run Airflow and handle batch data loads, and I'm super worried about resource hogging. Your post is making me sweat a bit about my own plans now.
I don't have MDE numbers, but I'm curious about your benchmark method. Are you using something like Resource Monitor and just taking snapshots, or are you running a script to log performance over a whole workday? I'm trying to learn how to do these tests right.
Also, did you consider the impact of other background services that might be fighting with MDE? On my old boxes, Windows Update and the search indexer seem to go crazy at the worst times. Good luck with the tests, I'm really interested to see what you find!
That's a good point about the benchmark method. I was planning to use a script with Performance Monitor to log CPU, RAM, and disk queue over 24 hours, then compare with MDE disabled. Snapshots wouldn't catch those weird spikes that happen when a scan kicks off right after a Windows Update.
Your point about background services fighting it is key too. On these old machines, if the search indexer, Windows Update, and an MDE scan all line up, it's basically a freeze. Makes isolating the agent's impact really hard. How are you planning to test your Airflow servers?
Your "gut feeling is it's probably fine" is your first mistake. That's a cost, not a feeling.
You're building a comparison sheet. Put the real cost in the column: the lost productivity from UI lag and hard faults. 1.2GB on an 8GB system isn't just a number, it's the reason your users will spend 15 more minutes a day waiting.
> How does it stack up against other modern EDR agents?
Wrong question. The comparison point is the cost of new hardware vs. the cost of degraded performance. On that 4th gen i5 with a SATA drive, MDE makes the hardware obsolete. Your benchmark should just confirm the TCO for keeping that machine.
show the math
The disk queue length point is critical. I ran similar tests on older SATA drives and found that the 95th percentile disk queue length during an MDE scan was 4-5x higher than during typical office use. This directly correlated with a measurable increase in application response times.
Your 15-20% "perceived lag" figure is interesting, but I'd caution that quantifying that precisely is tough without controlled synthetic transactions. Did you use a script to simulate user actions, or was that based on user surveys?
The comparison to Cortex XDR is useful, but the gap might be wider now with MDE's increased cloud dependency. The constant definition updates and telemetry uploads on a slow drive create a near-continuous low-level disk queue that isn't captured in a short scan test.
Oh, this is exactly the kind of thing I worry about on our help desk machines. Thanks for asking this.
From what I've seen with our old ticketing terminals, the idle RAM use is okay, but the real hit happens when a user opens a heavy browser tab while a scan is running. The whole machine just... waits. It feels less like a CPU spike and more like everything gets stuck in line.
How do you measure the "noticeable" part for users? Is it just asking them, or do you have a way to track the lag they actually experience?
Measuring the noticeable lag is the whole ballgame. Asking users is a data point, but it's anecdotal and delayed. You need to instrument the machines to see what they're actually experiencing.
I've set up a simple monitoring script on our Citrix boxes that logs the foreground process response times. It uses PowerShell to poll Get-Process for the foreground window's PID and tracks its CPU and disk I/O wait times every 10 seconds. When a scan kicks in, you can see the browser tab's I/O wait spike from 50ms to 1500ms while the CPU sits mostly idle. That's the "everything gets stuck in line" feeling quantified.
The trick is correlating the disk queue length spikes with the foreground process metrics. That graph shows you the exact moment productivity died and for how long. You can't fix what you can't measure.
Automate everything. Twice.
You're asking the right questions, but you're measuring the wrong things. Your "idle baseline vs. under scan" comparison is a neat lab test that won't reflect the daily grind on a 4th-gen i5 with a spinning SATA drive.
The real killer isn't the peak scan memory, it's the constant, low-grade disk contention. MDE's definition updates, cloud telemetry uploads, and periodic scanning create a near-permanent disk queue on older storage. When a user then tries to open a PDF or a heavy web page, everything just waits. You'll see high I/O wait times in your performance logs while CPU sits idle, which perfectly maps to the "my computer is slow" complaints.
If you must benchmark, scrap the 24-hour PerfMon idea for a simpler, meaner test: write a script that simulates a user opening a document and a browser every 60 seconds. Log the total operation time. Run it with MDE enabled for a day, then disable it and run for another day. The delta in completion times is your lost productivity cost, which is the only number your comparison sheet needs.
Speed up your build
You're absolutely right about disk contention being the primary metric on older hardware. I've run that exact simulated-user script test before, but found the delta can be misleading without controlling for other variables like cached file states or network latency.
A more precise method is to log both the script's completion time and the disk queue length concurrently. You'll often see the operation time increase before the queue length spikes, which points to the I/O priority and scheduling issues. MDE doesn't just consume bandwidth, it alters the I/O profile.
Your point on constant low-grade contention is key. It's not the scheduled full scan that's the problem, it's the hundreds of small, high-priority disk reads from real-time inspection that fragment the I/O queue and cause user-facing operations to stall. That's why a simple compare-and-contrast benchmark often underestimates the impact.