L'Article 1 de cette série posait le cadre : NIS 2 s'applique à vous, et vos terminaux sont en première ligne. Vous savez pourquoi. Il est temps de passer au comment.
Le ReCyF v2.5, publié par l'ANSSI le 17 mars 2026, découpe la conformité en 20 objectifs de sécurité répartis en quatre piliers (gouvernance, protection, défense, résilience). Huit de ces objectifs touchent directement les terminaux de vos collaborateurs. Cet article les passe en revue, regroupés en trois vagues de priorité : ce qu'il faut faire maintenant, ce qu'il faut structurer, et ce qu'il faut consolider.
Vague 1 : les fondations (à traiter en premier)
Inventaire et maintien en condition opérationnelle (Objectif 5)
Vous ne pouvez pas protéger ce que vous ne connaissez pas. L'objectif 5 du ReCyF exige une cartographie à jour de tous les composants du SI, terminaux inclus. En pratique : combien de smartphones accèdent à votre messagerie ? Quels modèles ? Quelles versions d'OS ? Si vous hésitez sur la réponse, c'est le premier chantier.
Le volet MCS (maintien en condition de sécurité) est le plus concret : appliquer les correctifs de sécurité « dans les délais recommandés par l'éditeur ». Pour Apple, ça veut dire pousser les mises à jour iOS dans les semaines suivant leur publication. Pour Android, c'est plus complexe : le calendrier dépend du fabricant (Samsung, Google Pixel, Xiaomi...) et les délais varient de quelques jours à plusieurs mois.
Un MDM résout les deux problèmes. L'inventaire est automatique : chaque appareil enrôlé remonte son modèle, sa version OS, son état de chiffrement, ses applications installées. Le patching devient pilotable : vous définissez des politiques de mise à jour forcée avec un délai de grâce (par exemple, 7 jours après la publication d'un correctif critique).
Protection contre les codes malveillants (Objectif 9)
Le ReCyF impose l'utilisation de solutions antimalware sur « les postes et serveurs maîtrisés ». Sur desktop, la question est réglée depuis vingt ans. Sur mobile, c'est moins évident.
iOS limite drastiquement ce que peut faire un antivirus tiers (pas d'accès au système de fichiers, pas de scan en temps réel). La protection repose sur le modèle de sécurité d'Apple lui-même : sandboxing strict, signature obligatoire, App Store Review. Le rôle du MDM est de s'assurer que ces mécanismes ne sont pas contournés : vérifier que l'appareil n'est pas jailbreaké, bloquer l'installation d'applications hors App Store, imposer un code de verrouillage.
Android offre plus de latitude. Google Play Protect analyse les apps en arrière-plan, et Android Enterprise ajoute une couche de contrôle via le profil professionnel. Mais sur un appareil non managé, rien n'empêche un utilisateur de télécharger un APK depuis un site tiers. Le MDM ferme cette porte en restreignant les sources d'installation aux stores autorisés.
Durcissement de la configuration (Objectif 18)
Cet objectif s'applique aux entités essentielles, mais les entités importantes ont tout intérêt à l'anticiper. Le principe : chaque terminal doit être configuré selon un référentiel de sécurité documenté. Pas de configuration par défaut livrée telle quelle.
Concrètement, ça couvre le chiffrement du stockage (activé par défaut sur iOS avec un code de verrouillage, à vérifier sur Android selon le constructeur), la désactivation des services inutiles (Bluetooth, AirDrop, partage de connexion selon le contexte), la politique de mot de passe (longueur, complexité, expiration), et le verrouillage automatique après inactivité.
Sans outil centralisé, maintenir cette cohérence sur 200 appareils relève de la fiction. Un profil de configuration MDM applique ces règles dès l'enrôlement et les impose en continu. Si un utilisateur désactive le chiffrement ou change son code pour « 0000 », l'appareil signale la non-conformité et peut être isolé automatiquement.
Vague 2 : la structuration
Gestion des identités et des accès (Objectif 10)
Qui accède à quoi, depuis quel appareil, avec quel niveau de privilège ? L'objectif 10 touche à l'IAM (Identity and Access Management) et s'applique particulièrement aux terminaux dans un contexte BYOD.
Le ReCyF attend « un mécanisme d'authentification impliquant au moins un élément secret ». Pour les entités essentielles, les exigences montent : mécanismes de chiffrement et d'authentification conformes aux recommandations de l'ANSSI, ce qui oriente vers l'authentification multifacteur.
Côté MDM, la réponse passe par le store applicatif privé : l'accès aux applications d'entreprise est conditionné par l'enrôlement de l'appareil et l'identité de l'utilisateur. Pas d'enrôlement, pas d'accès. C'est une forme de contrôle d'accès contextuel qui tient compte de l'appareil (est-il conforme ?) autant que de l'identité (est-il autorisé ?).
Sécurisation des accès distants (Objectif 8)
Le télétravail a rendu cet objectif incontournable. Le ReCyF exige que les accès distants au SI soient authentifiés, chiffrés et tracés. Pour les terminaux mobiles, ça signifie trois choses : un VPN d'entreprise (ou une alternative Zero Trust), un certificat d'authentification sur l'appareil, et des logs exploitables.
Le MDM simplifie le déploiement de configurations VPN à grande échelle. Le certificat est provisionné automatiquement à l'enrôlement. L'utilisateur n'a rien à configurer, ce qui élimine le support technique lié aux « je n'arrive plus à me connecter au VPN ».
Maîtrise de l'administration (Objectif 11)
Qui administre vos terminaux ? Avec quels droits ? Depuis quels postes ? L'objectif 11 impose la séparation des privilèges d'administration et la traçabilité des actions. Un admin ne devrait pas utiliser son compte courant pour gérer la console MDM.
C'est un point souvent négligé dans les PME où le DSI cumule les casquettes. Le ReCyF demande a minima des comptes d'administration dédiés, une revue régulière des droits, et pour les entités essentielles, des postes d'administration dédiés et des journaux d'actions conservés. Votre console MDM doit permettre cette séparation : rôles distincts (lecteur, opérateur, administrateur), logs d'audit, et authentification renforcée pour les actions critiques (effacement à distance, désenrôlement).
Vague 3 : la consolidation
Gestion des incidents de sécurité (Objectif 12)
Un smartphone perdu dans un taxi. Un collaborateur qui clique sur un lien de phishing SMS. Un appareil qui se connecte à un réseau Wi-Fi compromis. Ce sont des incidents de sécurité au sens du ReCyF, et ils doivent être détectés, qualifiés et traités selon une procédure documentée.
Le MDM joue un rôle de capteur : il détecte les anomalies (jailbreak, non-conformité de politique, absence de mise à jour critique) et peut déclencher des actions automatiques (verrouillage, effacement des données pro, notification à l'administrateur). Mais il ne remplace pas un processus de gestion d'incidents. Vous devez définir qui reçoit l'alerte, comment l'incident est qualifié, et quelles actions sont déclenchées selon la gravité.
Pour les entités essentielles, l'objectif 20 ajoute une couche de supervision active : les événements de sécurité des terminaux doivent être collectés et analysés, idéalement via un SIEM ou un outil de log management. Le MDM fournit la télémétrie ; c'est à vous de l'exploiter.
Sauvegardes et tests de restauration (Objectif 13)
Le ReCyF exige des sauvegardes régulières et des tests de restauration. Sur les terminaux mobiles, la question est plus nuancée que sur les serveurs.
Les données critiques ne devraient pas résider sur le terminal. Un smartphone bien configuré est un point d'accès, pas un coffre-fort : la messagerie est synchronisée (Exchange, Google Workspace), les fichiers sont sur le cloud (SharePoint, Drive), les applications métier stockent leurs données côté serveur. Si l'appareil est perdu ou détruit, un nouvel enrôlement reconstitue l'environnement de travail en quelques heures.
La vraie question de sauvegarde sur mobile concerne les configurations elles-mêmes : profils MDM, politiques de sécurité, listes d'applications autorisées. Ce sont les données de votre console MDM qui doivent être sauvegardées, pas celles de chaque terminal individuellement.
Par où commencer concrètement
Huit chantiers, ça peut sembler beaucoup. En réalité, si vous utilisez déjà un MDM, plusieurs cases sont cochées sans que vous le sachiez. L'inventaire est automatique (objectif 5). Le chiffrement est vérifié en continu (objectif 18). Les accès sont contrôlés par l'enrôlement (objectif 10).
La priorisation par vagues n'est pas arbitraire. La vague 1 traite les risques les plus immédiats et les plus visibles en cas de contrôle. La vague 2 structure ce qui existe de manière informelle. La vague 3 complète le dispositif pour les organisations qui visent un niveau de maturité élevé.
Si vous partez de zéro, concentrez-vous sur trois actions cette semaine : inventorier tous les terminaux qui accèdent au SI, vérifier que le chiffrement est actif sur chacun, et documenter votre politique de mise à jour. Ces trois actions couvrent les objectifs 5, 9 et 18, soit les fondations du ReCyF pour les terminaux.
Le troisième article de cette série passera du ReCyF à la mise en pratique : un template de conformité endpoint que vous pouvez adapter à votre organisation, avec les cases à cocher objectif par objectif.
Cet article propose une lecture pédagogique du ReCyF v2.5 (17/03/2026). Il ne se substitue pas à une analyse de conformité formelle ni au texte officiel publié par l'ANSSI. Consultez le ReCyF complet sur MesServicesCyber.