When Enterprise Network Perimeters Disappear: Zero-Trust Architecture and Continuous Authentication

For years, enterprise networks were built like castles. Google's 2014 BeyondCorp paper uses that comparison for the perimeter model: everything outside the wall is treated as hostile and anyone who gets past the drawbridge can reach the resources inside. NIST SP 800-207 names two weaknesses in that model. Once an organization relies on remote workers and cloud services, it no longer has a single, easily identified perimeter. Once an attacker breaches the perimeter, further lateral movement is unhindered. The BeyondCorp paper also argues that an internal network should be treated as being as dangerous as the public internet.

Zero Trust answers this by moving where access decisions happen. Network location alone no longer earns trust. Each resource access is evaluated on its own and the trust granted is reassessed for as long as the session lasts. The industry calls that last part continuous authentication, but the sources use different terms. NIST SP 800-63B-4 calls the practice session monitoring and notes that it is sometimes called continuous authentication. SP 800-207 speaks of trust being continually evaluated.

How does NIST SP 800-207 define Zero Trust?

SP 800-207, published by NIST in August 2020, defines Zero Trust as a set of guiding principles for system design and operations. A Zero Trust Architecture (ZTA) is the cybersecurity plan an organization builds from those principles. In the document's operative definition, the goal is to reduce uncertainty when making accurate, least-privilege, per-request access decisions in a network that is viewed as compromised.

The document explains the implicit trust zone with an airport. Everyone who clears the security checkpoint is trusted inside the boarding area. A checkpoint cannot apply policy beyond its own position in the flow, so Zero Trust moves decision and enforcement points closer to the resource they protect. The seven tenets read as follows:

1. All data sources and computing services are considered resources.
2. All communication is secured regardless of network location; a request from inside the enterprise network has to meet the same requirements as one from outside.
3. Access is granted per session with least privilege. Authenticating to one resource does not automatically grant access to another.
4. A dynamic policy decides access, taking into account the observable state of the client identity, the requesting device and the application or service.
5. The enterprise monitors the security posture of all its assets; no asset is inherently trusted.
6. Authentication and authorization are strictly enforced before access; trust is reevaluated throughout the communication.
7. The enterprise uses the state information it collects to improve its security posture.

NIST acknowledges that these tenets are an ideal goal and that a given strategy may not implement all of them in their purest form.

Logical components: Policy Engine, Policy Administrator and Policy Enforcement Point

SP 800-207 splits the Policy Decision Point (PDP) in two. The Policy Engine (PE) makes the final decision on whether a subject (a user, service or device requesting access) may reach a resource and logs that decision. The Policy Administrator (PA) carries it out: it sends commands to Policy Enforcement Points (PEPs) to open or close the communication path and generates the session-specific token. The PEP enables, monitors and terminates the connection between subject and resource. It can be split into an agent on a laptop and a gateway in front of the resource. These components talk over a control plane kept logically separate from the data plane that carries application traffic. PE inputs include a continuous diagnostics and mitigation (CDM) system that reports device patch levels, along with threat intelligence feeds.

The PE decides through a trust algorithm. A criteria-based algorithm grants access when every configured condition is met. A score-based algorithm computes a confidence level and compares it with the resource's threshold; a request below the threshold is denied or gets reduced privileges, such as read access to a file without write access. A singular algorithm evaluates each request on its own, while a contextual algorithm also looks at the subject's recent history. NIST says a trust algorithm should ideally be contextual, because it is more likely to catch subverted credentials used in an atypical access pattern. It also notes that the enterprise's existing infrastructure may not always allow this.

BeyondCorp shows what these components look like in production. According to Rory Ward and Betsy Beyer, only devices managed by the company can reach corporate applications. Each device is identified by a certificate tied to its inventory record. An SSO system validates both of the user's factors and issues short-lived tokens. Every application sits behind an internet-facing access proxy. The Access Control Engine inside it evaluates the user's group, the device record and the inferred trust level on every request. In one example from the paper, viewing an entry in the bug tracker can carry a looser rule than updating it.

Continuous authentication: reassessing trust throughout the session

In a perimeter model, trust is established at login and stays fixed until the session ends. SP 800-207 warns against this: an enterprise should not assume that all later requests are equally valid because the subject passed a base authentication level. Under the sixth tenet, monitoring continues throughout user transactions. Reauthentication and reauthorization can occur when policy defines it. The document gives four examples of such triggers: time-based conditions, a newly requested resource, resource modification and anomalous activity. The PA can also pause a session for reauthentication or terminate it.

