Windows Autopatch reduziert den manuellen Aufwand für die Planung von Windows-Updates, und für Unternehmen mit begrenzten IT-Ressourcen und einfachen, ausschließlich auf Windows basierenden Umgebungen könnte dieser Kompromiss akzeptabel sein. Für Unternehmensteams jedoch, die Compliance-Anforderungen unterliegen, gemischte Betriebssystemlandschaften verwalten oder in Umgebungen mit kontrollierten Änderungen arbeiten, in denen jede Bereitstellung nachvollziehbar und überprüfbar sein muss, können die integrierten Kontrollmechanismen von Autopatch unzureichend sein.
Die Verwaltung von Update-Ringen, die Steuerung des Bereitstellungstempos und die Überprüfung des Patch-Status auf Geräteebene sind die operativen Hebel, auf die sich Patch-Programme in Unternehmen stützen. Autopatch übernimmt diese Entscheidungen von Haus aus für Sie. Für viele Teams in Unternehmen stellt dieser Kompromiss bei der Konzeption die zentrale Einschränkung dar.
Aktuelle Nachrichten zu Windows Autopatch
Microsoft hat weltweit das „ “-Autopatch-Hotpatching über Intune unter April 2026 freigeschaltet. Die Einführung löste in den IT-Fachkreisen von Unternehmen umfangreiche Diskussionen aus, wobei sich die Administratoren mit den betrieblichen Auswirkungen einer Funktion auseinandersetzten, die im Rahmen der Einführung durch Microsoft weltweit aktiviert wurde. Wie bei allen Berichten, die auf Beiträgen aus der Community basieren, variieren die individuellen Rahmenbedingungen zwar, doch die wiederkehrenden Themen sind konsistent genug, um Beachtung zu verdienen.
Diese Probleme konzentrieren sich auf drei Aspekte: fehlerhafte Status-Dashboards für die Verwaltung, Warnmeldungen aufgrund einer fehlerhaften Konfiguration der Richtlinien für Treiberaktualisierungen sowie Unklarheiten darüber, wie sich das Verhalten des Autopatch-Rings auf bestehende „Windows Update for Business“-Konfigurationen auswirkt.
Das sind die Fragen, die IT-Teams tatsächlich stellen.
Ist Autopatch ein Ersatz für die Windows Update-Ringe, oder sollten beide gemeinsam genutzt werden?
Autopatch ist kein Ersatz für die „Windows Update for Business“-Ringe. Es läuft auf deren Basis und erstellt eigene Bereitstellungsgruppen.
Wenn Sie Geräte bei Autopatch registrieren, ordnet Microsoft diese einem von vier vordefinierten Ringen zu: „Test“, „First“, „Fast“ und „Broad“. Diese Ringe steuern die Fristen für die Aufschiebung von Updates, doch die Anpassungsmöglichkeiten sind begrenzter als bei der direkten Konfiguration von „Windows Update for Business“-Richtlinien in Intune.
Das praktische Problem besteht darin, dass in vielen Organisationen bereits Windows-Update-Ringe konfiguriert sind. Wenn „Autopatch“ aktiviert ist, empfiehlt Microsoft unter , dass Sie unter zulassen, dass die vom Dienst verwalteten Richtlinien das Update-Verhalten steuern. Sich überschneidende Windows Update-Richtlinien können zu Konflikten mit der erforderlichen Konfiguration von Autopatch führen, was unvorhersehbares Verhalten zur Folge haben kann: Updates, die außerhalb der erwarteten Zeitfenster erfolgen, oder Geräte, die einen falschen Konformitätsstatus aufweisen.
Wenn Sie Autopatch prüfen möchten, überprüfen Sie zunächst Ihre bestehenden „Windows Update for Business“-Konfigurationen und beheben Sie etwaige Konflikte, bevor Sie die Registrierung vornehmen.
Welche Aktualisierungen sind derzeit im Hotpatch enthalten bzw. nicht enthalten?
„Hotpatching“ ist ein Mechanismus, mit dem Windows-Sicherheitsupdates im Arbeitsspeicher angewendet werden, ohne dass ein Neustart des Geräts erforderlich ist. As of the April 2026 global enablement, hotpatching is available for Windows 11 Enterprise devices on supported versions enrolled in Intune.
Nicht alle Windows- 11 -Konfigurationen sind zulässig. Bitte überprüfen Sie vor der Planung von Bereitstellungen, ob die unterstützten Betriebssystemversionen und Verbindungstypen den aktuellen Hotpatch-Voraussetzungen von Microsoft entsprechen. Es umfasst einen Teil der monatlichen Sicherheitsinhalte, insbesondere Sicherheitsupdates, die Microsoft für In-Memory-Anwendungen zusammengestellt hat.
Nicht alle Aktualisierungstypen kommen für Hotpatching in Frage. Funktionsupdates, nicht sicherheitsrelevante Qualitätsupdates, Treiberupdates und Updates für Secure-Boot-Zertifikate sind davon ausgenommen und erfordern weiterhin die Installation eines vollständigen kumulativen Updates sowie einen anschließenden Neustart.
Microsoft veröffentlicht einen vierteljährlichen Hotpatch-Kalender, aus dem hervorgeht, in welchen Monaten Hotpatch-Updates bereitgestellt werden und in welchen Monaten ein vollständiges kumulatives Update mit Neustart erforderlich ist. Administratoren sollten den aktuellen Kalender zu Rate ziehen, anstatt von einem festen Muster auszugehen, da der Zeitplan variieren kann.
Systemadministratoren sollten nicht davon ausgehen, dass ein Gerät, das Hotpatches erhält, in allen Update-Kategorien auf dem neuesten Stand ist. Das Ausbleiben eines Neustarts bedeutet nicht, dass das Gerät alle relevanten Sicherheitsupdates erhalten hat.
Verzögert Hotpatch die Aktualisierung von Secure-Boot-Zertifikaten, und wann sollten Geräte davon ausgenommen werden?
Aktualisierungen der Secure-Boot-Zertifikate werden nicht über den Hotpatch-Mechanismus bereitgestellt. Damit die Änderungen wirksam werden, sind ein vollständiges kumulatives Update und ein Neustart des Geräts erforderlich. Im Rahmen eines Hotpatch-Zeitplans werden diese Updates nicht jeden Monat, sondern in festgelegten Monaten mit umfassenden Updates bereitgestellt, was im Vergleich zum herkömmlichen monatlichen Patch-Rhythmus zu einer Verzögerung führt.
In vielen Unternehmensumgebungen ist diese Verzögerung im Rahmen des vierteljährlichen Release-Rhythmus von Microsoft akzeptabel. Geräte in Hochsicherheitsumgebungen oder regulierten Umgebungen, insbesondere solche, die Compliance-Vorgaben unterliegen, welche bestimmte Zeitpläne für Zertifikatsaktualisierungen vorschreiben, müssen jedoch möglicherweise aus dem Hotpatch-Zeitplan ausgeschlossen und stattdessen einer standardmäßigen monatlichen Bereitstellung kumulativer Updates zugeordnet werden.
Prüfen Sie Ihre Compliance-Anforderungen anhand des von Microsoft veröffentlichten Zeitplans für Hotpatches, bevor Sie Geräte flächendeckend registrieren.
Warum meldet Autopatch Treiberaktualisierungen als falsch konfiguriert, und welche Richtlinie regelt tatsächlich die Treiberaktualisierungen?
Dies ist derzeit ein häufig gemeldetes Problem bei den von der Community gemeldeten Bereitstellungen. Administratoren stellen fest, dass Richtlinien für Treiberaktualisierungen im Autopatch-Verwaltungs-Dashboard als falsch konfiguriert gekennzeichnet werden, selbst wenn die Geräte die Aktualisierungen offenbar normal erhalten.
Die eigentliche Ursache ist eine Trennung der Richtlinien, die auf dem Dashboard nicht ersichtlich ist: Treiberaktualisierungen in Autopatch werden über eine separate Windows-Treiberaktualisierungsrichtlinie verwaltet, die sich von der Hauptkonfiguration für Qualitätsaktualisierungen in Autopatch unterscheidet. Falls diese Richtlinie zur Treiberaktualisierung fehlt, nicht korrekt zugeordnet ist oder mit einer bestehenden Richtlinie zur Treiberverwaltung in Ihrem Mandanten in Konflikt steht, meldet Autopatch eine Fehlkonfiguration.
Um das Problem zu beheben, müssen Sie sicherstellen, dass die von Autopatch erstellte Richtlinie zur Windows-Treiberaktualisierung korrekt auf Ihre registrierten Gerätegruppen angewendet wird und dass keine widersprüchlichen Treiberrichtlinien aus früheren Konfigurationen vorhanden sind. Das Löschen und erneute Erstellen der „Autopatch“-Treiberrichtlinie oder das explizite Ausschließen betroffener Gerätegruppen aus älteren Treiberrichtlinien behebt in der Regel die Warnmeldung.
Können die Berichte von Autopatch ungenau sein, selbst wenn die Geräte ordnungsgemäß aktualisiert werden, und wie sollten Administratoren dies interpretieren?
Ja. In den Autopatch-Berichts-Dashboards können Geräte als nicht konform oder im Fehlerzustand angezeigt werden, selbst wenn diese Geräte Updates erfolgreich empfangen und installieren. Dies ist ein immer wieder auftretendes Problem in der r/Intune-Community unter , in der Administratoren berichten, dass auf der Verwaltungsstatusseite keine Geräte angezeigt werden oder falsche Compliance-Zahlen erscheinen, obwohl Update-Aktivitäten auf den Endgeräten bestätigt wurden.
Die Berichtsebene in Autopatch stützt sich auf Daten, die aus den Berichten von „Windows Update for Business“ und dem Intune-Gerätestatus aggregiert werden; es wurden Verzögerungen und Synchronisierungsprobleme gemeldet, die zu irreführenden Anzeigen im Dashboard führen können.
Bevor Sie aufgrund einer Compliance-Warnmeldung von Autopatch Maßnahmen ergreifen, überprüfen Sie den tatsächlichen Aktualisierungsstatus des Geräts direkt in der Geräte-Compliance-Ansicht von Intune oder anhand des Windows Update-Verlaufs auf dem Endgerät selbst. Betrachten Sie die Daten des Autopatch-Dashboards als nachlaufenden Indikator und nicht als Echtzeit-Quelle der Wahrheit, und gestalten Sie Ihren Prozess zur Überprüfung der Compliance entsprechend.
Wie lassen sich sowohl Betriebszeiten als auch ein festgelegtes Zeitfenster für den Neustart ohne Konflikte zwischen den Richtlinien durchsetzen?
Betriebszeiten und Wartungsfenster dienen unterschiedlichen Zwecken und werden über unterschiedliche Richtlinienpfade konfiguriert; genau hier entstehen in der Regel Konflikte:
- Die aktiven Stunden (die über die Windows-Update-Einstellungen konfiguriert werden) geben dem Betriebssystem vor, wann ein Gerät nicht neu gestartet werden soll.
- Ein festgelegtes Neustartfenster, das in der Regel durch einen Bereitstellungsplan oder eine auf Fristen basierende Aktualisierungsrichtlinie durchgesetzt wird, gibt dem Betriebssystem vor, wann es neu gestartet werden muss.
Werden beide ohne Abstimmung konfiguriert, kann das Gerät in einen Zustand geraten, in dem die Frist für den Neustart während der Betriebszeiten abläuft, was zu unvorhersehbarem Verhalten oder unterdrückten Neustarts führen kann. Die Lösung ist nicht kompliziert, erfordert jedoch von vornherein eine sorgfältige Abfolge der Schritte.
Der richtige Ansatz besteht darin, sicherzustellen, dass sich Ihre Konfiguration der aktiven Zeiten nicht mit Ihrem geplanten Neustartfenster überschneidet. Legen Sie die Geschäftszeiten so fest, dass sie Ihren Kerngeschäftstag abdecken. Planen Sie den Zeitpunkt für den Neustart so, dass er außerhalb dieses Zeitfensters liegt – in der Regel über Nacht oder während eines festgelegten Wartungszeitraums.
Überprüfen Sie in Intune, ob die Fristeinstellungen Ihrer „Update Ring“-Richtlinie und Ihre Einstellungen für die aktiven Stunden aufeinander abgestimmt sind und sich nicht widersprechen.
Wenn Sie Autopatch zusammen mit manuell konfigurierten „Update Ring“-Richtlinien verwenden, sollten Sie besonders vorsichtig sein: Autopatch kann die von Ihnen an anderer Stelle festgelegten Fristeinstellungen überschreiben oder mit diesen in Konflikt geraten.
Wo sich Autopatch eignet und wo nicht
Der Kern des Problems besteht nicht darin, dass Autopatch ein schlechtes Werkzeug ist. Autopatch wurde zwar entwickelt, um die IT-Belastung zu verringern, indem es Ihnen Entscheidungen abnimmt, doch genau die Entscheidungen, die es übernimmt (Anpassungen auf Ringebene, Transparenz auf Geräteebene und Steuerung des Bereitstellungsrhythmus), sind diejenigen, die Unternehmensteams nicht an einen Dienst delegieren können, den sie nicht vollständig überprüfen oder außer Kraft setzen können.
Die Möglichkeit, benutzerdefinierte Netzwerkgruppen festzulegen, den Patch-Status auf Geräteebene in Echtzeit zu überprüfen und die Ergebnisse der Bereitstellung mit Prüfnachweisen zu verknüpfen, stellt in regulierten Umgebungen selten einen optionalen Mehraufwand dar. Dies ist die operative Grundlage, die das Patchen vertretbar macht.
Für Unternehmen mit begrenzten IT-Ressourcen und einer ausschließlich auf Windows basierenden Umgebung kann „Autopatch“ den Arbeitsaufwand erheblich verringern. Für Unternehmensteams, die Compliance-orientierte, betriebssystemübergreifende oder änderungskontrollierte Umgebungen betreiben, sind die Kontrollmechanismen, die Autopatch abstrahiert, genau diejenigen, die Sie beibehalten müssen.
Häufig gestellte Fragen
Die vorstehenden Abschnitte befassen sich speziell mit Windows Autopatch: Was das Programm leistet, wo seine Grenzen liegen und wie sich die gemeldeten Probleme umgehen lassen.
Die folgenden Fragen konzentrieren sich auf die Grundlagen des Patch-Managements und behandeln die Anforderungen an diesen Bereich, die Funktionen, die Unternehmenssoftware bieten sollte, sowie die Erstellung eines Arbeitsablaufs, der den Anforderungen der Compliance-Prüfung standhält.
Wenn Sie abwägen, ob Autopatch zu Ihrer Umgebung passt oder ob Sie eine Lösung benötigen, die darüber hinausgeht, ist dies der Kontext, der diese Entscheidung bestimmt.
Was versteht man unter Software-Patch-Management?
Das Software-Patch-Management ist der Prozess der Identifizierung, Prüfung und Bereitstellung von Updates für Betriebssysteme und Anwendungen auf allen Endgeräten eines Unternehmens.
Dies umfasst die Suche nach fehlenden Patches, die Priorisierung von Updates anhand des Schweregrads und des Risikos, die Planung von Bereitstellungen innerhalb festgelegter Wartungsfenster sowie die Überprüfung, ob die Patches erfolgreich installiert wurden.
Ein effektives Patch-Management ist ein grundlegender Bestandteil sowohl der Sicherheitshygiene als auch der betrieblichen Stabilität.
Welche Tools eignen sich am besten für das Patch-Management in Unternehmensumgebungen?
Welches Patch-Management-Tool für Unternehmen das richtige ist, hängt davon ab, welche Anforderungen Ihre Umgebung tatsächlich stellt. Im größeren Maßstab sind die Kriterien, die „angemessen“ von „vertretbar“ unterscheiden, folgende:
- Plattformübergreifende Abdeckung: Die meisten Unternehmen nutzen Windows, Linux und macOS. Ein Tool, das nur ein Betriebssystem unterstützt, erfordert parallele Arbeitsabläufe und führt zu Lücken in der Transparenz.
- Patch-Status in Echtzeit: Geplante Scans geben Aufschluss darüber, wo Sie standen, nicht darüber, wo Sie gerade stehen. In schnelllebigen Umgebungen hat die Kenntnis darüber, bei welchen Endgeräten derzeit – und nicht erst beim nächsten Scan-Intervall – ein kritischer Patch fehlt, Einfluss darauf, wie schnell Sie reagieren können.
- Kontrollierte Bereitstellungsabläufe: Ringbasierte Rollouts, Genehmigungsstufen und Wartungsfenster sind kein optionaler Mehraufwand. Auf diese Weise können Sie Probleme erkennen, bevor sie in der Produktion in großem Maßstab auftreten.
- Warnsignale bei der Bereitstellung: Zu wissen, dass ein Patch verfügbar ist, bedeutet nicht, dass dessen flächendeckende Bereitstellung unbedenklich ist. Tools, die die Erfolgsraten von Installationen oder bekannte Kompatibilitätsprobleme in einer großen Installationsbasis aufzeigen, helfen den Teams dabei, fundiertere Entscheidungen hinsichtlich der Reihenfolge der Installationen zu treffen.
- Integration von Compliance-Maßnahmen: Für die Installation von Patches und die Erstellung von Compliance-Berichten sollten keine separaten Tools erforderlich sein. Wenn Korrekturmaßnahmen direkt mit Sicherheitsbefunden verknüpft sind, ist der Prüfpfad übersichtlicher und der Reaktionszyklus kürzer.
Wie lässt sich das Patch-Management in großem Maßstab automatisieren?
Die Automatisierung des Patch-Managements in großem Maßstab erfordert mehr als nur planmäßige Bereitstellungen. Dies erfordert eine dynamische Zielausrichtung, eine schrittweise Einführung und eine Echtzeit-Validierung in jedem Schritt.
Die Kernkomponenten eines skalierbaren, automatisierten Patching-Workflows sind:
- Ein stets aktuelles Bestandsverzeichnis: Automatisierung ist nur so gut wie das, was sie erkennen kann. Eine vollständige Echtzeit-Bestandsaufnahme aller Hardware- und Software-Ressourcen in Ihrem Netzwerk bildet die Grundlage des gesamten Prozesses. Statische Bestandslisten verlieren in Umgebungen mit häufigem Gerätewechsel oder entfernten Endpunkten schnell an Aussagekraft.
- Risikobasierte Priorisierung vor der Bereitstellung: Nicht jeder Patch erfordert die gleiche Dringlichkeit. Bei der Priorisierung sollten die Verfügbarkeit von Exploits, die Kritikalität der Ressourcen und das Risiko einer Kompromittierung berücksichtigt werden (nicht nur die CVSS-Schweregrade), da diese eher das theoretische Risiko als den Kontext einer aktiven Bedrohung messen.
- Schrittweise, ringbasierte Rollouts: Bei einem ringbasierten Bereitstellungsmodell werden Geräte in logische Ebenen unterteilt, wobei jede Ebene erst dann Patches erhält, wenn die Stabilität im vorherigen Ring bestätigt wurde. In dieser Pause zwischen den Klingelzeichen treten Kompatibilitätsprobleme, fehlerhafte Integrationen und Neustartschleifen zutage, bevor sie in großem Maßstab in die Produktion gelangen.
- Bedingter Aufstieg, kein automatischer Aufstieg: Der Aufstieg zwischen den Rängen sollte an bestimmte Bedingungen geknüpft sein und nicht automatisch erfolgen. Legen Sie fest, wie Erfolg in jeder Phase aussieht: Schwellenwerte für die Installationsrate, Fehlerquoten, Überprüfungen der Dienstverfügbarkeit. Die Weiterleitung sollte sich nach diesen Kriterien richten und nicht allein nach der verstrichenen Zeit.
- Die Rollback-Fähigkeit muss vor der Bereitstellung definiert werden, nicht erst danach: Sollte ein Patch Probleme verursachen, hängt die Möglichkeit einer schnellen Rücknahme davon ab, dass im Vorfeld dokumentierte Rollback-Verfahren vorhanden sind. Ein Notfall-Rollback sollte nicht unter Zeitdruck improvisiert werden.
- Überprüfung auf Endpunkt-Ebene: Die Berichts-Dashboards bestätigen, dass ein Bereitstellungsversuch stattgefunden hat. Die Überprüfung auf Endpunkt-Ebene bestätigt, dass der Vorgang erfolgreich war. Dies sind nicht ein und dasselbe, und ihre Vermischung ist eine häufige Ursache für ein trügerisches Vertrauen in die Einhaltung der Vorschriften.
Welche Vorteile bietet der Einsatz von Tanium für das Patch-Management?
Das Patch-Management in Unternehmen scheitert an vorhersehbaren Stellen: unvollständige Transparenz über die IT-Ressourcen, manuelle Triage, die mit dem Patch-Aufkommen nicht Schritt halten kann, Bereitstellungsabläufe, denen die Kontrollmechanismen fehlen, um fehlerhafte Patches abzufangen, bevor sie in die Produktion gelangen, sowie Compliance-Berichte, die in einem vom eigentlichen Behebungsprozess getrennten System geführt werden.
Viele Unternehmen haben kein Problem mit der Patch-Verwaltung, sondern ein Problem mit der Fragmentierung. Die Arbeit verteilt sich auf verschiedene Tools, Konsolen und manuelle Übergaben, was den gesamten Prozess verlangsamt und es erschwert, zu jedem beliebigen Zeitpunkt zu wissen, wo man tatsächlich steht.
Tanium löst dieses Problem über eine einzige Plattform, , und der operative Unterschied ist erheblich: Wenn Fehlerbehebung, Transparenz und Compliance-Berichterstattung auf derselben Datenebene basieren, verbringen die Teams weniger Zeit mit dem Abgleich der Ergebnisse und mehr Zeit damit, darauf zu reagieren.
Tanium Patch bietet Echtzeit-Transparenz und -Kontrolle über Patches auf Windows-, Linux- und macOS-Endgeräten mit anpassbaren Zeitplänen, Wartungsfenstern, Sperrlisten und Bereitstellungsvorlagen. Um Teams dabei zu unterstützen, vor einer flächendeckenden Bereitstellung fundiertere Entscheidungen zu treffen, weist Tanium den Windows-Patches „ “-Vertrauenswerte zu, die auf den Installationsergebnissen und Leistungsdaten aus der Tanium-Kundengemeinschaft basieren. Dadurch werden Risiken bei der Bereitstellung aufgedeckt, bevor sie zu einem Problem im Produktivbetrieb werden.
Über dieselbe Plattform – – ermöglicht Tanium Automate Teams die Erstellung wiederverwendbarer No-Code- oder Low-Code-Playbooks, mit denen ringbasierte, schrittweise Rollouts durchgeführt, Ergebnisse auf Endgeräteebene überprüft und Ausnahmen ohne manuellen Eingriff in jeder Phase eskaliert werden können. Wenn bei der Bereitstellung eines Patches ein Sicherheitsbefund festgestellt wird, stellt Tanium Comply eine direkte Verbindung zur Behebung her.
Der Prüfpfad erstreckt sich von der Sicherheitslücke bis zur Behebung, ohne dass die Plattform verlassen werden muss oder die Ergebnisse voneinander getrennter Tools zusammengeführt werden müssen. Das Ergebnis ist eine Patch-Compliance, die darauf ausgelegt ist, eine kontinuierliche und nachweisbare Einhaltung zu gewährleisten – und nicht eine periodische Momentaufnahme, die im Nachhinein erstellt wird.
Das ist der praktische Vorteil, wenn alles an einem Ort zusammengefasst ist: Sie benötigen weniger Zeit für den Abgleich von Daten aus verschiedenen Systemen und haben mehr Zeit, darauf zu reagieren – wobei Ihnen der vollständige Kontext Ihrer Umgebung bereits vorliegt.
Weitere Ressourcen
- Dokumentation zu Windows Autopatch
- Transformieren Sie IT-Sicherheit und -Betrieb mit Microsoft und Tanium
- Autonomes Patch-Management mit Tanium
- Verwaltung von Unternehmensanwendungen mit Tanium
- Was ist das Windows-Patch-Management?
- Bewährte Verfahren für das Patch-Management
Tools, die zur Vereinfachung des IT-Betriebs entwickelt wurden, tun dies mitunter auf Kosten der Kontrollmechanismen, die die Arbeit rechtfertigen. Diese Lücke zu schließen, kann mehr Anfragen, mehr Konsolen und mehr manuellen Koordinationsaufwand bedeuten.
Tanium basiert auf einer anderen Prämisse: dass Transparenz, Automatisierung und Governance zusammenwirken sollten, anstatt sich gegenseitig auszuschalten. Das Ziel sind schnellere und fundiertere Entscheidungen – nicht weniger davon. Wenn Ihr Team in Echtzeit Einblick in die tatsächlichen Vorgänge in der gesamten Umgebung hat, basieren alle Entscheidungen nicht mehr auf Verzögerungen und Vermutungen.
Tanium AI und Tanium Ask ermöglichen es Ihnen, Ihre Umgebung in einfacher Sprache abzufragen und Antworten aus Echtzeit-Endpunktdaten zu erhalten – ganz ohne komplexe Abfragesyntax und ohne die Suche nach der richtigen Konsole. Wenn Sie wissen möchten, wie es tatsächlich um Ihre Patch-Compliance steht, fragen Sie einfach nach.
Erfahren Sie, wie Tanium die Transparenz bei Patches, die Kontrolle über die Bereitstellung und die Compliance auf einer einzigen Plattform vereint. Vereinbaren Sie eine Live-Demo unter.
