Fin de vie d’un pare-feu : comment conseiller votre client entre renouvellement…

Firewall
Cyber
Réseau
Intégrateurs IT

13 octobre 2026

Fin de vie d’un pare-feu : comment conseiller votre client entre renouvellement et FWaaS ?

Ce qu’il faut retenir

TL;DR

Une nouvelle vague de fins de support tombe entre novembre 2026 et fin 2027 : FortiGate série E, Meraki MX, WatchGuard T15/T35, arrêt définitif de Sophos UTM. Les clients dont la date est déjà passée sont les plus urgents.

Hors support, le boîtier filtre toujours, mais toute faille découverte ensuite reste ouverte, sur la catégorie d’équipement la plus visée par les attaquants.

Un boîtier peut perdre ses correctifs avant sa date de fin de support : version de système plus maintenue, mémoire trop juste pour les versions récentes, ou fonction supprimée comme le VPN SSL chez Fortinet.

Sept questions suffisent pour savoir si une étude FWaaS vaut la peine. Quand c’est le cas, le cycle de vie du matériel sort du périmètre du client.

Fin 2026 et en 2027, plusieurs gammes de pare-feux très répandues en PME et ETI arrivent en fin de support constructeur. Chez une partie de vos clients, la date est même déjà passée.

Le réflexe est de proposer le successeur du boîtier. Une fin de vie permet pourtant de vérifier que l’architecture colle encore aux usages du client : nombre de sites, télétravail, applications SaaS, ressources IT. Quand ces usages ont changé, le Firewall-as-a-Service (FWaaS) mérite d’être chiffré.

Les fins de support à venir (novembre 2026 à fin 2027)

Le tableau se limite aux gammes courantes en PME et ETI dont la fin de support tombe dans les quinze prochains mois. Les constructeurs déplacent parfois leurs dates : vérifiez chaque modèle sur le portail du constructeur avant d’agir. Dates vérifiées au 12 octobre 2026.

Fin de support	Constructeur	Modèles	À savoir
31 oct. 2026	Cisco Meraki	MX84	Des licences de 3 ans restent en vente alors que le support s’arrête avant leur terme : vérifiez avant tout renouvellement (liste EOL Meraki, communauté Meraki).
14 nov. 2026	Fortinet	FortiGate 50E, 81E	Date limite de renouvellement du contrat passée depuis novembre 2025 (portail Fortinet, flux lifecycle Fortinet).
29 déc. 2026	Fortinet	FortiGate 60E	Contrats non renouvelables depuis le 29 décembre 2025 (portail Fortinet, flux lifecycle Fortinet).
31 déc. 2026	Sophos	UTM et matériel SG	Fin de vie le 30 juin 2026. Après le 31 décembre 2026, plus aucun support, quelle que soit l’échéance de la licence, et la protection commence à se dégrader (annonce Sophos, FAQ Sophos).
1er févr. 2027	Cisco Meraki	MX100	Chez Meraki, la fin de support tombe en général cinq ans après la fin de vente (liste EOL Meraki).
1er mars 2027	WatchGuard	Firebox T15, T15-W, T35-DW, T35-R	Les T35 et T35-W sont, eux, hors support depuis le 31 décembre 2025 : vérifiez la référence exacte. Remplaçants proposés : T115-W, T125, T145 (politique EOL WatchGuard).
15 juil. et 14 oct. 2027	Fortinet	FortiGate 51E, 80E-POE (juillet), 60E-POE (octobre)	Derniers modèles de bureau de la série E encore supportés (portail Fortinet, flux lifecycle Fortinet).
26 juil. 2027	Cisco Meraki	MX64, MX64W	Fin du support constructeur (liste EOL Meraki).

