Visit Website →
← Back to blog

Two Quarter Zero Trust Network Access Pilot for IT Teams, CISA Aligned

September 26, 2026
Two Quarter Zero Trust Network Access Pilot for IT Teams, CISA Aligned

Zero trust network access enforces per-request, identity and context based access to specific applications, replacing broad network access with least-privilege app connectivity. It shrinks the attack surface by design, since users and devices only ever reach the one app they're authorized for, never the network behind it. For most IT teams, the smartest starting point is a scoped pilot on a small set of important, internet-facing apps, not a wholesale VPN rip-and-replace.

TL;DR:

  • Implementing ZTNA on a small set of critical, internet-facing applications during the pilot phase helps detect integration challenges early and builds stakeholder confidence quickly.
  • Success requires prerequisite infrastructure: support for modern identity federation, full endpoint posture management, comprehensive logging, and alignment with micro-segmentation.
  • Deployments should follow a phased approach over four quarters, focusing first on discovery, then narrow pilots, gradual expansion, and continuous measurement.
  • Operating ZTNA long-term depends on consistent telemetry collection, automation for token management and device posture, and ongoing policy governance.
  • Choosing the right deployment model depends on application type and environment, with options including agent-based, connector-based, or cloud-delivered solutions.
AccountNext-Nexus
Unify Your Security Approach
Nexus brings cybersecurity, IT management, cloud infrastructure, and compliance services together under one umbrella.
Explore Nexus solutions

Table of Contents

What is zero trust network access and how does it fit zero trust architecture?

Zero trust network access is the access layer of a broader zero trust architecture. Where zero trust architecture is the overall philosophy, defined by NIST SP 800-207 as a model in which access decisions are dynamic, per-request, and based on identity and context rather than network location, ZTNA is the specific mechanism that applies that philosophy to how users and devices reach applications.

Think of zero trust architecture as the constitution and ZTNA as one piece of enforcing legislation. It governs application access. It doesn't, on its own, cover data classification, workload segmentation inside a data centre, or how you protect an API between two microservices. Those pieces come from other zero trust controls: identity governance, data security, device management, and micro-segmentation strategy inside the network itself.

That distinction matters for budgeting and scope. A CIO who buys a ZTNA product expecting it to satisfy every pillar of the CISA Zero Trust Maturity Model will be disappointed. CISA's model spans five pillars: identity, devices, networks, applications and workloads, and data, tied together by cross-cutting capabilities in visibility, automation, and governance. ZTNA sits mainly in the applications pillar, with strong dependencies on identity and devices.

CISA zero trust pillars and cross-cutting capabilities

Practically, this means ZTNA is resource-centric rather than network-centric. Instead of granting a laptop a routable path into a subnet, ZTNA grants a verified identity a narrow, time-bound connection to one application. Everything else on the network stays invisible to that session, which is the core security gain over legacy remote access.

How does zero trust network access work?

Every ZTNA connection runs through a decision loop that repeats on each request, not once at login. Four categories of signal feed that decision:

  • Identity: who is asking, verified through SSO or an identity provider, ideally with multifactor authentication.
  • Device posture: is the endpoint managed, patched, and free of known compromise, typically checked via EDR or MDM agents.
  • Session context: location, time of day, network reputation, and whether the request pattern looks normal.
  • Behavioural telemetry: anomalies in usage that might indicate a compromised credential mid-session.

Those signals feed a policy decision point, or PDP, which is the brain of the system. The PDP evaluates the request against policy and either approves or denies it. The enforcement happens at a separate component, the policy enforcement point, or PEP, which sits in front of the application, whether that's an agent on the endpoint, a gateway, or a cloud proxy. This split between "decide" and "enforce" is deliberate. It lets you centralize policy logic while distributing enforcement close to wherever the app actually lives.

Once the PDP approves a request, it doesn't hand out a permanent key. It issues a short-lived token, often built on OAuth2 or OpenID Connect, that expires quickly and has to be renewed through the same verification loop. NIST's implementation guidance treats open standards like OAuth2 and OIDC as a practical foundation for this kind of cloud-native, interoperable authorization.

The sequencing is the real security win here. Authorization happens before any network connection is established, not after. The NCSC's 2026 ZTNA guidance is explicit on this point: applications should stay invisible to unauthenticated traffic, so there's nothing for an attacker to scan, fingerprint, or pivot from, even if they're sitting on the same network segment as a legitimate user.

Authorization gate issuing short-lived application access

Zero trust vs VPN: what actually changes?

This is the comparison IT leaders ask about most, and the honest answer is that ZTNA and VPN solve different problems even though they both claim to enable secure remote access. A VPN authenticates once, then hands the device a tunnel into a slice of the network. Once you're on, you're largely trusted to roam. ZTNA authenticates and authorizes every request, and connects the user only to the specific application, never the network.

