Sophos Mobile : migrer du mode Administrateur de l’appareil Android vers Android Enterprise

Cet article aide à définir le parcours de migration et les vérifications nécessaires. Il n’autorise aucune réinitialisation en production. Sophos qualifie le mode Administrateur de l’appareil d’obsolète : dans Sophos Mobile, il n’est disponible que pour Android 9 ou une version antérieure ; les appareils sous Android 10 ou une version ultérieure ne peuvent pas être inscrits dans ce mode. Cela ne signifie pas que toutes les fonctions Android Device Policy Manager ont été abandonnées, et ne constitue pas une recommandation de continuer à utiliser Android 9. N’inscrivez pas de nouveaux appareils dans l’ancien mode. La migration décrite ci-dessous suppose qu’un environnement Android Enterprise est déjà installé et configuré.

Déterminer d’abord le propriétaire et le mode cible

Avant tout changement, confrontez le mode de gestion réel, l’identité de l’appareil, son propriétaire, la version d’Android, l’utilisateur associé, les stratégies, les applications, la connectivité et le dernier état connu, sur l’appareil et dans le bon tenant Sophos.

Préparer la nouvelle inscription avant l’intervention

Cette vérification s’effectue tant que l’ancien appareil est encore géré. Elle ne déclenche ni réinitialisation ni désinscription. Consignez dans le journal de migration les informations suivantes pour le mode cible choisi :

Sous Sophos Fusion > My Products > Mobile > Setup > Google setup > Android Enterprise, vérifiez le mode indiqué dans Android Enterprise mode, les informations de compte affichées et l’état de Use managed Google domain device enrollment. Réutilisez l’inscription existante de l’organisation ; n’exécutez pas à nouveau Register account et ne remplacez pas la liaison avec Google. Si cette liaison est absente ou incertaine, clarifiez d’abord la situation en suivant la section Lier l’organisation à Google.
Préparez une Android Enterprise device policy pour l’appareil de l’entreprise et une Android Enterprise work profile policy pour l’appareil personnel. Notez les noms de la stratégie cible et du lot de tâches associé. Le lot correspondant au type d’appareil doit contenir au minimum Enroll et Assign policy, avec cette stratégie précise. Une ancienne stratégie Administrateur de l’appareil ne peut pas la remplacer.
Si vous utilisez le Self Service Portal, ouvrez sous Setup > Self Service Portal la configuration effective pour l’utilisateur. Dans les paramètres de la plateforme Android, Enrollment package doit pointer vers le lot de tâches préparé. Vérifiez Owner, le Device group cible, la priorité des groupes et le quota d’appareils restant. Vérifiez une configuration existante adaptée, plutôt que de créer systématiquement une nouvelle configuration ou de modifier Default. La préparation est décrite dans Préparer la stratégie, le lot et l’identité utilisateur.
Vérifiez l’approbation de Sophos Mobile Control dans Managed Google Play. Sans cette approbation, l’application gérée ne se met pas à jour automatiquement. Si l’inscription des appareils au domaine est activée, les utilisateurs prévus doivent exister dans le domaine Google géré. Cette inscription au domaine nécessite Mobile Control 9.8 ou une version ultérieure ; pour les profils professionnels, toutes les mises à jour disponibles du système d’exploitation et des applications doivent également être installées. Pour une tâche lancée par Sophos Mobile, l’adresse e-mail attribuée doit correspondre exactement à l’identifiant Google.
Sélectionnez une méthode d’inscription autorisée dans le mode actuel de l’organisation et préparez à l’avance, avec le service informatique compétent, l’accompagnement de l’utilisateur décrit ci-dessous. Pour une organisation inscrite avant le 9 avril 2024 en mode managed-Google-domain sans activation de l’inscription des appareils au domaine, l’inscription par l’administrateur n’est pas disponible ; préparez alors le parcours SSP autorisé. N’activez pas cette option au passage comme une étape de migration. Toute modification de la liaison de l’organisation ou du mode d’inscription nécessite une autorisation distincte.

Pour un appareil de l’entreprise auquel un utilisateur est attribué, le guide Android Enterprise, à la rubrique « Pilote administrateur » décrit le parcours pris en charge via l’assistant Devices > Add > Add device wizard, la sélection de l’utilisateur, Platform: Android et le lot d’inscription préparé. N’exécutez ce parcours qu’après la réinitialisation d’usine autorisée séparément et confirmée sur l’appareil. Si le SSP est requis, utilisez la procédure SSP décrite dans ce guide. Les méthodes par code QR, zero-touch et sans utilisateur sont des alternatives nécessitant leur propre préparation, et non des étapes obligatoires supplémentaires.

Pour un appareil dont le caractère personnel est confirmé, préparez à l’avance la section Configurer le profil professionnel dans le guide Android BYOD afin d’accompagner l’utilisateur. Elle présente Owner: Personal, le lot pour profil professionnel et la configuration de Mobile Control sur l’appareil. Cette nouvelle inscription ne commence qu’après confirmation de l’ancienne désinscription, puis suppression de la bonne entrée correspondant à l’ancien appareil. La vérification de la protection des données et du consentement dans la rubrique « Avant l’inscription » en fait également partie ; la procédure BYOD ne s’applique pas aux appareils de l’entreprise dotés d’un profil professionnel.

Si l’un de ces prérequis manque, arrêtez la procédure avant d’engager l’un ou l’autre des parcours de migration. Avant toute intervention en production, vérifiez le parcours choisi sur un appareil de test représentatif et autorisé. Des comptes préparés, un lot enregistré ou des options visibles dans le portail ne prouvent pas encore la réussite de l’inscription d’un appareil. Après l’inscription, contrôlez le mode de gestion, l’utilisateur associé, l’état des tâches et la stratégie effective dans Sophos Mobile et sur l’appareil.

