Retour au blog
UEM

L’UEM ne doit plus seulement voir les vulnérabilités. Il doit aider à les corriger.

Omnissa relie vulnérabilités, endpoints Windows et actions UEM pour aider les équipes IT à prioriser les risques et corriger plus vite.

6 min
omnissa-uem-vulnerability-defense-remediation-16x9.png

Pendant longtemps, l’UEM a surtout été présenté comme l’outil qui permet de gérer les terminaux.

Enrôler un poste. Appliquer un profil. Déployer une application. Vérifier une conformité. Pousser une mise à jour.

C’était déjà utile :)

Mais ce n’est plus suffisant.

Avec l’accélération des vulnérabilités exploitées, la pression réglementaire et des environnements de travail de plus en plus hybrides, la question n’est plus seulement de savoir si un terminal est managé. La vraie question devient : que fait-on lorsqu’il expose réellement l’entreprise ?

C’est précisément là que Workspace ONE Vulnerability Defense devient intéressant.

La fonctionnalité est apparue avec Workspace ONE UEM 2604, publié au printemps 2026, en disponibilité limitée. Ce point mérite d’être posé clairement : nous ne parlons pas ici d’une simple évolution cosmétique de console, mais d’un composant qui rapproche trois sujets habituellement séparés dans les organisations : l’évaluation des vulnérabilités, la priorisation du risque et la remédiation par Workspace ONE UEM.

Autrement dit, l’UEM ne sert plus uniquement à administrer le parc.

Il commence à devenir un bras opérationnel de la cybersécurité.

01_omnissa-vulnerability-defense-dashboard

Vue Workspace ONE Vulnerability Defense affichant les vulnérabilités détectées et les indicateurs de risque associés.

Voir ne suffit plus

Dans beaucoup d’organisations, la gestion des vulnérabilités suit encore un parcours assez laborieux.

Un outil sécurité détecte une faille. Un autre outil liste les terminaux concernés. Une équipe analyse la criticité. Une autre cherche comment corriger. Puis quelqu’un ouvre un ticket pour demander à l’équipe poste de travail de déployer le correctif.

Sur le papier, tout cela fonctionne.

Dans la vraie vie, chaque passage de relais ajoute du délai, de l’incertitude et parfois un peu de confusion. La vulnérabilité, elle, n’attend pas poliment la fin du workflow.

Workspace ONE Vulnerability Defense tente justement de réduire cette distance entre le signal et l’action.

Techniquement, la brique repose sur une intégration entre Workspace ONE UEM et CrowdStrike Falcon Exposure Management. CrowdStrike apporte l’évaluation des vulnérabilités et les recommandations. Workspace ONE UEM apporte l’inventaire des terminaux Windows managés, les capacités de distribution applicative, les correctifs Windows, les groupes d’assignation et le suivi d’exécution.

L’intérêt n’est donc pas seulement d’avoir un tableau de bord de plus. L’intérêt est de relier une exposition détectée à un périmètre réel de terminaux, puis à une action possible dans la console UEM.

Les signaux utilisés pour prioriser

Dans la vue Vulnerability Defense, l’administrateur peut trier et filtrer les vulnérabilités avec plusieurs indicateurs. C’est important, parce qu’une vulnérabilité ne se traite pas uniquement sur son score CVSS.

Omnissa documente notamment les critères suivants : score CVSS, niveau ExPRT.AI fourni par CrowdStrike, statut Known Exploited, nombre de terminaux impactés et date de première détection.

Dans le détail d’une vulnérabilité, l’administrateur peut retrouver la description NVD, le vecteur CVSS, le statut KEV lorsqu’il est disponible, les produits impactés, le nombre de devices concernés, l’âge moyen de la vulnérabilité dans l’environnement et la date de première détection.

Cette granularité change la discussion.

