Nous voyons encore beaucoup d’équipes IT s’appuyer sur le VPN, simplement parce que cela a toujours fonctionné. Alors que la manière dont les collaborateurs se connectent aujourd’hui à leurs applications a depuis longtemps dépassé ce pour quoi le VPN a été conçu. Dans cet article, Jan Claes, Business Lead Azure et Senior Azure Cloud Architect chez Xylos, vous explique en profondeur, sur le plan technique, pourquoi l’identité a remplacé le réseau comme véritable périmètre de sécurité. Et ce qui change concrètement lorsque vous échangez votre VPN contre Microsoft Entra Private Access. Cet article s’adresse aux IT managers et aux architectes qui veulent en comprendre le fonctionnement.

Des identifiants VPN compromis étaient à l’origine de 48 % des attaques par ransomware au T3 2025 (Beazley Security, via HIPAA Journal). Mandiant a par ailleurs constaté que dans environ un tiers des incidents de ransomware traités par l’entreprise en 2025, l’accès initial passait par l’exploitation de vulnérabilités, le plus souvent sur des VPN et des pare-feu courants.

La façon dont les gens travaillent, partout, sur n’importe quel appareil, à toute heure, est précisément ce pour quoi votre périmètre n’a jamais été conçu.

Le modèle traditionnel était un château. Tout ce qui avait de la valeur se trouvait à l’intérieur des murs : les serveurs, les données, les collaborateurs à leur bureau. Le pare-feu était la douve, le VPN le pont-levis, et quiconque franchissait le pont était digne de confiance. Cette logique tenait, parce que ce qui valait la peine d’être protégé se trouvait effectivement dans le bâtiment. Puis le bâtiment s’est vidé. Les gens travaillent aujourd’hui de chez eux, depuis l’aéroport, depuis un café, sur un iPad, à l’heure qui leur convient, sur des appareils qui n’appartiennent pas toujours à leur employeur. Le périmètre n’a pas été percé, il s’est dissous. Et dès lors que vos utilisateurs et vos données ne se trouvent plus à l’intérieur des murs, défendre ces murs ne protège plus rien. La seule chose qui accompagne chaque requête, quel que soit l’appareil ou le lieu, c’est l’identité de l’utilisateur. C’est pourquoi l’identité est aujourd’hui le périmètre, et non le réseau.

Un VPN accorde sa confiance au réseau. Le Zero Trust donne accès à une application. Cette différence n’est pas sémantique, elle est fondamentale : un modèle de sécurité entièrement différent.

Un VPN vieillissant ne réduit pas votre château pour l’adapter à la nouvelle réalité, au contraire. Il étend « l’intérieur » jusqu’à chaque ordinateur portable distant. Dès qu’un appareil se connecte, il devient en pratique un nœud de votre réseau interne, avec une large voie directe vers votre infrastructure.

Figure 1 : un seul tunnel authentifié donne un accès large au réseau interne.

Les conséquences sont structurelles, pas accidentelles :

• Mouvement latéral. Une seule victime de phishing ou un seul portable compromis suffit : l’attaquant n’atteint pas une application, il atteint le réseau et se déplace de là vers la cible suivante.

• Autoroute pour le ransomware. Cette même portée large est exactement la manière dont un ransomware se propage d’un seul terminal vers les partages de fichiers, les serveurs et les sauvegardes.

• Contrôle au niveau du réseau, pas par application. Le VPN vous vérifie une fois, à la périphérie, puis vous fait entièrement confiance. Il sait que « cet appareil est sur le réseau », mais pas quelle application vous demandez, si cet utilisateur doit y avoir accès, ni si l’appareil est sain.

• Une cible en soi. Les équipements VPN et pare-feu exposés à internet comptent parmi les appareils les plus exploités en ligne, avec chaque année de nouvelles vulnérabilités chez pratiquement tous les grands fournisseurs, permettant aux attaquants de contourner l’authentification.

