What is the difference between a VPN and a ZTNA proxy, and which changes the lateral movement risk?

A VPN creates an authenticated network tunnel between the connecting client and a network segment, granting the client IP-layer reachability to every host in that segment. Once a VPN session is established, the client has TCP/IP connectivity to any service in the target network that is not separately firewalled at the host level. The VPN authentication decision is a single gate: the user presents a valid credential, the VPN server authenticates it, and the result is full network presence in the internal subnet. The blast radius of a compromised VPN credential is the entire network segment the VPN routes into — every database, every admin interface, every internal service accessible from that subnet — regardless of which specific services the user actually needs. A zero trust network access proxy takes a different model: instead of granting network presence, the ZTNA proxy brokers access to specific named applications or services. The user authenticates to the proxy (typically via SSO), and the proxy grants access to the specific application the user has an access policy for, forwarding only traffic for that application and blocking all other internal network traffic. The user's device never has a routable path to internal services other than the specific applications they have been granted access to. A compromised ZTNA session grants access to the applications listed in the compromised user's access policies but not to other internal services, because there is no network route to those services from the user's device. The lateral movement ceiling of a ZTNA model is the set of applications in the compromised user's access policy, which can be scoped to the minimum set required for their role. The lateral movement ceiling of a VPN model is the entire internal network segment the VPN routes into, which is typically all internal services because segmenting the internal network at the host-firewall level for every service combination is operationally complex and rarely maintained as the internal service inventory grows. The critical distinction is not the authentication mechanism (both VPN and ZTNA require authentication) but what the authentication grants: network presence versus application-specific access.

What is device trust and why does SSO authentication alone not satisfy a zero trust access model?

SSO authentication verifies that the person initiating the access request controls the identity credential (the password plus MFA factor, or an active SSO session that was established by controlling those credentials). SSO authentication does not verify anything about the device from which the access is initiated: whether the device is managed by the organization and enrolled in MDM, whether the device has disk encryption enabled, whether the device is running endpoint detection and response software, whether the operating system and installed packages are at a minimum patch level, or whether the device itself has been compromised. A threat actor who obtains a valid SSO session cookie (through a browser session exfiltration attack, a malicious browser extension, or a phishing page that captures the SSO session token after authentication) can present that cookie to the SSO authentication flow and receive a new access token without knowing the user's password and without triggering an MFA prompt, because the SSO provider treats the session cookie as evidence that authentication already occurred. An access policy that requires only SSO authentication accepts this attack because the access decision is made on the SSO token, which is valid. Device trust adds a second verification layer: the access policy requires not only that the SSO authentication succeed but also that the connecting device presents a valid client certificate issued by the organization's internal certificate authority (device identity), that the MDM management API confirms the device is enrolled and policy-compliant (management status), or that an endpoint posture assessment confirms that disk encryption, EDR, and minimum patch levels are met at the time of the access request (posture check). These device trust signals cannot be satisfied by an attacker who has stolen an SSO session cookie, because the attacker's device does not have the client certificate, is not enrolled in the organization's MDM, and does not have an EDR agent that the organization's posture assessment server can query. The practical trade-off of device trust is that it requires managing a fleet of known devices, which excludes contractor devices that cannot be enrolled in MDM and personal devices used for work purposes. The access policy must document what happens in these cases: whether contractors receive access from a browser isolation session (the browser runs in a cloud environment managed by the organization, and the contractor sees rendered output without the device having a routable network path to internal services), whether contractors receive access to a limited subset of applications without device trust requirements, or whether contractors are required to use organization-issued managed devices before accessing internal systems.

What is microsegmentation and why does it limit the blast radius of a compromised access credential?

