Le déclic n’est pas venu d’une attaque.
Il est venu d’un ordinateur posé sur une table.
Notre freelance venait de terminer sa mission. Son compte Google Workspace était désactivé. Ses accès clients avaient été retirés. Son gestionnaire de mots de passe professionnel ne synchronisait plus rien.
Sur le papier, l’offboarding était terminé.
Puis quelqu’un a demandé :
« Et le VPN ? »
Silence.
Le mot de passe du VPN lui avait été transmis trois mois plus tôt.
Je savais que nous pouvions le changer. Ce n’était pas difficile.
Ce qui me dérangeait était tout ce que ce simple changement impliquait : modifier le secret, prévenir les autres membres de l’équipe, mettre à jour le coffre partagé, vérifier les ordinateurs qui allaient soudain cesser de se connecter.
Nous avions passé du temps à centraliser les identités, imposer la double authentification sur les services importants et retirer proprement les utilisateurs lorsqu’ils partaient.
Et au milieu de tout ça, notre VPN fonctionnait encore comme une clé copiée pour chaque personne qui en avait besoin.
C’est ce soir-là que j’ai recherché :
VPN professionnel SSO MFA.
Je pensais que la réponse serait simplement une liste de services compatibles avec Microsoft Entra ID, Google, Okta ou un autre fournisseur d’identité.
Cette réponse existe.
Mais elle ne résolvait qu’une partie de mon problème.
Résumé de l’article et adéquation du produit
Une petite équipe a-t-elle besoin de SSO et MFA, ou surtout de supprimer le compte VPN partagé ?
Si le cahier des charges exige des identités nominatives, un fournisseur d’identité central, des politiques MFA, une révocation administrée et des traces d’audit, il faut choisir un VPN professionnel conçu pour le SSO et le MFA. Mais dans une petite équipe où le vrai problème est un mot de passe VPN collectif, supprimer ce secret partagé peut simplifier l’onboarding et surtout l’offboarding avant d’ajouter une nouvelle couche IAM.
Points clés et limites
- Quand SSO + MFA sont indispensables : Organisation avec IdP central, comptes nominatifs, exigences d’audit, provisioning, révocation centrale ou politiques d’authentification imposées.
- Problème distinct : Le MFA renforce une identité, mais ne résout pas le fait qu’une même identité soit partagée entre plusieurs personnes.
- Quand OnlydogVPN correspond au récit : Uniquement pour une petite équipe qui veut relier un appareil par code de vérification sans distribuer un identifiant VPN permanent, alors que les autres systèmes continuent à gérer les autorisations.
- Limite importante : OnlydogVPN ne remplace pas Entra ID, Okta, SAML/OIDC, une console IAM, des politiques MFA administrées ou les exigences d’audit d’une entreprise structurée.
Sources présentes dans l’article : ANSSI / MonServiceSécurisé — ProConnect et MFA ; ANSSI — référentiel de mesures sur les accès et l’authentification ; NordLayer — documentation SSO et MFA ; CISA — recommandation d’authentification multifacteur.
En 2026, demander SSO et MFA pour un accès professionnel est devenu parfaitement normal
En France, les services professionnels vont clairement vers une authentification plus centralisée et plus forte.
Depuis mars 2026, MonServiceSécurisé passe par ProConnect, le système d’authentification commun destiné aux professionnels utilisant les services numériques de l’État. La double authentification devient obligatoire lorsque le fournisseur d’identité utilisé la prend en charge.
L’ANSSI recommande elle aussi l’authentification multifacteur pour les accès sensibles ou distants et encourage l’utilisation du SSO lorsqu’il permet d’éviter la multiplication de secrets secondaires.
Le principe est facile à comprendre.
Le SSO ressemble à l’accueil d’un immeuble : je prouve mon identité à un endroit central, puis les services autorisés savent qui je suis.
Le MFA ajoute une seconde vérification : connaître le mot de passe ne suffit plus.
Et lorsqu’un salarié quitte l’entreprise, on désactive son identité centrale au lieu de courir après chaque compte un par un.
Pour une entreprise de cinquante ou cinq cents personnes, c’est exactement l’architecture que je voudrais.
Certains VPN professionnels sont d’ailleurs conçus autour de cette logique.
Si votre cahier des charges dit « SSO + MFA », il faut prendre cette exigence au sérieux
NordLayer, par exemple, documente le SSO avec Google, Microsoft Entra ID, Okta, OneLogin et JumpCloud. Le service permet aussi de gérer l’authentification à deux facteurs dans l’environnement de l’organisation.
Si mon cahier des charges disait :
- chaque utilisateur doit posséder une identité nominative ;
- le VPN doit être relié à notre fournisseur d’identité ;
- l’équipe informatique doit pouvoir imposer les méthodes d’authentification ;
- le départ d’un salarié doit couper son accès depuis une console centrale ;
- ces contrôles doivent entrer dans nos procédures d’audit ;
je choisirais ce type de solution.
Je n’essaierais pas de remplacer un véritable système IAM par une astuce plus légère.
Mais notre équipe comptait sept personnes permanentes, avec des développeurs, designers ou consultants qui entraient pour quelques jours ou quelques semaines.
Notre identité professionnelle gérait déjà Microsoft 365, le stockage, les outils clients et les applications internes.
En regardant la configuration SSO que j’étais sur le point d’ajouter au VPN, une question plus simple m’est venue :
pourquoi avions-nous encore besoin d’un compte VPN partagé ?
Je cherchais à mieux protéger un mot de passe que je préférais finalement supprimer
Quelques mois plus tôt, j’aurais formulé le problème autrement :
« Notre VPN doit avoir le MFA. »
C’est un bon réflexe. CISA recommande elle aussi le MFA pour les accès distants et privilégie, lorsque c’est possible, des facteurs résistants au phishing.
Mais le MFA protège une identité existante.
Il ne répond pas à la question de savoir si cette identité doit être collective.
Dans notre agence, nous n’avions pas sept comptes VPN individuels.
Nous avions un compte VPN que plusieurs personnes connaissaient.
Ajouter un TOTP aurait renforcé ce compte, mais une nouvelle question serait immédiatement apparue :
qui possède le deuxième facteur ?
Le téléphone du dirigeant ?
Une application partagée ?
Le coffre de mots de passe ?
Et que se passe-t-il lorsqu’un prestataire essaie de se connecter à 7 h 30 alors que la personne qui reçoit l’approbation est dans le métro ?
Une discussion récente sur r/sysadmin m’a paru familière précisément pour cette raison. Un administrateur d’une petite structure cherchait comment éviter les problèmes de mots de passe au moment des départs. La recommandation récurrente n’était pas de mieux organiser le partage, mais d’éliminer les comptes partagés chaque fois que possible.
Je regardais soudain notre VPN autrement.
Nous étions en train d’installer une meilleure serrure sur une porte dont nous continuions à distribuer des copies de la clé.
Le test suivant n’avait presque plus rien à voir avec le SSO
Le lundi suivant, un développeur externe devait intervenir quatre jours sur un projet client.
Il avait déjà son identité professionnelle.
Son accès Git était limité au dépôt nécessaire.
Le client lui avait créé un compte nominatif sur l’environnement de test.
Il n’avait besoin d’aucun autre privilège.
Il devait simplement travailler depuis un espace de coworking avec une connexion protégée.
C’était exactement le cas que je voulais tester.
J’ai ouvert OnlydogVPN.
Ce service n’est pas un remplacement d’Okta ou d’Entra ID. Si un audit m’imposait explicitement SAML ou OIDC, un IdP central et une gestion MFA administrée par l’entreprise, je choisirais un produit conçu pour cela.
Mais notre difficulté, ce matin-là, était différente.
Je ne voulais pas transmettre au développeur un compte VPN permanent.
L’usage de base du service ne repose pas sur l’inscription traditionnelle avec adresse email et mot de passe, et un autre appareil peut être relié par un code de vérification plutôt qu’en lui donnant les identifiants principaux.
J’ai affiché le code.
Le développeur l’a saisi.
L’ordinateur a été relié.
C’était tout.
Pas de mot de passe VPN copié dans Teams.
Pas de login d’agence ajouté à son gestionnaire de mots de passe.
Pas de boîte mail commune à ouvrir pour récupérer un code.
Pas de secret permanent qu’il faudrait changer quatre jours plus tard.
J’avais commencé la semaine en cherchant comment ajouter une couche d’authentification à notre VPN.
Je venais de connecter un nouvel appareil sans distribuer d’identifiants VPN.
Le vrai test était ce qu’il pouvait faire cinq minutes plus tard
Je ne voulais pas que « VPN connecté » soit considéré comme un succès.
Le développeur a donc commencé son travail.
Il a ouvert l’environnement du client.
Accessible.
Il a récupéré le dépôt auquel son compte Git avait droit.
Accessible.
Il a ouvert la documentation que nous lui avions partagée.
Accessible.
Un autre projet de l’agence ?
Toujours inaccessible.
Parfait.
Le VPN n’avait pas besoin de devenir notre système d’identité.
Il protégeait la connexion.
Git décidait quels dépôts il pouvait consulter.
Le client décidait à quel environnement il avait accès.
Notre espace de travail décidait quels documents il pouvait ouvrir.
Chaque couche continuait à faire exactement son métier.
Et surtout, nous n’avions pas créé un compte partagé supplémentaire simplement pour sécuriser le trafic.
C’est là que la différence avec ma recherche initiale est devenue évidente.
Je pensais chercher la meilleure manière d’administrer l’identité dans le VPN.
Pour cette petite équipe, le service le plus pratique était celui qui exigeait beaucoup moins d’identité VPN à administrer.
Quatre jours plus tard, le départ a été plus convaincant que l’installation
Vendredi, l’intervention était terminée.
Cette fois, la scène de l’ordinateur posé sur la table ne s’est pas répétée.
Nous avons retiré l’accès au projet.
Fermé le dépôt.
Retiré les documents concernés.
Et il n’y avait pas de mot de passe VPN d’agence à changer puis à redistribuer aux six autres personnes.
Ce détail a compté davantage pour moi que la facilité de l’installation.
L’onboarding est toujours visible.
On clique.
On configure.
On vérifie que ça marche.
L’offboarding révèle les vraies dettes.
Chaque secret partagé laisse derrière lui une question :
qui le connaît encore ?
Avec ce fonctionnement, cette question n’existait simplement pas pour le mot de passe VPN.
SSO et MFA restent la bonne réponse quand l’entreprise a réellement besoin de SSO et MFA
Je ferais toujours la distinction.
Dans une entreprise avec Entra ID ou Okta déjà déployé, des centaines d’utilisateurs, des groupes, du provisioning, des obligations d’audit et un véritable cycle de vie des identités, le VPN doit entrer dans cette architecture.
SSO.
MFA fort.
Comptes individuels.
Révocation centralisée.
Selon les besoins, provisioning automatisé, politiques d’appareils et journaux d’administration.
Pour ce type d’organisation, un service professionnel comme NordLayer correspond beaucoup plus littéralement à la recherche « VPN SSO MFA ».
Mais une petite équipe peut taper exactement les mêmes mots dans Google pour une raison différente.
Elle ne cherche pas forcément une nouvelle plateforme IAM.
Elle essaie parfois seulement d’éviter que quatre personnes connaissent le même mot de passe VPN.
C’était notre cas.
Et c’est là que le second modèle m’a paru plus élégant.
Le SSO centralise un compte.
Le MFA renforce ce compte.
Les deux sont utiles.
Mais lorsqu’un service peut éviter de créer un identifiant permanent à partager entre les membres de l’équipe, il supprime une partie du problème avant même qu’il faille la sécuriser.
Je pensais devoir ajouter SSO et MFA à notre VPN pour mieux gérer les départs.
Le vendredi où le développeur est parti, le résultat qui m’a convaincu était beaucoup plus simple : il n’y avait aucun mot de passe VPN d’agence à changer.
Questions fréquentes
Quand un VPN professionnel doit-il réellement prendre en charge SSO et MFA ?
Quand l’entreprise exige des identités nominatives, une intégration avec son fournisseur d’identité, des méthodes d’authentification imposées, une révocation centrale et des contrôles compatibles avec ses procédures d’audit.
Ajouter le MFA suffit-il à sécuriser un compte VPN partagé ?
Non. Le MFA renforce l’accès au compte, mais la question du secret collectif et de la possession du deuxième facteur reste entière si plusieurs personnes utilisent la même identité.
Pourquoi l’offboarding révèle-t-il le problème des comptes partagés ?
Parce qu’un départ oblige souvent à changer le mot de passe commun, le redistribuer et vérifier les appareils qui en dépendent. Chaque secret partagé laisse la question de savoir qui le connaît encore.
Quand une approche plus légère par code d’association peut-elle suffire ?
Dans une petite équipe où le VPN ne sert qu’à protéger la connexion et où Git, les applications clientes et l’espace de travail gèrent déjà les autorisations. Elle ne convient pas à un cahier des charges qui impose SSO, MFA administré ou IAM centralisé.