Zero-Trust Network Access

By Michael Samuel Naeem · May 29, 2026 · 5 min read

Our VPN gave every authenticated user access to the entire 10.0.0.0/8 network — production databases, staging environments, and internal wiki included. A compromised laptop credential meant lateral movement everywhere. Moving to ZTNA replaced the flat network with per-application policies: engineers reach staging, on-call reaches production, finance reaches the ERP — each gated by identity, device posture, and MFA.

Zero trust principles

Traditional security: "trust inside the perimeter, verify at the gate."

Zero trust: "never trust, always verify" — for every request, regardless of origin.

ZTNA architecture

[User Device] ──> [ZTNA Client/Agent]
                        |
                  [Identity Provider]
                   (Okta, Azure AD)
                        |
                  [Policy Engine]
                   (access decision)
                        |
              [ZTNA Connector/Proxy]
                   /          \
        [Internal App A]  [Internal App B]

Components:

• Identity Provider (IdP) — authenticates users via SSO/MFA
• Policy Engine — evaluates identity, device, context against rules
• ZTNA Connector — lightweight agent near internal apps, no inbound ports
• Client — device agent or browser-based access portal

Policy-based access

Define policies per application:

policies:
  - name: engineering-staging
    application: staging-api.internal
    allow:
      groups: [engineering, qa]
      device_posture:
        os_version: ">= 13.0"
        disk_encrypted: true
        managed: true
      mfa: required
      time: business_hours

  - name: production-oncall
    application: prod-api.internal
    allow:
      groups: [oncall, sre]
      device_posture:
        managed: true
        certificate: company-device
      mfa: required
      approval: manager
    session:
      max_duration: 4h
      record: true

Access decisions combine multiple signals — not just username and password.

Device posture checks

Evaluate before granting access:

{
  "device_id": "abc-123",
  "platform": "macOS",
  "os_version": "14.5",
  "disk_encrypted": true,
  "firewall_enabled": true,
  "antivirus_running": true,
  "jailbroken": false,
  "managed": true,
  "last_seen": "2026-05-29T10:00:00Z"
}

Micro-segmentation

Replace flat network zones with per-app isolation:

Traditional:
  VPN → 10.0.0.0/8 → everything

Zero Trust:
  User A → Policy → App 1 only
  User A → Policy → App 2 (denied)
  User B → Policy → App 2 only

Each application runs behind its own ZTNA connector. No shared network segment between apps.

Implementation steps

1. Inventory applications — catalog internal services and current access patterns
2. Deploy IdP integration — SSO with MFA for all users
3. Install ZTNA connectors — one per application or application group
4. Define policies — map user groups to applications with conditions
5. Enable device posture — require managed devices for sensitive apps
6. Pilot with one team — validate access before broad rollout
7. Decommission VPN — migrate remaining users, remove network-level access

ZTNA vs. VPN comparison

Monitoring and audit

Log every access decision:

{
  "timestamp": "2026-05-29T14:30:00Z",
  "user": "[email protected]",
  "application": "prod-api.internal",
  "decision": "allow",
  "factors": {
    "identity": "verified",
    "mfa": "passed",
    "device_posture": "compliant",
    "location": "US-CA"
  },
  "session_id": "sess_xyz",
  "duration": "2h15m"
}

Alert on:

• Access denied spikes (credential stuffing)
• Non-compliant device access attempts
• After-hours production access
• Policy changes

Common ZTNA platforms

Evaluate based on existing IdP integration, application types (HTTP, SSH, RDP), and deployment model (cloud vs. self-hosted).

Legacy application access

Not every app supports modern ZTNA connectors. For SSH, RDP, and proprietary protocols, use ZTNA client agents that proxy non-HTTP traffic. Migrate HTTP apps first; keep VPN segments for legacy until connectors are available.

Break-glass access

Define emergency access procedures for when IdP or ZTNA platform is down. Break-glass accounts should be heavily audited, time-limited, and require multi-person approval. Test break-glass quarterly.

Measuring success in production

Deploy changes behind feature flags when possible so you can compare metrics between control and treatment groups. Use Real User Monitoring to capture performance data from actual devices and network conditions — lab tools alone miss the long tail of user experiences. Set up alerts for regressions: a 10% LCP increase week-over-week warrants investigation before it hits CrUX.

Document your baseline metrics before making changes. Performance work without measurement is guesswork. Share results with the team — concrete numbers ("LCP improved 800ms on mobile") build support for continued investment in web performance and reliability.

Review changes quarterly. Browser updates, new API support, and traffic pattern shifts can obsolete previous optimizations or create new opportunities. What worked in 2024 may not be the best approach in 2026.

Common production mistakes

Teams get zero trust network access wrong in predictable ways:

• Skipping failure-mode rehearsal — run a game day or fault injection exercise before peak traffic, not after the first outage.
• Missing correlation context — every error path should carry request, trace, or tenant identifiers so incidents are debuggable.
• Optimizing for demo, not steady state — load tests, cache warm-up, and cold-start paths matter more than local dev latency.
• Undocumented trade-offs — if you chose speed over strict correctness (or vice versa), write that down for the next engineer.

Production implementations of zero trust network access fail when staging mirrors production topology poorly, rollback is untested, and on-call runbooks describe the happy path only.

Resources

• NIST SP 800-207: Zero Trust Architecture
• Google BeyondCorp papers
• Cloudflare Zero Trust docs
• CISA Zero Trust Maturity Model
• Gartner ZTNA market guide