Planifier les prérequis et le cycle de vie de Sophos Endpoint

Un agent installé ne reste pas automatiquement pris en charge à long terme. Système d’exploitation, architecture, composants Sophos, certificats et modèle de licence évoluent indépendamment. Une exploitation Endpoint fiable vérifie donc non seulement si l’installation fonctionne aujourd’hui, mais aussi quand les plateformes cessent d’être prises en charge et comment les nouvelles versions de l’agent sont introduites.

Périmètre : Endpoint n’est ni serveur ni Linux

Ce guide concerne Sophos Endpoint pour les postes Windows et macOS. Windows Server est géré dans Server Protection ; les charges Linux utilisent Sophos Protection for Linux, avec leurs propres prérequis, notes de version et échéances. Une ligne serveur ou Linux du Retirement Calendar commun ne valide donc pas Endpoint et relève d’une procédure distincte.

État de planification vérifié au 29 octobre 2026

Version produit, système d’exploitation et contrat de support imposent des limites distinctes :

Les versions Windows Core Agent et macOS sont documentées, sans garantie qu’elles soient déjà proposées à chaque tenant. Un composant Sophos mis à jour ne change pas non plus la fin de support du système. Microsoft ESU couvre le système d’exploitation ; Sophos Endpoint for Legacy Platforms concerne la protection Sophos. Aucun de ces deux produits n’inclut automatiquement l’autre. Pour un ancien appareil, les deux droits et leurs échéances doivent être traçables.

Exemple : un appareil Windows 10 Pro dont l’état Sophos est sain ne retrouve pas pour autant le support Microsoft standard. Avant d’approuver la poursuite de son exploitation, consigner séparément build et édition OS, droit ESU éventuel, support Sophos précis et date de migration ferme. Évaluer un appareil LTSC selon sa propre entrée produit, pas selon l’échéance Home/Pro.

Limite de portée : les prérequis suivants ont été recoupés le 29 octobre 2026 avec la KBA Windows du 18 septembre, la KBA macOS du 28 septembre et le Retirement Calendar du 9 octobre 2026. Les ressources requises, la prise en charge du système et sa fin de support sont évaluées ensemble. Une version de système encore répertoriée peut déjà approcher de son échéance de Retirement.

Instantané d’approbation et décision de cycle de vie

Les numéros de version précis et les limites de prise en charge deviennent vite obsolètes. Le responsable du cycle de vie effectue donc le même contrôle encadré avant une première installation, une mise à niveau du système d’exploitation, un changement de package et au moins une fois par mois. Il part d’un instantané d’inventaire comprenant le type d’appareil, l’édition et le build complet du système, l’architecture, le processeur, la mémoire, l’espace libre sur le disque système, le chiffrement, le périmètre de protection requis ainsi que les composants Sophos installés et leurs versions.

Pour chaque nouvelle approbation, ouvrir les exigences Windows, les exigences macOS et le Retirement Calendar pour les plateformes et systèmes d’exploitation, tenus à jour en ligne, et les recouper ensemble. Le registre d’approbation contient la date du contrôle, l’entrée examinée, la plateforme et l’architecture, l’éligibilité à l’installation et à la mise à niveau, les prérequis minimaux, les exclusions, Maintenance, Retirement, les conditions de licence ou d’Extended Support et chaque note de bas de page. Un instantané conservé atteste une décision, mais ne constitue pas une liste de prise en charge permanente ; il est remplacé au changement suivant et l’écart est consigné.

La décision est approuvé, pilote uniquement, migration requise ou non approuvé. Elle indique le responsable, le périmètre, les fonctions nécessaires, les restrictions connues, les échéances de l’éditeur et de Sophos, la cible de migration et la date du prochain contrôle. Si l’entrée exacte système/architecture manque, si les informations se contredisent ou si la matrice est inaccessible, aucune nouvelle approbation n’est accordée : le dernier état approuvé reste inchangé, le responsable consigne l’heure de consultation et l’ambiguïté, puis la résout avec Sophos Support avant le pilote.

Prérequis Windows et limites de prise en charge

Le tableau des prérequis Windows distingue explicitement le périmètre de protection. Ces valeurs concernent les postes de travail, pas Windows Server :

Sophos recommande vivement un SSD comme disque de démarrage. Les exigences de ressources s’appliquent aussi au mode Sensor ; celui-ci n’est pas pris en charge sur les plateformes Legacy. Les valeurs matérielles seules ne rendent pas à un ancien système une prise en charge complète.