Microsegmentation is the practice of dividing an internal network or service inventory into isolated segments where traffic between segments is explicitly permitted by access policy rather than permitted by default. In a flat network model, every host that is authenticated to the network — whether through a VPN, a switched ethernet connection in the office, or a cloud VPC with no inter-service firewall rules — can initiate TCP connections to every other host in the network by default. Compromising one host in a flat network gives an attacker the same connectivity that host has to all other hosts: a compromised application server can connect to the production database; a compromised developer workstation can connect to the deployment pipeline and the secrets management service; a compromised VPN session can reach every internal service whose port is open to the internal subnet. Microsegmentation creates explicit allow-lists between segments: the production application server tier is allowed to connect to the production database on port 5432 but not to the secrets management service's administrative API, the secrets management service is allowed to receive connections from application servers and the deployment pipeline but not from developer workstations, and the developer VPN segment is allowed to connect to the staging environment and the internal monitoring dashboard but not to production databases or production admin APIs. In a ZTNA model, microsegmentation is implemented by the access policy itself: the ZTNA proxy only forwards connections to applications listed in each user's access policy, so a developer with access to the staging environment and Grafana cannot initiate a connection to the production database admin interface because there is no access policy entry that would cause the proxy to forward such a connection. In a VPN model, microsegmentation requires host-level firewall rules or network-layer ACLs that limit which source IP ranges can reach which destination IP ranges on which ports — an approach that is correct in principle but frequently degrades in practice because host-level firewall rules are not updated when new services are added, firewall exceptions are added for debugging and not removed, and the rules become contradictory and unauditable as the service inventory grows. The blast radius of a compromised credential in a microsegmented environment is bounded by the access grants associated with the compromised identity: a contractor credential that grants access to the staging environment and monitoring dashboard has a blast radius of those two systems, not the entire internal network.

The zero trust network access decision record: why the identity verification model you chose determines your lateral movement ceiling and your access control surface

Published 2026-07-16 · WhyChose

Zero trust network access decisions are made when the team first configures remote access for employees or contractors, when a security audit identifies a flat internal network where any compromised credential grants broad access to all internal services, or when a compliance requirement mandates network segmentation, access logging, and documented least-privilege access grants. The AI session that provisions a VPN or ZTNA proxy is practically focused and reaches a working state quickly: it selects a remote access solution — OpenVPN, WireGuard, Tailscale, Cloudflare Access, Zscaler Private Access — configures the server or proxy, adds user accounts or integrates an identity provider, creates access policies requiring authentication before reaching protected resources, and verifies that unauthenticated requests are blocked and that authenticated sessions reach the intended destinations. The session ships a configuration that enforces authentication and that the team observes correctly blocking unauthenticated access attempts while permitting authenticated ones.

What the AI session does not produce is the second half of the zero trust access model. The session answers "how do we require authentication before accessing internal services?" and delivers a working configuration. It does not ask: what is the identity verification model — what signals does the access policy evaluate beyond a valid authentication credential (the user's identity via SSO, the device's MDM enrollment status, the device's security posture including patch level and disk encryption, the time of day and geographic origin of the request), and what is the minimum verification depth required per resource class (should a staging environment require only SSO authentication, while a production database admin interface requires SSO plus MDM enrollment plus a device posture assertion confirming endpoint detection is running)? What is the microsegmentation policy — after a user authenticates to the VPN or ZTNA proxy and gains access, what other resources can that authenticated session reach, and if an authenticated VPN session is a network presence rather than an application presence, does it grant TCP/IP reachability to all services in the internal subnet including production databases, admin APIs, backup storage, and the secrets management service, or is each resource class isolated so that compromising access to one service does not grant network-level reach to adjacent services? What is the device trust model — does the access policy verify that the connecting device meets a minimum security baseline (MDM enrollment, valid client certificate issued by the organization's certificate authority, endpoint detection agent running, disk encryption enabled, operating system at a minimum patch level), and what happens when a contractor uses an unmanaged personal device that cannot be enrolled in MDM, and what is the access path for that contractor's device — full access, limited access, no access, or access from a browser isolation session that prevents data exfiltration to the unmanaged device? What is the access review cadence — when an employee leaves the organization or changes roles, or when a contractor's engagement ends, how quickly is access revoked, and is there a periodic review of all standing access grants to identify access provisioned for a specific project or system that was never revoked when the project concluded? What is the lateral movement analysis — if a service in the internal network is compromised through a software vulnerability or a stolen credential, what other services can an attacker reach from the compromised entry point, and is that lateral movement constrained by the segmentation model or unconstrained because the VPN model grants flat network access to an internal segment that was never divided? Each of these questions has an answer that is not derivable from "we configured VPN access with SSO authentication" as the team describes the founding configuration. Each answer determines whether a phished contractor credential grants an attacker simultaneous network-level access to the production database, the deployment pipeline, and the secrets management service, whether a compromised developer laptop with a stolen but valid SSO session cookie can authenticate past the ZTNA proxy because the access policy was never configured to check device posture, and whether the team discovers a lateral movement event through anomalous traffic detection or through a forensic analysis of a breach that accessed several internal services from a single compromised entry point. The answers exist in the AI sessions. They are the operational commitments behind the access configuration. They are almost never written down.