Pour d’autres modèles, la date est déjà passée et le boîtier ne reçoit plus aucun correctif. Ces clients sont à appeler en premier : Cisco ASA 5506-X, 5508-X et 5516-X depuis le 31 août 2026 (avis Cisco, page de la série) ; FortiGate 30E, 61E, 70E, 101E, 300E et 500E depuis le 15 juillet 2026, 80E et 100E depuis le 17 août 2026, 90E depuis janvier 2025 (portail Fortinet) ; SonicWall Gen 6, avec les TZ 400, TZ 600 et NSa 3650 au 1er août 2026 puis les TZ 350, TZ 500 et NSA/NSa 4600 à 6650 au 1er octobre 2026 (avis SonicWall, tableaux SonicWall) ; WatchGuard Firebox T35 et T35-W depuis le 31 décembre 2025 (politique EOL WatchGuard).

Les constructeurs nomment les étapes différemment, mais le cycle est le même partout : arrêt de la vente, fin du renouvellement des contrats, fin des mises à jour, puis fin de support. Chez Fortinet, la fin de support tombe 60 mois après l’arrêt de commande, et la date limite d’extension du contrat (LSED) 12 mois avant la fin de support. Une fois la LSED passée, plus aucun contrat ne peut être prolongé (politique de cycle de vie Fortinet, communauté Fortinet). Pour relancer un client à temps, c’est donc la LSED qu’il faut suivre.

En croisant votre parc installé avec ces dates, vous obtenez la liste des clients à contacter, classée par urgence.

Ce qu’implique un pare-feu hors support

Le boîtier continue de router et de filtrer, mais tout se fige : signatures IPS, base de filtrage URL, antivirus. SonicWall, par exemple, précise qu’après la fin de support il n’assure plus ni assistance technique, ni mise à jour du firmware, ni remplacement du matériel (avis SonicWall). Et une vulnérabilité publiée après la date ne sera jamais corrigée.

C’est un problème sérieux pour un équipement exposé à Internet. Dans le rapport DBIR 2025 de Verizon, les équipements de bordure et les VPN représentent 22 % des cibles d’exploitation de vulnérabilités, contre 3 % un an plus tôt (synthèse du DBIR 2025). VulnCheck a analysé 181 vulnérabilités d’équipements de bordure exploitées en 2025 : 42,5 % touchaient des matériels en fin de vie ou probablement en fin de vie, routeurs grand public compris (rapport VulnCheck).

En septembre 2025, Cisco a confirmé une campagne active contre ses ASA 5500-X, et l’agence américaine CISA a ordonné aux administrations fédérales de déconnecter ceux qui étaient déjà hors support (directive CISA ED 25-03). En février 2026, la CISA est allée plus loin avec la directive BOD 26-02 : inventaire des équipements de bordure hors support sous trois mois, retrait de ceux déjà hors support sous douze mois. La CISA, le FBI et le NCSC britannique recommandent à toutes les organisations d’appliquer la même démarche (directive BOD 26-02, BleepingComputer).

En Europe, la directive NIS2 demande des mesures de gestion des risques qui couvrent la maintenance des systèmes et le traitement des vulnérabilités. Elle n’impose aucune technologie, mais un équipement de sécurité qui ne peut plus être corrigé se défend mal en audit.

Les limites qui arrivent avant la fin de support

Un boîtier encore couvert par le support peut déjà être dans une impasse, parce que le matériel et son système d’exploitation (FortiOS chez Fortinet, ASA chez Cisco) n’ont pas le même calendrier.

Commencez par la version du système. Une série de versions (FortiOS 7.4.x, par exemple) n’est maintenue qu’un temps. Chez Fortinet, chaque série a deux échéances : la fin du support d’ingénierie, après laquelle les versions de maintenance courantes s’arrêtent, puis la fin de support. Pour FortiOS 7.4, Fortinet a repoussé ces dates d’un an en mars 2026, au 11 mai 2027 et au 11 novembre 2028, et rappelle qu’un boîtier n’est supporté que s’il tourne sur une série encore dans son cycle de support (note Fortinet). Côté Cisco, les versions logicielles ASA 9.16, 9.18 et 9.19 ne recevront plus de correctifs de sécurité après le 18 novembre 2027, pour une fin de support le 30 novembre (avis 9.16, avis 9.18, avis 9.19). Un boîtier trop ancien pour passer sur une version plus récente perd donc ses correctifs avant sa date de fin de support matérielle.