Une faille critique sur un logiciel présent sur trois machines isolées ne se pilote pas comme une vulnérabilité de criticité moyenne installée sur cinq cents postes commerciaux. Le score reste utile. Mais l’exposition réelle, la présence dans le catalogue CISA KEV, la recommandation CrowdStrike et le nombre de devices concernés donnent une lecture beaucoup plus opérationnelle.

C’est exactement ce que les équipes terrain attendent d’un outil de remédiation : moins de théorie, plus de contexte exploitable.

Les prérequis à ne pas oublier

Pour utiliser Workspace ONE Vulnerability Defense, la documentation Omnissa pose plusieurs prérequis.

Côté Omnissa, il faut Workspace ONE UEM 2604 ou version ultérieure et une licence additionnelle Workspace ONE Vulnerability Defense. Le fait que la fonctionnalité soit en disponibilité limitée signifie aussi qu’un accès doit être demandé via l’équipe de compte Omnissa. Ce n’est donc pas une case que l’on active un vendredi soir en espérant que tout soit propre le lundi matin.

Côté CrowdStrike, l’organisation doit disposer de CrowdStrike Exposure Management, du Falcon Sensor déployé sur les terminaux Windows concernés et d’un accès à la console Falcon pour créer des identifiants API OAuth 2.0.

L’intégration demande ensuite de générer un client OAuth dans Falcon avec des droits de lecture sur plusieurs scopes : API Integrations, Apps, Detections, Hosts, Assets et Vulnerabilities. Dans Workspace ONE UEM, la configuration se fait au niveau d’un Organization Group de type Customer, depuis Groups & Settings > Configurations > Vulnerability Defense, puis Add Provider > CrowdStrike.

Les champs à renseigner sont classiques, mais sensibles : Service URL, Client ID et Client Secret. La console permet ensuite de valider les identifiants, d’enregistrer la configuration et de connecter le fournisseur.

Dit autrement : avant de parler dashboard, il faut vérifier la base. Version UEM, licence, périmètre Windows réellement managé, capteur CrowdStrike en place, droits API propres et bon niveau d’Organization Group.

Sinon, l’histoire commence déjà mal.

Prioriser, puis corriger

L’autre intérêt de l’approche Omnissa est de connecter cette priorisation à des capacités de remédiation.

Pour les vulnérabilités applicatives, le Remediation Wizard s’appuie sur les recommandations CrowdStrike pour identifier les applications ou versions capables de réduire le risque. L’administrateur peut ensuite choisir une application déjà gérée dans Workspace ONE UEM, importer une application depuis l’Enterprise App Repository ou téléverser son propre package applicatif.

Là encore, le détail est important pour des administrateurs qui connaissent Workspace ONE. Nous ne sommes pas dans une correction abstraite. On retombe sur les mécaniques connues : propriétés applicatives, critères d’installation et de désinstallation, assignations, groupes cibles, suivi depuis Resources > Apps > Native Apps.

Une fois le produit de remédiation installé sur le terminal, CrowdStrike détecte la mise à jour. Après récupération des nouvelles informations par Vulnerability Defense, le device peut sortir de la liste des terminaux impactés.

Ce point est essentiel : la boucle ne s’arrête pas à l’envoi d’un ordre de déploiement. Elle doit revenir à l’état de vulnérabilité constaté.

02_omnissa-vulnerability-defense-remediation.png

Écran de détail Workspace ONE Vulnerability Defense présentant une vulnérabilité, les produits impactés et les options de remédiation.

La partie Windows Update reste un vrai sujet d’ingénierie

Pour les vulnérabilités du système d’exploitation Windows, la correction passe par les capacités de déploiement de correctifs depuis Devices > Device Updates > Windows > Update Deployments.

Le principe est assez direct. L’administrateur part de la vulnérabilité, identifie la KB recommandée, puis recherche cette KB dans Workspace ONE UEM. Si la mise à jour existe déjà dans la console, elle peut être assignée à des groupes ou terminaux avec les paramètres de déploiement adaptés. Si elle n’existe pas encore, l’administrateur peut l’ajouter depuis le catalogue Windows Update, vérifier les détails de révision, l’architecture, le type de device et les systèmes d’exploitation supportés, puis configurer les assignations et exclusions.

