Interesting. If you’re actually using “Zero trust” to attempt to convey “zero trust architecture”, in the BeyondCorp sense, I’m more confused than before.
The central premise of BeyondCorp and similar approaches is about no longer trusting based on network location, and instead always performing trust based on device identity and other factors. This is why PKI plays such a pivotal role in BeyondCorp: your organization’s CA signs certificates, which are present on every device, and that combined with additional forms of user authentication enables trust regardless of network location. Leveraging a WireGuard VPN is largely a step “backwards”; it moves back towards a VPN-style world where you allow access by requiring endpoints to step inside a conceptual network boundary (by connecting to the VPN). In practice, the Wireguard model has several advantages over that, but it’s explicitly different from the BeyondCorp/Zero Trust approach.
Edit to clarify:
“Zero trust architecture” doesn’t refer to whether endpoints trust a central service/provider, it refers to whether corporate assets base their trust determinations on the origin point of client traffic. For example, in a non-Zero-Trust environment, corporate assets might assume clients connecting from the local network are trusted, and require roaming users to VPN in. By contrast, a Zero-Trust environment might use MDM-provisioned certificates and MFA on all connections, regardless of the network placement of the endpoint.
“Zero trust” as colloquially used by service providers tends to mean “you don’t have to trust us”. This is largely because “zero trust architecture” doesn’t really make sense as something a provider provides, and also because providers have latched onto “zero trust” as a buzzword.