
Table of contents
Contractors, vendors, suppliers, auditors, implementation partners, and other third parties often need access to one or two business applications. They usually do not need broad network access.
VPNs still have a place, especially when users need private network access across many protocols. But for third-party access to browser-based business applications, VPN can be more access than the use case requires.
The Problem With Giving Contractors VPN Access
The issue is not that VPN is insecure by definition. The issue is fit. A contractor may need a single web application, while VPN gives them network reachability that has to be constrained, monitored, and supported.
- Contractors may only need one web app, but VPN can expose network paths beyond that app.
- External users may not be on managed devices or standard corporate endpoint controls.
- VPN clients create onboarding, installation, certificate, and help desk overhead.
- Shared vendor accounts make it harder to prove who accessed what.
- MFA at the VPN layer does not always create app-level evidence for each protected application.
- Access reviews become harder when network access and application access are mixed together.
A Better Pattern: Publish Only the Web App
For browser-based applications, an identity-aware proxy can sit in front of the app and enforce access before the user reaches it. The contractor reaches the proxy, completes authentication and MFA, passes policy, and is then forwarded only to the approved application.
This keeps the access decision close to the application instead of granting broad network reachability first and trying to narrow it later.
Three Identity Options for Third-Party Access
Contractor and third-party access is rarely one-size-fits-all. Some users belong in your corporate IdP; others should not.
Use your existing IdP when appropriate
If a contractor, partner, or vendor is already managed in Microsoft Entra ID, Okta, Ping, or another enterprise IdP, Datawiza can use that IdP for SSO, MFA, and conditional access.
Use built-in MFA for existing app users
If contractors already have application accounts and you do not want to migrate them into a CIAM or corporate IdP, Datawiza can detect the application login and enforce built-in MFA before access is granted.
Use a dedicated IdP for contractors and third parties
Datawiza can also provide a dedicated IdP for contractors and third parties when you want a separate external identity store without onboarding those users into your corporate IdP.
What Contractors Actually Need
- App-level access to the specific portal, admin app, ERP page, SharePoint site, or internal web application they are authorized to use.
- MFA or 2FA before access, with the right policy for the risk of the application.
- Flexible identity: corporate IdP, built-in MFA with existing app credentials, or a dedicated contractor IdP.
- Audit evidence that shows who accessed which application and when.
When This Is Better Than VPN
This pattern is usually a better fit when the access target is a web application, not a full private network.
- You want contractors to access one or a few browser-based applications.
- You do not want to install VPN clients on unmanaged external devices.
- You want to avoid giving third parties broad network reachability.
- You need MFA for legacy, custom, ERP, portal, or SharePoint applications that cannot be rewritten.
- You need application-level logs for audits, insurance, or access reviews.
VPN or ZTNA may still be the better answer for SSH, RDP, database access, developer network access, or non-web protocols. The identity-aware proxy pattern is strongest for HTTP and HTTPS applications.
Example Use Cases
- Supplier portals and vendor portals.
- Customer portals and partner applications.
- Contractor admin portals and temporary project access.
- Auditor access to internal reporting applications.
- Vendor access to ERP, maintenance, or support systems.
- SharePoint, intranet, and legacy web applications.
How Datawiza Helps
Datawiza Access Proxy provides app-level access for existing web applications. It can run in your environment, sit in front of the application, and add modern authentication controls without changing application code. It is also part of the broader ZTNA alternatives for web application access pattern.
- Add SSO and MFA to existing web applications without rewriting login.
- Use Entra ID, Okta, Ping, Cisco Duo, Google Identity, Auth0, or another IdP when useful.
- Use built-in MFA when contractors should keep existing application credentials.
- Use Datawiza’s dedicated IdP when third parties need a separate identity store.
- Keep access at the application layer instead of opening broader network paths.
- Collect per-application access logs for reviews and audits.
Frequently Asked Questions
Is Datawiza a full VPN replacement?
Not for every use case. Datawiza Access Proxy is designed for HTTP and HTTPS web applications. VPN may still be needed for broad private network access or non-web protocols.
Can contractors use existing application accounts?
Yes. Datawiza can enforce built-in MFA after the existing application verifies the user, so contractors can keep the app accounts they already use.
Can Datawiza provide a dedicated IdP for contractors?
Yes. Datawiza can provide a dedicated IdP for contractors and third parties when you do not want to place external users inside your corporate IdP.
What is the main benefit over VPN?
The main benefit is narrower access. Contractors reach the approved web application through an access layer instead of receiving broader network reachability first.
Conclusion
For third-party access to web applications, the cleanest answer is often not more VPN. It is app-level access with MFA, flexible identity, and logs in front of the application. Schedule a demo to review your contractor and vendor access pattern.