Donner un tunnel VPN à chaque portable distant, ce n’est pas fermer une porte à clé. C’est envoyer la clé de tout le bâtiment à quiconque se connecte.

Dites à un IT manager qu’il doit publier une application sur internet et il recule : cela semble dangereux. Placez les deux modèles côte à côte. Une application web derrière un VPN est protégée par un seul contrôle : êtes-vous parvenu sur le réseau ? Ensuite, le VPN vous fait entièrement confiance. Cette même application, publiée via Entra ID, est contrôlée à nouveau à chaque requête. Le Single Sign-On avec MFA constitue la base, complété par le Conditional Access qui évalue l’utilisateur, l’appareil, la localisation et le risque de connexion. L’appareil doit en outre être géré et conforme, et les mots de passe cèdent la place à des passkeys résistantes au phishing.

Figure 2 : la publication pilotée par l’identité évalue chaque requête ; aucun tunnel VPN n’est nécessaire.

Correctement publié et piloté par l’identité, c’est au moins aussi sûr qu’un VPN, et souvent davantage.

Les applications web sont le cas facile. La vraie valeur se trouve dans tout ce que vous ne pouvez pas publier tel quel : les applications client-serveur vieillissantes, les partages de fichiers SMB, le RDP, l’ancien ERP qui ne parlera jamais l’authentification moderne. C’est précisément là qu’un VPN semble inévitable, et précisément là que Microsoft Entra Private Access, le composant ZTNA de la suite Global Secure Access (SSE), le remplace pleinement.

Figure 3 : Entra Private Access, un connecteur qui n’établit que du trafic sortant, avec un accès par application basé sur l’identité.

• Trafic sortant uniquement. Un connecteur léger dans votre réseau n’ouvre que des connexions sortantes vers le service. Vous n’ouvrez plus de ports depuis internet vers vos serveurs ou votre DMZ, il ne reste rien d’entrant à attaquer.

• Par application, pas par réseau. Chaque ressource devient sa propre application d’entreprise dans Entra, avec un Conditional Access par application, adapté à sa criticité, et un accès par application aussi bien pour TCP que pour UDP. Least privilege dès la conception.

• Transparent pour les utilisateurs. Le client Global Secure Access tourne discrètement en arrière-plan : plus de rituel de connexion, plus d’étape « connectez-vous au VPN ». La ressource semble simplement présente, tandis que l’accès est géré par un identity provider moderne.

Et vous ne devez pas tout aborder d’un coup. Commencez par Quick Access pour reproduire la portée de votre VPN et détacher les utilisateurs de l’ancien client, utilisez Application Discovery pour voir ce que les gens utilisent réellement, puis transformez cela en applications d’entreprise par application avec leur propre Conditional Access. Le VPN sort, le Zero Trust entre, vague après vague.

C’est exact, et c’est une remarque légitime. Le Zero Trust Network Access est une catégorie mature, avec des acteurs solides et spécialisés : Zscaler Private Access, Palo Alto Prisma Access, Cloudflare Access et Netskope, pour n’en citer que quelques-uns. Certains sont excellents et, pour les organisations avec un paysage multicloud marqué ou un investissement existant dans l’une de ces plateformes, ils restent un choix légitime. Il ne s’agit pas de plaider que Microsoft est la seule voie vers le ZTNA. Il s’agit de ce que vous avez déjà en interne. Si votre organisation tourne sur Entra ID et Microsoft 365, ce qui est le cas de la plupart, alors la couche d’identité, le moteur de policy et l’expérience d’administration pour le Zero Trust se trouvent déjà dans votre tenant. Entra Private Access n’est pas une nouvelle plateforme à implémenter, c’est une fonctionnalité que vous activez :

• Le même identity provider. Les décisions d’accès utilisent le même Entra ID, les mêmes utilisateurs et groupes, et la même policy Conditional Access que vous utilisez déjà pour Microsoft 365. Une solution ZTNA tierce implique d’intégrer son modèle de policy à votre identité : un système de plus à garder synchrone.