Two ways zero trust access decisions produce the wrong outcome in production

The flat VPN subnet and the phished contractor credential

A growth-stage B2B SaaS company hires its first external contractor to work on the data pipeline infrastructure. The contractor needs access to the staging environment, the internal monitoring dashboard, and the deployment pipeline to complete their work. The founding remote access session configures a WireGuard VPN: a WireGuard server is deployed on the internal network, a peer configuration is generated for the contractor's laptop, and connectivity is verified by confirming the contractor can reach the staging database and the internal Grafana instance. All WireGuard peers are placed in the same 10.0.1.0/24 private subnet that also contains the production PostgreSQL database on port 5432, the production application servers, the internal admin API on port 8080, the HashiCorp Vault secrets management service on port 8200, and the Jenkins deployment pipeline on port 8443. The staging environment and the monitoring dashboard are in this subnet, so the contractor's verified access targets are present. The VPN configuration ships. No host-level firewall rules distinguish which subnet members can reach which other members; the VPN authenticates with a WireGuard pre-shared key generated per peer.

Six weeks into the contractor engagement, the contractor receives a spearphishing email impersonating the company's internal project management tool. The email links to a credential harvesting page that captures the contractor's laptop login password. The attacker separately performs a credential stuffing attack against the contractor's cloud storage backup service using the captured password and discovers that the contractor's WireGuard configuration file — the private key and the peer configuration — is stored in the contractor's backed-up home directory. The attacker now has a valid WireGuard peer configuration. The attacker establishes a WireGuard session from a VPS in a datacenter. The WireGuard server authenticates the session based on the peer's public key and the pre-shared key — both valid. The attacker has a VPN session with an IP address in the 10.0.1.0/24 subnet.

From the VPN session, the attacker has TCP/IP connectivity to every service in the subnet. The attacker connects to the production PostgreSQL database directly on port 5432 (the database accepts connections from any host in the 10.0.1.0/24 subnet, because the application servers are also in that subnet and need to connect). The attacker queries the users table and extracts 82,000 user records including bcrypt-hashed passwords and plaintext email addresses. The attacker then connects to the Jenkins web UI on port 8443 and discovers that the Jenkins configuration stores a Vault AppRole credential in the pipeline configuration for deploying secrets to production. The attacker uses the AppRole credential to authenticate to the Vault API on port 8200 and retrieves the production Stripe API keys, the production SendGrid API key, and the production database credentials. The incident is discovered eleven days later when a periodic Vault audit log review identifies API calls from an IP address not associated with any known internal host or user. The post-incident review identifies that the microsegmentation decision was never made: the VPN subnet contained production services alongside staging services because it was easiest to put everything in one segment, there was no network-level constraint limiting what a VPN peer could reach in the subnet, and the blast radius of a compromised peer configuration was therefore every internal service in the network.

The device-trust-free ZTNA policy and the compromised developer laptop

A fintech startup operating a payment processing API adds Cloudflare Access as a zero trust access layer after a penetration test identifies that several internal administration tools are directly reachable from the public internet with only HTTP basic authentication as the protection mechanism. The remediation session configures per-application Cloudflare Access policies for each internal tool: the Grafana metrics dashboard requires authentication with the company Google Workspace SSO, the deployment pipeline requires the same SSO, and the database administration interface running on the internal network requires SSO authentication with an additional group membership check confirming the user is in the "Engineering" group. The session verifies that unauthenticated requests to each tool produce a redirect to the Cloudflare Access login page and that authenticated requests from a member of the Engineering group reach the tools. The penetration test finding is closed. The ZTNA configuration ships.

The Cloudflare Access policies require Google Workspace SSO authentication and group membership verification. They specify no device posture checks: any device that can produce a valid Google Workspace session — including personal laptops not enrolled in MDM, contractor devices with no endpoint security requirements, and devices that have been compromised but still hold valid Google OAuth sessions — can satisfy the access policy and receive a Cloudflare Access JWT granting access to the protected tools. A senior engineer uses their personal laptop for both work and personal projects. The engineer's personal npm project depends on a utility package that was compromised in a supply chain attack six weeks after the ZTNA configuration shipped; the malicious version of the package includes a credential exfiltration payload that runs at install time and reads the browser's local storage and cookie store from the Chrome and Firefox profiles present in the home directory. The payload transmits the cookie store contents to an external endpoint controlled by the attacker.