La mémoire pose un problème voisin. Depuis FortiOS 7.4.4, les FortiGate à 2 Go de mémoire ou moins ne prennent plus en charge l’inspection en mode proxy : à la mise à jour, les politiques concernées passent en mode flux et les profils propres au proxy, comme le WAF, sont supprimés (documentation Fortinet). La liste des modèles concernés figure dans les notes de version 7.4.4. Ces boîtiers peuvent être encore sous support, et pourtant la mise à jour qui leur apporte les correctifs leur retire une fonction de sécurité.

Enfin, certaines fonctions disparaissent. Depuis FortiOS 7.6.3, le mode tunnel du VPN SSL est remplacé par un VPN IPsec, qui peut passer par le port TCP 443 (documentation Fortinet). La configuration SSL existante n’est pas reprise lors de la mise à jour : sans migration préalable, les nomades perdent leur accès (note technique Fortinet). Sur plusieurs modèles de bureau, le mode web (désormais appelé Agentless VPN) n’est plus pris en charge non plus (note technique Fortinet).

Pour chaque boîtier, relevez donc le modèle, la version logicielle, la mémoire et le type de VPN nomade. Si l’accès distant doit être reconstruit de toute façon, autant le faire dans la cible définitive que sur un boîtier remplacé deux ans plus tard.

Avant de renouveler : 7 questions à poser

Chaque réponse donne une tendance, aucune ne suffit à trancher catégoriquement.

Question	Oriente vers un pare-feu local	Oriente vers le FWaaS
Combien de sites ?	Un site	Plusieurs sites
Où travaillent les utilisateurs ?	Surtout sur site	Télétravail et nomades importants
Où sont les applications ?	Beaucoup de serveurs locaux	Surtout SaaS et cloud
Qui administre le pare-feu ?	Équipe réseau disponible	Peu de ressources internes
Quel trafic circule entre les ressources locales ?	Flux est-ouest importants (VLAN, serveurs), faible latence exigée	Usages surtout tournés vers Internet
Quelles contraintes d’architecture ?	Exigence réglementaire ou contractuelle d’un équipement local	Aucune contrainte particulière
Quelle échéance de support ?	Ne départage pas les options : elle fixe le calendrier. Moins de 12 mois ou date dépassée, l’audit démarre tout de suite.

Certains critères pèsent plus que d’autres : des flux locaux importants ou une contrainte d’architecture forte peuvent suffire à justifier le maintien d’un pare-feu local.

À relever aussi avant de chiffrer :

le débit réel avec IPS, antivirus et inspection SSL activés (le débit brut de la fiche produit ne le reflète pas) ;
le modèle, la version logicielle et la mémoire de chaque boîtier, pour repérer les plafonds décrits plus haut ;
le nombre de tunnels VPN site-à-site, le nombre de nomades et le type de VPN utilisé (SSL ou IPsec, client installé) ;
le volume de règles et d’objets, dont une part est souvent obsolète : une migration est l’occasion de nettoyer ;
les fonctions réellement utilisées : segmentation VLAN, serveurs publiés, haute disponibilité, NAT, SD-WAN, interfaces physiques ;
la prise en charge de la cryptographie post-quantique, que Gartner cite parmi les moteurs des renouvellements de pare-feux (résumé du rapport).

Votre client est-il candidat au FWaaS ?

Le diagnostic reprend ces critères. Son résultat indique si une étude FWaaS vaut la peine d’être ouverte.

Les trois profils du diagnostic

Profil 1 : le pare-feu local reste justifié

Un site principal, des applications surtout locales, des flux internes importants ou une exigence d’équipement sur site : le besoin reste proche de celui de l’installation d’origine. Le FWaaS ne répond pas à ce besoin, et mieux vaut le dire au client. Le renouvellement est alors l’occasion de redimensionner le débit, d’assainir les règles et de revoir la haute disponibilité.

Profil 2 : une étude comparative s’impose

Le réseau a changé depuis l’installation : agences ouvertes, télétravail, applications passées en SaaS, mais une partie des flux reste locale. Le remplacement à l’identique n’est plus la seule option à chiffrer. Cartographiez ce qui reste local et ce qui part vers Internet, puis comparez les deux modèles sur trois à cinq ans.

