Enterprises that still rely on corporate VPNs for accessing internal web applications face rising operational cost and growing gaps in visibility and control. Since 2023 the market has shifted: managed enterprise browsers, ZTNA gateways, and stronger device-binding options (mTLS, FIDO/WebAuthn attestation, and device posture APIs) have matured enough to make application-level zero trust the practical default for web apps. This updated guide (August 2026) walks IT and security teams through a concrete migration from VPN to enterprise-browser-based access, adding recent best practices, new standards and tooling patterns, and operational guidance that matters today.

Who this guide is for

  • IT and security engineers decommissioning VPNs for browser-accessible intranet apps
  • Enterprise-browser administrators integrating browsers with IdP, ZTNA, and device attestation
  • Project managers and architects planning pilot, rollout, and compliance validation

Prerequisites and context (what to know before you start)

Before you begin, confirm that your environment supports these baseline capabilities:

  • Identity provider (IdP): OIDC and/or SAML support, conditional access policies, and an API to automate client/app registration (Azure AD, Okta, Google Workspace Identity, etc.).
  • ZTNA/private access gateway: A proxy or connector approach (Cloudflare Access, Zscaler Private Access, Netskope Private Access, Palo Alto Prisma Access, Akamai/Edge) that can validate IdP tokens and device signals.
  • Enterprise browser management: Chrome Enterprise, Microsoft Edge managed mode, or another managed browser offering policy enforcement, certificate provisioning hooks, and telemetry. Ensure MDM/EMM integration (Intune, Jamf, Workspace ONE) for posture signals.
  • Standards familiarity: OIDC/SAML, OAuth2 token options (including RFC 8705 mutual TLS), WebAuthn/FIDO2 for device-bound authentication and attestation.

High-level architecture and decisions (updated for 2026)

The migration removes implicit network trust and replaces it with three coordination layers:

  • Identity + SSO: OIDC/SAML via your IdP for user authentication and attribute claims. Use short-lived access tokens and refresh mechanisms; consider Continuous Access Evaluation (CAE) if supported to revoke sessions quickly.
  • ZTNA / access broker: A gateway that validates identity and device posture, optionally enforces mTLS, and proxies or tunnels traffic to internal apps. Modern gateways increasingly support DPoP-style proof-of-possession or certificate-bound tokens in addition to mTLS.
  • Enterprise browser: A managed browser that enforces policies, handles client certs or FIDO attestation, isolates sessions, and emits curated telemetry to SIEM/EDR while protecting user privacy.

Optional: use remote browser isolation (browser-as-a-service) for unmanaged or BYOD devices so internal apps are never rendered in an unmanaged client.

Step 0 — Inventory and readiness checklist (additions for 2026)

Expand your inventory to include modern dependencies and attestation requirements:

  1. List all web applications accessed over VPN. Record hostnames, protocols (HTTPS, HTTP2, WebSocket), auth patterns (forms, Kerberos, NTLM, SSO), and any client cert usage.
  2. Identify non-browser protocols (SSH, RDP) and categorize whether they will remain on VPN, use a separate bastion, or be migrated to a gateway that supports TCP/UDP tunneling.
  3. Record compliance and attestation needs: eDiscovery, long-term audit retention, SOC/ISO requirements, and whether attested hardware-backed keys (FIDO/EK certs) are required.
  4. Document DNS and certificate dependencies: split-DNS, internal CA usage, and applications that validate client IPs or rely on internal hostname semantics.
  5. Inventory browser extension requirements and third-party scripts; extension risk is now one of the top control points for enterprise-browser security.

Step 1 — Choose your ZTNA/private access approach

Two dominant architectural patterns remain relevant in 2026:

  • Proxy-based ZTNA (fastest for web apps): A cloud or on-prem gateway terminates TLS, authenticates via IdP, enforces posture/mTLS, and proxies requests to apps. Advantage: minimal app changes, consolidated logging and policy. Look for gateways that support certificate-bound tokens (RFC 8705), DPoP-like protections, and integration with device attestation flows.
  • Connector/mesh (outbound connector agents): Lightweight connectors on-prem establish outbound tunnels to the provider. Advantage: fewer firewall changes, preserves internal routing, and is often easier for legacy networks.

Choice depends on firewall rules, telemetry needs, and whether you need full application-layer filtering or simple reachability. Hybrid deployments — connectors for some apps, proxying for others — are common.

Step 2 — Prepare IdP and register apps (OIDC/SAML)

Make the IdP the single source of truth for application access:

  1. Create a client (OIDC) or service provider (SAML) entry per app or per gateway route. Use gateway redirect URIs; do not hard-code app endpoints.
  2. Enforce short token lifetimes and prefer refresh tokens with revocation capability. Where supported, enable Continuous Access Evaluation (CAE) to minimize token lifetime and accelerate revocations.
  3. Map claims and groups required by apps. Use attribute-based access control (ABAC) where possible to centralize policy at the IdP/gateway layer.
  4. Automate app registration where possible; repeatable IaC-style registration reduces human error during rollouts.