Parcours de migration documentés

Ne mélangez pas les deux parcours documentés :

Appareil de l’entreprise, jusqu’ici en mode Administrateur de l’appareil → Android Enterprise : gestion complète de l’appareil. L’action Gerät anzeigen > Aktionen > Zurücksetzen rétablit les paramètres d’usine de l’appareil ; inscrivez-le ensuite à nouveau. Sophos cite comme voies possibles l’assistant « Gerät hinzufügen », le portail Sophos Fusion Self Service, l’inscription par code QR et l’inscription zero-touch. N’effectuez cette intervention qu’après une autorisation distincte.
Appareil personnel, jusqu’ici en mode Administrateur de l’appareil → Android Enterprise : gestion par profil professionnel. Utilisez Gerät anzeigen > Aktionen > Deregistrieren, puis Aktionen > Löschen ; n’inscrivez le profil professionnel qu’ensuite. Sophos cite l’assistant « Gerät hinzufügen » ou le portail Sophos Fusion Self Service. Cette intervention nécessite elle aussi une autorisation distincte. Pas de réinitialisation d’usine comme étape standard pour un appareil BYOD.

Ces libellés proviennent de l’aide Sophos en allemand datée du 22 septembre 2026 ; dans une console en anglais, les commandes sont Show device > Actions > Wipe, Unenroll et Delete. Vérifiez au préalable les menus, les autorisations et les méthodes d’inscription disponibles dans le tenant cible. Un Wipe de Sophos Fusion, un Zurücksetzen dans l’administration Mobile et la suppression d’un profil professionnel déjà configuré ne sont ni des termes interchangeables ni des étapes équivalentes de migration. Les appareils de l’entreprise disposant déjà d’un profil professionnel et les autres modes requièrent une décision distincte : ne les classez pas automatiquement dans ces deux catégories.

Arrêter la procédure avant toute action destructive

Appareil de l’entreprise : obtenez une autorisation écrite pour la réinitialisation d’usine de cet appareil précis ; vérifiez les données locales, les comptes professionnels, les applications, l’authentification, une sauvegarde et une restauration réellement utilisables. Une réinitialisation efface les données locales non sauvegardées. Une méthode d’inscription Android Enterprise effectivement opérationnelle, l’accès Wi-Fi ou mobile, les identifiants et les autorisations nécessaires doivent être prêts. Vérifiez au préalable, selon l’appareil et la méthode de réinitialisation, les comptes Google et les protections contre la réinitialisation. Sophos documente la Factory Reset Protection pour les appareils Android Enterprise entièrement gérés ; cela ne prouve pas que cette même configuration FRP régissait déjà la réinitialisation en ancien mode Administrateur de l’appareil. Ne promettez aucun contournement de la FRP.
Appareil personnel : clarifiez avec l’utilisateur son consentement, la distinction entre données personnelles et professionnelles et les effets de l’ancienne désinscription. La désinscription de l’ancien mode désactive l’administrateur de l’appareil Sophos Mobile Control, supprime les identifiants du serveur et les données reçues, et réinitialise Sophos Intercept X for Mobile. Confirmez d’abord la désinscription, puis supprimez l’enregistrement correspondant ; une tâche en attente ou la disparition d’une entrée de la console ne prouve pas que la gestion a bien été retirée de l’appareil. Si le profil professionnel créé ultérieurement est supprimé, ses applications et ses données locales sont perdues : cela ne restaure pas l’ancien profil. Ne garantissez pas la conservation des données personnelles sans contrôle sur l’appareil.
Appareil hors ligne, état inconnu ou appareil verrouillé : ne marquez pas l’opération comme terminée et ne déclenchez pas une deuxième suppression ou réinitialisation au hasard. Déterminez avec l’utilisateur et l’assistance Sophos ou l’assistance de l’appareil son état réel, la réception de la tâche et la voie de récupération autorisée. Une tâche envoyée depuis le cloud ne prouve pas son exécution.

Avant l’intervention, si des Restrictions sont configurées, relevez l’état réel du chiffrement de l’appareil et de la carte SD, ainsi qu’une méthode de sauvegarde et de restauration autorisée dont l’utilisabilité est démontrée. Sur certains anciens appareils, le chiffrement demandé de la carte SD peut avoir été interrompu ; l’attribution de la stratégie ne prouve pas l’état réel. Selon l’ancienne source, désactiver Allow backup désactive la sauvegarde Google, mais pas toutes les autres méthodes de sauvegarde. Les blocages USB/MTP peuvent empêcher le transfert de fichiers nécessaire. N’assouplissez pas ces blocages au hasard. Allow factory reset concerne la réinitialisation effectuée par l’utilisateur ; n’en déduisez ni l’autorisation ni la faisabilité du Wipe depuis la console, qui nécessite une autorisation distincte.

Utiliser l’ancienne stratégie comme inventaire, pas comme modèle Android Enterprise

La stratégie pour appareils Android concerne l’ancien mode Administrateur de l’appareil. Android Enterprise full device et Android Enterprise work profile disposent chacun de leurs propres familles de stratégies. Avant toute autorisation, établissez une matrice source/cible documentée pour les 14 sous-configurations anciennes ; pour chaque ligne, consignez le mode cible, le nouveau réglage pris en charge ou l’absence explicite d’équivalent, l’OS, l’OEM et la licence, les tests, les effets et la voie de retour :

