What it means
Zero trust changes the basis for an access decision: being inside the office network or owning a company device is not sufficient authorization. Policies focus on the resource, requester, requested operation, and available context. An implementation might combine strong authentication, device checks, narrowly scoped permissions, and ongoing session evaluation. This does not mean asking a person to type a password for every web request. Systems can use established sessions and other evidence while enforcing the appropriate checks. Policy quality, reliable identity information, and usable recovery paths remain necessary.
The idea at a glance / Access
Network location does not grant resource permission.
Keep location, resource permission and changed trusted context visible together.
Synthetic DrawingDesk trusts Maya’s identity and D192’s reported context. Its selected policy permits GET of Maya’s O192 only while D192 is acceptable. Modeled office and remote entry points use the same policy: own read works, other-record read and edit do not. A later trusted unacceptable-device signal refuses a new office read. Original O192 and Maya’s identity remain.
READ THE PICTURE
Location beside policy
Office and remote reads of O192 both work. Neither location permits editing or another owner’s record. A new office read is refused when trusted D192 context changes.
Keep in mindThis is a selected local HTTP/SQL resource-policy test, not a complete zero-trust architecture or real office/remote network. Entry-point labels model location. Identity/device binding, context integrity, protected channels and authoritative grants are assumed. Network context can matter to other policies; it does not grant access here. Continuous session teardown, physical device safety, outages and broader resources are untested.
Read the complete example
- Location beside policy. Office and remote reads of O192 both work. Neither location permits editing or another owner’s record. A new office read is refused when trusted D192 context changes. Both labeled entry points actually forward HTTP requests to one policy-enforcing application. The app validates Maya’s same established session and trusted D192 state, then checks its own GET/O192 grant. At acceptable context both own reads return 200; PUT O192 and GET Nora’s O193 return 403 at either entry. The selected policy does not use location as a grant. After the authoritative context changes to unacceptable, a fresh office GET O192 returns 403 although identity and stored grant remain valid. No password is requested for each HTTP operation. Nora’s separate acceptable-device session still reads the unchanged original. This demonstrates specific enforced decisions; it does not certify the device safe, implement all zero-trust tenets or prove ongoing connection termination.
This is a selected local HTTP/SQL resource-policy test, not a complete zero-trust architecture or real office/remote network. Entry-point labels model location. Identity/device binding, context integrity, protected channels and authoritative grants are assumed. Network context can matter to other policies; it does not grant access here. Continuous session teardown, physical device safety, outages and broader resources are untested.
Diagram references: NIST SP 800-207: resource policy, context and no implicit location trust
AN ILLUSTRATIVE SCENARIO
Network location does not grant resource permission
Synthetic DrawingDesk trusts Vera’s identity and D192’s reported context. Its selected policy permits GET of Vera’s O192 only while D192 is acceptable. Modeled office and remote entry points use the same policy: own read works, other-record read and edit do not. A later trusted unacceptable-device signal refuses a new office read. Original O192 and Vera’s identity remain.
Put it to work
- Select a business workflow and identify its resources, identities, data, and required actions. Include service accounts and dependencies instead of mapping only employee logins.
- Define explicit policies and enforcement points for that workflow. Reduce unnecessary standing access, collect relevant context, and consider what happens when an identity or device signal is unavailable.
- Pilot the policy, test legitimate work and denied requests, and monitor exceptions. Expand based on observed gaps and operational lessons rather than treating a product purchase as completion.
How to check your work
Test the same role from different network locations, then change its permissions or device condition. Confirm decisions follow the intended resource policy, revocation works, and an approved emergency process leaves an accountable record.
Connect the ideas
- ZTNA
Access that brokers application connectivity per identity and policy instead of placing users on a flat network.
- Least privilege
Granting each identity only the actions, objects, and time window required for the current job.
- Trust boundary
A place where identity, network, or data assumptions change and a fresh check is required.