From a more cynical point of view, "zero-trust" tends to mean something along the lines of: "trust a TPM on the user side... and all of my server logic and my cloud provider."
From a less cynical point of view it means "hold all the client's keys in their TPM and only authenticate on the server side, but don't decrypt (or otherwise pass keys around)"
zero trust at its core means authentication and authorization at each service, for each request. at a high level it means not trusting a connection from another service in the same network just because itβs on the same network. rooting trust to tpms is orthogonal but certainly the right way to root trust.
The space where I think zero trust is the most interesting are vpns like tailscale/wireguard/microsegmentation that flip the status quo around and say the network is the identity/authoritzed group
Wait, but I thought everyone was doing that anyway prior to the "zero trust" thing. The difference was who you trusted to hold user (and concern-specific) keys - before zero trust, it was your server, and afterward, it's the user.
Authentication and authorization for internal services is kind of basic.
> I thought everyone was doing that anyway prior to the "zero trust" thing.
Nope, lots and lots of organizations who have a zillion of internal services which they know to be insecure but are kept that way because they "are accessible only on the protected network".
From a less cynical point of view it means "hold all the client's keys in their TPM and only authenticate on the server side, but don't decrypt (or otherwise pass keys around)"