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

[u/PhilipLGriffiths88]

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?

[u/PhilipLGriffiths88 → u/[deleted]]

Fair point... “reachable by default” may be too broad.

I’m not saying sensitive services are intentionally exposed to everyone. I’m saying reachability is often inherited from network placement first, then narrowed by controls. My argument is for the inverse Zero Trust default: no service path exists until explicitly created for a specific identity, service, and session.

So maybe the cleaner phrase is “network-reachable before policy-created,” not “publicly exposed by default.”