• La même console, la même équipe. Vous le gérez depuis l’Entra admin center où votre équipe travaille déjà au quotidien : rien de plus à apprendre, à staffer ou à certifier.

• Un seul client, un seul agent. Le client Global Secure Access est un seul agent Microsoft, sans logiciel fournisseur supplémentaire qui viendrait concurrencer votre stack de sécurité existante pour les ressources du terminal.

• Un seul contrat. La licence est comprise dans votre accord Microsoft : pas d’achat distinct, pas de nouveau cycle de renouvellement, pas de relation de support supplémentaire.

Chaque fournisseur supplémentaire que vous ajoutez est un point d’intégration de plus, une surface d’attaque de plus, une facture de plus et une ligne de support de plus. L’architecture la plus défendable est généralement celle qui compte le moins de pièces mobiles. Et si vous avez déjà un environnement Microsoft, cela revient surtout à utiliser la plateforme d’identité sur laquelle vous vous êtes déjà standardisé. En tant que partenaire Microsoft, nous voyons chaque fois le même schéma : le choix de Microsoft ne vient pas d’une loyauté de marque, mais du fait que la fonctionnalité se trouve déjà dans votre tenant, prête à être activée.

1. Inventoriez le paysage d’accès : cartographiez quelles ressources sont accessibles via le VPN, par qui, et à quel point chacune est sensible. Vous ne pouvez pas sécuriser ce que vous ne voyez pas.

2. Faites d’Entra ID + MFA la porte d’entrée : activez le MFA pour chaque identité, y compris les administrateurs et les comptes de service, et désactivez les protocoles d’authentification obsolètes.

3. Déployez le client GSA avec Quick Access : il reproduit la portée du VPN, ce qui vous permet de valider la connectivité et de faire passer les utilisateurs sur le nouveau client sans perturbation.

4. Segmentez en applications par application : utilisez Application Discovery pour transformer l’accès large en applications d’entreprise individuelles, chacune délimitée pour les bons utilisateurs avec son propre Conditional Access.

5. Supprimez progressivement le VPN : une fois l’ensemble du portefeuille migré, vous retirez le concentrateur du service. La boîte la plus exploitée de votre périmètre cesse tout simplement d’exister.

Ce dont vous avez besoin et ce que cela coûte.

Prérequis : Microsoft Entra ID P1 ou P2. Attention : Microsoft 365 E5 contient bien P2, mais pas Private Access, une surprise budgétaire fréquente.

Choisissez ensuite : un add-on Entra Private Access séparé (prix indicatif 4,30 € par utilisateur/mois), ou la suite Entra complète (10,40 € par utilisateur/mois, avec engagement annuel), qui associe Private Access à Internet Access, ID Governance, ID Protection et Verified ID.

Les prix indicatifs ne servent que de repère budgétaire. Confirmez les prix actuels pour votre région et votre accord. Rapporté aux coûts de licence, de matériel et d’exploitation d’un VPN vieillissant, le calcul penche généralement en faveur de la consolidation.

Le Zero Trust est une architecture que l’on adopte. Entra ID, Conditional Access et Global Secure Access la rendent opérationnelle, sans devoir relier entre elles des solutions ponctuelles d’une douzaine de fournisseurs. La question pour chaque IT manager n’est donc pas « notre VPN fonctionne-t-il encore ? » Elle est plus difficile : sommes-nous réellement sûrs dans la manière dont nous livrons nos applications à nos utilisateurs ? Soutenons-nous la façon dont les gens travaillent réellement aujourd’hui : partout, sur n’importe quel appareil, à tout moment ? Continuez-vous à défendre un château dont les murs se sont effondrés il y a des années ? Si cette question vous fait réfléchir, une conversation en vaut la peine.

Nous aidons les organisations à supprimer progressivement leurs VPN vieillissants et à passer à un accès basé sur l’identité avec Entra Private Access, assessment et déploiement par phases inclus.

Planifiez un secure access assessment avec notre équipe.