C’est là que Granular Patch Management prend tout son sens.

Cette capacité, introduite avec Workspace ONE UEM 2604, permet de rechercher une mise à jour Windows par numéro de KB, titre, classification ou système d’exploitation supporté, puis de la pousser vers des terminaux Windows 10, Windows 11 ou Windows Server ciblés. L’objectif n’est pas de remplacer les anneaux de déploiement classiques, mais de répondre aux cas où il faut agir plus vite : vulnérabilité exploitée, avis de sécurité critique, urgence de conformité ou exception opérationnelle.

Les release notes Workspace ONE Intelligent Hub 26.04 ajoutent aussi des éléments à garder en tête côté environnement Windows. Elles listent notamment comme prérequis des versions Microsoft prises en charge de Windows 11 Semi Annual Channel, ainsi que Windows 10 et 11 LTSC 2019, 2021 et 2024. Elles mentionnent également .NET Framework 4.6.2 et donnent, pour cette génération de Hub, des spécifications recommandées de 1 GHz avec au moins quatre cœurs, 8 Go de RAM et 256 Go d’espace disque.

Pour les serveurs, Workspace ONE UEM 2604 marque aussi un jalon important : la gestion Windows Server passe en disponibilité générale pour Windows Server 2016, 2019, 2022 et 2025, y compris Server Core, avec gestion par Intelligent Hub. On retrouve notamment les profils ADMX, les baselines de sécurité, le patching granulaire, les scripts, les sensors et les workflows Freestyle Orchestrator.

Il faut donc éviter la lecture trop courte : Vulnerability Defense n’est pas juste une vue sécurité. Elle s’inscrit dans une évolution plus large de Workspace ONE UEM vers la gestion opérationnelle de Windows, poste et serveur.

03_omnissa-uem-phased-deployment

Vue Workspace ONE UEM montrant la gestion granulaire des déploiements de correctifs Windows.

La question qui arrive ensuite est simple : comment prouve-t-on que c’est corrigé ?

Omnissa documente plusieurs niveaux de validation. Dans Workspace ONE UEM, les administrateurs peuvent suivre l’état des updates depuis Devices > Device Updates > Windows. Au niveau d’un device, l’onglet Updates permet aussi de consulter les mises à jour installées.

Le détail intéressant est que les statuts Windows Update s’appuient sur plusieurs sources, notamment Windows Update Agent, DISM et WMI. Ce n’est pas anodin. Dans les environnements Windows, la simple présence d’une KB dans un inventaire ne suffit pas toujours à prouver qu’un patch est correctement appliqué, ou qu’un redémarrage n’est pas encore en attente.

Dans une logique MSP, ce niveau de validation devient essentiel.

Le client ne demandera pas seulement : avez-vous poussé le patch ? Il demandera : combien de terminaux étaient exposés, combien sont corrigés, combien sont encore en échec, combien attendent un reboot, combien nécessitent une exception et quel est le délai moyen de remédiation ?

C’est ici que l’UEM peut redevenir stratégique. Pas parce qu’il affiche de beaux graphiques, mais parce qu’il est capable d’exécuter et de documenter une action sur le parc.

Ce que cela change pour les administrateurs

Pour les administrateurs Workspace ONE, l’annonce est intéressante parce qu’elle réutilise des briques qu’ils connaissent déjà.

Organization Groups. Groupes d’assignation. Applications internes. Enterprise App Repository. Déploiement Windows Update. Update Deployments. Profils Windows. Sensors. Scripts. Freestyle Orchestrator. Suivi d’état.

La nouveauté n’est donc pas de découvrir une nouvelle console venue de nulle part. La nouveauté est de faire entrer la donnée de vulnérabilité dans le plan d’action UEM.

Cela demande tout de même un changement de méthode.