The exfiltrated cookies include the engineer's active Google OAuth session cookie — not the Cloudflare Access JWT, but the underlying Google authentication session that the Google SSO server uses to identify the user across the Google Workspace product suite. The attacker uses the Google OAuth session cookie to initiate an authentication flow against the company's Cloudflare Access policy. The Google SSO server receives the session cookie, identifies it as a valid active session for the engineer's corporate Google account, and issues a new OAuth code that Cloudflare Access exchanges for a JWT. The Cloudflare Access JWT is issued to the attacker's browser. The attacker now has access to Grafana, the deployment pipeline, and the database administration interface. At no point in this authentication flow was the engineer's password requested, because the Google OAuth session was treated as proof of prior authentication. At no point was the device posture checked, because the Cloudflare Access policies specified no device trust requirements. The access policy achieved its stated goal — requiring SSO authentication before accessing internal tools — precisely. The gap between "SSO authentication required" and "SSO authentication from a trusted device required" was the decision that was never surfaced in the founding ZTNA configuration session.

Three structural properties that zero trust access decisions determine

The identity verification model and the access control surface

The identity verification model determines which signals the access policy evaluates to grant or deny access beyond a valid authentication credential. Identity verification — confirming that the request originates from a known user who controls their authentication credential — is the minimum requirement, but it establishes only that the request comes from a known identity, not that the session is free of attacker influence. Beyond identity, access policies can evaluate device state at three levels of depth. Device identity verification confirms that the connecting device holds a client certificate issued by the organization's internal certificate authority — a certificate that cannot be stolen from a backup because it is bound to the device's TPM or hardware key store and cannot be exported. Device management status verification confirms that the device is enrolled in the organization's MDM platform and that the MDM reports the device as policy-compliant at the time of the access request. Device posture verification checks the device's active security configuration at connection time: disk encryption is enabled, the endpoint detection and response agent is running and up to date, the operating system is at a minimum patch level defined in the posture policy, and no known malicious processes are running. Each verification level represents a different barrier to credential theft attacks: device identity verification blocks attackers who steal passwords and MFA tokens but do not control the target device's hardware; management status verification blocks attackers who control an unmanaged device but cannot enroll it in MDM without organizational approval; posture verification blocks sessions from devices whose security configuration has been degraded by malware or misconfiguration, even when those devices were previously enrolled and trusted.

The identity verification model must be specified per resource class, not as a single uniform policy, because the appropriate verification depth differs by the sensitivity of the protected resource. A public-facing internal wiki or a shared calendar tool may require only SSO authentication — the consequence of a compromised session is low, and requiring device trust would exclude contractors and external collaborators who legitimately access the resource. A staging environment requires SSO plus group membership — not all authenticated users should be able to modify or read staging data, but device trust is not warranted because staging data is not production-sensitive. A production secrets management service or a production database admin interface requires SSO plus device identity plus posture verification, because the consequence of a compromised session is the exfiltration of every production secret or a direct read/write connection to the production database, and the additional friction of device trust requirements is justified by the blast radius of a successful attack. Documenting the verification depth per resource class alongside the rationale makes the trade-off explicit: "the production database admin interface requires device posture verification because a compromised session with direct database access constitutes a production data breach; the staging environment requires only SSO authentication because staging data is non-sensitive and contractor access to staging is a regular operational requirement." The authentication strategy decision record is the upstream document that specifies the SSO provider, the MFA policy, and the session token lifetime that the ZTNA access policies build on; inconsistencies between the authentication strategy (e.g., SSO session lifetime of 30 days) and the access policy's assumed security model (e.g., assuming that a valid SSO session means the user recently authenticated) produce gaps that the access policy does not close.

The microsegmentation policy and the lateral movement ceiling

