Zero-trust networking replaces the assumption that a request is trustworthy because it originates inside a corporate network. Cloud services, mobile work, SaaS applications, and external collaborators have dissolved the clean perimeter once enforced by a firewall. Location therefore says little about the identity, device, or intent behind a request, while an attacker who gains internal access may exploit inherited trust to move laterally. The operating assumption is breach: every principal remains untrusted until each requested action is verified and authorized. section 1.3.2 section 15.1
Figure 15.1 Why the perimeter model fails in modern environments. In the traditional model (left), a firewall defined a clear boundary, and anything inside the perimeter was implicitly trusted. In modern environments (right), cloud services, mobile work, SaaS applications, and external collaborators eliminate meaningful boundaries.
Compare the former firewall-defined perimeter with the distributed environment that makes network location an inadequate basis for trust. section 15.1
The practical shift is from broad, durable access after authentication to continuous authorization. Authentication establishes evidence of who or what is making a request, but it is only the beginning of the decision. A policy engine evaluates each access using identity attributes, device posture, operational signals, environmental context, and the request’s purpose; a Policy Enforcement Point (PEP) enforces the result at the protected resource. Reauthorization applies even to requests made during the same session, so the decision layer must be fast, consistent, and able to use current context. section 15.2 section 1.3.2
Figure 15.2 Zero trust is enforced through continuous authorization. Every access request is evaluated by a policy engine. Identity attributes, device posture, operational signals, and environmental context further influence the decision. The result is enforced locally by the PEP guarding the target resource.
Trace how identity, device posture, operational signals, and environment feed a policy decision that a PEP enforces locally. section 15.2
A zero-trust architecture depends on several coordinated capabilities:
- Reliable authentication for people and workloads, supplying consistent identity evidence rather than treating login as permanent authorization. section 15.2
- Governed identity, role, attribute, relationship, device-posture, and operational data that remain defined, validated, and current. section 15.1
- Shared policy evaluation across systems, so requests receive consistent decisions regardless of origin or deployment pattern. section 15.2
- Foundational security policies for enterprise-wide requirements, shared operational policies for workflow or environmental conditions, and application policies for resource-specific business rules. section 15.7
Managed device and after-hours access
A critical resource can require a company-managed device as a baseline rule, then apply extra safeguards outside business hours. This combines a global device-trust constraint with contextual conditions rather than granting access simply because a user is on a corporate network. Policy patterns for ownership, membership, and relationships can be combined with such attribute-based constraints, keeping business permissions distinct from enterprise security requirements. section 9.1 section 9.10
Policy-Based Access Control (PBAC) supplies the decision layer for this approach. It moves authorization out of scattered, ad hoc application checks into policies that can be evaluated together. A deny rule can override a permit so foundational requirements remain effective across systems. PEPs may be embedded in an application, placed at an API gateway, or run as sidecars in a service mesh; organizations can combine these options, balancing contextual visibility, centralized consistency, and operational complexity. section 15.7 section 4.5.1
Progress is assessed through the quality and consistency of authorization decisions, not a vendor maturity ladder. Useful independent indicators include policy coverage, signal quality, decision consistency, reduced reliance on perimeter controls, and fewer authorization exceptions. Codified shared policies can also improve auditability, incident investigation, and change speed: teams can explain an allow or deny from policy and context, and update a policy layer instead of coordinating changes across many services. Missing or stale signals should fail closed rather than silently restoring implicit trust. section 15.5 section 15.6