Les domaines de vérification suivants doivent figurer dans cette matrice. Relevez les valeurs existantes ; il ne s’agit pas de créer de nouvelles configurations Administrateur de l’appareil. L’absence d’équivalent doit rester visible comme une décision à prendre ; des options cibles portant des noms similaires ne prouvent pas qu’elles produisent le même effet.

Connexions et certificats

Pour chaque configuration APN existante, inventoriez aussi les champs suivants :

User-friendly name, le nom supplémentaire affiché sur l’appareil ; les deux entrées Server, séparément comme serveur HTTP du trafic web et comme passerelle WAP, ainsi que le Port du serveur web.
User name et la dépendance à User password, uniquement par une référence d’identité à accès restreint et une référence sécurisée au secret ; MMSC (Multimedia Messaging Service Center), MMS proxy server et MMS proxy port séparément pour le parcours MMS.
Authentication type pour l’authentification PPP, APN type pour les types de connexion de données, Bearer pour la technologie d’accès radio, et Protocol et Roaming protocol pour les protocoles de l’opérateur sur son réseau et en itinérance.

Hormis APN, les champs anciens sont facultatifs ; indiquez explicitement les champs inutilisés comme non configurés, sans inventer de valeurs. Pour APN type, * ou un champ vide signifie tous les types de données. Une seule configuration APN peut utiliser Use as default APN. Ces significations expliquent l’état ancien, pas la création d’un nouvel APN dans l’ancien mode. Associez chaque valeur utilisée à un remplacement cible dont la prise en charge a été vérifiée séparément, ou indiquez explicitement son absence ; confirmez également l’acceptation par l’opérateur pour la SIM/l’abonnement cible. L’accès indépendant de récupération reste nécessaire.

Pour APN, consignez le point d’accès actuel, l’opérateur et la carte SIM ou l’abonnement utilisé. Vérifiez auprès de l’opérateur qu’il accepte cet APN pour l’abonnement prévu. Relevez et vérifiez également les valeurs existantes de Mobile Country Code (MCC) et Mobile Network Code (MNC) : elles limitent l’utilisation de l’ancien APN à l’opérateur indiqué. Un mauvais réglage Use as default APN peut couper les données mobiles. Conservez donc les paramètres de l’opérateur et un accès indépendant avant l’intervention ; ne modifiez pas l’APN par défaut pour faire un essai.

Pour Wi-Fi et VPN, relevez les anciens certificats Wi-Fi/EAP, le SSID et les types de VPN, puis vérifiez séparément l’accès cible ; WEP n’est pas un standard cible sûr. Testez aussi la communication avec le système de gestion via un accès indépendant.

Pour chaque configuration Wi-Fi existante, ajoutez les anciennes valeurs suivantes à la matrice :

SSID et le Security type réellement utilisé : None, WEP, WPA/WPA2 PSK, EAP/PEAP, EAP/TLS ou EAP/TTLS. None et WEP ne sont pas des recommandations pour la cible. L’ancienne documentation exclut l’attribution d’une stratégie WEP aux appareils sous Android 12 ou une version ultérieure ; cette condition historique n’ouvre aucune possibilité d’inscription dans l’ancien mode de gestion.
Phase 2 authorization, uniquement pour EAP/PEAP et EAP/TTLS : consignez le choix existant, None, PAP, CHAP, MSCHAP ou MSCHAPv2. N’ajoutez pas de valeur ancienne de ce type pour EAP/TLS.
Pour EAP, relevez séparément Identity et Anonymous identity. Cette dernière est le pseudonyme envoyé sans chiffrement pendant la phase 1 de la négociation EAP. Pour Password, documentez la dépendance au mot de passe Wi-Fi existant et la méthode sécurisée de conservation ou de mise à disposition d’un remplacement, pas le mot de passe lui-même.
Relevez Proxy host, le nom ou l’adresse IP du proxy de cette connexion Wi-Fi, et Proxy port séparément. Global HTTP proxy n’est pas un équivalent démontré de ce proxy propre à la connexion.

Pour chaque configuration VPN existante, relevez Connection name (le nom visible sur l’appareil), Server (le nom d’hôte ou l’adresse IP de la passerelle) et le Connection type réellement utilisé. L’ancienne documentation distingue les dépendances suivantes :

L2TP/IPsec (PSK): documentez l’utilisateur associé sous User et la dépendance au mot de passe sous Password, séparément de la clé d’authentification prépartagée du champ L2TP/IPsec (PSK).
L2TP/IPsec (certificate): relevez les Client certificate et Root certificate sélectionnés, ainsi que User et la dépendance à Password. Dans ce cas ancien, la sélection de certificats ne remplace pas la dépendance à l’utilisateur et au mot de passe.
Cisco AnyConnect: inventoriez séparément le fichier XML du profil VPN et celui du profil NVM (Network Visibility Module), en indiquant pour chacun le responsable, la version et une référence vers son stockage sécurisé ; signalez tout profil absent. N’en déduisez ni un import XML automatique ni une visibilité réseau équivalente dans la cible.

Ne consignez les associations d’identité que dans le journal de migration à accès restreint. Pour les mots de passe, les PSK et les clés privées, indiquez uniquement des références vers leur conservation ou leur mise à disposition sécurisée ; ne publiez ni secrets ni identités réelles sensibles dans les éléments justificatifs. Associez chaque ancienne valeur Wi-Fi utilisée et chaque dépendance VPN à un équivalent cible vérifié séparément, ou documentez explicitement son absence. Pour le VPN, vérifiez la prise en charge par l’application, l’OS, la passerelle et le mécanisme d’authentification, sans la déduire de l’ancien type de connexion. Vérifiez la signification des champs cibles, les rôles des certificats et la configuration de l’application VPN dans l’article connexions Android indiqué en lien ; les vérifications de certificats ci-dessous restent également nécessaires.

