Un éditeur SaaS rencontre NIST SP 800-63 le jour où un prospect lui demande quel niveau d'assurance d'authentification sa plateforme prend en charge. La question est mal posée : une plateforme n'a pas un niveau, elle en a autant que de parcours d'accès. La bonne réponse consiste à présenter une cartographie — connexion utilisateur final, console d'administration, API, support — et à assumer un niveau distinct pour chacun.
Cet article propose une lecture opérationnelle et ne constitue pas un avis juridique. Ce référentiel américain n'a pas de portée contraignante en Europe, mais il devient exigible dès qu'un contrat client y renvoie.
Une question d'appel d'offres avant d'être une question technique
Le fonctionnement du référentiel — séparation entre vérification d'identité, authentification et fédération, classement de l'OTP par SMS ou par voix comme déconseillé, résistance au phishing au niveau le plus élevé — est traité dans notre lecture générale de NIST SP 800-63. Côté éditeur, le rôle change : votre réponse conditionne la conformité que le client pourra afficher.
Votre niveau d'assurance devient le plafond du sien. Un client qui vise un haut niveau sur ses accès sensibles ne l'atteindra pas si votre console d'administration ne le permet pas. C'est ce raisonnement qui fait perdre des marchés, bien plus qu'un audit.
Quatre parcours, quatre niveaux
La connexion de l'utilisateur final
Parcours le plus visible, souvent le moins critique. Deux sujets dominent : la qualité des méthodes proposées en propre, et la capacité à s'effacer devant la fédération quand le client dispose de son annuaire. Imposer son authentification à un client mature plafonne mécaniquement le niveau d'assurance de ce dernier.
La console d'administration
Elle mérite le niveau le plus élevé, parce qu'elle est asymétrique : un compte compromis expose plusieurs clients à la fois. C'est aussi le parcours sur lequel un acheteur régulé exigera explicitement la résistance au phishing.
Les accès programmatiques
Les clés d'API et les comptes machine ne relèvent pas des niveaux d'assurance d'authentification, conçus pour des personnes. Mieux vaut le dire que prétendre le contraire : ce qui est attendu ici, c'est une gestion des identités non humaines — propriétaire identifié, portée limitée, durée de vie courte, rotation, journalisation.
Le support technique
Parcours oublié des grilles de réponse, et le plus dangereux. Un technicien qui consulte l'application « comme le client » franchit la frontière entre locataires. Le niveau attendu y est celui de l'administration, augmenté d'une exigence de traçabilité et de consentement que le référentiel ne formule pas mais que les clients réclament.
| Parcours | Ce que le client cherche réellement à savoir | Réponse défendable | Réponse qui fait échouer |
|---|---|---|---|
| Connexion utilisateur final | Puis-je imposer mes propres règles à mes utilisateurs ? | Fédération prise en charge, méthodes résistantes au phishing disponibles en propre | « Nous proposons la MFA » sans précision de méthode |
| Console d'administration | Combien de vos employés peuvent voir mes données ? | Nombre restreint, authentifiant matériel, journal consultable | Comptes d'administration protégés par un code à usage unique |
| API et comptes machine | Que se passe-t-il si une clé fuite ? | Portée limitée, durée courte, rotation, révocation immédiate | Clé permanente à portée globale |
| Support avec usurpation | Quelqu'un peut-il regarder mon espace sans que je le sache ? | Session bornée, motif enregistré, trace visible côté client | Fonction activable en interne, sans trace exposée |
| Récupération de compte | Par où contourne-t-on tout le reste ? | Parcours aligné sur le niveau de la connexion | Réinitialisation par courriel seul |
Ce qu'un questionnaire client demande vraiment
Sous des formulations variables, les questionnaires cherchent presque toujours cinq choses : quelles méthodes sont réellement disponibles et lesquelles le client peut imposer ; comment sont protégés vos comptes internes à privilèges ; ce qui est journalisé et combien de temps la trace reste exploitable ; en combien d'étapes un accès est révoqué ; et par quel chemin un compte se reprend hors procédure normale.
Cette dernière question départage les dossiers. Beaucoup d'éditeurs décrivent soigneusement leur connexion et laissent la réinitialisation dans l'ombre. Un acheteur expérimenté sait qu'un parcours de récupération faible annule le reste, comme un vol de jeton de session annule la qualité de l'authentification initiale.
Clients américains et clients européens : deux grilles, une architecture
Un éditeur qui vend des deux côtés de l'Atlantique reçoit des questionnaires structurés différemment. Les grilles américaines raisonnent par niveaux d'assurance et catégories d'authentifiants. Les grilles européennes raisonnent par obligations et par preuve : proportionnalité au risque, traçabilité, maîtrise de la sous-traitance, comme le demandent NIS2, DORA ou le Cyber Resilience Act.
L'erreur serait de maintenir deux architectures. Mieux vaut une seule architecture, documentée deux fois : la même méthode résistante au phishing sur la console d'administration se décrit comme un niveau d'assurance élevé pour un acheteur américain, et comme une mesure proportionnée au risque et journalisée pour un acheteur européen. S'y ajoute, côté européen, une question absente du référentiel américain : la localisation des données et la juridiction applicable, où une solution française change la réponse.
Le SMS-OTP conservé « pour compatibilité »
Presque tous les éditeurs le gardent, pour la même raison : quelques clients l'utilisent encore, et le retirer déclencherait des tickets. Le coût du maintien est rarement calculé.
Il est d'abord commercial : sa présence dans la liste des méthodes déclenche une question dans le questionnaire suivant, parfois une réserve à l'évaluation. Il est ensuite technique : tant que le canal existe, il constitue un chemin de repli, et un attaquant en échec face à une méthode résistante au phishing tentera de faire basculer la session vers la méthode faible — un basculement que l'interface propose souvent d'elle-même. Il est enfin organisationnel : deux niveaux d'assurance sur un même parcours rendent toute affirmation de niveau invérifiable.
La sortie propre est progressive : désactivation par défaut sur les nouveaux locataires, mesure de l'usage résiduel, information des clients concernés, puis restriction aux parcours que l'analyse de risque tolère. Sur les actions irréversibles, aucune méthode reposant sur un code transmissible ne tient : une preuve d'intention distincte de la session, comme le facteur cognitif, apporte ce que l'empilement de facteurs ne donne pas.
FAQ
Peut-on annoncer un niveau d'assurance pour toute la plateforme ?
Non, et l'annoncer dessert l'éditeur. Un acheteur technique demandera aussitôt si la console d'administration et le support sont au même niveau que la connexion utilisateur. Publiez une cartographie par parcours : plus longue à écrire, impossible à prendre en défaut.
La fédération avec l'annuaire du client nous décharge-t-elle ?
Elle transfère la vérification de l'identité et l'authentification, pas le reste. Durée des sessions, révocation, comptes locaux de secours et accès internes restent de votre responsabilité — et ce sont eux qui seront audités.
Comment répondre quand le client demande un niveau que nous n'atteignons pas ?
En l'écrivant, avec le parcours concerné, la méthode actuelle et l'échéance de mise à niveau. Une réponse précise passe mieux qu'une réponse ambiguë, qui sera de toute façon vérifiée en phase technique.
Faut-il choisir entre le référentiel américain et les textes européens ?
Non, ils ne portent pas sur le même objet : l'un fournit une échelle technique, les autres des obligations de résultat. Une architecture unique, correctement documentée, satisfait les deux lectures.
Aller plus loin : pilier : authentification cognitive · lecture générale de NIST SP 800-63 · ISO 27001 chez les éditeurs SaaS · grille d'évaluation d'un fournisseur