That difference cascades into daily operations:

  • Discovery risk: a compromised VPN credential lets an attacker probe an entire subnet; a compromised ZTNA session exposes exactly one app.
  • Visibility: VPN concentrators log connections, not per-app activity; ZTNA logs every access decision, which feeds much richer telemetry.
  • User experience: VPNs often mean a slow client and a "connect before you work" habit; ZTNA can run silently in the background, reauthorizing without user action.
  • Blast radius during an incident: containing a VPN breach means cutting off broad network segments; containing a ZTNA breach means revoking one app's tokens.

None of this means every VPN needs to disappear overnight. Site-to-site connections, legacy protocols that don't map cleanly to app-level proxies, and small environments without budget for a phased migration are all reasonable places to keep a VPN running for now. The pragmatic path most teams take is coexistence: move the highest-risk, most-used applications to ZTNA first, and let VPN handle whatever's left until it's cheaper to migrate than to maintain.

Which ZTNA deployment model fits your environment?

There's no single "right" architecture. The choice depends on what you're protecting and who's connecting to it.

  1. Agent-based, gateway-fronted ZTNA. A lightweight agent on the endpoint talks to a cloud or on-premises gateway, which brokers access to private and legacy apps. This model handles older protocols well and gives you strong device posture checks, but it requires agent deployment and management across every endpoint, which adds overhead in bring-your-own-device environments.

  2. Gateway or proxy with lightweight connectors. A small connector sits next to the application, often inside a private data centre, and establishes an outbound-only connection to a broker in the cloud. Nothing inbound ever touches the app directly. This is the pattern of choice for internal apps that were never meant to be internet-facing, since it avoids opening any inbound firewall rules at all.

  3. Cloud-delivered ZTNA inside SSE or SASE. Access control, web filtering, and data protection converge into one cloud-delivered stack, which suits organizations with a large distributed workforce and heavy SaaS use. It reduces the number of point products you're managing but ties you more tightly to a single vendor's global network performance.

Pick based on four practical criteria: application type (legacy protocol versus modern web app), latency tolerance for your busiest users, whether the app can stay hidden from direct discovery, and how much ongoing management overhead your team can absorb. A distributed sales team living in SaaS tools points toward SSE/SASE; a manufacturing plant with legacy control systems points toward gateway and connector patterns.

What has to be in place before ZTNA works?

ZTNA fails quietly when the surrounding infrastructure isn't ready, not because the product is broken. The NCCoE's implementation guidance is blunt about this: real deployments combine identity governance, endpoint controls, micro-segmentation, and telemetry, and skipping any one of them creates a gap attackers eventually find.

Run through this checklist before you commit to a vendor:

  • Identity and SSO: your identity provider needs to support modern federation (SAML, OIDC) and ideally already enforces MFA, because ZTNA policy is only as strong as the identity signal feeding it.
  • Endpoint posture tools: EDR and MDM coverage across the fleet, plus a plan for non-human identities like service accounts and API keys, which don't fit neatly into human-centric posture checks.
  • Logging and telemetry: a SIEM or equivalent that can ingest per-request access logs, because ZTNA generates far more granular data than a VPN concentrator ever did, and that data is wasted if nothing's collecting it.
  • Segmentation alignment: ZTNA controls access to an app, but micro-segmentation strategy inside your network still limits what happens if that app itself is compromised, so the two need to work together, not in isolation.

Pro Tip: Audit your identity provider's OAuth2 and OIDC support before you shortlist ZTNA vendors. A mismatch here is the single most common reason pilots stall past week three.

How do you roll out ZTNA without breaking production?

Treat this as an integration programme, not a software install. A quarter-by-quarter structure keeps scope honest and gives leadership measurable checkpoints.

  1. Quarter one: discovery and scoping. Inventory every application, who accesses it, and how (VPN, direct, SaaS login). Cross-reference against your identity provider's user and group data. This step alone usually surfaces forgotten legacy apps still sitting on flat network access.

  2. Quarter two: pilot on a narrow, high-value app set. The NCCoE's field experience shows that pilots limited to a handful of time-critical or compliance-sensitive apps surface integration gaps early and build stakeholder confidence faster than a broad rollout. Define success metrics before you start: authorization accuracy, latency added versus current access, and help desk ticket volume.

  3. Quarter three: phased rollout with a rollback plan. Expand by business unit or app category, not all at once. Keep the old access path live in parallel for each group until the new one has run clean for at least two weeks, and document exactly how to revert if a policy change breaks production access.

  4. Quarter four: measurement and tuning. Track policy accuracy (the ratio of correctly authorized versus denied requests), mean time to remediate a bad policy, and how much application exposure you've actually reduced. CISA's maturity model explicitly warns against measuring success by remote-user coverage alone; a broader measurement approach across identity, devices, apps, and data gives a truer picture.