La KBA classe Windows 10 64 bits et Windows 11 parmi les plateformes entièrement prises en charge. La KBA ARM64 complémentaire du 27 octobre 2026 confirme explicitement Windows 10 et Windows 11 sur ARM64 ; Insider Preview n’est pas pris en charge. Windows 7 et 8.1 nécessitent Extended Support pour la prise en charge Legacy ; Windows 10 32 bits est également classé Legacy. Les échéances Microsoft et l’entrée Retirement précise de Sophos restent applicables en parallèle. Pour Windows 10 en particulier, « entièrement pris en charge » dans le tableau Sophos ne doit pas être confondu avec le support Microsoft standard.

Pour Windows, vérifiez séparément l’édition et le build complet, x64 ou ARM64, le processeur et la mémoire, l’espace libre et le disque système, les mises à jour et certificats Microsoft requis ainsi que le mode de protection souhaité par rapport à l’entrée actuelle. Les valeurs minimales sont des conditions d’accès, pas des recommandations de capacité. Distinguer aussi l’espace disque libre nécessaire à l’installation et aux mises à jour de la RAM. Une recommandation pour des charges EDR, XDR ou MDR n’est pas reprise comme minimum d’une autre offre ; la colonne et le périmètre licencié doivent correspondre à l’appareil. Les builds Insider, Preview et autres préversions ne sont pas approuvés, sauf si l’entrée exacte les inclut expressément.

Consignez également la date de fin de support Microsoft pour cette édition et cette branche de version précises. Réussite de l’installation, état sain et prise en charge actuelle de la plateforme sont trois constats distincts. Windows Server n’est pas un Endpoint Windows, même avec un build similaire, et sort du périmètre de cette approbation.

Prérequis macOS et limites de prise en charge

Pour macOS, vérifiez la version complète du système, Intel ou Apple Silicon, l’espace libre, le mode d’installation et le périmètre de protection requis. Le dossier d’approbation contient aussi les profils MDM utilisés pour System Extensions, Network Extensions, le filtrage web/contenu, Full Disk Access et les notifications. Une ligne de système correspondante ne prouve donc pas à elle seule l’efficacité de la protection.

Prérequis et échéances vérifiés le 29 octobre 2026 : la KBA macOS du 28 septembre 2026 répertorie macOS 14, 15, 26 et 27, les Mac Intel 64 bits et Apple Silicon M Series. Pour Endpoint Protection et Intercept X Advanced (MDR Included), elle indique dans chaque cas 2 GB de RAM et 2 GB d’espace disque libre. Les notes de version indiquent l’agent 2026.2.0 pour macOS 27 Golden Gate.

Cette liste de systèmes doit être lue avec le Retirement Calendar plus récent du 9 octobre 2026 : macOS 14 Sonoma atteint son Retirement fin octobre 2026, macOS 15 Sequoia fin octobre 2027. Le calendrier vérifié ne prévoit encore aucune échéance de Retirement pour macOS 26 et 27. Cela ne garantit pas une prise en charge illimitée. Selon ce calendrier, il n’existe aucun Extended Support pour macOS. Un Mac encore sous Sonoma a donc besoin dès maintenant d’un parcours de mise à niveau validé ; sa présence dans le tableau des prérequis ne prolonge pas son échéance.

Le tableau commun Sophos ne garantit pas que chaque architecture répertoriée puisse exécuter chaque version de macOS : Apple exige Apple Silicon pour macOS 27 ; les Mac Intel ne sont pas éligibles. Apple inclut les Mac M-Series et A-Series, tandis que Sophos mentionne explicitement M Series dans sa matrice. L’approbation d’Apple seule ne confirme donc pas la prise en charge par Sophos sur un Mac A-Series. Il faut clarifier cette combinaison avec Sophos avant toute nouvelle approbation, plutôt que de déduire une prise en charge ou son absence de la formulation. Installer Sophos Endpoint sur macOS décrit la procédure concrète d’installation et de validation.

Testez toute nouvelle version majeure ou mineure de macOS, y compris l’éligibilité actuelle de l’installateur et de la mise à niveau, sur un Mac pilote représentatif. Consignez explicitement les différences entre une installation neuve et un agent existant ; « macOS pris en charge » ne signifie pas que les deux parcours ou toutes les fonctions le sont. N’acceptez Extended Support que si l’entrée macOS exacte le précise.

