VPN vs ZTNA : pourquoi les DSI doivent repenser l'accès distant en 2026 

Failles critiques en série, directives d’urgence des agences de cybersécurité, campagnes de ransomware alimentées par des identifiants VPN dérobés : le premier semestre 2026 a placé l’accès distant au sommet des priorités des DSI. Au-delà des correctifs à appliquer dans l’urgence, ces incidents posent une question de fond : le modèle même du VPN, qui repose sur l’exposition d’un point d’entrée sur Internet, est-il encore adapté ? Le Zero Trust Network Access (ZTNA), et en particulier son approche universelle, propose une réponse architecturale à ce problème structurel. Décryptage. 

Le VPN, un modèle qui a rendu service mais qui atteint ses limites 

Pendant plus de vingt ans, le VPN a été la réponse standard à l’accès distant : un portail d’authentification exposé sur Internet, qui ouvre après connexion un tunnel chiffré vers le réseau de l’entreprise. Ce modèlea parfaitement fonctionné dans un monde où les utilisateurs étaient majoritairement au bureau et les applications dans le datacenter. 

Ce monde n’existe plus. Télétravail généralisé, applications réparties entre datacenters et clouds, multiplication des prestataires et des équipements non gérés : les flux à sécuriser se sont diversifiés, et avec eux les briques empilées au fil des années — VPN pour les collaborateurs, bastion pour les administrateurs, reverse proxy pour les tiers. Chaque brique ajoute de la complexité opérationnelle, et surtout une surface d’exposition supplémentaire. 

2026 : la démonstration par les faits

L’actualité récente illustre concrètement cette fragilité. Selon le rapport DBIR 2026 de Verizon, qui analyse plus de 22 000 brèches, l’exploitation de vulnérabilités est désormais le premier vecteur d’accès initial des attaquants. Et les équipements d’accès distant exposés en sont la cible privilégiée : 

• Un contournement d’authentification (CVSS 9.8) sur une passerelle SSL-VPN parmi les plus déployées du marché. La faille permettait à un attaquant non authentifié de franchir la page de connexion et d’obtenir un accès réseau. Environ 47 000 équipements étaient exposés sur Internet ; l’agence américaine CISA a émis le 26 février 2026 une directive contraignante imposant de corriger ou de désactiver les services concernés sous 72 heures. 

• Une campagne de vol d’identifiants à grande échelle (juin-juillet 2026). Environ 74 000 identifiants de firewalls et de VPN volés en circulation et au moins 12 organisations touchées par des ransomwares déployés via des équipements compromis, selon SOCRadar. Fait notable : cette campagne ne reposait sur aucune vulnérabilité inédite — la simple existence d’un portail de connexion exposé suffisait à en faire une cible pour le rejeu d’identifiants et la force brute. 

• Une vulnérabilité critique exploitée en moins de 24 heures. Fin juin 2026, une faille touchant une passerelle d’accès distant largement répandue a été exploitée dans les 24 heures suivant sa divulgation publique, d’après Lupovis — quelques semaines après l’inscription de deux autres failles du même équipement au catalogue KEV (vulnérabilités activement exploitées) de la CISA. 

• Une exécution de code à distance avec privilèges root (CVSS 10.0). Une injection de commandes pré-authentification sur une passerelle de mobilité d’entreprise, activement exploitée et inscrite au catalogue KEV le 11 juin 2026, avec un code d’exploitation public et des instances compromises confirmées par la Shadowserver Foundation. 

• Un contournement d’authentification via des configurations VPN dépréciées. Sur une autre passerelle de sécurité majeure, des configurations d’échange de clés obsolètes (IKEv1) permettaient d’établir des connexions VPN non autorisées, avec des liens observés vers un affilié du ransomware Qilin. 

Précisons-le : ces incidents ont touché plusieurs éditeurs majeurs et reconnus, qui corrigent, publient des avis de sécurité et coopèrent avec les agences. Le sujet n’est pas le sérieux de tel ou tel acteur. Plusieurséquipements de premier plan, un même schéma d’attaque : c’est le signe d’un problème de modèle, pas de fournisseur. 

Pourquoi les architectures d’accès historiques sont structurellement fragiles

Les architectures d’accès traditionnelles reposent sur des hypothèses que le contexte actuel remet en cause. Quatre limites structurelles ressortent des incidents de 2026 : 

• Une surface d’attaque exposée par conception. Un VPN doit écouter sur Internet pour que les utilisateurs s’y connectent. Cette page de connexion est identifiable par un simple scan, et chaque nouvelle vulnérabilité transforme instantanément des dizaines de milliers d’équipements en cibles. 

• Un accès réseau plutôt qu’un accès applicatif. Une fois le tunnel établi, l’utilisateur — ou l’attaquant qui a dérobé ses identifiants — accède à un segment de réseau, souvent peu cloisonné. C’est le point de départ des mouvements latéraux qui précèdent le déploiement d’un ransomware. 

• Une dépendance critique à la vitesse de patching. Quand une vulnérabilité est exploitée en moins de 24 heures et que les agences imposent des correctifs sous 72 heures, faire reposer la sécurité de l’accèsdistant sur la réactivité des équipes devient un pari difficile à tenir dans la durée. 