Inventoriez séparément Client certificate, Root certificate et SCEP. Les anciens certificats client et ancres de confiance dépendent de la stratégie ; SCEP exige que l’autorité de certification du serveur SCEP soit définie comme configuration racine. Vérifiez à nouveau l’identité cible, l’émission et le renouvellement, la confiance dans l’autorité de certification et l’authentification Wi-Fi/VPN ; ne désactivez jamais la vérification des certificats pour résoudre un incident.

Dans l’ancienne stratégie pour appareils Android, le certificat racine défini dans Root certificate était installé sur l’appareil lors de l’attribution de la stratégie. Pour l’inventaire des anciens appareils, documentez le fichier de certificat X.509 configuré ainsi que son encodage PEM ou DER. Chaque certificat racine supplémentaire nécessitait sa propre configuration Root certificate ; consignez donc séparément toutes les configurations racine existantes dans la matrice source/cible. L’ancienne attribution ne prouve à elle seule ni l’état réel des certificats sur l’appareil concerné ni leur reprise automatique dans Android Enterprise.

Pour chaque configuration Root certificate existante, relevez également l’ancienne stratégie et les autres configurations de cette même stratégie qui utilisent effectivement ce certificat racine, notamment pour la confiance dans les serveurs Wi-Fi/EAP, le cas échéant. Distinguez la confiance dans le serveur, l’identité du client et l’autorité de certification du serveur SCEP. Associez chaque dépendance à la stratégie et au mode cibles choisis, ou documentez l’absence d’équivalent pris en charge. Lors du pilote cible autorisé, vérifiez l’identité attendue du serveur, la confiance dans l’autorité de certification, la connexion et l’authentification ; ne supposez aucune reprise automatique.

Uniquement pour interpréter les anciens champs SCEP : URL pouvait être liée, via %_SCEPPROXYURL_%, à l’URL du serveur dans l’onglet SCEP de la page Sophos setup ; Challenge pouvait renvoyer, via %_CACHALLENGE_%, à l’URL de challenge configurée à cet endroit. Une fois les espaces réservés remplacés par les données réelles, Subject doit être un nom X.500 valide. Les anciens choix SAN signifient : RFC 822 name = une adresse e-mail valide ; DNS name = le nom DNS du serveur de l’autorité de certification (CA) ; Uniform resource identifier = l’URL entièrement qualifiée du serveur de la CA. Consignez les champs configurés et non configurés ainsi que l’identité réellement résolue dans l’inventaire à accès restreint ; pour les secrets, utilisez uniquement des références sécurisées de conservation/provisionnement. Il ne s’agit pas d’une consigne de nouveau provisionnement dans l’ancien mode ni de réutilisation des secrets de challenge. N’en déduisez pas les significations SAN de la cible et ne recopiez pas ces anciennes significations liées à la CA dans une nouvelle identité de client.

Pour chaque configuration SCEP existante, relevez les dépendances suivantes avec le service PKI/MDM compétent, sans modifier les anciennes entrées pour les déterminer :

Obtention : documentez les points de terminaison du serveur et du challenge, leurs dépendances et, le cas échéant, l’association à des variables résolue via la configuration. Ne consignez aucun mot de passe de challenge ni aucun autre secret dans le journal ou dans l’article.
Identité et sélection : relevez l’ancien alias ou la référence de sélection, le lien avec l’utilisateur ou l’appareil, l’expression Subject et le nom résolu, ainsi que les types et valeurs SAN configurés et l’AD-UPN. Signalez explicitement les champs non configurés comme absents. Lors du pilote, comparez ces informations à l’identité requise pour le service et à la sélection réelle du certificat cible ; laissez ouvertes les correspondances non prises en charge.
Lien de confiance : identifiez sans ambiguïté le certificat racine effectivement sélectionné dans l’ancienne stratégie actuelle, au besoin à l’aide de son empreinte. Vérifiez séparément la confiance dans le serveur SCEP, celle dans le certificat client émis et celle dans le serveur du service. Ne retirez pas une ancre de confiance encore nécessaire avant d’avoir constaté que la cible répond aux critères de validation.
Clé et usages : relevez la valeur existante de Key size, les exigences de compatibilité de l’autorité de certification et les sélections et usages distincts pour la signature numérique et le chiffrement. Clarifiez les exigences cibles avec la PKI et le service qui utilise le certificat, puis vérifiez lors du pilote le certificat émis et les usages requis. N’activez pas systématiquement les deux usages et ne reprenez pas automatiquement l’ancienne taille de clé.

Vérifiez indépendamment la méthode d’obtention prise en charge dans la cible, les rôles des certificats et leurs usages à l’aide du guide des connexions Android et du runbook certificats/SCEP auquel il renvoie. Ces guides cibles ne remplacent ni l’inventaire ni la vérification des effets réels dans la cible.

Identifiez aussi sans ambiguïté le Client certificate existant par une référence sécurisée au fichier réel PKCS #12 (.pfx) et au Certificate name lu dans ce fichier. Dans l’inventaire des certificats, consignez les configurations de la même ancienne stratégie qui le sélectionnent. Les autres anciennes stratégies exigeaient des chargements distincts ; c’est une dépendance ancienne, pas une consigne de nouveau provisionnement dans l’ancien mode. Ne publiez ni n’exportez de clé privée et ne supposez aucun transfert automatique vers la cible.

Applications, autorisations et mot de passe des applications

