Zero trust means access is not granted just because a device is on the office network or owned by the company. Each request is verified for both the user and the device, and protection focuses on resources rather than network zones. NIST SP 800-207 lays out the model. For remote engineers, it mostly changes how access is decided.
What NIST says
NIST SP 800-207, Zero Trust Architecture, was published in August 2020. Its abstract describes zero trust as a set of evolving cybersecurity paradigms that move defenses away from static, network-based perimeters toward users, assets and resources. It says the approach responds to trends such as remote users, bring-your-own-device policies and cloud based assets outside the enterprise network boundary. The publication gives an abstract definition of zero trust architecture along with general deployment models and use cases.
From that abstract three ideas stand out.
- No implicit trust from network location or ownership.
- Authenticate and authorize the user and the device before a session with a resource starts.
- Protect the resources, such as services, workflows and accounts, not network segments.
What it replaces
The old model was a castle. Get inside the VPN or the office and you could reach most things. That model assumes the inside is safe, which is a weak assumption once people work from homes, cafes and phones, and once the apps they use live in someone else's cloud.
Zero trust does not mean "trust nothing and block everything." It means each access decision uses current evidence: who is asking, from which device, for which resource, and whether that is normal.
What it looks like for a remote engineer
- Sign-in uses strong, phishing resistant methods. See passkeys for developer accounts.
- The device is checked. Is it updated, locked, and managed or at least enrolled? NIST's mobile guidance, SP 800-124 Rev. 2, covers managing organization and personally owned devices.
- Access is to specific applications, not the whole network. A developer reaches the code host, the CI system and the dev environment, not the finance file share.
- Sessions are short, and risky actions ask again. See how long a remote session should last.
- Everything is logged, so unusual access is visible.
What it does not fix
Zero trust is not a product you install. Several things stay your job.
- A trusted user with a compromised device is still a risk, so device checks matter.
- Over-broad permissions stay over-broad. Least privilege is a separate task.
- Stolen sessions still work until they expire.
- Software you ship still has bugs and vulnerable dependencies.
A practical starting list
- List your most sensitive systems: source control, package publishing, cloud consoles, CI, production.
- For each, require phishing resistant sign-in.
- Decide what device state is acceptable, and enforce it where you can.
- Cut standing access. Make elevated access time boxed.
- Turn on logging for sign-ins and sensitive actions, and read it.
- Pick one system a quarter and move it from network based trust to identity based trust.
Do not try to do it all at once. The NIST text is a reference model for planning, not a checklist to finish in a sprint.
How it connects to everyday tools
Many of the topics on this site are pieces of zero trust: session timeouts, approval gates, scoped agent permissions and device loss handling. Each makes one decision depend on evidence, not on where you sit.
Quick check
Is zero trust the same as using a VPN?
No. A VPN extends a network perimeter to remote users. Zero trust, as NIST describes it, avoids granting trust based on network location and verifies users and devices for each resource.
Does zero trust apply to small teams?
The ideas do. Phishing resistant sign-in, device checks, short sessions and least privilege cost little and help at any size. You do not need a large program to start.
Sources
Last reviewed: 19 October 2026.
