To measure ZT progress, count the services and security controls which rely on VPN/LAN. The closer it is to zero, the closer you are to ZT.
For example, all VPNs give you a single lockout/change password point, so this has to be at least common authentication. And VPNs have good logging for connections, so you got to have this too. And if your VPN client had device attestation, your solution should have have this too. And also services on VPN are not nearly vulnerable to auth bypass bugs, so your webserver should have some protection on this too (authenticating proxy?).
I think !VPN is exactly hallmark of ZT... as long as security is preserved. If you disagree, what do you think ZT's hallmark is?
(There is a philosophical question: if a company had a crappy VPN with no logging, and multiple VPN servers with no central auth.. and went to equally crappy user/pass webapp on internet.. does this count as "ZT transition"?)
Putting your internal apps behind an OIDC proxy instead of the VPN is a straight upgrade at that point. Especially if your provider already does some checks for you (e.g. Chrome Enterprise, requiring Cloudflare WARP app)
I think the whole DevSecWhateverOps thing fails to account for the severe antipathy large organizations have for outside-the-box solutions. A solution that requires people leave their silos, learn new concepts, or adopt new practices is just too much for them.
You can also see this publicly in GCP's Workload Identity and ALTS primitives, which enable very sophisticated policies.
Most BeyondCorp concepts seem simple, and they are, but they depend on a lot of existing machinery, almost all of which is non-existent in pre-existing corp networks. The average tech company is currently struggling to catch up.
I was discussing about ZT with a friend recently and we were agreeing that one of the problems with the USGov memo (and most of ZT advocates) is referring to ZT as an "Architecture". The memo paints a picture of ZT as a destination whereas it really should be understood as a framework, culture and design philosophy. And that makes it, by definition, a journey. Its principles are supposed to guide your architecture design but they are not the architecture i.e there can never really be a point where you can call a friend and be like "Look at this, I've finally 'built' a Zero Trust Architecture". And you can't have a consultant come in and go back a few months later telling you "Alright, here's your Zero Trust Architecture". ZT has to be continuously entangled into your dev flow, ops, policies and day to day technical decision making.
I also suspect that another important missing piece (whether you look at it as a journey or a destination) is how to quantitatively MEASURE progress on Zero Trust. Having precise reference metrics would help in actually enforcing the goal of the memo or at least being able to tell that company A has a better measured ZT progress than company B.
I guess, like they say, "Zero Trust is like teenage sex: everyone talks about it, nobody really knows how to do it, everyone thinks everyone else is doing it, so everyone claims they are doing it."
Disclaimer: Googler but I don't work on the BeyondCorp team.