The microsegmentation policy determines what network reachability an authenticated session has beyond the specific resource the user authenticated to access, and whether compromising that access path grants reach to adjacent resources that the user was not explicitly granted access to. In a VPN model, the authenticated session grants network presence in an IP subnet. The lateral movement ceiling of that session is the set of services reachable from that subnet: if the subnet contains both the contractor's staging environment and the production database, an attacker who compromises the contractor's VPN session has immediate TCP/IP access to the production database on the same network segment. The microsegmentation policy determines whether the subnet is divided — whether a network ACL or security group rule prevents VPN clients from reaching production hosts, even though both are in the same broad internal network — or whether the subnet is flat and every authenticated VPN peer can reach every other host by default.

In a ZTNA model, the microsegmentation is implemented by the access policy itself: the ZTNA proxy forwards only traffic to applications listed in the user's access policy, and the user's device has no routable path to internal services not in that policy. A contractor with an access policy that lists the staging environment and Grafana cannot initiate a TCP connection to the production database admin interface, because the ZTNA proxy has no access policy entry directing it to forward such a connection and the contractor's device has no route to the production network segment independent of the proxy. The lateral movement ceiling of a ZTNA model is the union of all applications in the compromised user's access policy — bounded and auditable. The microsegmentation policy must document three properties: the segmentation model (VPN with host-level ACLs, ZTNA with application-level access policies, or a hybrid of both), the blast radius of each access tier (what services a compromised credential in each tier can reach), and the east-west traffic rules between tiers (whether an application server in the production tier can initiate connections to the secrets management service, whether the CI/CD pipeline in the deployment tier can access the production database directly or only through the application server tier). Without these three properties documented, the microsegmentation policy is an intent rather than a specification. The security ADR and threat model is the upstream document that identifies the threat actors and attack paths the segmentation policy is designed to constrain; a microsegmentation policy that is not derived from a threat model is segmentation for compliance appearance rather than for a defined threat reduction.

The device trust model and the credential compromise blast radius

The device trust model determines what constitutes a trusted device for the purpose of the access policy, how device trust is verified at access time, and what the access path is for devices that do not meet the trust requirements. Device trust requirements create a gap between the set of users who have valid credentials and the set of sessions that can satisfy the access policy — the gap that prevents a stolen credential from producing an authorized session on an unmanaged attacker-controlled device. The gap size depends on how device trust is implemented. A client certificate requirement creates a strong gap: the attacker needs both the user's authentication credential and a valid client certificate bound to a trusted device, and the client certificate cannot be exported from a hardware-backed key store. An MDM enrollment check creates a softer gap: the attacker needs the user's credential and needs the attacking device to be enrolled in the organization's MDM, which requires organizational approval and device registration. A posture-only check (disk encryption enabled, EDR running) creates the softest gap: these properties can potentially be faked by a sufficiently sophisticated attacker who has local administrator access on the device, because posture checks query the device's own software rather than an independent device identity assertion.

The device trust model must address the contractor and unmanaged device scenario explicitly, because this scenario is where the business requirement (contractors need access to specific internal tools) and the security requirement (only trusted devices should access internal systems) are in direct tension. Three resolution paths exist and each must be evaluated against the resource classes the contractor needs to access. The first path is mandatory managed device: contractors who need access to internal systems are required to use an organization-issued managed device; the contractor cannot use their personal laptop. This is appropriate for contractors with access to production data or sensitive systems. The second path is browser isolation: contractors access internal tools through a browser isolation service (Cloudflare Browser Isolation, Menlo Security, Prisma Access Browser) where the browser runs in a cloud environment managed by the organization, and the contractor sees rendered browser output without the contractor's device having any routable path to internal services or any ability to copy data to the local clipboard or download files. This allows unmanaged personal devices to access internal tools without the organization needing to enroll the device in MDM. The third path is scoped unmanaged access: contractors are granted access without device trust requirements, but only to the specific subset of tools where the blast radius of a compromised contractor session is acceptable — staging environments and internal documentation, not production systems. The secrets management decision record is the downstream document that specifies which secrets are accessible to each access tier: a contractor with staging-only access should not have credentials in the secrets management service that grant access to production systems, and the secrets management access policy must be consistent with the ZTNA access policy in what it allows each identity tier to retrieve.

Three AI session types that embed zero trust access decisions without documenting them

