MDR vs. traditional antivirus: why the old model is dying

Antivirus looks for known bad files. That worked well when most attacks arrived as a file. Today, many do not. Modern attacks often use no bad files at all: stolen passwords, legitimate admin tools and cloud misconfigurations. There is nothing for a signature to match.
This post explains what antivirus still does well, where it stops, and what managed detection and response (MDR) adds. It is not an argument to throw antivirus away. It is an argument to stop treating it as the whole plan.
01.How the old model worked
Traditional antivirus compares files against a list of known malicious patterns, called signatures. When a file matches, it is blocked or removed. The model is simple, fast and still catches a great deal of commodity malware.
Its weakness is in the word "known". A new variant, a file with a small change, or an attack that never writes a file, will pass. The tool cannot judge behaviour it has not been told to look for. It also cannot decide what to do next. It raises a flag, and a person must act.
02.How attacks changed
Attackers learned that the easiest way in is often a valid login. They phish a password, buy one, or reuse one from another breach. Once inside, they use tools that already exist on your systems, such as remote admin software and scripting engines, because those look normal. In the cloud, they take advantage of open storage or over-broad permissions, which are settings, not files.
None of this trips a signature. It looks like someone doing their job, until you look at the pattern.
03.What MDR adds: people and process
MDR adds what antivirus lacks. Analysts watch activity across devices, identities and cloud, investigate what looks wrong, and act. The tooling gathers data. The people decide what it means and what to do.
What changes with MDR
- Behaviour, not signatures. A login from a new country followed by mass file downloads is suspicious, even if no file is "malware".
- Investigation. An alert becomes a decision: real threat or false alarm. Your team stops reading raw noise.
- Response. Someone isolates the device or disables the account, at any hour. Speed matters because attackers move quickly once inside.
- Learning. Each incident improves detection for the next one.
04.A short example
Picture an employee whose password was stolen. The attacker logs in from another country, creates a mailbox forwarding rule and starts downloading files from a shared drive. No malware is involved, so antivirus is silent.
An MDR analyst sees an unusual login, a new rule and bulk downloads in the same session. They check with the user or the named contact, disable the account, reset credentials and remove the rule. The incident ends with a short report on how it happened and how to prevent a repeat.
05.Where antivirus still fits
Antivirus is still useful. It blocks a large amount of everyday malware cheaply, and it should stay on your endpoints. Think of it as one layer. MDR sits above it, using its signals along with identity and cloud data to see the wider picture.
If your endpoint protection already includes behavioural detection, good. The question remains who watches the alerts, and who acts when it is the middle of the night.
06.What detection looks like in practice
Behaviour-based detection works by comparing activity with a picture of normal. A finance user who logs in from the same city every day, during office hours, from one laptop, has a pattern. A sign-in from a new country at 2 a.m., followed by a new mail rule and large downloads, breaks it.
Single events are weak signals. Combined events are strong ones. This is why analysts look across devices, identity and cloud together. An alert from one source rarely tells the whole story.
07.Why alerts alone are not enough
Many companies have security tools that generate alerts. The problem is volume and time. Someone must read each alert, work out whether it matters, find the owner of the affected asset and decide on an action. In a small IT team, this competes with everything else.
MDR moves that work to people who do it every day. Good analysts close most alerts quickly as harmless, and spend their time on the few that matter. That is where the value lies.
08.Cost and trade-offs
MDR is a service, so it costs money every month. Set it against the alternative. A small in-house security team needs several people to cover nights and weekends, plus tooling, training and management. Most mid-sized companies cannot justify that.
There are trade-offs. You give a partner some access to your systems, so trust and clear rules matter. You depend on their quality. And you still need someone inside to answer questions and approve fixes. MDR reduces your workload. It does not remove your responsibility.
09.Reading the signs that you are exposed
- Your security tools alert to an inbox that nobody watches at night.
- You cannot say who can disable an account out of hours.
- Your last incident took days to understand, because logs were missing.
- Customers are asking about monitoring and you answer with policy documents.
10.Common mistakes
- Assuming a tool equals coverage. A product that sends alerts to an unread inbox protects nobody.
- Watching only endpoints. Many attacks start with identity or cloud.
- Skipping response playbooks. Without agreed actions, analysts wait for permission while the attacker moves.
- Never testing. Run simulated events and time the result.
11.Fitting MDR into your wider security
MDR is not the whole security programme. Patching, backups, strong authentication, staff awareness and least-privilege access still matter, and they reduce what analysts have to deal with. Think of MDR as the watch on the wall, while those controls are the wall itself.
It also supports compliance work. Many frameworks and customer questionnaires ask about monitoring, incident response and logging. A service that provides records, reports and tested playbooks gives you real answers. Keep copies of reports and test results, since they are evidence you can show.
12.A realistic first month
In the first month, expect effort. You will list your systems, connect data sources, agree contacts and review early alerts. Expect some noise while the rules settle. By the end of the month, you should know what normal looks like, have playbooks that people have read, and have seen a first report.
13.Who should be told
Decide in advance who hears about an incident: IT, a senior manager, legal and, where needed, customers. Agree the order and write it down. Analysts can contain a threat, but the business decides what to say and to whom.
14.What to do next
Answer the five questions above in writing. Where the answer is "nobody", that is the gap. Decide whether to build a team, or to use a partner who already runs monitoring around the clock.
Brandsmashers provides senior security analysts, detection engineers and cloud security specialists for teams that cannot build a full security operations function. If you want to talk through what coverage would look like for you, we are happy to help.
NEXT STEP
Need help with this?
KEEP READING