Filtre d’applications de Restrictions : relevez la valeur de Filter type séparément d’App Control : Allowed apps ou Forbidden apps, le groupe d’applications associé et ses membres, ainsi que les applications réellement concernées. Selon l’ancienne source, les applications installées par Sophos Mobile sont exclues de ce filtre ; le blocage du lancement par App Control n’est donc pas un équivalent démontré. De même, selon l’ancienne source, le blocage du navigateur natif ne concerne pas les navigateurs tiers. Pour l’objectif de protection des applications et des navigateurs, vérifiez séparément le périmètre cible et les effets réels.
App Control : Documentez l’ancien groupe d’applications sélectionné et ses membres. Ce blocage empêche leur lancement, y compris pour les applications du fabricant qui ne peuvent pas être désinstallées ; il ne les supprime pas. Pour chaque application bloquée, consignez le mode cible et le nouveau groupe auquel elle sera associée. Cela ne garantit ni un transfert automatique vers le Play Store ni un blocage des applications personnelles dans le mode cible.
App permissions : Pour chaque ancienne application, notez son identité exacte ainsi que chaque autorisation d’exécution configurée et sa valeur : Selectable signifie que l’utilisateur peut la modifier, Granted qu’elle est accordée et Denied qu’elle est refusée. Pour chaque application et autorisation, indiquez le mode cible, l’application cible, l’effet souhaité et les modifications autorisées à l’utilisateur, ou signalez l’absence d’équivalent. Dans un profil professionnel sous Android 12 ou une version ultérieure, la localisation, l’appareil photo, le microphone, les capteurs corporels et l’activité physique peuvent être refusés au nom de l’utilisateur, mais pas accordés. La décision cible doit tenir compte de cette limite.
App Protection : Relevez l’ancien groupe d’applications et ses membres, Password complexity, Grace period in minutes et Allow fingerprint authentication. Toutes les applications protégées utilisent le même mot de passe ; l’utilisateur le définit à la première ouverture de l’une d’elles. Pendant le délai configuré après la fermeture d’une application protégée, les applications protégées peuvent être ouvertes sans nouvelle demande de mot de passe. L’empreinte digitale peut remplacer le mot de passe des applications. L’ancienne protection peut être contournée par d’autres applications, des fonctions système ou les modes multifenêtres ; elle ne garantit donc pas une protection d’entreprise équivalente. Comparez indépendamment les réglages pris en charge pour la gestion complète de l’appareil et pour le profil professionnel.

Compte de messagerie et accompagnement de l’utilisateur

Pour Email account, vérifiez séparément l’application de messagerie, le cloud Exchange, l’authentification OAuth prise en charge et le flux réel des messages. Un ancien champ de mot de passe ou Allow all certificates ne constitue pas une solution de repli pour Exchange Online. Outre le serveur, les certificats et l’utilisateur associé, les valeurs anciennes suivantes doivent figurer dans le journal :

Nom du compte, parcours, transport et contenu

Relevez Account name et le Server name réel ; distinguez une adresse Exchange directe de l’URL d’un EAS proxy. outlook.office365.com s’applique au cloud Microsoft 365 mondial, pas à tous les autres clouds Microsoft. Observez le parcours de messagerie réellement approuvé, sans le remplacer sans vérification.
Relevez les valeurs résolues de Email address et Sender indépendamment de User ; %_EMAILADDRESS_% est remplacé par l’adresse réelle dans les deux champs. Les données d’identité restent dans le journal à accès restreint.
Pour Password, consignez uniquement la référence sécurisée de conservation/provisionnement et la dépendance existante : un champ ancien vide obligeait l’utilisateur à saisir le mot de passe sur l’appareil. Ce n’est pas une recommandation de repli par mot de passe à la place d’OAuth pris en charge.
Relevez les états existants de SSL/TLS et Allow all certificates, le Client certificate sélectionné et Synchronize content types. L’ancienne option de contournement n’est pas un réglage cible sûr. Associez chaque champ de messagerie utilisé à un effet cible pris en charge ou indiquez explicitement l’absence de remplacement. Dans le pilote autorisé, vérifiez l’identité réelle du compte/de l’expéditeur et du serveur, la confiance TLS et les contenus sélectionnés pour la synchronisation avec des données inoffensives ; n’utilisez ni repli par mot de passe ni contournement de la validation des certificats.

Identité dans l’ancien compte et dans le compte cible

Relevez d’abord l’ancienne valeur de User et le nom de connexion réellement obtenu à partir de cette valeur. Pour les espaces réservés %_USERNAME_% et %_EMAILADDRESS_%, les champs Exchange Login et Email Address de l’utilisateur associé doivent être renseignés dans Sophos Fusion. L’ancienne documentation indique généralement %_EMAILADDRESS_% pour Exchange Online et %_USERNAME_% pour Exchange Server. L’adresse e-mail et l’identifiant réel ne sont toutefois pas automatiquement identiques.

Consignez également Domain. Selon l’ancienne description, ce champ reste vide pour Exchange Online et contient le domaine du compte utilisateur pour Exchange Server. Ces indications expliquent l’identité utilisée par l’ancien compte. Avant toute autorisation, comparez les anciennes valeurs résolues et l’utilisateur associé à l’identité cible choisie. Vérifiez comment le nom d’utilisateur et le domaine sont représentés dans la cible ; l’authentification prise en charge doit faire l’objet de la vérification distincte décrite plus haut.

Configuration sur l’ancien appareil

Documentez l’OEM/API ainsi que le mode de configuration du compte, automatique ou manuel. L’ancienne description cite LG GATE, Samsung Knox et Sony Enterprise API pour la configuration automatique. Sur les autres appareils, l’utilisateur devait configurer l’application de messagerie à partir des détails fournis dans Sophos Mobile Control. Prévoyez un accompagnement propre au client cible et un pilote de l’application ; ne répétez pas simplement l’ancienne configuration.