Contrôle des composants et des versions

Sophos Endpoint comprend plusieurs composants mis à jour indépendamment : AutoUpdate, Endpoint Defense, Health Service, Management Communication, Network Threat Protection, Endpoint UI et d’autres modules selon la licence. Un niveau de produit affiché dans Central ou un seul numéro de version local ne décrit donc pas l’état global.

À cette étape précise, le responsable du cycle de vie ouvre, selon la plateforme, le flux actualisé Sophos Core Agent pour Windows ou Sophos Anti-Virus pour macOS. À chaque contrôle, il y relève directement le build cible, l’état du déploiement, les correctifs et les restrictions connues. Le registre de version atteste ce contrôle ponctuel et ne dispense pas d’un nouveau contrôle lors de la revue suivante.

Le registre de version consigne l’heure, la plateforme, le nœud produit/version sélectionné, l’avis de publication et de déploiement, les builds des composants, les correctifs, les problèmes connus et les écarts avec l’entrée précédente. Le responsable associe chaque élément aux fonctions utilisées et aux appareils pilotes, puis décide approuver, différer ou refuser. Un flux vide, indisponible ou contradictoire ne vaut pas approbation : conserver la capture ou l’erreur, vérifier les paramètres de sélection et l’accès réseau, réessayer plus tard et faire clarifier toute ambiguïté persistante par Sophos Support. L’affectation du package et la vague suivante restent bloquées jusque-là.

Tester ressources et logiciels tiers dans le pilote

Le minimum officiel n’est qu’un seuil d’entrée. Un pilote représentatif mesure démarrage, ouverture de session, CPU, mémoire, espace libre et I/O avec les applications réelles. SSD/HDD, chiffrement, DLP, sauvegarde, VPN, prise en main à distance et allowlisting sont des attributs explicites de l’échantillon.

En cas de régression, utilisez Sophos Performance Analysis et les logs des composants. Ne désactivez pas globalement protection ou Event Journals. Toute mesure temporaire ciblée exige responsable, échéance, acceptation du risque et nouveau test ; la solution durable peut être un correctif éditeur, une mise à niveau ou un remplacement matériel.

Comprendre le déploiement progressif

Sophos publie parfois les notes de version le premier jour d’un déploiement qui dure plusieurs semaines. Une nouvelle version documentée n’est donc pas nécessairement disponible immédiatement sur chaque tenant ou Endpoint.

Cela évite deux erreurs d’interprétation :

• Un appareil n’est pas automatiquement obsolète parce qu’il n’a pas reçu la nouvelle version le jour de la publication.
• Une réinstallation manuelle ne force pas de manière fiable un niveau logiciel qui n’a pas encore été publié.

Niveaux pilote et production

Software Packages et Update Management Policies permettent un déploiement contrôlé :

1. Pilote : IT et combinaisons représentatives de matériel, OS et logiciels.
2. Production initiale : petit échantillon après validation des critères.
3. Production : affectation large après approbation du changement.
4. Package fixe : uniquement pour un besoin justifié, avec responsable et expiration surveillée.

Vérifiez dans Sophos Fusion (anciennement Sophos Central) et sur la page actuelle Software packages les noms, disponibilité, type de support, expiration et chevauchement. Cet article ne fige aucune durée. Les mises à jour de contenu de sécurité sont distinctes des versions produit.

Définissez appareils sains, composants attendus, absence de concentration d’alertes et performances acceptables comme critères. Préparez aussi le retour arrière : suspendre l’affectation, isoler le groupe, conserver les affectations de stratégie et de package, réaffecter un package actuellement proposé par Sophos et testé, puis contrôler l’état. Un retour manuel à une version antérieure ou un ancien installateur n’est pas fiable.

Extended Support est transitoire

Comprendre le nom de licence : Sophos nomme l’option correspondante Sophos Endpoint for Legacy Platforms ; son ancien nom était Central Extended Support for Server 2012/2012 R2. Elle complète des droits Endpoint ou Workload Protection valides, sans les remplacer. L’annonce du 28 août 2025 décrit des plateformes Windows et Linux anciennes, pas une prise en charge actuelle et permanente des OS. Pour commander, comparer plateforme exacte, durée et périmètre confirmé à l’offre. Ne pas en déduire la couverture de toutes les anciennes versions Windows/Linux ni celle de macOS ancien.