SP 800-63B-4, published in July 2025, covers the application side. It defines session monitoring as the ongoing evaluation of session characteristics to detect possible fraud during a session. Characteristics it lists include usage patterns, velocity and timing, behavioral biometrics such as typing cadence, device and browser characteristics, geolocation and whether the IP address belongs to a block known for abuse. When fraud is suspected, the relying party (RP) should work with the Identity Provider (IdP) to reauthenticate the user, terminate the session or notify support staff.

The same document prefers session management to repeatedly asking for credentials, because poor usability pushes users toward workarounds that defeat the purpose of authentication. CISA's Zero Trust Maturity Model v2.0 describes the most advanced stage of its identity pillar as continuing to validate identity with phishing-resistant MFA after access is first granted.

Gaps in the session mechanism

Under SP 800-63B-4, a session runs on a session secret issued at authentication time and is bound by two timeouts. The overall timeout limits total time since authentication. The inactivity timeout closes a session that has gone idle.

Token lifetime can undermine continuous authentication. The document says an RP must not treat the presence of an OAuth access token as evidence that the user is still there without other signals. It also notes that access and refresh tokens can remain valid long after the session ends. In federation, IdP and RP sessions are independent, so closing a session at the IdP does not automatically close the one at the RP. SP 800-63C-4 describes shared signaling for this gap: the IdP should signal the RP when an account is suspended, suspected of compromise or has its authenticators updated. On the application side, the work is to wire those account events into a process that revokes sessions. Without that link, a "cut access" decision from the Policy Engine may not reach a session that is still open in the application.

From trigger to response: a sample policy

The triggers SP 800-207 lists, together with the signals above, can be translated into an enterprise policy along these lines. The right response depends on the organization's risk assessment.

Most of the signals used in session monitoring are personal data. SP 800-63B-4 requires that processing them be included in the privacy risk assessment. For organizations operating in Türkiye, Article 4 of Law No. 6698 on the Protection of Personal Data (KVKK) makes it mandatory for personal data to be relevant, limited and proportionate to the purposes for which they are processed. That test should decide which behavioral signals to collect.

How do you implement Zero Trust across the five pillars?

CISA's maturity model divides implementation into five pillars: Identity, Devices, Networks, Data and a combined Applications and Workloads pillar.

Identity

In CISA's model, scattered identity stores are consolidated at the more advanced stages. For authentication, the model describes a move to passwordless, phishing-resistant MFA based on FIDO2 or PIV. SP 800-63B-4 adds that syncable authenticators cannot be used at AAL3, the highest authentication assurance level, because they require the private key to be exportable. In access management, the traditional stage is permanent access with periodic review; the most advanced stage is just-in-time and just-enough access. SP 800-207 asks for extra scrutiny when roles are assigned to privileged users such as developers and administrators. Service accounts also count as subjects that belong in the inventory.

Devices

The enterprise needs to tell which devices it manages and what their current security posture is. SP 800-207 asks that this rest on credentials the enterprise issues and rules out spoofable data such as MAC addresses. The device certificate in BeyondCorp identifies a device without granting access by itself; it works as a key to the information held about that device. Unmanaged devices or those with known vulnerabilities can be denied all connections.

Networks: micro-segmentation and service-to-service mTLS

Under SP 800-207, enterprise resources should not be reachable without going through a PEP. A remote user should not have to tunnel back into the enterprise network over VPN to reach a service hosted in a public cloud. In CISA's network pillar, the most advanced stage is micro-segmentation built around application profiles.

For traffic between services, NIST SP 800-207A describes identity-tier policies based on service identity instead of IP addresses. The document's example draws the line: "permit calls from 192.168.10.0/24 subnet to 10.0.0.31" is a network-tier policy, while "order processing front-end service can communicate with inventory back-end service" is an identity-tier policy. According to 800-207A, each service should present a short-lived, cryptographically verifiable identity. Authenticating every request would be highly disruptive to application response times, so authentication happens at connection setup through mTLS. Connections are not kept open for long. For end users, the document recommends exchanging short-lived external tokens for a JWT that can be verified at each hop.

In a Kubernetes environment running the Istio service mesh, the first resource below enforces mTLS in the orders namespace, the second sets a default deny and the third lets only the order-frontend service account reach the reservation paths on the inventory service:

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: orders
spec:
  mtls:
    mode: STRICT
---
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-nothing
  namespace: orders
spec:
  {}
---
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: inventory-from-order-frontend
  namespace: orders
spec:
  selector:
    matchLabels:
      app: inventory
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/orders/sa/order-frontend"]
    to:
    - operation:
        methods: ["GET", "POST"]
        paths: ["/reservations*"]