Synchronisation et compte par défaut

Relevez Synchronization interval, l’intervalle entre deux synchronisations, séparément de Synchronization period, l’ancienneté des messages pris en compte. Documentez le mécanisme cible de fréquence de relève ou l’absence d’équivalent. Relevez aussi Default account et déterminez comment l’application cible choisit le compte par défaut, ou si aucun réglage géré n’est disponible.

Flux de données, format et taille des messages

Pour Allow forwarding emails et Allow use of HTML format, relevez les valeurs existantes et les décisions antérieures concernant le besoin professionnel et la protection des données. Pour chacune de ces règles, indiquez si l’application cible ou Exchange peut la faire respecter. Sinon, signalez explicitement l’absence d’équivalent.

Recopiez littéralement la valeur de Maximum attachment size in MB. Malgré le nom du champ, Sophos décrit ainsi la taille maximale d’un message électronique individuel, et non explicitement celle d’une seule pièce jointe. Vérifiez séparément l’effet pertinent pour l’exploitation et la limite appliquée par l’application cible ou Exchange.

Cas particulier des anciens appareils Sony

La source allemande indique Enterprise API de niveau 6.x ou antérieur, et la source anglaise de niveau 6 ou antérieur. Sur les appareils concernés, les informations du compte Exchange doivent correspondre à l’utilisateur associé. Mobile Control ne peut pas y transmettre l’ID ActiveSync. Au premier contact avec le proxy EAS, celui-ci recherche donc un appareil dont l’ID ActiveSync est inconnu et auquel le bon utilisateur est associé. S’il en trouve un, il lui associe l’ID envoyé par le client de messagerie et transmet la requête ; sinon, il la rejette. Vérifiez la version de l’API, l’utilisateur associé et l’identité réelle du client avant d’autoriser l’ancien compte. Observez le parcours de messagerie existant et autorisé, sans réinitialiser les identités ni contourner les contrôles d’accès. Vérifiez séparément le parcours cible ; n’appliquez pas cette ancienne condition à Gmail sous Android Enterprise.

Kiosque et sortie autorisée

Pour Kiosk mode, consignez la valeur existante de Select source (Custom, App list ou No app), l’App ID exact, l’installation réelle, l’état de l’attribution et l’état de l’appareil. Pour App list, documentez l’entrée d’application Android sélectionnée, déjà ajoutée dans Sophos Mobile, et comparez l’identité du package obtenue à App ID et à l’application réellement installée avant de l’associer à la cible. Si l’application kiosque configurée manque lors de l’attribution de l’ancienne stratégie, la tâche d’attribution de la stratégie reste Incomplete / Unvollständig jusqu’à l’installation de l’application. Face à cet ancien état, vérifiez d’abord l’identité et l’installation ; une réinitialisation ne doit pas servir de dépannage au hasard. No app signifie en revanche que les restrictions sont transmises, mais qu’aucune application ne démarre. Ne confondez pas cette valeur avec un package manquant ou une option Enterprise appelée None.

Si les fonctions de l’appareil ne sont pas désactivées, l’utilisateur peut quitter l’ancienne application kiosque et utiliser l’appareil normalement ; le seul choix d’une application ne prouve pas que l’appareil est verrouillé en mode kiosque. Documentez notamment les états existants de Allow Home button et Allow task manager, ainsi que l’accès physique ou alternatif autorisé à l’administrateur. Vérifiez l’application kiosque, son lancement et la possibilité de quitter ce mode avant la réinitialisation, puis vérifiez-les séparément dans le mode cible.

Pour Sony Enterprise API de niveau 9 ou ultérieur, l’ancienne source précise que la désactivation d’une seule des options Allow volume up, Allow volume down ou Allow volume mute désactive toutes les touches de volume. Relevez le modèle concerné, le niveau de l’API et l’ancien état. Lors du pilote cible autorisé, vérifiez les commandes du son et des touches prises en charge pour ce modèle et le mode de gestion choisi. Testez sur l’appareil le son et les touches nécessaires plutôt que de supposer que l’ancien effet sera conservé.

Knox Premium, protection au démarrage et applications administrateur

Consignez la valeur existante de Allow firmware auto update options, son responsable et la prise en charge par l’appareil/la licence. L’ancienne option fait rechercher automatiquement les mises à jour du firmware par l’appareil ; l’utilisateur ne peut pas modifier ce comportement dans les réglages de l’appareil. Cela ne signifie pas que toutes les mises à jour sont installées automatiquement. Documentez séparément le remplacement cible pris en charge ou son absence et observez le comportement réel des mises à jour dans le pilote autorisé, sans réactiver d’anciennes options.

Les anciennes Knox Premium restrictions agissent sur l’appareil Samsung Knox, et non sur le conteneur Knox. Leur application nécessite une licence Samsung Knox Premium enregistrée dans Sophos Mobile. Vérifiez séparément le type d’appareil, l’enregistrement de la licence et l’effet réel sur l’appareil. Déterminez spécifiquement la licence requise et les effets pris en charge dans le mode Enterprise cible choisi ; l’ancien enregistrement de licence ne prouve pas son transfert.

Relevez l’état existant de Enable ODE Trusted Boot verification. Selon l’ancienne description, la partition de données n’est déchiffrée au démarrage qu’avec un binaire et un noyau officiels. Clarifiez l’accès aux données et la voie de récupération autorisée avant un redémarrage ou une réinitialisation ; ne désactivez pas la vérification pour raccourcir une migration ou une récupération.

