Le mot de passe est le maillon qui cède en premier
Lors de chaque campagne de phishing documentée par le NCSC, le vecteur d'entrée initial est quasi systématiquement un identifiant volé ou un mot de passe réutilisé. En Suisse, les PME de 20 à 150 employés concentrent une part croissante des signalements : elles disposent rarement d'un SOC interne, leurs utilisateurs jonglent entre outils SaaS, VPN et postes Windows 11 ou macOS 14, et la politique de mots de passe reste souvent figée à un standard des années 2010 — 8 caractères, rotation trimestrielle, stockage dans un tableur partagé.
FIDO2 — le standard porté par l'alliance FIDO et normalisé sous la forme WebAuthn (W3C) — supprime structurellement ce risque : aucun secret partagé ne transite sur le réseau, aucune base de données côté serveur ne contient de hash craquable. La clé privée ne quitte jamais l'authenticator. Ce n'est pas un renforcement du mot de passe ; c'est sa suppression.
Cadre légal suisse : ce que la nLPD impose concrètement
Principe de Privacy by Design et mesures techniques adéquates
La loi fédérale sur la protection des données (nLPD), en vigueur depuis le 01.09.2023, introduit l'obligation de mettre en œuvre des mesures techniques et organisationnelles (MTO) proportionnées au risque dès la conception du traitement. L'art. 8 nLPD exige explicitement que le responsable du traitement prenne des mesures appropriées pour garantir la sécurité des données. Une authentification par mot de passe simple sur un système qui traite des données personnelles sensibles (données de santé, données financières, données RH) ne satisfait pas ce critère en 2024.
L'autorité fédérale de protection des données (PFPDT/FDPIC) peut, à la suite d'un incident, demander des justifications sur les MTO en place. L'absence de MFA documenté constitue une aggravante lors de l'évaluation de la gravité d'une violation.
Obligation de notification en cas d'incident
Si un attaquant accède à des données personnelles via des identifiants volés, l'art. 24 nLPD impose une notification au PFPDT dès que possible lorsque la violation est susceptible d'engendrer un risque élevé pour les personnes concernées. Il n'existe pas de délai de 72 heures fixé par la loi suisse (contrairement au RGPD), mais la jurisprudence en construction et les recommandations du PFPDT pointent vers une notification rapide — en pratique, 48 à 72 heures après la détection est considéré comme raisonnable. La procédure de signalement est distincte de celle du signalement volontaire au NCSC, qui reste conseillé en parallèle pour les PME.
Secteurs régulés : obligations supplémentaires
Les établissements financiers sous surveillance FINMA (banques, gérants de fortune indépendants, assurances) doivent respecter la circulaire FINMA 2023/1 sur les risques opérationnels, qui traite de la résilience des systèmes d'information. Une authentification forte — MFA résistant au phishing, soit FIDO2 ou certificats EAP-TLS — devient une attente explicite lors des audits. Les fiduciaires et cabinets d'avocats manipulant des données fiscales ou juridiques ne sont pas directement sous FINMA, mais la nLPD s'applique pleinement.
Architecture FIDO2 : ce qui se passe vraiment sous le capot
La cryptographie asymétrique comme fondation
Lors de l'enregistrement (registration), l'authenticator — clé USB YubiKey 5, module TPM 2.0 intégré dans un Surface Pro ou un MacBook M3, ou passkey stockée dans le trousseau iCloud/Android Keystore — génère une paire de clés asymétriques. La clé publique est transmise au serveur (relying party) ; la clé privée ne quitte jamais le périmètre de l'appareil. Lors de l'authentification, le serveur envoie un challenge aléatoire signé par la clé privée. Pas de mot de passe, pas de hash, pas de replay possible.
WebAuthn supporte deux modes : roaming authenticators (clés physiques FIDO2, port USB-A/USB-C/NFC) et platform authenticators (TPM sous Windows 11, Secure Enclave sous macOS/iOS). Les passkeys — dérivé grand public de FIDO2 — permettent la synchronisation entre appareils via le cloud du fournisseur (iCloud Keychain, Google Password Manager) : pratique pour les utilisateurs, mais à évaluer selon votre politique de souveraineté des données.
Intégration dans l'infrastructure existante d'une PME
La majorité des applications SaaS courantes (Microsoft 365, Google Workspace, Salesforce, GitHub, AWS IAM Identity Center) prennent en charge WebAuthn nativement. La brique critique est l'Identity Provider (IdP) : Azure AD (Entra ID), Okta, Keycloak auto-hébergé ou Authentik. C'est l'IdP qui valide le challenge FIDO2 et émet le jeton d'accès (SAML 2.0 ou OIDC) vers les applications.
Pour les postes Windows 11 joints à Entra ID, Windows Hello for Business utilise le TPM 2.0 comme platform authenticator FIDO2 — déploiement via stratégie Intune, sans coût matériel additionnel si le parc a moins de 3 ans. Pour macOS 14 (Sonoma), la Touch ID sur MacBook fait office de platform authenticator compatible FIDO2 dans Safari et Chrome. Les clés physiques (roaming authenticators) restent indispensables pour les accès administrateurs et les scénarios sans appareil de confiance.
Cas limite : applications legacy sans support WebAuthn
Les applications qui n'exposent qu'une interface LDAP ou une authentification par formulaire HTML classique ne peuvent pas consommer directement FIDO2. La solution standard est un proxy d'authentification (ex. : Keycloak avec un adaptateur LDAP) qui modernise la couche d'authentification sans toucher à l'application. Si l'application est un ERP on-premise vieux de 10 ans, le projet FIDO2 devient un projet de migration IdP — effort à budgétiser séparément (40 à 120 heures selon la complexité).
Procédure de déploiement : étape par étape
- Inventaire des applications et des flux d'authentification (DSI + RSSI) — Lister toutes les applications avec leur protocole d'authentification actuel (LDAP, SAML, OIDC, formulaire). Identifier les applications critiques qui traitent des données personnelles au sens nLPD. Durée estimée : 1 à 2 jours pour un parc de 50 endpoints.
- Choix et déploiement de l'IdP central (DSI) — Si Entra ID est déjà en place, activer les méthodes d'authentification FIDO2 dans le portail Azure (Entra ID > Security > Authentication methods). Pour un IdP auto-hébergé, Keycloak 24+ ou Authentik sont les options open source matures. Prévoir 1 à 3 jours d'intégration et de test.
- Enregistrement des authenticators — pilote 10 % des utilisateurs (DSI + utilisateurs pilotes) — Distribuer les clés physiques aux administrateurs et aux utilisateurs à haut privilège en priorité. Pour le reste du parc, activer les platform authenticators (Windows Hello / Touch ID). Documenter la procédure d'enregistrement en 5 étapes avec captures d'écran.
- Migration progressive et suppression du fallback SMS/TOTP (RSSI + DSI) — Ne pas supprimer les méthodes legacy le jour J. Maintenir un fallback TOTP (RFC 6238) pendant 30 jours post-déploiement. Après validation que 95 % des utilisateurs s'authentifient via FIDO2, désactiver les méthodes plus faibles. Le SMS OTP (SIM swapping) doit être désactivé en priorité sur les comptes administrateurs.
- Procédure de récupération documentée (RSSI + juriste) — Définir le processus lorsqu'un utilisateur perd son authenticator : vérification d'identité en présentiel ou par vidéo supervisée, réinitialisation par un administrateur habilité, journalisation de l'événement. Ce processus doit être testé et documenté avant de désactiver les fallbacks.
- Journalisation et surveillance des authentifications (SOC ou DSI) — Configurer des alertes sur les tentatives d'authentification échouées répétées, les connexions depuis des géolocalisations inhabituelles et les enregistrements de nouvel authenticator. Rétention des logs : minimum 6 mois (recommandation NCSC pour les PME), 12 mois pour les entités régulées.
- Test de pénétration ciblé post-déploiement (prestataire externe) — Valider l'absence de bypass via le flux legacy, l'impossibilité de replay de challenge et la robustesse de la procédure de récupération. Budget typique pour un périmètre PME : CHF 3 000 à 8 000.
- Mise à jour de la documentation de sécurité et notification PFPDT si pertinent (RSSI + juriste) — Mettre à jour le registre des traitements (art. 12 nLPD) pour refléter les nouvelles MTO. Si un incident a précédé le projet, vérifier si l'obligation de notification au PFPDT est déclenchée.
Cas pratique : fiduciaire de 45 postes à Lausanne
Contexte : Fiduciaire Dupraz & Associés SA, 45 collaborateurs, Lausanne, canton de Vaud. Parc : 32 postes Windows 11 22H2, 8 MacBook Pro M2 (macOS 14.4), 5 postes partagés en salle de réunion. Applications critiques : Microsoft 365 (Entra ID comme IdP), un ERP comptable on-premise accessible via RDP sur port TCP 3389, un portail client HTTPS avec authentification par formulaire. Données traitées : données financières et fiscales de plusieurs centaines de clients personnes physiques — clairement dans le périmètre nLPD.
Situation initiale : MFA activé sur 60 % des comptes M365 via SMS OTP. Pas de MFA sur le RDP. Mot de passe de l'ERP partagé entre 4 associés, stocké dans un fichier Excel protégé par un mot de passe de 6 caractères.
Incident déclencheur : En mars 2024, un collaborateur clique sur un lien de phishing imitant le portail SwissID. Ses identifiants M365 sont capturés. L'attaquant contourne le SMS OTP par SIM swapping (la carte SIM du collaborateur est temporairement transférée). Accès à la boîte mail pendant 11 heures avant détection. Environ 2 300 mails contenant des données de clients sont exfiltrés. Notification au PFPDT déclenchée — risque élevé avéré.
Projet FIDO2 post-incident — budget et calendrier :
- 12 clés YubiKey 5C NFC (associés, managers, IT) : CHF 720 (CHF 60/unité)
- Platform authenticators Windows Hello for Business sur les 32 postes Windows 11 via Intune : CHF 0 (matériel TPM 2.0 déjà présent, licences M365 Business Premium existantes)
- Touch ID sur les 8 MacBook M2 : CHF 0
- Intégration Entra ID — activation des méthodes FIDO2, conditional access policies (bloquer tout accès sans MFA résistant au phishing) : 8 heures DSI externe à CHF 180/h = CHF 1 440
- Proxy Keycloak devant le RDP pour éliminer l'exposition directe du port 3389 et forcer l'authentification FIDO2 : 16 heures = CHF 2 880
- Formation utilisateurs (2 sessions de 45 min) + documentation procédure de récupération : CHF 800
- Test de pénétration ciblé (périmètre M365 + RDP proxy) : CHF 4 500
- Total projet : CHF 10 340
Résultat à 60 jours : 100 % des authentifications M365 passent par FIDO2 (platform ou roaming authenticator). Le port RDP 3389 n'est plus exposé sur Internet. Le SMS OTP est désactivé sur l'ensemble des comptes. Les 5 postes de salle de réunion utilisent des clés physiques partagées avec code PIN local — procédure documentée et journalisée. L'ERP fait l'objet d'un projet de migration IdP planifié pour le T4 2024, avec une clé physique dédiée par associé en attendant.
Coût d'opportunité comparé : un incident de même ampleur (11 heures d'accès, 2 300 mails exfiltrés) génère des coûts de réponse typiques de CHF 25 000 à 80 000 (forensique, notification, communication client, honoraires juridiques, potentielle perte de mandats). Le ratio investissement/risque évité est sans ambiguïté.
Récapitulatif opérationnel
- Désactiver le SMS OTP en priorité sur tous les comptes à privilèges — c'est le vecteur de contournement le plus fréquent et le plus simple à exploiter.
- Activer Windows Hello for Business via Intune sur tout poste Windows 11 avec TPM 2.0 — déploiement sans coût matériel additionnel si le parc a moins de 3 ans.
- Distribuer des clés physiques FIDO2 aux administrateurs, associés et utilisateurs à haut privilège avant d'étendre au reste du parc.
- Ne jamais exposer RDP directement sur Internet — proxy d'authentification ou VPN avec MFA FIDO2 obligatoire en amont.
- Documenter et tester la procédure de récupération avant de supprimer tout fallback — un utilisateur bloqué qui contourne via le helpdesk non sécurisé annule le bénéfice du déploiement.
- Mettre à jour le registre des traitements nLPD pour refléter les nouvelles MTO après déploiement — un audit PFPDT post-incident vérifiera la cohérence entre la politique déclarée et la réalité technique.
- Planifier les applications legacy dans une roadmap de migration IdP — ne pas laisser subsister des ilots d'authentification par mot de passe simple sur des systèmes qui traitent des données personnelles.
- Signaler tout incident d'authentification compromis au NCSC via le formulaire de signalement, indépendamment de l'obligation de notification au PFPDT — les deux démarches sont complémentaires et non exclusives.
- Auditer les logs d'authentification mensuellement — rechercher les comptes qui n'ont pas encore basculé sur FIDO2, les authentifications hors périmètre géographique habituel, les enregistrements de nouvel authenticator non initiés par le helpdesk.
- Intégrer les CIS Benchmarks niveau 1 pour Windows 11 et macOS 14 comme référentiel de configuration de base — ils incluent des contrôles explicites sur l'authentification forte et la gestion des credentials.
SynGuard accompagne les PME romandes dans l'inventaire de leur parc endpoints et la mise en conformité de leur chaîne d'authentification — sans vente forcée, avec un diagnostic technique préalable gratuit.
Sources
- Loi fédérale sur la protection des données (nLPD) — fedlex.admin.ch — Texte consolidé de la nLPD en vigueur depuis le 01.09.2023, base légale des obligations MTO et de notification.
- Signalement d'incidents au NCSC — ncsc.admin.ch — Formulaire et procédure de signalement volontaire pour les PME et entreprises suisses.
- Préposé fédéral à la protection des données et à la transparence (PFPDT) — edoeb.admin.ch — Autorité de surveillance nLPD, procédures de notification en cas de violation de données.
- CIS Benchmarks — cisecurity.org — Référentiels de configuration sécurisée pour Windows 11, macOS et autres plateformes, incluant les contrôles d'authentification.
- NIST Cybersecurity Framework — nist.gov — Cadre de référence international pour la gestion du risque cyber, utilisé comme complément au cadre suisse par les PME exportatrices.