The initial remote access provisioning session is where the access model is established for the first time. The session is triggered by a concrete operational need — a new employee needs to work remotely, a contractor needs access to internal systems, or the team moves to a remote-first model. The goal is clear and bounded: get access working, confirm that the intended resources are reachable, and confirm that access requires authentication. The session selects the access solution most readily available (WireGuard because it is simple to configure, Tailscale because the team has used it personally, Cloudflare Access because someone read a blog post about it this week) and configures it to meet the immediate access requirement. The test scenario is: the user authenticates successfully and reaches the intended resource. The adversarial test scenario — does a session initiated from a non-organizational unmanaged device satisfy the access policy? — is not part of the session goal. The microsegmentation question — what can this authenticated session reach beyond the intended resource? — is not examined because the test only verifies that the intended resource is reachable, not what else is reachable. The device trust question — what is the verification depth beyond a valid credential? — is not raised because the immediate problem is "enable access" and device trust requirements are operational overhead when the founding access requirement is internal team members using their known laptops.

The contractor access session is the moment when the access model's implicit assumptions first diverge from the operational reality. The contractor is an external party using an unmanaged device whose security posture the organization does not control. Granting the contractor VPN access with the same configuration used for internal team members places the contractor's unmanaged device in the same network segment as production services. Granting the contractor ZTNA access using the same SSO-only access policy used for internal employees allows the contractor to authenticate with credentials that the organization does not manage (the organization controls the SSO identity but not the contractor's device). The session that provisions contractor access is focused on making the contractor productive — it generates a VPN config or adds the contractor to an SSO group — and does not examine whether the contractor access path creates a different risk profile than internal employee access. The access policy for contractors is typically identical to or derived from the internal employee policy, because the session is about provisioning access rather than designing an access model. The distinction between trusted-device employee access and unmanaged-device contractor access is the decision that is not made in this session. The open-source extractor surfaces these contractor provisioning sessions from AI chat history, recovering the access configuration choices and the access scope decisions made before the team needed to understand what a compromised contractor session could reach or what the device trust requirements for contractor access were.

The security audit remediation session is where the access model's gaps are first addressed, but typically in response to specific audit findings rather than as a comprehensive review. A penetration test finding that an internal admin interface is accessible from the internet without authentication produces a remediation session that adds authentication to that specific interface — Cloudflare Access SSO, or a VPN requirement, or an IP allowlist. The remediation addresses the specific finding: the interface now requires authentication. The session does not examine whether the authentication requirement includes device trust, whether the access policy for the interface is appropriately scoped to the team members who need access, whether the interface is isolated from other internal services so that a compromised session cannot reach adjacent systems, or whether the access grant will be reviewed and revoked when the team member who needs access changes roles. The remediation session closes the specific finding and often creates a new access configuration whose implicit decisions — no device trust requirement, no microsegmentation of the newly protected interface, no access review schedule — are not documented as deliberate choices. The incident response playbook decision record is the companion document that specifies what the team does when a compromised access credential is detected: whether there is a documented revocation procedure, how long revocation takes from detection, and whether the access policy produces sufficient audit logs to reconstruct what the compromised session accessed during the window before detection. An access configuration that cannot be audited after a breach and cannot be revoked within a defined time window after detection is a configuration whose security properties are not complete.

The five sections of a zero trust network access decision record

The first section documents the identity verification model specification. For each protected resource class — internal tooling accessible to all employees, staging environment accessible to engineers, production monitoring accessible to on-call engineers, production admin interfaces accessible to senior engineers — the specification must name the verification signals required: identity only (SSO authentication, confirming user identity), identity plus group membership (SSO with a defined group as a required claim in the access token), identity plus device identity (SSO plus a client certificate bound to an enrolled device), or identity plus device posture (SSO plus a real-time posture check confirming disk encryption, EDR running, and OS patch level). The rationale must state why each resource class received its verification depth: "the staging environment requires identity plus group membership because staging data is non-sensitive and contractor access is a regular requirement; the production database admin interface requires identity plus device identity plus posture because a successful attack against this resource constitutes a production data breach." The test procedure for each verification level must be specified: "device posture verification for the production admin tier is verified by attempting access from an enrolled device with EDR disabled and confirming access is denied, then re-enabling EDR and confirming access is granted within the posture check interval." The authorization model decision record is the companion document specifying what permissions an authenticated session has within each application — the ZTNA access policy controls whether a user can reach the application, while the authorization model controls what the user can do within it; both must be specified for access to a production admin interface to be appropriately scoped.

The second section documents the microsegmentation policy. The segmentation model must be stated — VPN with network ACLs, ZTNA with application-level access policies, or a hybrid — alongside the segmentation boundary for each tier. For a VPN model: which source IP ranges (corresponding to which VPN peer groups or network segments) are permitted to reach which destination IP ranges on which ports, and what the default-deny rule is for traffic not explicitly permitted. For a ZTNA model: which application names are listed in the access policy for each user group, and which are explicitly excluded. The blast radius of a compromised credential in each access tier must be stated explicitly: "a compromised contractor credential can access the staging PostgreSQL database (port 5432 on 10.0.2.x), the internal Grafana dashboard (port 3000 on 10.0.3.x), and the CI pipeline UI (port 8443 on 10.0.3.x); it cannot reach the production database (10.0.1.x, no access policy entry), the Vault service (10.0.1.x, no access policy entry), or the production application servers (10.0.1.x, no access policy entry)." The east-west traffic rules between application tiers must be documented: "the CI pipeline server is permitted to call the Vault API to retrieve deployment secrets (outbound from 10.0.3.x to 10.0.1.22:8200); the CI pipeline server is not permitted to connect directly to the production database (no rule permits 10.0.3.x to 10.0.1.x:5432); database access during deployments is performed only through the application's migration command running on the application server tier." The access control model decision record specifies the authorization model within each application; the microsegmentation policy specifies what network paths exist between applications — both must be consistent for the least-privilege model to hold at the application layer and the network layer simultaneously.

The third section documents the device trust model. The specification must state what constitutes a trusted device for each access tier — what signals define device trust (client certificate, MDM enrollment, posture check), what the enrollment process requires (MDM profile installation, certificate provisioning, EDR agent installation), and what the verification mechanism at access time is (is trust verified by a pre-provisioned certificate that does not change session to session, by an MDM API call that returns the device's current compliance state, or by an on-device posture agent that the ZTNA proxy or access gateway queries at connection time). The specification must address the unmanaged device scenario for each category of user: "internal employees use organization-issued macOS devices enrolled in Jamf MDM; access to all internal tiers requires MDM enrollment status verification. Contractors use personal unmanaged devices; contractors are granted access to the staging tier through Cloudflare Browser Isolation, which runs the browser session in a managed cloud environment and prevents the contractor's device from receiving internal network traffic; contractors are not granted access to the production monitoring or production admin tiers." The client certificate lifecycle must be documented: "device client certificates are issued with a 12-month validity period and are provisioned during MDM enrollment; certificates are revoked when the device is unenrolled from MDM, when the device is reported lost or stolen, or when the employee offboards; revocation uses OCSP with a maximum 4-hour revocation propagation window — a compromised device whose certificate is revoked may retain access for up to 4 hours after revocation is initiated, which is documented in the incident response playbook as the revocation window." The CI/CD pipeline decision record is the upstream document specifying how the deployment pipeline authenticates to internal services — the pipeline's service account credentials must be subject to the same microsegmentation constraints as human user access, because a compromised pipeline service account with unconstrained internal network access represents the same blast radius as a compromised VPN peer.

The fourth section documents the access review cadence. The specification must state how access grants are provisioned and how they are terminated. On provisioning: who can grant access to each tier (a specific access approver role, an automated provisioning system that grants access based on HR system role assignments, or a team-level self-service model), what the access grant scope is (time-bounded to the duration of a contractor engagement or a specific project, or standing access for the duration of employment), and what the access grant record is (who approved access, when, for what purpose, with what expected duration). On termination: what the offboarding procedure is (when an employee leaves, when is SSO access suspended, when are device certificates revoked, when are VPN peer configurations invalidated, and is there a maximum window between HR notification and access termination — "access is revoked within 4 hours of HR system offboarding record creation"), and what the standing access review schedule is (quarterly review of all access grants to identify access that was provisioned for a project that has concluded, contractor access that was not terminated when the engagement ended, or access to resource tiers that the user no longer needs based on current role). The access review cadence must specify the review procedure: "every quarter, the access approver for each tier reviews all active access grants and terminates any grants where the business justification no longer applies; the review produces a signed attestation confirming that all remaining grants are justified." The security scanning decision record specifies the vulnerability scanning and configuration audit schedule; the access review cadence is the human complement to automated scanning — automated tools detect misconfigurations in the access policy implementation, while periodic access reviews detect outdated access grants that are correctly implemented but no longer justified.

The fifth section documents the observability model. The access observability must provide four views that together characterize whether the access model is operating within the defined parameters and whether anomalous sessions should be investigated. First, the authentication attempt rate per resource class: the count of successful and failed authentication attempts per resource, per time period, broken out by user identity and device (if device identity is logged); a spike in failed authentication attempts for a specific resource or a specific user identity indicates a credential stuffing or brute-force attack, while a successful authentication from a geographic location inconsistent with the user's normal access pattern may indicate a stolen credential. The alert threshold must be documented: "alert when a single user identity produces more than 10 failed authentication attempts against any single resource within 5 minutes." Second, the access policy change rate: every change to an access policy — adding a resource, adding a user, modifying the verification requirements — must be logged with the identity of the operator who made the change and the time of the change; an access policy change that was not initiated by an authorized operator (a change made using a stolen admin credential) is a high-priority indicator of an active attack. Third, the device posture drift rate: if posture checks are part of the verification model, the rate at which enrolled devices are flagged as non-compliant (disk encryption disabled, EDR not running, OS patch level below the minimum) indicates a drift from the baseline security posture; a sudden increase in non-compliant device flags may indicate a widespread configuration change or a targeted compromise. Fourth, the anomalous access pattern rate: access from a new geographic location for a known user, access at an unusual time of day, access to a resource class the user has not accessed in the prior 30 days, or access from a device the user has not previously used for this resource class are signals that the session may be unauthorized. The observability strategy decision record specifies the logging infrastructure and the alert routing model; the zero trust access observability model must be integrated into the same infrastructure so that access anomaly alerts route to the same on-call channel as application performance alerts, and so that the access logs are retained for the duration required by the incident response policy to support forensic reconstruction of what a compromised session accessed. The decisions never written down in a zero trust access deployment are the microsegmentation policy (what an authenticated session can reach beyond the intended resource), the device trust model (what verification depth is required per resource class and what the unmanaged device path is), and the access review cadence (when access grants are reviewed and terminated) — three properties that together determine whether a compromised credential grants access to one application or to every internal service, whether a stolen SSO session satisfies the access policy or is blocked by device trust verification, and whether former employee or concluded-contractor access persists beyond the intended engagement window.

The initial remote access provisioning session that configured a WireGuard VPN with all peers in a flat /24 subnet because the contractor needed access to the staging environment and the staging environment was on the internal network; the contractor onboarding session that granted the contractor the same access configuration as internal engineers because the session was about making the contractor productive rather than designing a contractor-specific access tier; and the security audit remediation session that added Cloudflare Access SSO authentication to internal admin tools without configuring device posture requirements because the audit finding was "no authentication" and adding authentication closed the finding each produced zero trust access decisions whose long-term security cost — a phished contractor credential granting an attacker direct TCP access to the production database and the secrets management service because all VPN peers shared a flat network segment with no host-level ACLs; a compromised developer laptop exfiltrating an SSO session cookie that satisfied an access policy which required only SSO authentication and never checked whether the connecting device was managed or posture-verified; a former contractor whose access was never revoked because there was no documented offboarding procedure that included access termination within a defined window — exceeds what a microsegmentation policy with explicit per-tier blast radius documentation, a device trust specification with a contractor unmanaged-device access path, and an access review cadence with a maximum offboarding-to-termination window would have cost to specify at the time the founding decisions were made. The decisions are in the AI sessions: the VPN configuration that "puts everything in one subnet to keep it simple," the ZTNA policy that "adds SSO authentication without device trust requirements to close the audit finding quickly," the contractor access grant that "uses the same group as internal engineers because the provisioning path already exists." WhyChose's open-source extractor surfaces these founding access provisioning sessions, contractor onboarding sessions, and audit remediation sessions as structured decision records before a phished credential grants network-level access to a flat internal subnet that contains the production database alongside the staging environment the credential was provisioned for, a stolen SSO session authenticates past an access policy that was designed to require authentication but never designed to require a trusted device, or a concluded contractor engagement leaves access grants active because the founding configuration session never specified an access review cadence or an offboarding-to-termination window. The decisions never written down in a zero trust access deployment are the microsegmentation policy, the device trust model, and the access review cadence — the three operational commitments that determine whether the access configuration functions as a security control that limits the blast radius of a compromised credential to a single application, or whether it functions as an authentication gate whose boundary is the entire internal network for every authenticated session regardless of what resource the session was intended to access.