Téléphone perdu, accès bloqué. Seul quelqu'un avec un accès à la base de données peut réinitialiser le second facteur.
Quand la réinitialisation 2FA passe par l'équipe de développement et la base de données de production, l'utilisateur ne peut plus travailler et le ticket mobilise des spécialistes. COD gère les mots de passe à usage unique TOTP et HOTP de façon centralisée : réinitialisation en un clic pour les managers, self-service pour les utilisateurs, sans toucher à la base de données. Multi-tenant, on-premise.
Tableau de bord OTP : gestion centralisée des tokens TOTP/HOTP.
Cela vous parle ?
Téléphone perdu, accès bloqué, et la réinitialisation passe par la base de données
Le problème : Un collaborateur perd son smartphone, l'application d'authentification disparaît avec, l'accès est bloqué. Le helpdesk ne peut pas aider, car seul quelqu'un avec un accès direct à la base de données peut réinitialiser le second facteur. Le ticket escalade jusqu'à l'équipe de développement, qui édite la base de production à la main.
La conséquence : L'utilisateur ne peut pas travailler jusqu'à la réinitialisation, le ticket mobilise le premier niveau et des spécialistes, et chaque intervention manuelle dans la base de production est un risque de panne et d'erreur, sans processus propre.
Comment COD le résout : Dans le module OTP de COD, un clic sur « Réinitialiser l'OTP » dans la vue utilisateur suffit aux managers et aux admins, sans aucune intervention en base de données. Les utilisateurs restaurent leur OTP eux-mêmes en self-service dans leurs propres paramètres, ou l'activent de façon autonome si leur rôle le permet. Cela soulage le premier niveau et rend superflus les resets risqués en base.
Déployer la 2FA, c'est créer chaque token à la main, un par un
Le problème : Quand la 2FA doit être introduite pour tout un service, l'admin crée chaque token individuellement : générer le secret, saisir les paramètres, le transmettre de façon sécurisée, aider à la configuration. Pour des setups presque identiques, la même configuration est recomposée encore et encore, et chaque faute de frappe donne un token qui ne fonctionne pas.
La conséquence : Le déploiement traîne, mobilise du temps d'admin pour du travail répétitif et produit des erreurs évitables. Au pire, l'introduction de la 2FA est reportée, et les comptes restent plus longtemps protégés par un simple mot de passe.
Comment COD le résout : Les groupes OTP soutiennent le déploiement, et l'enrollment par QR remplace la saisie des secrets lors de la configuration sur l'appareil de l'utilisateur. Pour les setups récurrents, il y a la fonction de copie : sélectionner une entrée existante, la copier, ajuster les champs, enregistrer. Une nouvelle entrée est créée avec un secret généré aléatoirement, sur la base de la configuration éprouvée. Vous gérez TOTP et HOTP dans une seule interface.
Plusieurs tenants, des comptes AD, des responsabilités floues
Le problème : En tant que prestataire IT ou collectivité, vous gérez la 2FA pour des tenants séparés, plus des utilisateurs Active Directory dont la 2FA était jusqu'ici réglée à part. Qui peut créer ou réinitialiser des tokens pour quel tenant n'est proprement défini nulle part. Dans le doute, l'admin central a un accès complet partout.
La conséquence : Des permissions mal définies sont un risque de sécurité et d'audit, et chaque cas particulier engendre du travail manuel et des tickets supplémentaires. La gestion ne suit pas le nombre de tenants.
Comment COD le résout : Le module OTP de COD est multi-tenant et basé sur les rôles dès la conception : managers et admins gèrent et réinitialisent exactement les OTP dont ils sont responsables. Les utilisateurs Active Directory aussi gèrent leur OTP directement dans leurs propres paramètres. De plus, la gestion des OTP migre vers Stronghold, le secrets management intégré à COD : les tokens existants sont repris automatiquement à la première ouverture du coffre (nouveau en 3.6), et jusqu'au déploiement propre, le module OTP continue de fonctionner inchangé comme solution de repli.
Pourquoi COD, pas seulement une fonctionnalité
Chez COD, le second facteur s'inscrit dans le même modèle de rôles multi-tenant que le reste de la plateforme : réinitialisation et gestion sortent de la base de données pour rejoindre des responsabilités claires, utilisateurs AD compris. C'est propre pour l'audit et cela suit le nombre de tenants. Le chemin vers Stronghold fait le lien avec le secrets management intégré à COD : la migration est en marche, sans que rien ne disparaisse aujourd'hui.
Questions fréquentes
Découvrez le module OTP en direct
Demandez une démonstration en direct et nous vous présentons le module OTP de COD de manière concrète, sans pression commerciale, ou téléchargez la fiche technique du module OTP de COD.