How to Give Remote and Third-Party Users Access to Internal Web Applications — Without a VPN

It usually starts with one request. A new vendor needs to reach the internal ticketing system. An auditor needs the finance portal for two weeks. A contractor needs the operations dashboard, but only that dashboard. A newly acquired team needs three of your internal apps and none of your network.

The default answer for twenty years has been "give them a VPN account." But a VPN account is the wrong-sized answer to an application-sized question — and increasingly, it's the answer that security teams, auditors, and cyber insurance carriers push back on. This guide covers why, what the per-application access pattern looks like, and how to publish an internal web application externally with MFA and identity policy enforced in front of it, without changing the application.

Why a VPN Is the Wrong Tool for App-Level Access

A VPN answers the question "how does this person join our network?" But the actual requirement was "how does this person reach one application?" That mismatch creates four concrete problems:

Network access instead of application access. A VPN credential typically lands the user on a network segment, not in an application. Unless your segmentation is unusually disciplined, the vendor who needed one dashboard can now probe everything else on that segment. Every security framework written in the last decade — from NIST's zero trust architecture to the NCSC's guidance — points the same direction: grant access to the resource, not the network.

Third-party onboarding friction. VPN clients need to be installed, configured, and supported on devices you don't manage. Contractors juggle a VPN client per client. MSPs juggle dozens. Every one of those installs is a support ticket on day one and an offboarding task everyone forgets on the last day — and a forgotten VPN account for a departed contractor is a standing credential into your network.

The VPN is itself a top attack target. Internet-facing VPN appliances have been among the most exploited devices in enterprise environments — VPN and remote-access gateway CVEs appear continuously in CISA's Known Exploited Vulnerabilities catalog, and several of the most damaging enterprise breach campaigns of recent years began at a VPN gateway. Concentrating all remote access through one appliance concentrates the blast radius there too.

Audit and insurance scrutiny. Cyber insurance questionnaires ask specifically about third-party remote access and whether MFA is enforced on it. "Vendors connect through the VPN" invites the follow-up questions: to what, with what privileges, and who reviews those accounts? "Vendors reach exactly one application through an identity-aware proxy, with MFA, and every session is logged" is a shorter conversation. We cover the underwriting side in MFA requirements for cyber insurance.

The Per-Application Access Pattern

The alternative is to publish the internal web application through an identity-aware reverse proxy:

1. The application stays where it is — on-premises, in a VPC, in a data center. Nothing about the app changes.
2. An access proxy is deployed in front of it and published externally on a hostname you control (for example, portal.yourcompany.com).
3. Every request must pass identity checks at the proxy — SSO, MFA, and access policy — before any traffic reaches the application.
4. The user gets a URL, not a network. They open a browser, authenticate, and reach the one application they were granted. There is nothing else to probe, no client to install, no network to join.

This is the core idea behind zero trust network access, scoped to where most of the actual need lives: browser-based applications. You don't need to re-architect your network or roll out a platform to every employee to solve the vendor-needs-one-app problem. You need identity enforcement in front of that app.

How Datawiza Publishes Internal Web Apps Securely

Datawiza Access Proxy is a reverse proxy that adds SSO, MFA, and granular access control in front of any web application — modern or legacy — without code changes. For remote and third-party access, two deployment patterns cover most cases:

Identity provider integration. Datawiza intercepts requests before the application's login page is exposed and redirects to your identity provider — Microsoft Entra ID, Okta, Ping, Auth0, or Duo. The IdP enforces SSO, MFA, and conditional access; Datawiza validates the session, applies application-level policy (by user, group, or attribute), and forwards approved identity context to the app. External vendors can be onboarded as guest users in your IdP, so their access is created, reviewed, and revoked in the same place as everything else — no orphaned VPN accounts.

Built-in MFA at the proxy layer. For an application with its own local username-and-password login and no IdP connection, Datawiza adds an MFA challenge after the user successfully signs in with their existing credentials, enforced before they can access the application. This is the fast path when the app's accounts can't move to the IdP yet.

In both patterns, every authentication and access event is logged centrally — the evidence trail for audits, insurance questionnaires, and third-party access reviews. Deployment is a routing change: point DNS at the proxy (hosted or self-hosted in your own environment), configure the upstream application, set policy. The application code is never touched.

When a VPN Is Still the Right Answer

Honest scoping matters. A VPN (or a full ZTNA platform) remains the right tool when the access is not browser-based: thick-client applications, RDP and SSH sessions, file shares, database connections, engineering tools that speak raw TCP. If your remote-access requirement is "developers need SSH to the build farm," that's not a web proxy problem.