Per the Istio documentation, STRICT mode requires an mTLS tunnel in which the client presents a certificate. The principals field derives identity from the peer certificate, so it requires mTLS. When a workload has ALLOW policies and a request matches none of them, the request is denied, which is how the rule-less allow-nothing policy creates a default deny. That deny covers every workload in the namespace, including traffic to order-frontend, until each one has its own explicit ALLOW policy. Starting in PERMISSIVE mode (which accepts both plaintext and mTLS traffic) and switching to STRICT once traffic is verified applies the "observe first, enforce later" approach described below at the network layer.

Applications, data and visibility

In CISA's applications pillar, the initial stage bases access on per-request contextual information with an expiration condition; at the most advanced stage, access is continuously authorized using real-time risk analytics. In enterprise applications this decision can be enforced at an API gateway or reverse proxy, the role BeyondCorp's access proxy plays. That requires the APIs behind it to have well-defined contracts, a discipline covered in our API-First design post.

In the data pillar, CISA describes a move from static access controls to automated controls that weigh identity and device risk together and are time-limited where applicable. At the advanced stage, secrets are not hard-coded and keys are rotated regularly. Who controls encryption keys and how to keep immutable access logs are covered in detail in our post on data sovereignty in hybrid cloud architectures.

Under the seventh tenet, collected logs and traffic data feed back into policy. SP 800-207 flags a risk here as well: stored traffic data can give an attacker insight into the architecture and the assets worth targeting. The tool that manages access policies can show which accounts are most valuable to compromise. Access to both should be limited to designated administrator accounts.

Common mistakes

• Treating VPN as Zero Trust: If a VPN still gives a connected device broad access, the implicit trust zone remains and the second tenet goes unmet.
• Writing policy before the inventory is complete: According to NIST, incomplete knowledge most often leads the Policy Engine to deny requests for lack of information. The problem grows when unknown shadow IT deployments are running.
• Leaving the Policy Engine unprotected: An administrator with access to PE rules can make unapproved changes. An attack that cuts off the PE or PA can disrupt operations. NIST requires configuration changes to be logged and audited. It also notes that replicating these components across locations reduces the risk without eliminating it.
• Leaving service accounts out of scope: NIST notes that AI and other software agents may perform administrative tasks with a lower authentication bar than a human, such as an API key instead of MFA. It adds that an attacker could theoretically trick such an agent into acting on their behalf.
• Switching policy straight to enforcement: NIST recommends running a new workflow in reporting-only mode for a while. Basic rules, such as denying requests that fail MFA, are enforced from the start.

Migration roadmap: moving through maturity stages

According to SP 800-207, most enterprises will run a hybrid of Zero Trust and perimeter-based architecture for an indefinite period. Migration can proceed one business process at a time. Inventory comes first. The cycle NIST describes runs as follows:

1. Identify human users and service accounts, with particular attention to privileged accounts.
2. Catalog accounts, applications and digital certificates alongside devices, shadow IT included.
3. Rank business processes by risk and pick a low-risk one for the first transition. NIST notes that an application used by a subset of the enterprise, such as a purchasing system, may be preferred over one everyone depends on, such as email.
4. Map the candidate process's dependencies, write its policy, then assess candidate solutions against criteria such as whether they require an agent on the client.
5. Run the policy in observation mode first, tune it with the data collected, then expand the scope.

CISA's model tracks the same journey on a scale that runs from a Traditional starting point through Initial, Advanced and Optimal. It notes that each pillar can progress at its own pace until cross-pillar coordination is required. A practical starting point is to mark where the organization stands today on each of the five pillars and match the weakest pillar to the needs of the first candidate process.

Google's own migration was phased as well. According to the BeyondCorp paper, applications moved from being reachable on the privileged network and over VPN, to also being reachable through the access proxy, to being reachable only through the access proxy. A traffic monitor on user devices first ran in logging mode, recording traffic that would fail the new rules, then switched to enforcement mode and dropped it. Running the old and new paths side by side for a period follows the same logic as the Strangler Fig Pattern in application modernization.

The decision point becomes a dependency

When Zero Trust moves the access decision from the network edge to the Policy Engine, that component becomes a critical system in its own right. NIST writes that the PE, PA and PEPs become key components of every business process and that losing access to them directly affects the workflow. Continuous authentication involves a similar trade-off: each added signal can sharpen the trust decision. Each one also adds usability and privacy cost. Two questions belong in the design together: which signal changes which access decision and how a business process behaves when the decision point cannot be reached.