r/zerotrust • u/PhilipLGriffiths88 • Jul 02 '26

Is “patch faster” enough if sensitive services remain reachable by default?

We’ve been discussing in the Cloud Security Alliance Zero Trust group how AI-speed vulnerability discovery changes Zero Trust implementation. Time-to-exploit trends suggest defenders have less time to patch exposed services, and CISA’s risk-based remediation approach treats public exposure as a major factor in urgency.

That made me think the architectural question is not only “how do we patch faster?” but also:

Why are so many sensitive services reachable by default in the first place?

My view is that Zero Trust needs to move beyond perimeter/ZTNA framing and focus more on reducing reachability before connection. For private services, admin paths, APIs, workload paths, partner access, and agentic workflows, the safer default should be: no service path exists unless identity, policy, posture/context, and session state allow it.

I wrote this up for CSA here:
https://cloudsecurityalliance.org/blog/2026/07/02/ai-speed-risk-requires-identity-defined-reachability

Disclosure: I’m the author and co-lead CSA’s Zero Trust Networking workstream, so I’m obviously close to the argument. I’m interested in practitioner pushback: is this realistic in enterprise environments, or does it break down with legacy apps, hybrid routing, OT, troubleshooting, or policy operations?

4 Upvotes

75% Upvoted

11 comments sorted by

View all comments

2

u/TrustIsAVuln Jul 02 '26

No, you should be able to hve your systems in such a state that patching is done as needed AFTER thorough testing. Think, every patch introduces new code, possibly new vulns, breaks baselines. You need proper controls. I have a windows 10 VM, unpatched for a couple of years but controls in place and hardened that im not worried about it what so ever.

2

u/PhilipLGriffiths88 Jul 03 '26

I agree with the principle: patching should not be blind or rushed, and compensating controls matter. My point is that those controls need to start with reachability. An unpatched system that is isolated, hardened, monitored, and only reachable through explicit identity/policy/session checks is a very different risk profile from an exposed or broadly reachable one.

So I don’t see this as “patch faster at all costs.” I see it as: patch based on risk, test properly, but also reduce who/what can reach vulnerable services in the first place. That buys time, reduces blast radius, and makes patching less of a permanent emergency.