Step 3 — Decide on device binding: mTLS, FIDO/WebAuthn, or posture

Device binding is a key control. In 2026 you have three practical options — combine them where risk requires:

  • Device posture + conditional access: Use MDM/EMM (Intune, Jamf) to assert compliance and feed signals into the IdP. This is the most operationally flexible approach for managed devices.
  • mTLS (client certificates): Use SCEP/EST for automated provisioning from MDM and require gateway mTLS for high-risk apps. Certificate rotation and expiration automation is essential.
  • FIDO/WebAuthn attestation and ephemeral keys: Use hardware-backed WebAuthn credentials or attested keys to bind authentication to device hardware. When combined with attestation statements, these provide strong, phishing-resistant binding that works well in browsers supporting WebAuthn attestation.

Recommendation for 2026: start with posture + conditional access for scale, use mTLS selectively for high-assurance apps, and evaluate WebAuthn attestation and ephemeral keys as the long-term path to cryptographic device binding in browsers.

Step 4 — Configure the enterprise browser (detailed)

Enterprise browsers have matured: expect built-in hooks for SSO, certificate stores, and policy APIs. Key configuration steps:

  1. Enroll the browser via MDM or the vendor console. Use mandatory managed profiles for internal access so unmanaged copies cannot access intranet hostnames.
  2. Enable IdP SSO integration and configure silent SSO (system browser or OS-level federation) to reduce friction. Test across Windows, macOS, and mobile platforms.
  3. Configure client certificate rules and WebAuthn credential policies: map which hostnames should receive certs and which should prompt for FIDO registration. For mTLS flows, ensure the browser only exposes certs to the intended gateways.
  4. Set isolation and data-loss prevention policies: site-level isolation, clipboard controls, download restrictions, and forced navigation to secure-browser contexts for sensitive apps.
  5. Harden extension policy: block third-party extensions or allow a curated list. Manifest V3 and similar extensions frameworks help but enforce allowlists in the management console.

Step 5 — Gateway configuration and internal routing

Configure your ZTNA gateway to act as the enforcement plane:

  • Authenticate via IdP and map claims to policies. Enforce device posture or require mTLS/WebAuthn where applicable.
  • Apply application-level RBAC and least-privilege rules. Use short session lifetimes and require reauthentication for sensitive operations.
  • Proxy or connector logic: preserve original client IPs when needed (X-Forwarded-For) and be explicit about header handling to avoid leakage of internal headers or cookies.
  • DNS options: either expose internal names through your gateway or publish apps under externally resolvable hostnames routed internally. Gateways increasingly support internal name resolution via connectors.

Step 6 — App compatibility and minimal code changes

Many apps need little change when proxied. Watch for:

  • Kerberos/NTLM: these legacy flows often require special handling (delegation, constrained kerberos delegation) or temporary hybrid access via VPN. Identify such apps early.
  • Client IP reliance: logging or licensing tied to IPs requires coordination — preserve source IP when feasible or update logging to accept X-Forwarded-For trust chains.
  • Cookie and SameSite behavior: review cookie scope, domain, and SameSite flags when introducing a gateway that changes the domain or path surface.

Step 7 — Logging, monitoring, and audit (2026 priorities)

Centralized, correlated telemetry is the primary benefit of migrating off VPN. Implement:

  • Gateway logs to SIEM (Splunk, Elastic, Microsoft Sentinel) with user identity, device posture, action, and reason for denial.
  • Curated browser telemetry: managed event streams for policy enforcement, downloads, extensions, and FIDO/WebAuthn registrations. Balance observability with privacy — use hashed identifiers and minimize PII where possible.
  • Traceability across IdP, gateway, and application logs. Build a session reconstruction schema to support forensics and compliance requests.

Step 8 — Phased rollout and testing (recommended pattern)

  1. Pilot (2–4 weeks): Select a small set of non-critical apps and a cross-functional pilot group (help-desk, power users). Validate SSO, posture signals, browser config, and logging.
  2. Expanded pilot (4–8 weeks): Add more apps and business units; stress test peak load and connector scaling. Run simulated incident drills to verify revocation and CAE effectiveness.
  3. Cutover windows: schedule migrations per team; keep VPN as a controlled fallback for 1–2 weeks and monitor support metrics.
  4. Decommission: remove VPN routes and update documentation after stable operation and compliant logging are verified.

Step 9 — User experience and support

Good UX reduces help-desk load. Deliver:

  • Clear user documentation: sign-in flows, posture remediation steps (e.g., "Install Company Portal and ensure device is compliant").
  • Help-desk playbooks: posture failures, certificate expiry, browser enrollment errors, and connector troubleshooting.
  • Fallback for legacy access: time-limited VPN or bastion access for explicitly declared legacy apps, with a deprecation timeline.

