A network boundary is easy to draw. A trust decision is harder: it depends on a subject, a resource, a requested action and the conditions under which access is appropriate. Treating the line on a diagram as the policy can hide those decisions.
What NIST means by the shift
NIST Special Publication 800-207 describes zero trust as a move away from implicit trust based solely on network location or ownership. Its focus is protecting resources rather than network segments. The publication describes access as a decision involving subjects, assets, resources and policy—not a blanket assumption that something inside a perimeter is trustworthy. See the source for the full model and its qualifications.
Read the boundary as a decision
That framing gives a team a more useful review than asking whether a system is ‘inside’ or ‘outside.’ For a particular request, ask which person or service is acting; which resource and action are involved; what identity, device or other context is evaluated; which rule makes the decision; and what is recorded so the decision can later be understood.
- Subject: which user, workload or service is requesting access?
- Resource and action: what specific data or function is requested?
- Policy and context: which conditions affect the decision, and who owns that rule?
- Evidence: what decision record exists, and how is it reviewed?
- Change: what happens when identity, device state, resource sensitivity or context changes?
Architecture is also governance
NIST’s model is an architecture framework, not a product checklist. A control that verifies a request is only useful when the organization can explain its policy, maintain accurate identities and resource descriptions, handle exceptions, and review the resulting records. The framework does not remove the need to decide what should be protected or how the organization will operate the controls.
This is an interpretation of the cited guidance, not a LeshCore implementation assessment or claim that any particular architecture is secure. The appropriate design depends on the system, threat model, people, operational capacity and applicable requirements.
Questions before buying another tool
- Which access decision is currently unclear or inconsistent?
- What authoritative identity and resource information will the tool use?
- Can an operator explain why access was allowed or denied?
- How will exceptions, outages and recovery be handled?
- What evidence will show whether the change improved the intended control?
Sources and limits
The cited NIST publication establishes the framework summarized here. This short explainer does not compare vendors, measure adoption or outcomes, provide an implementation recipe, or establish that zero trust is suitable as a label for every security program. The questions are a systems-design lens offered for discussion.