Profil 3 : le FWaaS est la cible naturelle

Quand ces évolutions sont devenues la norme, le boîtier local a perdu une bonne partie de son intérêt. Le FWaaS déplace le filtrage vers un pare-feu hébergé et administré par le fournisseur. La fin de vie devient alors son affaire : les mises à jour, la maintenance et le maintien en conditions opérationnelles passent du côté du fournisseur, et il n’y a plus de matériel à renouveler chez le client (Firewall Cloud inherent_partners).

Côté architecture, les sites rejoignent le pare-feu hébergé par le réseau privé (MPLS) ou par des tunnels IPsec, et les nomades par VPN. Vérifiez le chemin réseau de chaque site : le FWaaS reste moins pertinent quand le trafic entre serveurs locaux est important, surtout si le détour par une infrastructure distante ajoute de la latence.

Voir notre guide Comment choisir un Firewall-as-a-Service et notre article sur l’impact de NIS2 sur le firewall.

Budget : l’effet de la hausse des prix mémoire

Gartner attend une hausse de 130 % des prix combinés DRAM et SSD d’ici fin 2026. L’étude porte sur les PC et les smartphones, et ce chiffre ne se retrouve pas tel quel sur un pare-feu, dont la nomenclature comprend aussi le processeur ou l’ASIC, les interfaces, l’alimentation et le châssis.

Fortinet a donné un ordre de grandeur dans ses résultats du quatrième trimestre 2025 : la direction y situe la mémoire entre 10 et 20 % du coût de ses produits et annonce des hausses de prix de 5 à 20 % selon les appliances. Les autres constructeurs n’ont pas tous publié de chiffres comparables.

La pénurie peut aussi raccourcir la vie d’un boîtier. En 2021, Ivanti annonçait un support de ses appliances ISA jusqu’à fin 2031 (politique Ivanti). Les ISA 6000 et 8000 seront finalement hors support le 31 janvier 2027, parce que la mémoire DDR4 qu’elles utilisent n’est plus produite (synthèse de l’avis Ivanti).

Pour un client qui reste sur un boîtier, mieux vaut ne pas compter sur une baisse prochaine : verrouillez le prix et le délai dès que le projet est validé, et prévoyez de la marge de capacité. Le FWaaS remplace cet investissement par un abonnement, sans achat d’équipement ni renouvellement à financer ; regardez dans le contrat les conditions d’évolution du tarif.

Pour comparer les deux modèles, chiffrez sur trois à cinq ans : d’un côté le matériel, les licences, la maintenance, les interventions, la supervision, la migration et le temps d’exploitation, de l’autre l’abonnement et la part d’exploitation qui reste à votre charge.

Migrer sans rupture

Auditer le parc : modèles, versions logicielles, mémoire, licences, date limite de renouvellement et date de fin de support.
Cartographier les sites, les VPN, les flux, les serveurs publiés et les accès distants.
Préparer la bascule : exporter la configuration, nettoyer les règles, monter les tunnels et valider les politiques en amont.
Faire coexister l’ancien et le nouveau pare-feu le temps de la validation, avec une bascule par étapes : un site, un VLAN ou un groupe d’utilisateurs à la fois.
Basculer sur une fenêtre convenue, puis décommissionner l’ancien boîtier et effacer sa configuration et ses identifiants.

Quand le parc est déjà en FortiGate, la migration vers un FortiGate hébergé reste dans l’écosystème FortiOS : les règles, objets et tunnels gardent la même logique, ce qui limite le travail de conversion.

Le Firewall Cloud inherent_partners repose sur la technologie FortiGate de Fortinet. Il est hébergé sur l’infrastructure inherent_partners et administré par nos équipes. Il couvre le filtrage stateful, le filtrage web, l’antivirus, le contrôle applicatif, l’IPS, la protection anti-DDoS et le VPN.

Découvrir le Firewall Cloud inherent_partners

Le rôle du partenaire