Relevez séparément Prevent installation of another administrator app et Prevent activation of another administration app. La première ancienne option empêche l’installation d’applications disposant de droits d’administrateur de l’appareil, sauf celles installées par Sophos Mobile ; la seconde empêche l’activation de ces droits. Vérifiez au préalable leur effet réel sur les applications nécessaires et le parcours d’inscription prévu, sans assouplir globalement ces blocages.

Si Allow Common Criteria mode est présent, relevez également les six anciennes conditions :

chiffrement de l’appareil activé ;
chiffrement rapide désactivé ;
chiffrement du stockage externe activé ;
seuil de tentatives infructueuses déclenchant l’effacement de l’appareil défini ;
révocation des certificats activée ;
historique des mots de passe désactivé.

Sans ces conditions, le CC Mode n’est pas appliqué selon l’ancienne source. Il s’agit de dépendances de départ, pas d’une instruction d’activer à nouveau d’anciennes options ou d’affaiblir la protection par mot de passe dans la cible. Ne testez pas l’effacement après des tentatives infructueuses sur des appareils en production. Vérifiez séparément la prise en charge actuelle, l’équivalent cible et la récupération lors du pilote autorisé ; l’ancienne description ne constitue pas une preuve de certification actuelle.

Verrouillage de l’écran et restrictions

Pour le verrouillage de l’écran existant, relevez sous Password policies la valeur de Password type et sa signification dans l’ancienne stratégie : Pattern, PIN or password exige un verrouillage de l’écran sans restriction supplémentaire ; Simple password exige un mot de passe contenant au moins une lettre, les chiffres étant autorisés ; PIN or password autorise ces deux types de verrouillage. Alphanumeric password et Complex password exigent un mot de passe contenant des lettres et des chiffres. Seul Complex password ajoute les six minima de composition indiqués ci-dessous. Ces indications décrivent la stratégie de départ ; elles ne demandent pas de créer une nouvelle stratégie dans l’ancien mode et ne garantissent pas un comportement identique dans Android Enterprise.

Pour Simple password, PIN or password, Alphanumeric password et Complex password, relevez également les valeurs disponibles : Minimum password length (nombre total de caractères), Maximum idle time before password prompt (durée d’inactivité configurée ; l’appareil peut imposer une durée plus courte), Maximum password age in days (intervalle de renouvellement ; ancienne plage de 0 à 730 jours, sans renouvellement exigé à 0), Maximum sign-in attempts (nombre de tentatives infructueuses avant l’effacement de l’appareil dans l’ancien mode) et Password history (nombre d’anciens mots de passe mémorisés dont la réutilisation est interdite). N’inventez aucune valeur pour les champs absents du type choisi. Avant toute autorisation, documentez pour le type et chaque champ l’effet cible pris en charge ou son absence explicite, l’OS/OEM et le verrouillage choisi pour l’appareil ou le profil professionnel ; ne reprenez pas automatiquement les anciennes valeurs.

Dans Password policies, pour un Complex password existant, relevez séparément les six minima : lettres, minuscules, majuscules, caractères non alphabétiques, chiffres et caractères spéciaux. Les caractères non alphabétiques et les caractères spéciaux sont des valeurs anciennes distinctes, et non une exigence unique. Comparez chaque valeur à la gestion complète de l’appareil, au verrouillage de l’appareil ou du profil professionnel choisi, ainsi qu’aux indications propres à l’OS et à l’OEM. Pour chaque minimum, documentez l’équivalent pris en charge ou son absence, ainsi que son application observée sans test destructif.

Relevez aussi Allow fingerprint authentication et Allow iris authentication, avec leurs valeurs existantes. Les anciennes méthodes de déverrouillage ne s’appliquent qu’aux appareils qui les prennent en charge. Vérifiez séparément, selon l’OS et l’OEM, les méthodes de déverrouillage disponibles et réellement autorisées dans le mode cible. L’empreinte digitale d’App Protection ou Weak biometric recognition ne prouvent pas l’existence d’un équivalent identique.

Pour Password policies et Restrictions, vérifiez la récupération, la sauvegarde ainsi que l’effet, selon l’OS et le mode, de chaque verrouillage ou restriction pertinente ; ne supposez pas les mêmes effets sur les appareils personnels et ceux de l’entreprise. Un seuil de tentatives infructueuses peut effacer l’appareil ; ne le testez pas sur des appareils en production.

Pour les Restrictions réellement utilisées, complétez la matrice jusqu’à chaque réglage pertinent : ancienne valeur, effet observé sur l’appareil, objectif de protection professionnel, OS/OEM, dépendances entre options principales et secondaires, équivalent cible pris en charge ou écart explicite autorisé. Incluez notamment le partage et l’enregistrement des données, l’utilisation des fonctions radio, de partage et des périphériques, la connectivité, les communications d’urgence et l’itinérance, les mises à jour et la récupération, les comptes, y compris la suppression du compte Google, ainsi que les sources d’installation d’applications et la désinstallation. Excluez les éléments inutilisés ou non applicables en justifiant leur exclusion. N’évaluez pas les blocages uniquement d’après leur nom : selon l’ancienne source, une interdiction de la vidéo autorise les photos et le streaming ; le presse-papiers partagé nécessite Allow clipboard. Si Bluetooth est utilisé, vérifiez aussi les appairages et profils existants ; pour le partage de connexion ou l’appareil photo sur l’écran de verrouillage, vérifiez également l’option principale. Relevez de même les valeurs secondaires SD/USB pertinentes avec leurs options principales. Un ancien blocage de Beam ne contrôle pas Quick Share. Lors du pilote cible autorisé, vérifiez les fonctions nécessaires et les flux de données interdits à l’aide de données de test inoffensives ; en l’absence d’équivalent ou si l’effet diffère, arrêtez le déploiement jusqu’à ce qu’une décision soit documentée.