Security and operational considerations (new 2026 tips)

  • Least privilege and ABAC: enforce attribute-based rules at the gateway; prefer short-lived and revocable tokens.
  • FIDO/WebAuthn: prefer hardware-backed attestation for high-security apps; combine attestation with posture checks.
  • Ephemeral session models: use ephemeral browser profiles or remote browser isolation for untrusted endpoints and BYOD.
  • Extension and supply-chain risk: block unmanaged extensions, monitor extension installs via browser telemetry, and enforce manifest restrictions.
  • Certificate lifecycle automation: automate issuance and renewal (SCEP/EST) and alert on expiry trends.

KPIs and success metrics (practical)

  • Reduction in VPN sessions to migrated apps (target: >90% of those apps moved off VPN).
  • User time-to-access and failure rates (compare pre/post migration).
  • Number of posture-related access denials and mean time to compliance remediation.
  • Mean time to resolve access-related support tickets and percent of tickets attributable to extension or browser issues.

Common mistakes and how to avoid them

  • Underestimating legacy auth: inventory Kerberos/NTLM apps early; plan delegation or maintain hybrid access for them.
  • Poor certificate and key management: automate provisioning/rotation and test renewals before rollout.
  • Insufficient cross-logging: ensure IdP, gateway, and app logs are correlated before cutting over.
  • Failing to control extensions: allowlist essential extensions and block the rest; extension abuse remains a common vector.
  • Inadequate BYOD strategy: deploy remote browser isolation for unmanaged devices to avoid exposing internal apps.

Example minimal timeline (updated for 2026)

  • Weeks 1–2: Detailed inventory, pilot app selection, architecture decisions and policy definitions.
  • Weeks 3–5: IdP registrations, ZTNA gateway setup, MDM posture policy deployment.
  • Weeks 6–8: Enterprise browser enrollment, certificate and WebAuthn pilot, logging pipelines to SIEM.
  • Weeks 9–12: Pilot testing, remediation, CAE and revocation drills.
  • Weeks 13–16: Phased rollout and VPN decommissioning for migrated apps; ongoing monitoring.

Conclusion

Shifting intranet web access from VPN to enterprise-browser-based access is now a practical, measurable step toward application-level zero trust. In 2026 the key enablers are mature ZTNA gateways, richer device-binding choices (mTLS, FIDO/WebAuthn attestation), improved browser management APIs, and better telemetry integration. Success hinges on a complete inventory, an IdP-first design, pragmatic use of posture and cryptographic bindings, and staged rollouts with robust logging. Use this guide as a checklist and adapt specifics to your vendor stack; the operational goals remain the same: reduce VPN reliance, preserve or improve user experience, and create auditable, revocable access controls.

Common mistakes

The single largest operational mistake teams make is treating this as a networking migration only — neglecting the IdP, browser policy, and logging changes until cutover. Address those three areas early.

Pro tips

  • Automate app and client registration using IdP APIs to avoid manual errors.
  • Use remote browser isolation for BYOD and contractors to avoid certificate sprawl.
  • Run periodic simulated revocations to validate CAE and token revocation paths.
  • Curate a minimal extension allowlist and enforce it via browser management.

FAQ

Do I need to use mTLS for all applications?

No. mTLS provides strong cryptographic device binding but adds operational overhead for certificate provisioning and rotation. The current best practice is to use posture-based conditional access for most apps and reserve mTLS for high-risk or regulatory-controlled applications. Consider FIDO/WebAuthn attestation as a modern alternative for device-bound authentication in browsers.

How do I support unmanaged/BYOD devices?

Use remote browser isolation (browser-as-a-service) or a secure managed browser container for BYOD. Isolation prevents sensitive content from being rendered in an unmanaged client and reduces the need for device certificates. Combine this with short-lived sessions and granular download restrictions.

What about legacy Kerberos/NTLM applications?

Kerberos and NTLM typically require delegation or preservation of existing on-prem flows. Options include constrained delegation configured on the gateway, a hybrid approach keeping limited VPN access for those apps during migration, or modernizing the app to support SSO via OIDC/SAML where feasible.

How do I verify I’ve preserved compliance and eDiscovery?

Ensure your gateway and browser telemetry export detailed logs to your SIEM with user, device, timestamp, and action context. Validate log retention, integrity, and the ability to reconstruct sessions across IdP, gateway, and app logs before decommissioning VPN paths.

Will enterprise browser telemetry violate user privacy?

Not if implemented correctly. Limit telemetry to the minimum fields needed for security and compliance, hash or pseudonymize identifiers where possible, and disclose telemetry practices to users. Use role-based access to telemetry in SIEM to restrict who can see sensitive details.