Watch for two recurring failure modes: policy sprawl, where every exception gets a bespoke rule until nobody can audit the rule set, and orphaned service accounts that never got folded into the identity governance process. Both are fixable, but only if someone owns policy hygiene as an ongoing job, not a launch task.

What does it take to keep ZTNA running well?

Deployment is the easy part. Operating ZTNA well over years is where most of the value, and most of the risk, actually lives.

Telemetry needs to flow continuously, not just during incident response. Every access decision, every denied request, every token renewal is a data point worth keeping, because patterns in denials often reveal misconfigured policy before they reveal an actual attack. Feed that data into whatever SIEM your team already uses, so ZTNA telemetry sits alongside the rest of your detection stack rather than living in its own silo.

Automation earns its keep in two places: just-in-time access grants that expire automatically instead of relying on someone to remember to revoke them, and automated remediation when a device fails a posture check mid-session, cutting access immediately rather than waiting for a human to notice.

Governance is the part organizations underinvest in. Someone needs to own the policy lifecycle: who can create a new access rule, how often existing rules get reviewed, and how that mapping ties back to the CISA maturity pillars so leadership can see progress in terms the board actually understands. Without a named owner, policy quietly drifts until an audit finds it.

Nexus's quick-start checklist for a CISA-aligned pilot

A ZTNA pilot runs against a checklist: full app and identity inventory, connector deployment for non-internet-facing apps, and SLA-backed 24/7 monitoring from day one. Milestones track directly to NIST and CISA maturity pillars, so quarterly progress is measurable, not anecdotal.

Where does ZTNA actually get used?

The pattern looks different depending on organization size and industry, though the underlying logic (verify every request, expose nothing by default) stays constant.

A mid-sized healthcare provider with a mix of on-site clinical systems and remote administrative staff typically starts with ZTNA on billing and scheduling apps, since those carry HIPAA exposure and the highest volume of remote logins. Clinical systems tied to legacy hardware often stay on a more gradual timeline, protected instead by tighter network segmentation until they can be modernized.

A financial services firm under PCI-DSS or SOC 2 obligations tends to prioritize ZTNA for anything touching cardholder data or audit trails, because per-request logging gives compliance teams exactly the evidence auditors ask for: who accessed what, when, and under what device posture.

Manufacturing and industrial organizations face a different problem: legacy operational technology that can't run modern agents. Here, gateway and connector patterns dominate, since they let ZTNA sit in front of a system without requiring changes to the system itself.

Smaller organizations, meanwhile, often get the fastest wins from cloud-delivered ZTNA bundled with existing SaaS security tools, since it avoids standing up dedicated infrastructure. A twenty-person startup with no on-prem data centre and everything in SaaS is arguably the easiest ZTNA deployment there is, precisely because there's no legacy network to unwind.

How do leading ZTNA approaches compare?

Rather than ranking specific products, it's more useful to compare ZTNA offerings by category, since the trade-offs are consistent across the market regardless of which name is on the invoice.

Agent-based enterprise platforms tend to offer the deepest device posture integration and the widest legacy protocol support, which suits organizations with a large managed-device fleet and older internal applications. The cost is management overhead: every endpoint needs the agent installed, updated, and monitored.

Cloud-native SSE and SASE platforms bundle ZTNA with web filtering, data loss prevention, and firewall-as-a-service, which appeals to organizations trying to consolidate vendors and reduce the number of consoles security teams juggle. The trade-off is a heavier dependency on one vendor's global network performance, which matters if your workforce is spread across regions with uneven connectivity.

Lightweight connector-based tools focus narrowly on brokering access to private apps without inbound firewall changes, which fits organizations that mainly need to retire an aging VPN concentrator without a full platform overhaul.

Whichever category you evaluate, insist on the same interoperability checks: OAuth2/OIDC support, SIEM export formats, and documented APIs for automation. A platform that can't integrate cleanly with your identity provider and logging stack will cost more in workaround engineering than it saves in licensing, regardless of feature list.

What does ZTNA mean for remote and hybrid teams?

Hybrid work is where ZTNA earns its budget line fastest, because it removes the single biggest weakness of remote access as it existed for the last two decades: the assumption that once you're authenticated, you're trustworthy for the rest of the session.

Under a VPN model, a compromised home laptop, an unpatched personal device, or a stolen credential grants an attacker a foothold on the corporate network itself. Under ZTNA, that same compromise is contained to whichever single application the attacker's session happened to be authorized for at that moment, and continuous verification means a sudden change in behaviour, an odd login location, a device that suddenly fails a posture check, can trigger re-authentication or outright denial mid-session.

