Zero Trust Without the Vendor Pitch: A Pragmatic Roadmap

Why "Zero Trust" stopped meaning anything

"Zero Trust" is the most marketed term in security. Every product on the market claims to do it. There are Zero Trust firewalls, Zero Trust browsers, Zero Trust SD-WAN, Zero Trust endpoint agents, Zero Trust file shares. It's been shoved onto so many things that conversations about it usually devolve into people defending which vendor's definition is right, instead of doing the actual security work.

The original idea is small and good. It comes from a Forrester paper and a Google BeyondCorp series, and it boils down to: don't trust the network as a security boundary. Authenticate and authorize every request individually based on identity, device posture, and context. Treat the corporate network the same as the open internet. That's it. Everything else is implementation.

This post is what Zero Trust means in practice for a real engineering organization. The five things to ship first, the order to ship them in, what to ignore, and how to talk about it with leadership without using buzzwords. None of this requires a vendor product, though some vendors will help you go faster.

1. The five things that actually matter

Zero Trust touches a lot of areas, but in our experience there are five concrete capabilities that get you 80% of the value. If you ship these, you've meaningfully done Zero Trust. If you skip any of them, you haven't, no matter how many vendor logos are on your slides.

1. Strong identity, with phishing-resistant MFA, for every user. The foundation. Without this, nothing else works.
2. Device trust as a first-class signal in access decisions. Authenticated users on unknown devices don't get the same access as the same users on managed devices.
3. Per-application access, not network-level access. Users authenticate to individual applications. The network they're on is irrelevant.
4. Workload identity for service-to-service auth. Services authenticate to each other with short-lived, automatically-rotated credentials tied to their workload identity. No long-lived API keys or shared secrets.
5. Continuous evaluation, not one-time authentication. Sessions get re-evaluated as risk signals change. A user whose device just lost compliance gets kicked out of sensitive applications even mid-session.

Notice what's not on the list: micro-segmentation, ZTNA appliances, "Zero Trust" SIEMs, network analysis tools. Those are valid technologies but they're implementation details. Start with the five above. The rest comes later if it makes sense at all.

2. Phase 1: identity and phishing-resistant MFA

If your identity provider isn't already centralized and isn't already enforcing strong MFA, this is where you start. Everything else depends on it.

The target state: every user authenticates through a single IdP (Okta, Microsoft Entra ID, Google Workspace, or equivalent). Every application is integrated with the IdP via SAML, OIDC, or SCIM. No application has its own user database except where it must. MFA is required for every login, and the MFA factor is phishing-resistant — FIDO2 security keys, platform authenticators (Touch ID, Windows Hello, Android biometrics), or push-based passwordless. SMS and TOTP do not count as phishing-resistant. They're better than passwords alone, but they get phished routinely and modern adversary toolkits include real-time SMS interception.

The hard part isn't picking the IdP. The hard part is the long tail of applications that aren't on it. Every legacy app, every shadow-IT SaaS, every internal tool with its own login. The work is to enumerate them all, prioritize by risk, and migrate. Plan for this to take a quarter at least.

One tactical recommendation: start the MFA migration with admin and engineering accounts, not with the broader user base. Admins are the highest-value targets and the most willing to deal with friction. Roll out to the rest of the org in waves once the friction is ironed out.

3. Phase 2: device trust

Authentication says who the user is. Device trust says what they're authenticating from. The combination is much stronger than either alone. An attacker who phishes a user's password and MFA token still can't access anything if the access policy requires the request to come from a managed device — and the attacker isn't on a managed device.

Implementing device trust takes three things:

• An MDM that knows which devices are managed. Jamf for Mac, Intune for Windows, MDM-of-choice for mobile. The MDM enforces baseline configurations (disk encryption, OS version, screen lock) and reports compliance.
• A way to bind device identity to authentication. Device certificates from your MDM, presented during the auth flow. Or a posture signal from your endpoint agent (CrowdStrike, SentinelOne, Defender for Endpoint) that the IdP can read.
• Access policies that condition on device state. Okta, Microsoft Entra ID, and Google Workspace all support this. The policy says: "for this application, require managed-device, compliant, current OS." Non-compliant devices get blocked or downgraded to read-only.

Roll this out by application sensitivity. Start with the most sensitive (production cloud consoles, code repositories, sensitive customer data). Loosen for the long tail.

4. Phase 3: per-application access (kill the VPN)

Every flat corporate VPN is a Zero Trust violation. The premise of a VPN is "you're on the network, so you're trusted." That premise is wrong. Once an attacker is on the VPN — through a phished credential, a stolen device, or a compromised contractor — they have lateral movement to everything the VPN reaches.

The replacement is per-application access. Each internal application is published through an identity-aware proxy that enforces auth and posture per request, instead of being accessible to anyone on a network. The proxy options:

• Cloudflare Access (and equivalents from Zscaler, Tailscale, NetFoundry). Hosted ZTNA services. Wire your applications behind them, configure access policies in the IdP, you're done. Lowest operational cost.
• BeyondCorp Enterprise if you're a Google Workspace shop and Google's ecosystem fits.
• Self-hosted identity-aware proxy (oauth2-proxy, Pomerium, Authelia). Higher operational cost but fewer external dependencies.

The migration sequence: enumerate every internal app behind the VPN, prioritize by usage, publish the top ones through the proxy, give users instructions, monitor adoption. Once a critical mass is migrated, kill the VPN entry point for those apps. The VPN itself can stick around for a long tail of legacy systems but it shouldn't be the front door.

The hardest internal apps to migrate are usually the homegrown ones with their own auth. You'll have to wedge an authenticating proxy in front of them or refactor them to delegate auth to your IdP. Both are work; both are unavoidable.