The two patterns also compose. Many organizations keep the VPN for the network-level cases — with MFA enforced on it through Duo, Entra, or Okta — and move browser-based application access to the proxy pattern, shrinking the population that needs VPN accounts at all. Fewer VPN users means fewer VPN licenses, fewer unmanaged devices running your VPN client, and a smaller attack surface on the appliance everyone is trying to exploit.

VPN vs. Access Proxy for Web Application Access

Access granted

• VPN account: Network segment
• Datawiza Access Proxy: One application per policy

Third-party onboarding

• VPN account: Client install on unmanaged device, credentials, support
• Datawiza Access Proxy: A URL and an identity — guest user in your IdP or app credentials plus proxy MFA

Offboarding

• VPN account: Remember to disable the VPN account
• Datawiza Access Proxy: Disable the identity; access ends everywhere it was granted

MFA enforcement

• VPN account: At the tunnel; app access inside is often unchallenged
• Datawiza Access Proxy: At every application session

Audit trail

• VPN account: Connection logs (who joined the network)
• Datawiza Access Proxy: Per-application access logs (who reached what, when, challenged how)

Attack surface

• VPN account: Internet-facing appliance with network-wide blast radius
• Datawiza Access Proxy: Per-app enforcement point; nothing else published

Implementation Checklist

1. Inventory the remote-access requests from the last year. Separate browser-based application access from network-protocol access (RDP, SSH, file shares).
2. For the browser-based set, identify who needs each app: employees, contractors, vendors, auditors.
3. Choose the identity model: guest users in your existing IdP (cleanest lifecycle), or the application's own accounts with MFA enforced at the proxy.
4. Publish the first application through the access proxy on a dedicated hostname. Start with the app generating the most VPN requests.
5. Enforce MFA and group-based policy at the proxy. Test the full login path as an external user would experience it.
6. Move the app's users off VPN access and document the change — it strengthens the answer on your next insurance questionnaire and audit.
7. Repeat per application, and review who still genuinely needs a VPN account.

Frequently Asked Questions

How can remote users access an internal web application without a VPN?

Publish the application through an identity-aware reverse proxy. The proxy is exposed externally on a hostname you control, enforces SSO and MFA on every request, and forwards only authenticated, authorized traffic to the internal application. The user needs a browser and an identity — no VPN client, no network access.

Is it safe to expose an internal application to the internet this way?

The application itself is never directly exposed — only the enforcement point is. Every request must pass identity checks before any traffic reaches the app, which is a stronger position than an application sitting on a flat internal network reachable by every VPN user. The pattern is the application-access core of zero trust architecture.

How do we give a vendor or contractor access to one internal app only?

Add the vendor as a guest user in your identity provider and write a proxy policy granting that identity access to that one application. They receive a URL, authenticate with MFA, and can reach nothing else. When the engagement ends, disable the guest identity — there is no VPN account to remember.

Do we need a full ZTNA platform for this?

Not for browser-based applications. ZTNA platforms solve organization-wide access across all protocols and devices — a larger project with per-user pricing. If the problem is specific web applications needing secure external access, a per-app access proxy solves it without the platform migration, and can coexist with a VPN or ZTNA deployment for non-web access.

Does this work with Duo, Microsoft Entra ID, or Okta?

Yes. Datawiza integrates with Microsoft Entra ID, Okta, Ping, Auth0, and Duo — the identity provider handles SSO, MFA, and conditional access, and Datawiza enforces the application route. For apps that keep their own local login, Datawiza's built-in MFA adds the second factor at the proxy after the application's password login.

The Bottom Line

When the requirement is "this person needs this application," a VPN account grants too much, demands too much onboarding, and concentrates risk on the one appliance attackers target most. Publishing internal web applications through an identity-aware access proxy grants exactly what was asked for: one app, one identity, MFA on every session, and a log of all of it. Keep the VPN for the access that genuinely needs a network — and stop handing out networks when someone asked for an application.

To see the pattern in action, explore the MFA reverse proxy, MFA for web applications, and adding MFA to legacy apps without code changes.

If a vendor, auditor, or remote team needs access to an internal web application this quarter, book a demo to see how Datawiza publishes it securely — without a VPN and without changing the app.

Sources

• CISA Known Exploited Vulnerabilities Catalog
• NIST SP 800-207 Zero Trust Architecture
• NCSC Zero Trust Architecture guidance

Related ZTNA guidance

• modern ZTNA alternative explains the broader zero-trust access architecture behind the VPN-less pattern.
• clientless ZTNA covers the agentless model for browser-based application access.