r/zerotrust

we just finished rolling out SASE across our org and now leadership wants metrics to prove it was worth it. im struggling to define what actually matters in terms of SASE metrics.

latency numbers look acceptable, but users still report slowness. incident volume hasn’t changed much. costs are higher than expected even after optimization.

not sure which signals to trust. latency doesn’t always reflect user experience. incident counts don’t capture partial issues. cost per user increased, but visibility and control improved.

are user complaints the main indicator or is there a better way to measure this?

I propose the OSI model is flawed. The layers are simply patches to correct poor architecture and add persistance and security to a fundamentally stateless and insecure model.

The future of networks is not more complexity with firewalls WAFs and socket persistence, the future of authentication is not Oauth/JWT/Kerberos or Cookies. It's cryptographic identity, distributed ledgers and binary maps. Creating shared execution environments where trust comes first.

This model saves on compute & bandwith and increases fault tolerance & security. It already exists. Its already real and you can install it right now infront of your legacy stack.

Been doing a discovery pass across our environment lately and the shadow IT problem is way messier than I expected. Defender for Cloud Apps keeps surfacing stuff nobody's heard of - random SaaS tools people signed up for with their work email, old internal apps that still auth, somehow (still trying to nail down whether that's legacy SSO, LDAP, or something else entirely), and things that clearly touch business data but have no owner listed anywhere. Worth noting that discovery fidelity varies depending on your licensing tier, so your mileage may vary on how complete the picture actually is. The inventory phase alone has taken way longer than planned and we're not even close to done. What I'm struggling with is the prioritization side once you actually have a list. My current thinking is to go hard on anything that's internet-exposed, touches sensitive data, has weak or, no auth, has external user access, or has no clear business owner - and triage the rest. Business criticality is probably worth stacking on top of that too, since some of these ownerless apps might still be load-bearing in ways that aren't obvious. I'd also check whether something can just be retired outright before spending time bringing it under SSO. I've seen arguments for blocking unknown apps outright and only bringing them back if someone complains, which feels aggressive but honestly might be realistic in some environments. The counter-risk is you block something with a hidden dependency and have a bad day. Keen to know how others are actually handling this - especially whether you're doing a full, inventory before any enforcement, or just starting with the highest-risk stuff and working outward from there.

Been thinking about this lately after a conversation with a colleague who's mid-rollout and genuinely frustrated. Their org had a cloud migration moving along nicely, then ZT got bolted on top of it, as a parallel workstream, and now both projects are fighting for the same people and the same decisions. App inventory's incomplete, device posture data is all over the place, and every new cloud onboarding is hitting a wall waiting for policy sign-off. The security intent is right but the execution is basically creating a bottleneck on stuff that was already moving. My take from what I've seen is that it usually comes down to scope and sequencing. If you start by trying to redesign the whole network and overhaul identity at the same time, yeah it's going to slow everything down. NIST's guidance on zero trust architecture has always framed this as an incremental approach, not a big-bang network redesign, and that tracks with what actually works in practice. Starting identity-centric, getting Conditional Access doing real work first, and scoping early phases to high-value apps and data tends to cause way less friction. The ZT work then starts to feel like it's enabling the migration rather than blocking it. The other thing that keeps coming up is that orgs treating ZT as a separate security, program rather than embedding it into the cloud migration itself are the ones hitting the worst bottlenecks. Duplicated approvals, resource contention, decisions that need two teams to agree before anything moves. That governance piece is where a lot of rollouts quietly stall right now. Curious whether others have hit this and what actually helped, especially in hybrid AD and Entra setups, where the on-prem side adds a whole extra layer of complexity around device trust and identity sync.

The one that comes up constantly is treating zero trust as a destination rather than a continuous posture. People get a vendor in, stand up ZTNA or SSE, tick the box, and then act like it's done. The whole point is that trust is evaluated dynamically on every access request based on context at that moment, not granted once and left alone. The moment you treat it as a solved problem you've basically rebuilt the perimeter with extra steps. The other one I see constantly in hybrid environments is assuming zero trust is mostly an identity problem. Identity is critical, no question, but if you've got unmanaged devices, service accounts with hardcoded creds, and lateral, movement paths that your IdP has never even heard of, identity controls alone aren't going to save you. Segmentation and protect surface definition matter just as much, probably more in environments where legacy infrastructure predates the current team. I've spent a fair bit of time cleaning up exactly this kind of thing on the AD, and Entra side of hybrid setups and it's always messier than the identity layer makes it look. The tool sprawl situation has gotten worse too as orgs consolidate vendors without actually rationalising the underlying architecture first. Curious what misconceptions others keep hitting, especially in orgs that are mid-implementation rather than greenfield. The gap between the framework on paper and what actually gets deployed seems pretty consistent across different environments regardless of where they started.