Rethinking security maturity when compromise is assumed.
Enterprise security has a familiar rhythm. Vulnerability drops, advisory hits your inbox, someone schedules an assessment, patch discussion goes in circles, exception request gets filed, dashboard turns green, repeat. Most security programs run on that loop without ever questioning whether it’s the right one.
And look, patching matters. Advisories matter. CVEs are real.
But somewhere along the way, vulnerability response stopped being part of the security program and became the whole thing.
That’s the problem.
AI is shortening the time between “vulnerability found” and “vulnerability exploited.” It’s increasing the volume of signal teams have to process. It’s making the old question, “are we patched?” feel increasingly inadequate.
The question that actually matters now is: how much control do we have when patching can’t save us?
That’s what Zero Trust was built for.
The perimeter didn’t disappear, it multiplied
There’s a persistent misconception that Zero Trust is a network architecture, or something you can buy a product for. ZTNA is one implementation of the principles. It’s not the whole framework. Purchasing a Zero Trust product doesn’t make you Zero Trust.
The actual foundation of Zero Trust is one uncomfortable idea:
Assume compromise.
Not as a thought experiment. As a design constraint.
Assume credentials get stolen. Assume endpoints get infected. Assume that “trusted” network isn’t. Assume a fully patched environment can still be used against you.
Once you accept that, the questions shift:
- If this system is compromised, what can it reach?
- Where have we granted trust we haven’t thought carefully about?
- How long before we’d notice something was wrong?
- How fast could we cut it off?
- How fast could we get back to a clean state?
- What’s the cost of acting early versus absorbing a bigger hit later?
That’s the real shift. Not a product category. A posture.
For years security practitioners kept saying “the perimeter is dead.” That framing was only half right.
The old network perimeter, firewall at the edge, everything inside assumed safe, has largely eroded. But “perimeterless” isn’t accurate either. The modern enterprise has more perimeters than ever. Internet-facing applications. Remote access services. Cloud platforms. SaaS environments. APIs. Identities. Third-party integrations. Every one of them a trust boundary. Every one a potential entry point.
Zero Trust remains relevant precisely because of this. It won’t let you assume safety based on location, behind a firewall, inside the corporate network, authenticated via VPN. None of that is sufficient anymore.
A VPN session isn’t a guarantee. A server inside the perimeter isn’t inherently protected. A SaaS account with working credentials can still be a liability.
Trust has to be earned continuously, scoped tightly, and easy to revoke.
Vulnerability management is not exposure control
The security industry is genuinely good at finding vulnerabilities. Less good at understanding what they actually expose.
Those aren’t the same problem.
A vulnerability is a technical defect. Exposure is the full picture, reachability, privilege, what the compromised system can touch, whether compensating controls exist, how fast you can recover if it’s exploited. A critical CVE on a well-segmented, closely monitored system may carry less practical risk than a moderate finding on an integration server with standing access to everything that runs the business.
Vulnerability volume creates noise that looks like progress. More findings, more tickets, more dashboards. But without understanding attack paths and trust relationships, its motion, not control.
Zero Trust reorients the question. Not “how many vulnerabilities do we have” but “where does meaningful exposure actually exist, and what trust relationships make it dangerous.”
That’s the gap between vulnerability management and exposure control, and it’s wider than most programs acknowledge.
Resilience means rebuild velocity
AI won’t overnight-transform every attacker into a nation-state. But it does make the economics of attack better, cheaper reconnaissance, faster exploit development, more convincing phishing, automated variation at scale. The window between “vulnerability exists” and “vulnerability is being used” keeps shrinking.
Prevention still matters. It just can’t be the whole answer.
The harder question is: when something gets through and something will, how fast can you contain it before it becomes a business problem?
That’s where resilience stops being a DR concept and starts being a security control.
Build like an engineer. Design systems to be isolated, observable, and replaceable. When a component is compromised, the goal isn’t to rehabilitate it while the attacker moves laterally through your environment. You contain it, swap it out for a known-good version, preserve what telemetry you need, and keep the business running.
Immutable infrastructure, golden images, infrastructure as code, workload segmentation, tighter identity controls, better observability, the specific mechanism matters less than the underlying logic: the more exposed a system is, the faster you need to be able to replace it.
Resilience used to be measured by what you prevented. Increasingly it’s measured by how quickly you can recover when prevention wasn’t enough.
Detection only matters if action follows
Security teams have spent heavily on EDR, MDR, SIEM, SOAR, cloud security tooling, identity analytics, threat intelligence. All of it justifiable. None of it sufficient on its own.
Deploying EDR isn’t response. Collecting telemetry isn’t acting on it. Alerts that don’t drive action don’t reduce risk, they add overhead.
The question worth sitting with is: when your tools surface indicators of compromise, what actually happens? Can you revoke access fast enough? Can you isolate a compromised asset before the attacker pivots? Can you make the call to accept a small disruption now rather than risk a much larger one?
These are operational questions, not technology questions.
And this is where Zero Trust gets practical in a way that’s easy to miss. It’s not primarily an access control framework. It’s a framework for removing trust quickly once that trust is no longer justified. The organizations that handle compromise well aren’t usually the ones with the most sophisticated tooling. They’re the ones that have done the work to make decisive action possible when the moment arrives.
Attack paths matter more than findings
Treating every vulnerability as its own emergency is a good way to stay busy without improving your actual security posture.
What matters more is understanding how an attacker moves once they’re in.
When something suspicious appears on an internet-facing system, the exploited vulnerability is almost secondary. The more urgent questions are about what it connects to:
- Where was the attacker trying to go?
- What made that path available, which identity, integration, or service account?
- How do you break that path before it reaches something critical?
- How do you close it so it can’t be used again?
This is where Zero Trust and exposure management do their most useful work together. The goal isn’t a longer list of weaknesses; it’s a clear picture of how weaknesses connect to things that actually matter to the business.
Often the fastest risk reduction isn’t a patch. It’s a segmentation change, an identity restriction, a revoked permission, a configuration adjustment that immediately severs the attack path. Patching is important but it’s rarely the fastest lever, and in some cases it’s not available at all.
Organizations that measure security by finding count tend to miss the real exposure. Organizations that understand how attack paths are constructed are the ones that can actually get ahead of it.
Business continuity is a security discipline
For a long time, business continuity lived in a separate room from cybersecurity. Related, occasionally coordinated, but organizationally distinct. That separation is becoming harder to justify.
Ransomware, supply chain compromise, AI-assisted exploitation, identity abuse, recovery isn’t something that happens after the security program fails. Recovery is part of what a security program is supposed to deliver.
A program that can’t answer “how do we rebuild” isn’t mature, it’s just half-finished.
That means knowing which systems have to come back first. Which services can be reconstructed automatically. Which workloads can be isolated without pulling everything else down. Which business processes have grown dependent on systems that were never designed to be critical.
NIST CSF 2.0 puts it plainly: Recover is a core function, sitting alongside Govern, Identify, Protect, Detect, and Respond. Not a phase that happens after the incident is closed. Not a backup exercise. A capability that has to be built and maintained deliberately.
The more critical a system is, the more intentional recovery planning needs to be.
The more exposed it is, the less time you’ll have.
Zero Trust is a control philosophy
The industry spent years turning Zero Trust into a product, then a framework, then a maturity model, then a transformation initiative. Some of that scaffolding is useful. Most of it obscures a fairly simple idea.
Don’t grant trust by default.
Not because a user looks legitimate. Not because a device is on the corporate network. Not because a workload is in a managed environment. Trust should be explicit, tied to context, limited in scope, and revocable when that context changes.
That idea runs through every serious security framework. NIST Zero Trust Architecture removes implicit trust based on location. CISA extends Zero Trust principles across identities, devices, networks, applications, workloads, and data. NIST CSF 2.0 builds the full lifecycle around it.
None of them are asking organizations to be more permissive. They’re asking organizations to be more deliberate, to understand where trust has been extended, whether it’s still warranted, and how quickly it can be pulled back.
That’s control. That’s what Zero Trust has always been pointing at.
The new test of security maturity
Patch velocity used to be a reasonable proxy for security maturity. It still matters. It’s just not a complete picture.
The more revealing question is what happens when patching isn’t an option, when the patch isn’t available, when deployment would break something critical, when the vulnerability is being exploited faster than the change window allows.
Can you see your estate clearly enough to know what’s exposed? Can you identify attack paths, isolate compromised assets, revoke trust quickly, rebuild from a clean state, preserve the evidence you’ll need, and keep the business running through it?
That’s what executives should be testing their programs against.
Vulnerability management is part of the answer, an important part. But only part. The programs that will hold up over the next few years aren’t the ones optimizing patch SLAs. They’re the ones building environments where compromise is anticipated, blast radius is contained by design, recovery is fast because someone engineered it that way, and control can be demonstrated even when something goes wrong.
Security isn’t about assuming nothing will break.
It’s about building things so that when they do, the business keeps going.