5. Phase 4: workload identity for service-to-service auth

Zero Trust isn't just for users. Services authenticating to other services should follow the same rules: short-lived credentials, identity tied to the workload, no shared secrets sitting in environment variables. We've written a separate post on cloud IAM modernization that covers this in depth, but the short version:

• In AWS: IAM Roles for Service Accounts (IRSA) inside EKS, or IAM Roles Anywhere for workloads outside the cluster. Both eliminate long-lived AWS access keys.
• In Azure: Workload Identity Federation. Federated tokens from your CI or your Kubernetes cluster, exchanged for Microsoft Entra ID tokens at runtime.
• In GCP: Workload Identity Federation, again. The pattern is consistent across the major clouds.
• For service-to-service inside your environment: SPIFFE/SPIRE if you have the operational appetite, or your service mesh's mTLS (Istio, Linkerd, Consul Connect) for a managed equivalent.

The benefit of workload identity is the same as the benefit of phishing-resistant MFA: you move from "static secret that can leak" to "dynamic credential issued at runtime." Most leaked-credential incidents stop being possible.

6. Phase 5: continuous evaluation

Authentication used to be a one-time event: you log in, you get a session, the session lasts until it expires. Continuous evaluation means the session gets re-checked as risk signals change. If a user's device falls out of compliance mid-session, the session ends. If a user's IP moves from a known location to a high-risk country, the session ends. If the user's role changes in HR, sensitive sessions end.

The major IdPs all support this in some form (Okta has Risk-Based Authentication, Microsoft Entra ID has Conditional Access continuous evaluation, Google Workspace has session control). The work is to wire risk signals into the IdP and to define which applications require continuous evaluation. Start with the highest-sensitivity applications; the rest can be long-session.

7. What to ignore (for now)

A list of things vendors will tell you are essential to Zero Trust, that you can defer or skip:

• Network microsegmentation as a day-1 priority. Microsegmentation is a fine idea, but it's a year of effort and the ROI is much lower than the five things above. Do it after you've shipped the basics.
• "Zero Trust" branded versions of existing tools. A "Zero Trust firewall" is usually just a firewall with marketing on top. Buy infrastructure based on what it does, not on the brand label.
• Replacing your existing endpoint agent with a "Zero Trust endpoint" product. Your existing EDR is fine. You don't need to rip and replace.
• "Zero Trust" SIEMs. A SIEM is a SIEM. Pick one based on detection engineering needs, not on the marketing copy.
• Trying to do everything at once. The biggest failure mode of Zero Trust programs is scope. Pick the five capabilities, ship them in order, and resist the urge to add more before the basics are done.

8. How long does this take?

A realistic timeline for a mid-size engineering org (100–500 people, single-cloud, mostly SaaS apps with some internal services):

• Months 0–3: identity consolidation, MFA migration to phishing-resistant factors for admin and engineering accounts, MDM coverage for managed devices.
• Months 3–6: device trust signals wired into the IdP. First applications gated on device posture. MFA rolled out to the rest of the org.
• Months 6–12: identity-aware proxy in front of internal apps, top applications migrated, VPN dependency reduced for the migrated set.
• Months 9–15: workload identity for cloud IAM and CI. Long-lived credentials retired in production paths.
• Months 12–18: continuous evaluation enabled for sensitive applications. Session policies tuned.

If a vendor or consultant tells you they can do all of this in three months, they're wrong. If a vendor or consultant tells you it takes three years, they're trying to sell you a multi-year contract. The honest range is one to two years for a mid-size org, depending mostly on how much legacy you have to migrate.

9. Metrics that prove progress

Vanity metrics for Zero Trust programs are easy to find. Real ones are harder. Track these:

• Percentage of users with phishing-resistant MFA enrolled. Aim for 100% over time; the curve matters. SMS-only doesn't count.
• Percentage of internal apps behind the identity-aware proxy. This measures the de-VPNification of the network.
• Percentage of cloud workloads using workload identity (not static credentials). This measures the death of long-lived API keys.
• Number of long-lived service credentials in your secret store, declining. Inverse of the above; concrete and falsifiable.
• Time-to-revoke for a compromised user. From "we know this account is compromised" to "all sessions are killed and access is removed everywhere." Should be under 5 minutes; many orgs are at hours.

10. How to talk to leadership without buzzwords

The pitch for leadership isn't "we're implementing Zero Trust." Leaders have heard that phrase enough that it's lost meaning. The pitch is: "we are reducing the impact of stolen credentials, lost devices, and compromised vendors by changing how we authenticate and authorize access." Then walk through the five capabilities in plain language.

Tie each capability to a recent incident the leadership reads about. The MGM breach was a phished credential and a missing MFA factor. The Okta support compromise was a long-lived session token that didn't have continuous evaluation. The SolarWinds incident was a supply-chain compromise that walked through static credentials. Every leader has read about one of these. Connect your roadmap to those headlines and the budget conversation gets easier.

The short version

Zero Trust means: don't trust the network, authenticate and authorize every request individually. The five capabilities that get you 80% of the value are phishing-resistant MFA, device trust as an access signal, per-application access via an identity-aware proxy, workload identity for service-to-service auth, and continuous evaluation for sensitive sessions. Ship them in roughly that order over twelve to eighteen months. Skip the vendor- branded extras. Measure the percentage of users with phishing-resistant MFA, the percentage of apps behind the proxy, the percentage of workloads on workload identity, and the time-to-revoke a compromised user.

Done well, this is the most impactful security program a mid-size engineering org can run. Done badly, it's a slide deck with vendor logos. The difference is whether you actually ship the five capabilities or just talk about them.