Zero Trust Without The Vendor Fog

Zero Trust gets flattened into slogans quickly. "Never trust, always verify" is memorable, but it is not an implementation plan.

The cleaner starting point is NIST SP 800-207. Read it as an architecture document, not a product category. It says access decisions should be based on identity, device state, resource sensitivity, policy, and telemetry rather than network location alone.

That sounds obvious until you look at a real environment and find flat internal networks, shared admin paths, unmanaged devices, and applications that still treat "inside the VPN" as a security decision.

What NIST Is Really Saying

The useful parts of SP 800-207 are simple:

• treat applications, data, and services as resources
• secure communication regardless of where the client sits
• grant access per session, not forever
• make policy dynamic enough to consider context
• monitor device and asset posture
• enforce authentication and authorization before access
• collect enough telemetry to improve decisions over time

None of that requires buying a single magic box. It does require knowing your assets and being honest about where implicit trust still exists.

Where To Start

Identity

Identity work usually pays off first:

• enforce MFA on meaningful access paths
• centralize SSO where the application supports it
• reduce standing privilege
• review privileged accounts and service accounts
• make contractor and vendor access time-bound

This is not glamorous, but it closes a lot of real doors.

Devices

Device trust is where many programs get stuck. A login from a managed, patched laptop is not the same as a login from an unknown machine. Access policy should be able to tell the difference.

At minimum, track whether a device is managed, encrypted, patched, and running the expected security controls.

Network Segmentation

Flat networks make every compromise more expensive. Segmentation does not have to start with a perfect software-defined perimeter. Start by separating the systems that should never freely talk to each other:

• user workstations and servers
• production and development
• payment or regulated systems
• administrative management planes
• third-party access zones

The point is to reduce blast radius while the rest of the program matures.

Applications And APIs

Legacy applications are where Zero Trust plans meet reality. Some will not support modern auth. Some will need an access proxy. Some should be retired rather than wrapped forever.

For new work, the bar should be clear: modern authentication, authorization at the resource level, useful logs, and sane API controls.

Data

Zero Trust without data classification becomes a login project. Data sensitivity should influence access decisions, monitoring, retention, and encryption requirements.

You do not need a perfect taxonomy on day one. You do need to know which data would hurt if it moved.

Common Failure Modes

Treating Zero Trust As A Product

A product can help enforce policy. It cannot decide what your policy should be, classify your data, fix stale access, or tell you which legacy path matters most.

Ignoring User Friction

Bad rollouts create prompt fatigue and workarounds. Risk-based step-up authentication is usually better than asking every user to approve every action all day.

Leaving Third Parties Out

Vendors and contractors often sit on the most sensitive paths. Apply the same rules: identity, device posture where possible, least privilege, time bounds, and monitoring.

Measuring Activity Instead Of Risk Reduction

"MFA deployed" is a useful milestone. It is not the outcome. Better questions:

• How many privileged accounts still lack strong controls?
• How many sensitive apps still trust the network?
• How much lateral movement remains possible from a normal workstation?
• How quickly can we revoke access for a user, device, or vendor?

A Practical Sequence

1. Inventory critical resources and access paths.
2. Fix privileged identity first.
3. Enforce MFA and SSO for externally reachable systems.
4. Segment high-risk systems.
5. Add device posture to access decisions.
6. Improve application logs and resource-level authorization.
7. Revisit policy based on incident and telemetry data.

That is slower than a slide deck, but it is closer to how programs actually improve.

Bottom Line

Zero Trust is not a trust problem. It is an architecture and operations problem.

The useful goal is not to declare the enterprise "zero trust." The goal is to remove the places where access is granted because of location, habit, or old assumptions nobody wants to touch.