A few weeks ago I asked on X and LinkedIn a deceptively simple question: which “security basics” matter more against AI-armed attackers, and which ones don’t matter anymore?

[before you freak out about ‘…but Anton, we don’t even have a consensus definition of “security basics’, read on — I gracefully sidestep this critical issue :-)]

I got about 60 answers. Most of them converged on the same reasonable, practitioner-approved, completely unsurprising consensus: the basics aren’t dead, AI just punishes sloppy execution faster. This is true. It has also been true of every attack trend since 1998 (hi Satan! hi Metasploit! hi fuzzing!). If that were the whole story, this post would end here.

But one reply challenged the premise, and it turned out to be the most useful comment in the thread: what can an “AI attacker” actually do that a skilled human attacker couldn’t?

The honest answer today is: nothing.

Still, this has implications related to scale, speed, coverage and a whole lot of other things. Sometimes changing the speed on the attack side should NOT lead to “well, defense should also run faster” arguments. We should “do different”, not run “almost as fast” as the attacker. Let’s think about it!

The scarce resource was never technology. It was attention.

This is also the “secret” why “luck-based” security works for some organizations. Even if they have glaring holes, DMZ CVSS 10s unpatched since 2016, Windows 2003, Red Hat Linux 9 and PHP (oh god, so much PHP!) they may still be in business, and doing sort of OK. That is why I always say that people with 10K unpatched HIGHs do NOT fear Mythos-induced “vuln-apoc” of having 300K unpatched HIGHs. The lift won’t change risk for them (IMHO) So let’s say 30x more vulnerabilities leads to … I dunno … 3% more risk?

Anyhow, for the entire history of this field, the single scarcest resource on the offensive side was skilled (defined broadly, perhaps semi-skilled too) attacker hours. There were never enough competent humans to exploit every reachable vulnerability at every company, craft a convincing lure for every employee, abuse every public S3 bucket and work through every organization’s attack surface.

The attackers did what any rational actor does with a scarce resource: they allocated it. They went after the easiest targets, the juiciest ones, or the ones that happened to be in front of them.

Here is the uncomfortable part. Perhaps you think it is obvious? A surprising share of what we call “security basics” were never really about stopping attackers. They were about not being worth the effort at the moment:

• Patch cadence was about closing the window before someone got around to you. Not before someone could, before someone would (This is a profound idea, IMHO. Thanks Claude Fable 5.1!)
• Phishing awareness training worked, to the extent it ever did, because mass phishing was sloppy. Crafting a good lure was expensive, so most lures were bad, so “spot the typo” was a real signal.
• “We’re not a target” was a risk-acceptance strategy that only made sense if the attacker was choosing targets. Again, “luck based security” was very much a thing.
• Coverage metrics like “80% of assets patched within SLA of 30 days” implicitly assumed the remaining 20% was hiding in a pile the attacker wouldn’t bother to sift through. IT sure couldn’t ;-)

None of these controls fail because attackers got smarter. They fail because attacker labor became elastic. When the marginal cost of one more exploitation attempt, one more tailored lure, one more recon pass drops toward zero, there is no such thing as low-hanging fruit anymore. All the fruit gets picked. Ok, this is new! This is fun!

Still, we have seen a similar movie before, and I was there for the first showing. Network scanners in the late 1990s and Shodan in the 2010s did not invent new vulnerabilities. They removed obscurity from the discovery phase and forced everyone to admit that “nobody knows about that server” was not a control.

In my view, AI is doing the same thing one layer deeper: removing scarcity from the exploitation and social-engineering phases.

Whatever you believe about the exact numbers in the recent frontier-model evaluations (end-to-end corporate takeover chains, three-figure attack costs, and so on), the direction is not in dispute. The attacker is no longer rate-limited by their headcount and “attention count.”

The sorting rule

This gives us something better than a list. It gives us a rule.

A [security] basic survives if it works by physics or math. A basic dies if its risk reduction was proportional to attacker effort.

• No wire, no access. Network isolation does not care whether the probe came from a bored teenager or an agent running 1,000 recon passes a second. Hey Cisco ;-)
• No binary, no execution. Application allowlisting does not care how the entry point was found.
• No phishable auth factor, no phish. FIDO2 does not care how convincing the lure is, or whether it arrived as a flawless email or a cloned voice. No chip — no access.
• No software, nothing to patch. You cannot exploit what has been removed.

In the “1990s speak”, AI cannot scan your ports, if you don’t have ports. Get rid of the TCP/IP stack while you are at it :-) Conversely, anything that reduces risk by making you slightly harder to attack than the next guy is on the wrong side of this line. So your zero-day laden security tool that runs “input filtering” is shot in the butt…

