> provide access to a network

That's your first mistake. You should be providing access to software, not networks. The idea of a "trusted" network that applications or users can communicate on is the fundamental idea that zero-trust architecture aims to get rid of.

> You should be providing access to software, not networks.

You should be providing access to an identity, not software. If someone is running the same software but with the wrong identity, it should be denied access.

One non-malicious example that comes to mind is the right application from the wrong environment, e.g. dev frontend calling prod backend, or even worse prod backend calling test DB, etc.

I think they meant that software is 'what the identity should gain access to', and you 'should not grant that identity access to networks'; it is worded a bit confusingly.

From a known identity to an API

I feel like you need to go back and read the comment I'm responding to again, because you have deeply misinterpreted what I'm saying. I'm talking about the things users access, not who they are when they access them.

Close! Identity and environment. Even if you have "launch the missiles" authority, you might not have it on the weekends, at night, or from Cuba.

Indeed. Resulting in similar complexity between cloud and internal apps.

You can also call it 'perimeter-less security'.

As for zero trust - that seems to be a bit of a misnomer to me - doesn't it tend to aggregate trust into one big bucket - certs?

Won't anybody who can do man-in-the-middle or has access to root certs have total free reign?

Security services wet dream.

absolutely. can even completely 'eliminate' the network by closing all inbound firewall ports (not even allowing dynamic hole punching), and then opening ephemeral, session-specific L3 outbound connects (from both sides* of the session) only for authorized sessions.

* requires intermediate 'gateways' which can bridge both sides to enable bidirectional data flow, initiated from either side