Il faudra définir le périmètre des devices Windows réellement concernés, vérifier la qualité de l’inventaire applicatif, confirmer la couverture Falcon Sensor, travailler les droits API, organiser les groupes de test, prévoir les exclusions, mesurer les échecs de déploiement et documenter les fenêtres de maintenance.

Bref, un vrai sujet d’ingénierie.

Et c’est précisément pour cela qu’il est intéressant.

Ce que cela change pour les MSP

Pour un MSP ou un partenaire qui exploite des environnements clients, ce type d’évolution est loin d’être anecdotique.

Le modèle traditionnel consiste souvent à promettre que les terminaux sont correctement gérés et que les mises à jour sont appliquées. Mais les clients vont de plus en plus demander autre chose : quelles vulnérabilités me concernent vraiment ? Combien de terminaux sont exposés ? Quel correctif est prioritaire ? Quel est le délai de remédiation ? Que reste-t-il à traiter ?

Autrement dit, la valeur ne sera plus seulement dans la capacité à pousser une mise à jour.

Elle sera dans la capacité à transformer un signal de risque en action mesurable.

Cela change aussi la conversation commerciale. On ne vend plus simplement une console UEM, un lot de licences ou un service d’administration de parc. On vend une capacité continue à réduire l’exposition de l’environnement de travail, à prioriser les risques et à démontrer que les remédiations avancent réellement.

Et dans un monde où les attaquants exploitent de plus en plus vite les failles publiées, cette capacité vaut beaucoup plus qu’un joli inventaire de terminaux parfaitement rangé.

💬 Ce qu’on en pense chez KromeWork

Chez KromeWork, c’est exactement ce type d’évolution que nous regardons de près.

Parce qu’elle montre que l’UEM n’a pas vocation à disparaître derrière les grandes plateformes cloud, les agents IA ou les outils de sécurité spécialisés.

Il doit plutôt se connecter à eux.

Un bon UEM ne doit plus seulement dire : “ce terminal est conforme”. Il doit aider à répondre à des questions beaucoup plus opérationnelles : quelle faille expose réellement quels utilisateurs ? Quel correctif faut-il pousser maintenant ? Sur quel périmètre ? Avec quel niveau de risque pour l’expérience utilisateur ? Et comment prouve-t-on que la remédiation a bien été réalisée ?

C’est là que la convergence entre UEM, sécurité endpoint et DEX devient intéressante.

La cybersécurité ne manque pas de signaux.

Elle manque souvent de chemins d’action simples, rapides et contrôlables.

Si Workspace ONE Vulnerability Defense tient cette promesse, l’UEM redevient ce qu’il aurait toujours dû être : non pas une console d’inventaire, mais une plateforme de remédiation opérationnelle.

Et, franchement, c’est beaucoup plus utile qu’un tableau de bord rouge de plus.

Article rédigé par Cédric Dervaux, avec l’assistance de l’IA pour la relecture, la structuration et la mise en forme.

Pour en savoir plus

Omnissa Docs : Workspace ONE Vulnerability Defense with CrowdStrike Assessment

https://docs.omnissa.com/fr-FR/WorkspaceONEVulnerabilityDefense/Vulnerability_Defense_Integration_and_User_Guide?hl=fr-FR

Omnissa : Workspace ONE UEM 2604, One console, every endpoint

https://www.omnissa.com/insights/blog/workspace-one-uem-2604-release/

Omnissa Tech Zone : Managing Updates for Windows Devices, Workspace ONE Operational Tutorial

https://techzone.omnissa.com/managing-updates-windows-devices-workspace-one-operational-tutorial

Omnissa Docs : Workspace ONE Intelligent Hub for Windows Release Notes

https://docs.omnissa.com/intelligent-hub-windows-rn/ws1-intelligent-hub-windows-rn

Omnissa : Endpoint risk and vulnerability remediation

https://www.omnissa.com/platform/endpoint-risk-vulnerability-remediation/