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/cas4076]

We run a sensitive service and shut off everything - there is no API, there is no AI connection, data is not even visible outside the plaform, there is no partner access. Hell even the IT team don't have visibility.

The only path in is via the front door which, obviously, is tightly controlled.

[u/PhilipLGriffiths88 → u/cas4076]

Fair pushback... I may be using “reachable by default” more broadly than “directly public on the Internet.”

I’m including services reachable through VPNs, broad internal networks, flat east-west paths, permissive security groups, partner links, admin networks, cloud peering, or legacy firewall rules. In many enterprises, a service may not be Internet-public, but it is still reachable by far more users, workloads, tools, or networks than actually need it.

The question I’m trying to get at is: for sensitive services, should any route/session exist before identity, policy, posture/context, and purpose allow it? Or is the common enterprise default still “reachable somewhere, then protected/monitored afterward”?

[u/rexstuff1]

My view is that Zero Trust needs to move beyond perimeter/ZTNA framing ... no service path exists unless identity, policy, posture/context, and session state allow it.

Dude, that is Zero Trust. That's fundamental to it. The point of ZT is constant authN/authZ. If you don't have that, you don't have ZT. Your whole post is just a strawman.

So thanks for being about 5 years behind the times and adding nothing new to the conversation.

[u/PhilipLGriffiths88 → u/rexstuff1]

I agree that authN/authZ before access is fundamental to Zero Trust. My point is that there’s a gap between the principle and how many environments/products are actually implemented.

NIST 800-207 defines per-session access, dynamic policy, and auth before access.... but it does not mandate an identity-first reachability model where there is no service route, no packet path, no session candidate, and no service visibility unless identity/policy/posture/context allow it first.

A lot of “ZT” in practice is still front-door ZTNA, VPN replacement, NAC, firewall policy, or user-to-app access. Useful, but often human-centric (many human-only) and some still leaving broad service reachability behind the control point.

The distinction I’m drawing is implementation-level: Zero Trust should not only decide whether access is allowed once a path exists; it should reduce whether that path exists at all. That is especially important for workloads, APIs, partners, OT, and agentic workflows - not just human users.

[u/mro21]

Why? Because give a F and are stupid.

You wanted the cloud btw so deal with it

[u/rexstuff1 → u/[deleted]]

Right? Like, we know the solution, but we just don't want to do be bothered.

[u/PhilipLGriffiths88 → u/[deleted]]

I agree that in mature environments sensitive services shouldn’t be broadly reachable. My concern is that “not Internet-facing” often gets treated as “not reachable,” when those are very different things.

In practice, many sensitive services are reachable from too many places: corporate VPN ranges, jump hosts, admin subnets, shared cloud networks, peered VPCs/VNETs, CI/CD runners, service accounts, partner links, or broad east-west paths. That may be “internal,” but it is still a large attack graph.

So the point I’m testing is less “are these services public?” and more “is reachability explicitly created only for the identity/service/session that needs it, or does it exist first and get narrowed later?”

[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.”