« Legacy » ou « Extended Support » est une transition, pas une validation générale. Vérifiez dans le Retirement Calendar actuel l’entrée exacte de l’OS client, les dates de Maintenance et Retirement, les fonctions disponibles et la licence éventuelle. Fixez une échéance de migration à chaque appareil.

Les lignes Windows Server et Linux n’appartiennent pas au groupe Endpoint. Planifiez-les selon les exigences et licences propres à Server Protection ou Sophos Protection for Linux. Ne présumez pas d’Extended Support pour macOS sans déclaration explicite de Sophos pour la version exacte.

Planifier les redémarrages

Sophos ne force pas toujours immédiatement un redémarrage requis. Les mises à jour de protection et de détection peuvent se poursuivre pendant qu’un composant attend le prochain redémarrage de maintenance.

Sur les appareils qui n’ont pas redémarré depuis longtemps, plusieurs états de mise à jour peuvent nécessiter chacun un redémarrage successif. Il faut laisser assez de temps entre deux cycles pour que la première mise à jour soit entièrement traitée. Les alertes Central et l’état logiciel local sont vérifiés après chaque redémarrage.

Early Access Programs

Un Early Access Program n’est pas un canal de production normal. Avant de le rejoindre, l’objectif, les appareils cibles, les changements attendus, la procédure de recours au support, le plan de sortie et les conséquences sur la protection des données sont définis.

Les appareils EAP appartiennent à un groupe pilote clairement nommé. Après la sortie, il faut vérifier quand ils retrouvent la version logicielle normale. Un EAP n’est pas activé sur des appareils critiques uniquement pour contourner un problème sans analyse de cause.

Appliquer, valider et diagnostiquer

Le technicien chargé de l’exécution n’applique au groupe pilote défini que le package approuvé dans le registre d’approbation ; les changements improvisés d’installateur, les retours manuels à une version antérieure et les anciens packages d’installation sont exclus. Il conserve d’abord le groupe d’appareils, les affectations de stratégie et de package, les versions des composants, l’état de santé, les alertes ouvertes et un test fonctionnel reproductible. Le groupe cible et les critères de réussite restent inchangés pendant l’observation.

Après l’installation, la mise à jour et chaque redémarrage requis, contrôlez dans Central Last active, l’état de santé et les alertes, puis localement l’état des services et les versions attendues des composants. Répétez ensuite les mêmes tests avant/après : connexion et temps de démarrage, réception des stratégies, capacité de mise à jour, test de logiciel malveillant selon la procédure interne, protection réseau/web et toutes les fonctions soumises à licence. Sous macOS, prouvez aussi que les extensions et autorisations de confidentialité sont actives. Le responsable rapproche le résultat du registre de version et du registre d’approbation et consigne les écarts dans les deux ; seul un pilote entièrement réussi ouvre la vague suivante.

Commencez par classer l’échec : plateforme non approuvée, installateur bloqué, composant obsolète, déploiement pas encore proposé, redémarrage en attente, autorisation MDM absente ou conflit tiers. Rassemblez heure, appareil, build complet, architecture, package et stratégie Central, toutes les versions, santé/alertes, état du redémarrage, étapes reproductibles et logs pertinents. Arrêtez ensuite l’affectation à d’autres appareils et annulez isolément le dernier changement si Central propose à cette fin un package actuel déjà testé. Ne désactivez pas globalement la protection et n’imposez pas un ancien installateur. Si la cause ou un retour sûr reste incertain, isolez le pilote, passez le registre de version à différé et transmettez ce dossier de diagnostic à Sophos Support.

Contrôle mensuel du cycle de vie

Un rythme d’exploitation pertinent comprend :

• vérifier les nouvelles notes de version d’Endpoint et de Central,
• comparer Retirement Calendar aux plateformes utilisées,
• exporter les appareils par système, architecture et Agent Mode,
• attribuer un responsable aux appareils anciens et inactifs,
• contrôler les packages Fixed Term ou LTS arrivant à expiration,
• traiter les alertes de redémarrage et de mise à jour,
• documenter les résultats du pilote.

L’architecture technique des mises à jour est expliquée dans Mises à jour de Sophos Endpoint, cache et Message Relay.

Questions fréquentes