• Un empilement coûteux à opérer. VPN, bastion, reverse proxy : autant de solutions à administrer, à maintenir et à corriger, avec autant de surfaces d’exposition que de briques. 

Le ZTNA : inverser la logique d’accès

Le Zero Trust Network Access repose sur un renversement simple : plus personne n’entre dans le réseau ; ce sont les applications qui sont publiées, une à une, vers des utilisateurs vérifiés en continu. Trois principes en découlent : 

• Ne jamais faire confiance par défaut. L’identité, le terminal et le contexte sont vérifiés à chaque requête, et non une seule fois au montage du tunnel. 

• Le moindre privilège applicatif. L’utilisateur accède à son application, jamais au réseau. Un identifiant volé n’ouvre rien à lui seul, et n’ouvre jamais tout. 

• L’invisibilité. Ce qui n’est pas exposé ne peut être ni scanné, ni attaqué. 

C’est ce dernier point qui répond directement à la vague de vulnérabilités de 2026 — et c’est aussi sur ce point que les implémentations ZTNA diffèrent le plus entre elles. 

L’approche universelle : le U-ZTNA d’Ekinops

Le U-ZTNA (Universal ZTNA) d’Ekinops applique la logique Zero Trust jusqu’au bout de l’architecture, sur le modèle SDP (Software Defined Perimeter). 

Aucun port entrant, nulle part

Les connecteurs U-ZTNA établissent des connexions exclusivement sortantes : ni portail de connexion, ni interface d’administration, ni service à l’écoute sur Internet. Pour un scanner, un botnet ou un rejeud’identifiants volés, il n’y a rien à trouver. Les deux premières étapes du schéma d’attaque observé en 2026 — scanner Internet, puis attaquer le service exposé — n’ont plus de cible. Et contrairement à une idée reçue, cela vaut aussi en déploiement on-premise : même hébergés dans le périmètre de l’entreprise, les connecteurs sortent, ils n’écoutent pas. 

Un accès par application, jamais au réseau

L’identité, la posture du terminal et le contexte sont vérifiés en continu, à chaque requête, en intégration avec le fournisseur d’identité et le MFA existants de l’entreprise. Même un compte compromis n’atteintqu’une application : le rayon d’impact est contenu par construction. 

Universel, pour simplifier l’existant

Un seul modèle d’accès couvre les usages qui imposaient hier l’empilement VPN, bastion et reverse proxy : collaborateurs en mobilité, prestataires, BYOD, environnements OT — sur tout appareil, partout. L’accèsagentless avec bastion SSH/RDP intégré et enregistrement de session couvre les cas où le déploiement d’un agent n’est pas possible. 

La maîtrise des données et la conformité

Déploiement as-a-service, dédié ou 100 % on-premise : les données comme les clés de chiffrement restent sous le contrôle de l’organisation. Solution conçue, développée et hébergée en Europe, non soumise aux lois extraterritoriales comme le Cloud Act, elle s’inscrit dans les exigences du RGPD et accompagne la mise en conformité NIS2 et DORA. 

Une migration progressive 

U-ZTNA coexiste avec les firewalls et le VPN en place, application par application, sans remplacement brutal. Les DSI peuvent migrer d’abord les accès les plus sensibles — administration, prestataires, applications critiques — et réduire progressivement leur surface exposée, à leur rythme. 

Ce qu’il faut retenir

Là où le VPN expose un portail de connexion scannable et accorde un accès réseau après une vérification unique, le ZTNA universel ne présente aucun port entrant, accorde un accès limité à l’applicationdemandée et vérifie l’identité, le terminal et le contexte en continu. La dépendance à la course au patch s’en trouve fortement réduite : il n’y a plus de service exposé à corriger dans l’urgence. Et là où l’accèsdistant reposait sur un empilement de solutions, un modèle unique couvre collaborateurs, administrateurs, prestataires et environnements OT. 

Soyons précis : aucune architecture ne garantit l’immunité absolue, et il serait malhonnête de le prétendre. Des risques résiduels demeurent — compromission d’un poste de travail, attaque visant le fournisseurd’identité — et sont traités par la vérification continue et le moindre privilège. Mais la mécanique qui a marqué 2026 — scanner Internet à la recherche d’un portail, exploiter la vulnérabilité du jour ou rejouer des identifiants volés, puis se déplacer latéralement — n’a pas de prise sur une architecture sans exposition : on ne peut pas compromettre ce que l’on ne peut pas atteindre. 

Pour les DSI, la question n’est donc plus de savoir si la passerelle d’accès distant fera l’objet de la prochaine vulnérabilité critique, mais si le modèle d’accès de l’organisation doit continuer à dépendre de cetteéventualité. Le ZTNA universel offre une voie de sortie pragmatique : progressive, réversible et alignée avec les exigences réglementaires européennes. 

Sources externes citées 

Verizon DBIR 2026 ; CISA (catalogue KEV — Known Exploited Vulnerabilities — et directive opérationnelle contraignante du 26/02/2026) ; SOCRadar ; Lupovis ; Shadowserver Foundation.