The matrix: AI resilience × modern feasibility

Back in my Gartner days, we wrote a paper on IT hygiene and which controls actually constitute a foundation. Oh those endless debates on whether NIDS is a basic control in 2016…. I recall you so fondly!

The list below is a first pass at re-running a similar exercise with two axes:

• Does it hold against a tireless attacker, and
• Can anyone actually deploy it in a modern environment?

BTW, the second axis matters more than people think. A control that is AI-proof, but undeployable is not a security basic. It is a wish at best…

From this, three things that are emerging as basics, done by a few now and needing to become universal:

• Identity verification for humans at hiring and high-risk moments. In-person or equivalent anti-deepfake process for video hiring. This sounded paranoid in 2023. This sounds routine in 2026.
• Anything that cuts off network access still works well. If you can gracefully limit connectivity, no attacker — with AI or without — can touch it. This of course wins some degree of Easier Said Than Done prize… but it is still real.
• Identity and inventory for non-humans. If you cannot enumerate your agents and service identities, “intent enforcement” is a slide, not a control. Agent security (however defined) cannot be solved unless we solve agent identity.
• AI-driven code and data discovery. If your data classification project has been “in progress” since 2019 (or:1989?), the attacker’s is not. So, here you do need to run faster than the attacker, yes.

The patching dilemma, properly stated

Now back to patching. According to many, patching is the ultimate “security basic,” so it deserves its own math. BTW, others say that it is neither security nor basic… Review these first, perhaps.

Under a human attacker, patch coverage was roughly linear. Going from 30% to 80% of assets patched within SLA removed 50 “points of exposure”, because the attacker was not going to find and exploit every one of the remaining gaps. Some of them were effectively hidden by the attacker’s own bandwidth.

Under a tireless attacker (read: AI), exposure stops being “what fraction is unpatched” and becomes “is there at least one reachable, usable, exploitable gap.” That number stays stubbornly close to 1 until coverage approaches 100% for reachable assets. Improving from 30% to 80% may produce close to zero risk reduction. The remaining 20% is not hiding anymore. This is new, and a bit scary. But this is an assumption to test, not a law. We need data!

But if it holds even partially, the levers change:

• Shrink the denominator. Fewer things that need patching. This is why attack surface reduction jumps up in importance.
• Make the gaps unreachable. Network isolation converts “unpatched” into “unpatched yet irrelevant.” This is why segmentation is back. Microsegmentation grows in importance.
• Make patching a rebuild, not a maintenance window. If you cannot rebuild a workload from code in minutes, you are not going to win a speed contest against a vuln storm. This is less a security basic than an IT cornerstone, which is exactly the problem.

So “patch faster” and “patching doesn’t cut it” are both right. The goal survives. The implementation everyone recognizes as “patching” does not.

That pattern repeats across the table: many basics survive as objectives and die as the specific practice we associated with them. Similarly, awareness training survives as “humans exercise judgment” and dies as “annual click-through module.” Least privilege survives as a principle and dies as “someone reviews IAM policies quarterly.”

What this means, operationally

If you take one thing from this: subtract before you add. Before buying the AI-vs-AI tooling that every vendor is now pitching, remove the software you don’t need, cut the wires that don’t need to exist, and finish the asset inventory you’ve been not-finishing since your first CMDB project. These are not exciting. They are also the only controls on the list that a tireless attacker cannot outrun. Niels Provos reminds us of the same.

One more honest observation. Several of the “promoted” basics above (remove unnecessary software, segment aggressively, fix least privilege) have been recommended for 20 years, and no previous threat trend actually motivated organizations to do them. Maybe an attacker who never sleeps and never gets bored finally will. Or … maybe we will spend the budget on AI-powered SOC dashboards instead. I am, as always, an optimist…

Related:

• The Feynman Bet: Why You Still Won’t Vibe Code Your SIEM (Today)
• Beyond the Vulnerability Apocalypse: Scaling Your Basics and Vulnerability Management
• Breaking the Patch Sound Barrier Part 2: So Is The Apocalypse Coming and What Is It?
• The Ancient Art of SIEM: Why 2003 Problems Look So Familiar in 2026
• “AI Normal Tech” vs “AGI by Tuesday”: Security Advice That Survives Either Future

Survival of the Basics: Which Security Fundamentals Were Secretly Relying on Lazy Attackers? was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

Not sure it’s practical, but it’s certainly striking.