What do teams get wrong when they rely only on antivirus and firewalls against hacking?

Teams often assume perimeter tools are sufficient, but the article argues that modern attackers are too strategic for that model. Antivirus and firewalls do not stop credential abuse, lateral movement, or repeated access attempts across cloud and SaaS environments. Effective defense requires identity and device controls, multi-factor authentication, and a Zero Trust approach that verifies each request, not just the initial login.

Why Antivirus and Firewalls Miss the Real Attack Path

Antivirus and firewalls are useful controls, but they are designed around signatures, network boundaries, and known patterns. Modern intrusions often succeed by using valid credentials, remote access, or trusted application paths, which means the traffic and activity can look legitimate once the attacker is inside. That is why these tools are only one layer, not the whole defense.

The core mistake is treating prevention at the perimeter as equivalent to control over the asset itself. If an attacker can authenticate successfully, move laterally, or reuse an approved cloud or SaaS session, perimeter tools may never see a clearly malicious event to block.

Teams also underestimate how much of today’s exposure comes from identity and device trust rather than from a noisy malware sample. Once an account, token, or device is trusted, the attacker can often operate through normal administrative, browser, or API flows without triggering a classic antivirus-style detection.

Why Credential Abuse and Lateral Movement Slip Past Legacy Controls

Credential abuse changes the problem from “can the malware be stopped” to “should this request be trusted at all.” Firewalls do not tell you whether a login is stolen, and antivirus does not determine whether a session token is being used by the right person, device, or location. That is why repeated access attempts, phishing success, and token theft are so effective against perimeter-only thinking.

Lateral movement is similarly hard for these tools to catch when the attacker uses built-in admin tools, remote management, or approved internal connections. The activity may be technically allowed by the network stack, even though it is operationally hostile. In cloud and SaaS environments, the attack often moves through identity, permissions, and session reuse rather than through a detectable payload.

This is also where device trust matters. If the endpoint is unmanaged, out of date, or already compromised, a firewall at the edge cannot prove that the request is safe. Effective containment depends on verifying the user, the device, and the request context together.

What a Better Control Model Looks Like

A stronger model combines identity controls, device controls, multifactor authentication, logging, and trust decisions that are made per request. That shifts the question from “did the user ever log in?” to “should this specific action be allowed now?” The difference is important because attackers frequently exploit the gap between successful initial access and later privileged action.

In practice, this means reducing standing access, tightening privilege, and making authentication harder to replay. It also means detecting abnormal use of valid accounts, not just malware execution. For environments with SaaS, cloud consoles, and APIs, the control objective is continuous verification of access paths, not blind confidence in a clean perimeter.

Risk and Threat Considerations

Relying on antivirus and firewalls alone creates blind spots around valid logins, stolen sessions, and internal movement after the first foothold. The risk is not just initial compromise, but the attacker’s ability to use permitted channels while appearing normal to boundary controls.

Failure mechanism: The defender trusts network location and malware detection more than identity, device posture, and request context, so stolen credentials, session hijacking, and approved remote access can bypass the intended security model.

Impact: Attackers can persist longer, expand access laterally, and reach cloud or SaaS assets without needing to defeat the perimeter again, which increases blast radius and slows detection.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-2 — Identification and Authentication (Organizational Users)	Credential abuse and login trust are central to the attack path.
	IA-5 — Authenticator Management	Session reuse and stolen credentials make authenticator lifecycle critical.
	AC-6 — Least Privilege	Limit what a compromised account can do after perimeter bypass.
Recommendation — Enforce strong user authentication before granting access to sensitive systems. Rotate, protect, and revoke authenticators that could be replayed or stolen. Restrict permissions so compromised accounts cannot move freely or escalate.
NIST Zero Trust (SP 800-207)	Zero Trust Architecture	The question directly contrasts perimeter trust with verify-each-request defense.
Recommendation — Adopt per-request verification and continuous trust assessment instead of perimeter trust.
OWASP ASVS	V6 — Authentication	The answer hinges on stronger authentication than a one-time perimeter check.
	V8 — Authorization	Attackers abuse permitted access paths after they get in.
Recommendation — Require strong authentication and reauthentication for sensitive operations. Verify authorization on every sensitive action, not just at login.
MITRE ATT&CK	T1078 — Valid Accounts	The core failure mode is attacker use of legitimate credentials and sessions.
	T1021 — Remote Services	Lateral movement often uses approved internal or remote access channels.
Recommendation — Hunt for legitimate-account abuse and alert on abnormal use patterns. Monitor remote service usage for unusual source, timing, and privilege.

Practitioner Guidance

What to prioritise: Treat account abuse and session reuse as first-class intrusion paths, not edge cases. If your telemetry focuses on blocked malware but not on anomalous logins, privilege changes, or impossible travel patterns, you are likely measuring the wrong thing.

What to verify: Confirm that access decisions are tied to identity assurance and device state, and that high-risk actions require fresh verification. If a user can reach sensitive systems from an unmanaged device with only one-time login validation, the control design is too permissive.

Practitioner takeaway: The real failure is not that antivirus and firewalls are useless, but that they do not answer the question modern attackers exploit most, whether this request should be trusted right now.