This matters more as hybrid work normalizes bring-your-own-device policies and split-tunnel home networks that IT never fully controls. Zero trust remote access doesn't assume the home network is safe; it assumes nothing is safe until proven otherwise, request by request.

It also changes how security teams think about contractors and third parties, a group that historically got broad VPN access out of convenience. Identity-based access lets you grant a contractor exactly the one app they need for exactly the duration of their engagement, with an audit trail that shows precisely what they touched, which matters enormously the next time an auditor or a breach investigation asks.

Does ZTNA make life harder for end users?

Done badly, yes. Done well, most users barely notice it, which is the actual goal.

The complaint that surfaces most often in early rollouts is reauthentication fatigue: users forced to prove their identity repeatedly throughout the day, which trains people to resent security rather than trust it. That's usually a policy tuning problem, not an inherent ZTNA limitation. Well-configured continuous verification runs in the background, using device posture and behavioural signals to renew access silently, and only surfaces a prompt when something genuinely changes, a new device, an unusual location, a failed posture check.

Latency is the other usability concern worth taking seriously. Routing every request through a policy engine adds a decision step that didn't exist under a flat network model. For most modern applications the added delay is imperceptible, but it's worth testing against your actual highest-traffic apps before a full rollout, not after users start complaining.

The balance that works in practice: front-load the friction into the trust-building signals (strong initial identity verification, solid device posture baselines) so that ongoing access can stay quiet. Pair that with clear communication to staff about why access now feels different, since a security change nobody explains reads as an obstacle, while the same change explained as "this protects your work account if your laptop is ever compromised" tends to land as reasonable. Organizations that skip that communication step see the highest volume of help desk pushback in the first thirty days, almost always resolved once users understand what changed and why.

A leadership perspective on getting ZTNA right

Most ZTNA programs stall not on technology but on scope creep. I've watched teams try to solve identity, segmentation, and application access all at once, when the disciplined move is picking one high-value app set, proving the model, and expanding from measurable success. Start narrow, measure honestly, and let the results make your case to the board.

— Nick - Sr. Executive

How Nexus supports your ZTNA rollout

If you've read this far, you already know ZTNA isn't a product you install over a weekend. It's an integration project that touches identity, endpoints, telemetry, and governance all at once, and most internal IT teams are already stretched thin running day-to-day operations alongside a project like this.

AccountNext-Nexus

A single provider can consolidate that entire lift instead of leaving your team to coordinate identity vendors, endpoint tools, and logging platforms separately. A ZTNA pilot can integrate directly into monitoring you might otherwise have to build from scratch, providing one point of accountability for the whole rollout, rather than multiple vendors. For teams designing access controls around automated or agentised workloads, the same governance-first thinking shows up in broader AI access control patterns worth reviewing alongside your ZTNA plan.

AccountNext-Nexus's Cybersecurity and Network Infrastructure services cover exactly this kind of engagement, from initial app and identity inventory through connector deployment and ongoing SLA-backed monitoring. If a quarter-by-quarter ZTNA pilot is on your roadmap, the next step is a scoping conversation, not another vendor demo.

Sources

FAQ

What is zero trust network access vs VPN?

ZTNA authenticates and authorizes every request and connects a user only to a specific application, never the underlying network. A VPN authenticates once at connection time and then grants broad access to a network segment, which is why a compromised VPN credential carries far more risk than a compromised ZTNA session.

What's the difference between zero trust and zero trust network access?

Zero trust, as defined in NIST SP 800-207, is the overall security philosophy: never trust by default, verify every request based on identity and context. ZTNA is the specific technology and set of controls that applies that philosophy to application access, one piece of the larger zero trust architecture alongside identity governance, device management, and micro-segmentation strategy.

Which vendors offer zero trust network access solutions?

ZTNA is offered across three broad categories: agent-based enterprise platforms, gateway and connector tools, and cloud-delivered SSE/SASE platforms, each suited to different application types and workforce distributions. AccountNext-Nexus helps organizations evaluate and integrate ZTNA as part of its Cybersecurity and Network Infrastructure services, rather than reselling a single fixed product.

How does ZTNA reduce lateral movement risk?

Because ZTNA grants access to one application at a time instead of a network segment, an attacker who compromises a session or credential can't discover or pivot to other systems the way they could on a flat VPN-connected network. The NCSC's 2026 guidance treats this reduced exposure as a core design goal, not a side effect.

How long does a ZTNA pilot typically take?

A scoped pilot on a small, high-value app set generally runs one quarter for discovery and scoping, followed by a second quarter for the pilot itself, based on the phased approach that NCCoE's implementation research associates with faster stakeholder buy-in. Full organization-wide rollout typically follows over subsequent quarters, app group by app group.