Les anciennes pages décrivent les paramètres de départ, parfois datés de 2022–2023, et non la prise en charge actuelle des anciens protocoles ou des fonctions OEM sur les appareils cibles. Ces domaines de vérification indiquent les dépendances à clarifier avant la migration. Avant toute recommandation de stratégie concrète, consultez les deux stratégies cibles complètes et vérifiez votre propre tenant. Les articles distincts sur les stratégies pour appareils entièrement gérés, les stratégies des profils professionnels, les connexions Android, le BYOD et la FRP ne remplacent pas l’autorisation de migration. L’article sur la migration Exchange traite également de l’authentification de la messagerie.

Pilote, arrêt et retour arrière

Une fois le propriétaire, le tenant, les licences et la voie de récupération autorisée clarifiés, ne réalisez le pilote que sur des appareils représentatifs dont on peut se passer, pour chaque mode. Sauvegardez au préalable les données de l’appareil et les anciennes stratégies ; préparez séparément la nouvelle stratégie et la méthode d’inscription. Pendant le pilote, confirmez l’exécution de l’action sur l’appareil, contrôlez le nouveau mode de gestion et l’attribution effective, puis observez les applications, la connexion au compte et le flux de messagerie, le kiosque le cas échéant, le Wi-Fi/VPN, l’émission et le renouvellement des certificats, ainsi que les données personnelles après le passage d’un appareil BYOD. Ne décidez d’étendre la migration à d’autres appareils qu’après en avoir constaté les effets.

Consignez lors du pilote les résultats attendus et observés pour les anciennes valeurs relevées :

Données mobiles

Avec la carte SIM et l’opérateur prévus, vérifiez l’accès aux données mobiles séparément de l’accès indépendant de récupération et de gestion testé auparavant. Contrôlez ensuite la communication avec le système de gestion. Si l’accès aux données ne fonctionne pas, ne migrez aucun autre appareil ; utilisez l’accès indépendant et la procédure d’escalade autorisés au préalable.

Applications et autorisations

Vérifiez d’abord le lancement de chaque application auparavant bloquée, ainsi que celui des applications nécessaires à l’exploitation et aux situations d’urgence. Contrôlez ensuite, avec des données de test, chaque application cible et ses autorisations d’exécution. Comparez l’état attendu au fonctionnement réel de l’application lorsque l’autorisation est accordée ou refusée. Vérifiez aussi que l’utilisateur peut modifier l’autorisation comme prévu, ou que cette modification est empêchée. Tenez compte des limites d’Android 12 dans le profil professionnel.

Avant toute modification, consignez les réglages et l’attribution. Utilisez uniquement la méthode de mise à jour ou de remplacement prise en charge et testée au préalable. Si une modification de stratégie doit être annulée, confirmez la synchronisation et répétez les mêmes vérifications d’autorisations.

N’accordez pas globalement des autorisations simplement pour faire fonctionner une application. Les retirer plus tard ne récupère pas les données déjà divulguées.

Mot de passe des applications et verrouillage de l’écran

Dans la cible, vérifiez la demande de mot de passe attendue, les autres méthodes d’accès autorisées, le délai sans nouvelle demande et l’authentification. Pour le verrouillage de l’appareil ou du profil professionnel, contrôlez séparément les exigences minimales et les méthodes biométriques disponibles, sans test destructif ni tentative d’atteindre le seuil d’échecs de connexion.

Pour le verrouillage cible choisi, comparez les types de verrouillage autorisés et la longueur totale à la décision documentée, puis observez la durée réelle d’inactivité avant la demande de mot de passe, y compris les limites plus courtes imposées par l’appareil. Vérifiez le comportement de renouvellement et de réutilisation, dans la mesure où il est pris en charge, sur un compte ou un appareil de test autorisé, ou à l’aide d’éléments de statut pris en charge ; consignez explicitement toute absence de prise en charge. Sur les appareils en production, n’accélérez pas le renouvellement des mots de passe, n’affaiblissez pas la protection et n’épuisez pas les tentatives autorisées. Conservez la voie de récupération préparée et arrêtez le déploiement en cas d’écart.

Messagerie

Dans un compte de test autorisé, vérifiez avec des contenus inoffensifs le délai de réception, le compte par défaut lors de la rédaction, le transfert autorisé ou interdit, le comportement HTML et les tailles de messages pertinentes. N’utilisez aucune donnée confidentielle réelle. Comparez les résultats à la décision cible documentée, même si un réglage auparavant géré n’existe plus dans la cible.

Arrêter en cas d’écart

En cas d’écart, arrêtez le déploiement. Une configuration cible visible ne suffit pas ; déterminez d’abord la cause, l’équivalent pris en charge et une voie de retour sûre.

En cas d’absence de connexion, d’incertitude sur les données, d’erreur d’appareil ou de mode, d’échec de connexion au compte ou de blocage lié à la réinitialisation, arrêtez et faites remonter le problème. Avant toute intervention, définissez l’assistance compétente, une connexion indépendante fonctionnelle et une méthode de remise en service. Le retour arrière n’annule ni une réinitialisation d’usine ni la suppression d’un profil professionnel : la restauration n’est possible qu’à partir de sauvegardes dont l’utilisabilité est démontrée et par une nouvelle inscription autorisée ; ni l’exécution immédiate d’une tâche à distance ni des effets identiques des stratégies ne sont établis. Sans test sur le tenant et l’appareil, ne présentez pas ce texte comme une procédure de migration en production ou une garantie de réussite.