Une fin de support donne une raison de reprendre contact avec le client et de revoir avec lui ses usages, ses sites et ses accès distants. Le sujet dépasse vite le boîtier pour devenir un projet réseau, que vous portez de l’audit à la migration.

Le passage au FWaaS change ensuite la nature de votre travail. Les sujets liés au matériel sortent de votre agenda : choix du modèle, suivi des versions de firmware, dates de fin de support, remplacement d’un boîtier en panne. Vous vous concentrez sur l’exploitation (règles, accès distants, supervision) et sur ce que le client attend de sa sécurité.

Ce temps gagné vous permet d’élargir la discussion au-delà du pare-feu. Un FWaaS ne voit pas ce qui se passe sur les postes et ne protège pas les données face à un rançongiciel. C’est l’occasion de parler EDR et sauvegarde, et de construire avec le client une couverture cyber plus complète (voir notre article FWaaS, EDR et BaaS : bâtir une offre cyber pour TPE/PME).

Vous réduisez aussi votre exposition. Une mise à jour oubliée ou une fin de support passée inaperçue suffit à abîmer une relation client, et c’était jusqu’ici à vous d’y veiller. Ces tâches ne relèvent plus de vous, et vos échanges avec le client portent sur ses projets plutôt que sur l’état de ses boîtiers.

FAQ

Peut-on encore utiliser un pare-feu hors support ?

Techniquement oui, mais sans correctifs ni nouvelles signatures, et sans remplacement en cas de panne. Le risque augmente avec le temps, sur un équipement exposé à Internet, et il se défend mal en cas d’audit.

Comment identifier les pare-feux en fin de vie chez ses clients ?

Relevez modèle, version logicielle et licences de chaque équipement installé, puis comparez-les aux calendriers publiés par les constructeurs. Notez l’arrêt de la vente, la fin du renouvellement des contrats, la fin des mises à jour et la fin de support.

Quand faut-il remplacer un pare-feu ?

Avant la date limite de renouvellement du contrat, qui tombe 12 mois avant la fin de support chez Fortinet. Lancer l’audit 12 à 24 mois avant l’échéance laisse le choix de l’architecture.

Mon pare-feu est encore supporté : suis-je tranquille ?

Pas forcément. Vérifiez que le boîtier peut passer sur les versions récentes de son système et qu’il conserve les fonctions utilisées, notamment le VPN nomade. Un modèle à faible mémoire peut perdre des fonctions de sécurité avant sa date de fin de support.

Le FWaaS remplace-t-il un pare-feu matériel ?

Pas systématiquement pour votre client. Le FWaaS convient bien aux entreprises multi-sites, très SaaS ou avec beaucoup de nomades. Des flux locaux importants ou de fortes contraintes d’architecture peuvent justifier de garder un pare-feu local.

De votre côté, le calcul est différent. Si vous gérez les pare-feux d’une vingtaine de petits clients monosite, vous administrez en fait un parc de vingt boîtiers, avec autant de firmwares à suivre, de fins de support à surveiller et d’interventions sur place. C’est la situation d’un DSI multi-sites. Même chez un client monosite, le FWaaS vous libère des contraintes du boîtier et vous permet de gérer tous vos clients de la même façon.

La NIS2 impose-t-elle un pare-feu physique ?

Non. La directive demande des mesures de gestion des risques proportionnées, dont la maintenance des systèmes et le traitement des vulnérabilités, sans imposer de technologie. Pour une organisation soumise à un référentiel précis, l’architecture se valide au regard de ce référentiel.

Comment migrer un pare-feu sans interruption ?

En préparant le nouveau pare-feu hors production, puis en basculant par étapes (site par site ou segment par segment) pour qu’aucun flux ne traverse les deux équipements. L’ancien boîtier reste configuré, prêt à reprendre le trafic si un retour arrière est nécessaire.

Fin de support à l’horizon

Un client dont le pare-feu arrive en fin de vie ?

Commencez par la liste des clients concernés, puis passez chacun au diagnostic. Pour un projet FWaaS, nos équipes vous accompagnent dans l’étude et la migration.

Évaluer un projet Firewall Cloud