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)"
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
Authentication and authorization for internal services is kind of basic.
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".
So long as you have two factors of auth, I am fine with it.
> I don't know what "zerotrust" is supposed to mean
My point exactly. What happens in most orgs is they pick out a few apps that are really important, implement MFA, collect some logs and put an edr on the servers and voila you have zero-trust. However, the authentication and security behind the trust you are establishing itself has implicit trust and lacks many layers of defenses so you're just polishing turd and calling it zero-trust.
Now, if every freaking device and user in your trusted compute base is authenticated before traversing a security boundary then all is well -- but wait, what does that really mean? Authenticated? So if I am a member of "domain users" and "authenticated users" in AD and I can just RDP to your fancy zero-trust labeled apps, is that really zero trust? If indirect and non-explicit permission grants such as with nested or broad group/role memberships grant people permissions then is that zero trust?
You see what I mean by this? Execs want to see zero-trust so all this b.s. gets pushed down and zerotrust ends up causing an increase in risk and exposure!
"Passwordless" isn't terrible if it means "use a physical device or TPM-stored secret instead of a password". It shouldn't replace 2FA by having 2 actual factors.