← Toutes les publications

Defender macOS : valider Device Control v2 après le retrait de v1

Les notes de Defender macOS 101.26092.0009, rattachées à octobre 2026, annoncent le retrait de l’ancien Device Control v1. Les organisations qui contrôlent les périphériques avec ces politiques doivent vérifier la configuration réellement active et valider leur migration vers v2.

Impact
Mac intégrés à Defender for Endpoint utilisant Device Control v1 ; cette annonce ne concerne pas le moteur Device Control de Windows.
Action
inventorier les politiques v1 encore présentes, préparer leur équivalent v2 dans l’outil de gestion utilisé, puis tester les autorisations et interdictions sur un Mac représentatif.
Statut
À tester

Un retrait documenté, sans date quotidienne de lancement

Les notes de version indiquent explicitement « Legacy Device Control v1 is retired » pour 101.26092.0009. Le journal des nouveautés classe cette version macOS en disponibilité générale : ce statut n’est pas déduit du seul numéro.

Microsoft rattache la version à octobre 2026, sans jour de sortie indiqué dans les pages consultées. Ce n’est donc pas une annonce datée du 28 octobre. Le sujet mérite un contrôle maintenant pour éviter de conserver une ancienne politique pendant la mise à jour de l’agent. La documentation ne décrit pas ici le comportement exact de chaque politique v1 après mise à niveau ; ne pas en déduire un blocage ou une ouverture universelle des accès.

Device Control demande une souscription incluant les capacités Defender for Endpoint Plan 1, un macOS pris en charge et un agent installé et intégré au service. Le seuil historique 101.96.85 de la fonctionnalité ne doit pas être confondu avec la version d’octobre annonçant le retrait.

Vérifier l’agent et la configuration effective

Sur le Mac concerné, les commandes de consultation suivantes sont documentées pour Terminal. Microsoft ne demande pas d’élévation dans ces étapes ; elles ne déploient aucune politique.

mdatp version
mdatp health --details device_control

La première relève la version rapportée par l’agent. La seconde évite de conclure à la protection sur la seule présence d’un profil MDM.

Pour une configuration v2 fonctionnelle, la procédure Microsoft donne les valeurs attendues suivantes :

  • active: ["v2"], v1_configured: false et v2_configured: true ;
  • v2_state: "enabled" ;
  • v2_sensor_connection: "created_ok" ;
  • v2_full_disk_access: "approved".

Si v1 est encore configuré, préparer son remplacement. Si les deux versions apparaissent actives, Microsoft demande de retirer la configuration v1. Une connexion au capteur incorrecte ou un accès complet au disque non approuvé appelle un diagnostic avant toute conclusion sur l’application des règles.

Migrer et vérifier les accès attendus

Conserver l’ancienne politique pour comparaison. Le dépôt Microsoft fournit dcupgrade, un outil de conversion des profils macOS v1 vers le JSON v2. Relire le résultat et le valider avec la procédure officielle : une conversion ne prouve pas l’équivalence opérationnelle.

Pour v2, accorder Full Disk Access à com.microsoft.dlp.daemon et activer DC_in_dlp. Avec Intune, la documentation utilise un profil macOS personnalisé déployé par Device channel ; avec Jamf Pro, elle utilise le schéma de préférences Defender. Ces voies nécessitent leurs abonnements et droits propres. Le chargement manuel d’une politique est réservé à la préproduction, sur un Mac sans politique Device Control gérée par MDM.

Sur un Mac représentatif, comparer avant/après un support autorisé et un support interdit : lecture, écriture et exécution selon les règles réellement prévues. Contrôler aussi les préférences, règles et groupes effectifs via la rubrique Verify Device Control. Généraliser seulement si la santé v2 est correcte et si autorisations comme interdictions correspondent au résultat attendu. Sinon suspendre l’élargissement et revoir ciblage, permissions et règles.

Si le périmètre inclut les transferts Bluetooth sous macOS 27, ajouter un test réel : Microsoft documente qu’un utilisateur peut retirer l’autorisation Bluetooth même avec un profil MDM la déclarant accordée. Dans ce cas, Device Control ne peut plus appliquer les restrictions de transfert Bluetooth. Le statut du profil seul n’est donc pas un critère de réussite.

Ces commandes et tests n’ont pas été exécutés pour cet article. Les étapes de validation proposées constituent une recommandation PatchFactory, sans délai de migration officiel ajouté.

Sources