Zero trust architecture: per-resource policy and continuous evidence

Zero trust removes implicit trust based on network location or ownership. Subjects, devices, and workloads obtain resource-specific access through policy decision and enforcement points using current identity, posture, and threat evidence.

Security invariants

• ZT-C1: Zero trust grants no implicit trust based solely on physical or network location, ownership, or affiliation.
• ZT-C2: Access is resource-specific and mediated by a policy decision point and policy enforcement point before the session reaches the resource.
• ZT-C3: Policy uses current identity, device or workload posture, resource, action, environment, and threat evidence.
• ZT-C4: Cloud-native zero trust uses application and service identities plus application-level enforcement, not only IP segmentation.
• ZT-C5: Grants are least-privilege, resource and action scoped, and time bounded rather than broad network admission.
• ZT-C6: A required policy dependency outage fails closed or follows an explicit narrow continuity policy; it never silently creates implicit trust.

Trust-boundary map

Component	Responsibility
user	User
device	Device and Client
identity-provider	Identity Evidence
policy-enforcement	Policy Enforcement Point
policy-decision	Policy Engine and Administrator
posture-service	Device and Workload Posture
telemetry	Telemetry and Threat Signals
resource	Protected Enterprise Resource
workload	Calling Service Workload
service-enforcement	Service Policy Enforcement
data	Resource Data

Topology edges represent authenticated or otherwise explicit communication paths. Responses reuse those physical paths in reverse; no response-only or bypass edges are added.

Executable scenarios

per-resource-decision — Evaluate every resource request

Access is granted to a specific resource and action after identity, device, policy, and risk evidence are evaluated at the enforcement point.

▶Walkthrough: per-resource-decision (not found)

network-location-is-not-trust — Network location does not grant access

Being on a corporate subnet or VPN supplies context but never bypasses authentication and resource authorization.

▶Walkthrough: network-location-is-not-trust (not found)

posture-change — Respond to a posture change

Device or workload state is dynamic evidence. A newly noncompliant device loses or narrows subsequent access without treating the prior session as permanent trust.

▶Walkthrough: posture-change (not found)

service-to-service — Apply zero trust to workloads

A service identity reaches another service through an application-level enforcement point; network reachability alone grants no method permission.

▶Walkthrough: service-to-service (not found)

least-privilege-session — Limit authority and duration

A grant is scoped to the minimum resource, action, and duration; it does not become broad lateral network access.

▶Walkthrough: least-privilege-session (not found)

policy-service-outage — Policy outage fails closed

The enforcement point does not interpret an unavailable policy decision as allow; explicitly designed low-risk continuity policies remain narrow and auditable.

▶Walkthrough: policy-service-outage (not found)

continuous-reevaluation — Reevaluate on new threat evidence

Telemetry does not magically inspect every packet, but material risk changes can trigger a new decision, session restriction, or reauthentication.

▶Walkthrough: continuous-reevaluation (not found)

Operational and failure rules

• Every rejection path fails closed at the component that owns the decision; infrastructure failure is never converted into authentication, authorization, or integrity success.
• Retries preserve stable transaction identity, replay detection, bounded freshness, and audit context. A retry does not erase a prior success or compromise signal.
• Concurrent validation branches are independent checks. Completion requires every mandatory branch, and no check substitutes for another.
• Logs contain decision metadata and stable identifiers, not credentials, bearer tokens, cryptographic keys, or sensitive payloads.

Related concepts

[CONCEPT]authn-models [CONCEPT]authz-models [CONCEPT]mtls [CONCEPT]api-security

Authoritative sources

1. NIST SP 800-207: Zero Trust Architecture
2. NIST SP 800-207A: Zero Trust Access Control in Cloud-Native Applications