Services
Overview Cybersecurity solutions Penetration testing SOC Digital forensics & incident response Audit & Advisory GRC Security awareness & training Social engineering IT staffing & placement
Partners
Use cases
Overview Infrastructure & network Unified secure network Industrial infrastructure Wi-Fi network Zero Trust access (ZTNA) Cloud & identity Microsoft 365 / Azure migration Privileged access (PAM) Active Directory Corporate email Detection & response Detection capability (SOC) Responding to a compromise Vulnerability management Compliance & resilience Preparing for ISO 27001 ICT Minimum Standard DORA regulation Business continuity (BCP/DRP) Human factor Reducing human risk
Clients
Company
About Certifications Careers CSR commitments
Contact
FRENDE
Zero Trust access

Replacing the VPN with Zero Trust access

The VPN was designed to extend the office network to people's homes. It does badly a job it was never asked to do: giving dozens of people, devices and contractors measured access to a handful of applications. Here is how we replace it, without touching the rest of the network.

The challenge

The problem is not the tunnel, it is what it opens

A VPN authenticates once, then places the user on the network. From there, what is reachable depends on internal filtering — which, in practice, means a great deal. A compromised personal device, a contractor account whose password has leaked, and the attacker is in the same position as an employee sitting in the office.

On top of that come everyday problems: the concentrator becomes a mandatory bottleneck that saturates at peak times, SaaS applications travel needlessly through headquarters, and nobody can say precisely who accessed what.

The Zero Trust model reverses the rule: nothing is reachable by default, access is granted resource by resource, on every connection, checking identity and device posture. Our role is to run that shift gradually, keeping the VPN as a fallback until the new path has proved itself.

What is at stake
  • One compromised remote access opens the whole network
  • Personal and contractor devices unmanaged on the internal network
  • Concentrator saturated at peak times
  • No fine-grained record of who reached which application
  • Contractor accounts still live long after the assignment ends
Diagram

An open tunnel, or a decision per resource

VPN and Zero Trust access: what each one opens VPN one tunnel, then the network Zero Trust access one decision per resource UserUser ApplicationsServersThe restApplicationServerOut of scope authenticated once, reachable thereafteridentity and device posture checked on every access
The VPN authenticates and then leaves the network reachable; Zero Trust evaluates identity and device posture on every request, and opens only the resource concerned.
Our approach

How we proceed

A shift in waves, application by application, with the VPN kept as a fallback throughout.

01

Inventory of usage

Who connects remotely, to which applications, from which devices — managed or not. That list, not the number of users, is what sizes the project.

02

Access policies

Defining the rules per resource: which groups, which identity conditions, which requirements on device posture (encryption, patching, active protection), and what stays outside the perimeter.

03

Deploying the access broker

Putting the ZTNA component in place and connecting it to the directory and to strong authentication, without exposing the applications directly on the Internet.

04

Migration in waves

Moving over application by application, starting with a pilot group. The VPN stays available as a fallback; it is withdrawn only once the last wave has passed and proved itself.

05

Control and operations

Validating the policies through a penetration test, connecting the logs to monitoring, and reviewing access periodically — contractor access in particular.

Services involved

Several disciplines, a single point of contact

Designing the policies, deploying the component and checking that it holds: the design and its offensive validation are carried out by the same team.

Cybersecurity solutions Penetration testing SOC Audit & Advisory GRC
Deliverables
  • Inventory of remote access and the applications concerned
  • Documented access policies, resource by resource
  • Zero Trust access broker deployed and connected to the directory
  • Plan for the migration waves and for withdrawing the VPN
  • Penetration test report on the new arrangement
Frequently asked questions

Frequently asked questions

No, and that is the point of the approach. ZTNA sits in front of the applications without changing the existing segmentation. It is an access project, not an infrastructure project — it can in fact precede a network overhaul and simplify it.

They are handled explicitly rather than tolerated. Depending on the resource, you can require a managed device, allow read-only access, or route through an isolated environment. That is precisely what a VPN cannot express.

Yes. Some needs — network administration, legacy protocols, industrial sites — sit awkwardly with ZTNA. The aim is to reduce the VPN to those residual cases, not to remove it on principle.

The pilot is in place within a few weeks. The full migration depends on the number of applications and on the pace your teams can absorb: we break it into waves so that none of them is blocking.

Does your VPN open more than it needs to?

An inventory of remote access is enough to measure the gap between what is open and what should be.

Contact us