Das Dashboard zur Patch-Compliance zeigt 96 % an. Windows ist auf dem neuesten Stand, macOS ist auf dem neuesten Stand, das Sicherheitsteam gibt grünes Licht und der Bericht geht an den Prüfer. Das Problem ist, dass diese 96 % nur die Betriebssystem-Situation widerspiegeln. Der Endpunkt, der unter dieser grünen Kachel verborgen ist, läuft zudem mit einer Chrome-Version aus dem Spätsommer, einer Adobe Reader-Version, für die drei CVEs veröffentlicht wurden, einem Zoom-Client, der älter ist als die letzte Sicherheitsempfehlung, und einer Java-Laufzeitumgebung, an die seit achtzehn Monaten niemand im Team mehr gedacht hat. Nichts davon schlägt sich in der Bewertung nieder.
Genau diese Lücke soll das Patch-Management für Drittanbieter schließen, und für die meisten IT-Teams und MSPs ist dies der Teil des Patch-Programms, der im Verhältnis zum tatsächlichen Risiko stillschweigend unterfinanziert ist. Laut dem Qualys-Unternehmens-Benchmark 2026 beträgt die durchschnittliche Zeit bis zur Behebung bei komplexen Drittanbieteranwendungen fünf Monate und zehn Tage. Angreifer agieren hingegen in einem Zeitfenster, das sich in Tagen, manchmal sogar in Stunden bemisst. Diese beiden Zeitrahmen sind nicht miteinander vereinbar.
Die RMM-Lösungen von Kaseya übernehmen das Patch-Management für Millionen von Endgeräten für MSPs und interne IT-Teams weltweit und liefern einen klaren Überblick darüber, wo Patch-Programme von Drittanbietern unter Druck bestehen und wo sie versagen. Dieser Leitfaden erläutert, was Patch-Management von Drittanbietern ist, warum die technischen Abläufe schwieriger sind als das Patchen von Betriebssystemen, welche Prioritäten gesetzt werden sollten, wie das Programm operativ aufgebaut werden sollte und welche Anforderungen an die Automatisierung gestellt werden müssen, um mit dem Release-Rhythmus Schritt zu halten.
Was ist Patch-Management für Drittanbieter?
Das Patch-Management für Drittanbieter-Software umfasst die Identifizierung, Bewertung, Bereitstellung und Überprüfung von Updates für die Software, die auf Ihren Endgeräten läuft und nicht vom Betriebssystemhersteller bereitgestellt wird. Das ist ein weit gefasster Begriff. Dazu gehören Browser, PDF-Reader, Konferenz-Clients, Laufzeitumgebungen wie Java und .NET, Office-Suiten, Entwicklertools, Komprimierungsprogramme und die Vielzahl an Geschäftsanwendungen, die sich im Laufe der Zeit in jeder Umgebung ansammeln.
Es fällt zwar unter denselben übergeordneten Bereich des Patch-Managements wie Betriebssystem-Patches, unterliegt jedoch anderen Rahmenbedingungen. Microsoft, Apple und die großen Linux-Distributionen stellen ihre Updates über standardisierte, gut durchdachte Kanäle bereit. Drittanbieter tun dies nicht. Für Slack gibt es keinen „Patch Tuesday“. Es gibt keinen zentralen Katalog, der den Release-Zeitplan von Adobe mit dem von Mozilla, dem von Oracle und der Nischen-Branchenanwendung verknüpft, die das Finanzteam 2019 installiert hat. Jeder Anbieter veröffentlicht nach seinem eigenen Rhythmus, in seinem eigenen Format und über seinen eigenen Kanal, und jemand muss den Überblick über alle gleichzeitig behalten.
Der Begriff „Drittanbieter“ deckt hier ein breites Spektrum ab. Er umfasst alles – vom Browser, den jeder Mitarbeiter im Unternehmen nutzt, bis hin zu einem speziellen Entwicklungstool, das auf drei Rechnern installiert ist. Beide fallen unter denselben betrieblichen Begriff, und beide können als Einfallstor für einen Sicherheitsverstoß dienen.
Warum Patches von Drittanbietern wichtiger denn je sind
Jahrelang galt die Auffassung, dass Sicherheitslücken im Betriebssystem das Hauptproblem darstellten und Anwendungen nur eine untergeordnete Rolle spielten. Das trifft schon seit einiger Zeit nicht mehr zu. Die Datenlage hat sich mittlerweile dem Stand der Erkenntnisse der Angreifer angeglichen.
Die von Adaptiva gemeinsam mit Demand Metric durchgeführte Umfrage „State of Patch Management 2025“ ergab, dass 87 % der Unternehmen im vergangenen Jahr auf Sicherheitslücken in Anwendungen von Drittanbietern gestoßen sind, die gepatcht werden mussten. Das ist kein Einzelfall. Es ist der Normalzustand in fast jeder IT-Umgebung, in der moderne Software zum Einsatz kommt.
Der Katalog „Known Exploited Vulnerabilities“ (KEV) der CISA beleuchtet dasselbe Thema aus einer anderen Perspektive. Die KEV-Liste erfasst Schwachstellen, die von Angreifern aktiv ausgenutzt werden – nicht nur theoretische, nach CVSS bewertete Schwachstellen –, und ein stetiger Anteil der neuen Einträge betrifft Anwendungen von Drittanbietern und nicht die Kernbetriebssysteme. Browser, Dokumentenleser, Konferenztools und Laufzeitbibliotheken tauchen Monat für Monat auf. Sie sind weit verbreitet, es werden regelmäßig Sicherheitsupdates veröffentlicht, und die Lücke zwischen der Veröffentlichung durch den Anbieter und der Installation durch den Endnutzer ist der Ort, an dem Angreifer ihr Werk verrichten.
Das Tempo macht die Sache noch komplizierter. Am „Patch Tuesday“ im April 2026 behob Microsoft allein in seinem eigenen Software-Stack 163 Sicherheitslücken (CVEs). Rechnet man Adobe, Oracle, Google, Mozilla, Cisco, Atlassian und ein Dutzend weiterer Anbieter noch dazu, sieht das monatliche Volumen, mit dem jedes Patch-Programm Schritt halten soll, schon fast unüberwindbar aus. Eine manuelle Überprüfung eines Feed dieser Größenordnung ist keine Strategie.
Der „Verizon Data Breach Investigations Report 2025“ stellte fest, dass bei 20 % der Sicherheitsverletzungen die Ausnutzung von Schwachstellen als Einstiegspunkt diente – ein Anstieg um 34 % gegenüber dem Vorjahr. Dieser Anstieg ist nicht allein auf Zero-Day-Exploits auf Betriebssystemebene zurückzuführen. Er spiegelt die zunehmende Nutzung von Schwachstellen in Software von Drittanbietern wider, von deren Einsatz die Unternehmen entweder nichts wussten oder für die sie noch keine Patches installiert hatten.
Herausforderungen beim Patch-Management von Drittanbietern
Sobald man weiß, dass das Risiko real ist, stellt sich natürlich die Frage, warum so viele Programme diese Lücke trotzdem offen lassen. Die Antwort ist technischer Natur und hat nichts mit der Motivation zu tun. Das Patchen von Drittanwendungen ist aus vier miteinander verknüpften Gründen strukturell schwieriger als das Patchen des Betriebssystems.
Zersplitterung des Anbietermarktes
Die Update-Infrastruktur von Microsoft kümmert sich um Microsoft-Software. Die von Apple kümmert sich um macOS. Für den Rest gibt es keinen vergleichbaren einheitlichen Kanal. Jeder ISV unterhält sein eigenes Release-Portal, sein eigenes Format für Benachrichtigungen und seinen eigenen Bereitstellungsmechanismus. Um Releases bei 50 oder 100 Anwendungen von Drittanbietern manuell zu verfolgen, muss man Dutzende separater Feeds abonnieren und jeden einzelnen in konkrete Maßnahmen umsetzen. Das ist eine Vollzeitaufgabe, für die die meisten Teams keine personellen Kapazitäten haben.
Variabilität der Schrittfrequenz
Der „Patch Tuesday“ bietet Ihnen einen festen Rhythmus für Windows. Veröffentlichungen von Drittanbietern folgen keinem solchen Rhythmus. Ein kritischer Browser-Patch kann mitten in der Woche erscheinen. Ein Laufzeit-Update kann ohne Vorankündigung veröffentlicht werden. Ein Konferenztool kann einen Sicherheits-Build veröffentlichen, noch am selben Tag, an dem ein Druckertreiberhersteller eine CVE veröffentlicht. Weder das Volumen noch der Zeitpunkt sind vorhersehbar, was bedeutet, dass ein auf einem monatlichen Rhythmus basierendes Patch-Programm zeitkritische Updates von Drittanbietern naturgemäß regelmäßig verpasst.
Vielfalt der Installateure
Betriebssystem-Patches werden über standardisierte Mechanismen bereitgestellt. Anwendungen von Drittanbietern nutzen MSI, EXE, MSIX, App-V, herstellerspezifische Updater, webbasierte Installationsprogramme und gelegentlich maßgeschneiderte Bereitstellungsskripte. Jedes Format verfügt über eigene Flags für die unbeaufsichtigte Installation, ein eigenes Neustartverhalten, eine eigene Logik zur Versionserkennung und eigene Fehlermodi. Eine zuverlässige Automatisierung bei dieser Vielfalt erfordert entweder ein Tool mit herstellergeprüfter Unterstützung für jede Anwendung oder benutzerdefinierte Skripte, die von Ihrem Team auf unbestimmte Zeit gepflegt werden müssen.
Entdeckung
Man kann nichts patchen, von dem man nicht weiß, dass es vorhanden ist. Benutzer installieren Anwendungen außerhalb der von der IT genehmigten Kanäle. Durch Übernahmen werden nicht verwaltete Softwarebestände übernommen. Abteilungen standardisieren auf Tools, von denen das Endpunktteam nichts weiß. Ohne eine kontinuierliche, agentengesteuerte Erfassung, die jede installierte Anwendung und Version auf jedem verwalteten Gerät aufdeckt, stützt sich das Patch-Programm auf einen Bestand, der schon von vornherein falsch ist.
Diese vier Einschränkungen lassen sich nicht durch bloßen Einsatz beseitigen. Sie sind Eigenschaften des Ökosystems der Drittanbietersoftware selbst. Ein funktionierendes Programm ist eines, das sich an diese Einschränkungen anpasst, anstatt gegen sie anzukämpfen.
Welche Anwendungen sollten vorrangig behandelt werden?
Nicht jede Drittanbieteranwendung birgt das gleiche Risiko – und wenn man sie alle über einen Kamm schert, sind die Programme am Ende genauso anfällig wie gar keine Programme. Der richtige Ansatz besteht darin, sie nach Einsatzbereich, Ausnutzungshistorie und Nähe zum Netzwerkrand zu stufen und dann die Häufigkeit der Überprüfungen und die SLAs auf die oberste Stufe zu konzentrieren.
Browser stehen ganz oben auf fast jeder Liste. Chrome, Edge, Firefox und Brave sind auf jedem Endgerät installiert, stellen per Definition nicht vertrauenswürdige Inhalte aus dem gesamten Internet dar und erhalten mehrmals im Monat Sicherheitsupdates. Häufig werden die installierten Updates zudem bis zum Neustart zurückgestellt, was bedeutet, dass ein verfügbarer Patch erst dann tatsächlich installiert ist, wenn der Benutzer das Fenster schließt. Ein SLA von 24 bis 48 Stunden für kritische Browser-Updates, dessen Einhaltung durchgesetzt wird, ist eine angemessene Mindestanforderung.
Als Nächstes kommen PDF- und Dokumentenleseprogramme. Adobe Acrobat und Reader weisen eine lange Liste kritischer CVEs auf und sind seit jeher das Ziel bösartiger Dokumente, die per E-Mail versendet werden. Eine aktuelle Version auf jedem Endgerät ist für die meisten Teams die kostengünstigste Möglichkeit, die Erfolgsquote von Phishing-Angriffen wirksam zu senken.
Laufzeitumgebungen bilden die dritte Gruppe. Java, OpenJDK, die .NET-Laufzeitumgebungen und verschiedene JavaScript-Engines bilden die Grundlage für Unternehmensanwendungen, die für Sicherheitstools möglicherweise nicht als eigenständige Abhängigkeiten erkennbar sind. Eine Schwachstelle in einer Laufzeitumgebung betrifft jede darauf aufbauende Anwendung, und der Schadensumfang kann groß sein, selbst wenn die Laufzeitumgebung selbst eher unbekannt erscheint.
Anwendungen für Konferenzen und Zusammenarbeit bilden eine vierte Kategorie. Zoom, Teams (als eigenständige Installation), Slack und ähnliche Tools sind überall installiert, interagieren mit nicht vertrauenswürdigen externen Links und Dateien und werden regelmäßig aktualisiert. Ihre Angriffsfläche ähnelt der eines Browsers, auch wenn ihre Sichtbarkeit im Bestandsverzeichnis unterschiedlich ist.
Komprimierungsprogramme, Archivierungstools, Entwicklerabhängigkeiten und die Vielzahl von Geschäftsanwendungen runden das Bild ab. Sie alle tragen einen erheblichen Teil des Risikos, und das richtige Rahmenwerk für ihre Einstufung ist dasselbe risikobasierte Modell, das auch für die Patches des Betriebssystems gelten sollte: Schweregrad (CVSS), Ausnutzungsstatus (KEV-Listung, Threat-Intelligence-Feeds, öffentliche Exploits) und geschäftlicher Kontext (mit dem Internet verbunden, sensible Daten, Potenzial für laterale Bewegung). Weitere Informationen zur Einbindung dieses Rahmens in das übergeordnete Programm finden Sie unter Best Practices für das Patch-Management.
Bewährte Verfahren für das Patchen von Drittanbieter-Software: So erstellen Sie ein Programm
Ein funktionierendes Patch-Programm eines Drittanbieters folgt zwar im Großen und Ganzen dem gleichen Ablauf wie der allgemeine Patch-Management-Prozess, doch muss bei der Umsetzung in jeder Phase die zusätzliche Komplexität berücksichtigt werden, die durch die Software eines Drittanbieters entsteht.
Die Erfassung muss kontinuierlich, agentengesteuert und lückenlos erfolgen. Ein wöchentliches Software-Audit anhand des Bestandsverzeichnisses reicht nicht aus. Der Agent sollte jede installierte Anwendung, jede Version und jede vom Benutzer installierte Instanz auf jedem verwalteten Endgerät erfassen und die Daten nahezu in Echtzeit aktualisieren. Wo immer diese Transparenz fehlt, ist das Patch-Programm genau in diesem Umfang blind.
Das Gleiche gilt für die Überwachung. Sobald Sie wissen, welche Software installiert ist, benötigen Sie einen Feed, der Sie darüber informiert, wann die einzelnen Anbieter Sicherheitsupdates veröffentlichen – idealerweise nach Schweregrad geordnet. Einen solchen Feed für fünfzig Anbieter intern aufzubauen, ist eine ziemliche Herausforderung. Die realistische Lösung ist ein Patching-Tool, dessen Anbieter neue Versionen innerhalb weniger Stunden nach der Veröffentlichung in einen getesteten Katalog aufnimmt, sodass das Team nur einen Feed statt fünfzig nutzen muss.
Gerade bei der Priorisierung weichen Patches von Drittanbietern in der Praxis am häufigsten von den Patches des Betriebssystems ab. Die oben beschriebene Risikoeinstufung fließt direkt in Ihre SLA-Struktur ein, die ausdrücklich in Ihrer Patch-Management-Richtlinie festgeschrieben sein sollte. Eine Richtlinie, die Drittanbieteranwendungen namentlich nennt, sie Schweregraden mit festgelegten SLAs zuordnet und dokumentierte Ausnahmen vorschreibt, beseitigt die implizite Priorisierung nach dem Motto „zuerst das Betriebssystem, dann die Drittanbieter“, die diese Lücke überhaupt erst entstehen lässt.
Das Testen unterscheidet sich grundlegend. Betriebssystem-Patches werden vor der Veröffentlichung von Microsoft, Apple oder dem jeweiligen Linux-Betreuer validiert. Patches von Drittanbietern werden vom ISV und im Idealfall durch die Katalog-Qualitätssicherung Ihrer Patching-Plattform validiert. Das verbleibende Risiko ist die Interaktion zwischen Anwendungen: ein Browser-Update, das das Rendering-Verhalten ändert und eine interne Web-App lahmlegt, ein Java-Runtime-Update, das Kompatibilitätsprobleme mit einem Branchenpaket aufdeckt, ein Teams-Build, der eine benutzerdefinierte Integration beeinträchtigt. Ein kleiner Pilotring mit repräsentativen Endpunkten, mit einer Wartezeit von 24 bis 48 Stunden für Routine-Updates und einem komprimierten Smoke-Test für aktiv ausgenutzte Schwachstellen, fängt das meiste davon ab, bevor es in die Produktion gelangt.
Bei der Bereitstellung wird das getestete Update innerhalb der von Ihnen festgelegten Wartungsfenster auf die übrigen Systeme der Infrastruktur übertragen, wobei Endpunkte, die beim ersten Versuch offline waren, erneut versucht werden und bei Fehlern Rollback-Pfade zur Verfügung stehen. Dies ist der Teil des Programms, bei dem bei manueller Ausführung die meisten Probleme sichtbar werden, da der Umfang die verfügbaren Stunden in Anspruch nimmt und die Ausnahmebehandlung die Routinearbeit verdrängt.
Die Überprüfung schließt den Kreis. Das für Sie relevante Compliance-Signal ist die installierte Version, nicht der Bereitstellungsstatus. Ein Bereitstellungsbericht kann den Status „gesendet“ anzeigen, während ein im Hintergrund aufgetretener Fehler beim Installationsprozess dazu führt, dass die alte Version auf dem Gerät verbleibt. Erst die anwendungs- und gerätespezifische Überprüfung der aktuell ausgeführten Version gibt Aufschluss darüber, ob der Patch tatsächlich installiert wurde.
Die Berichterstattung erfolgt auf Anwendungsebene und nicht auf Geräteebene. Ein Gerät, auf dem zwar die aktuelle Chrome-Version installiert ist, Java jedoch drei Versionen hinterherhinkt, gilt in keiner Weise als konform, die ein Prüfer akzeptieren würde. Die Berichterstattung sollte nach Anwendung, Schweregrad und SLA-Verstößen gegliedert sein und die Aufschlüsselung nach Kunden enthalten, die MSPs für ihre Kundenbescheinigungen benötigen.
Warum ein automatisiertes Patch-Management durch Drittanbieter unverzichtbar ist
Ohne sie geht die Rechnung nicht auf. Fünfzig Anwendungen von Drittanbietern, Dutzende von Releases pro Monat bei jedem großen Anbieter, Hunderte oder Tausende von Endgeräten, nicht aufeinander abgestimmte Release-Rhythmen der Anbieter und SLAs, die sich bei den Patches mit dem höchsten Risiko auf Stunden beziffern. Kein Team kann das manuell aufrechterhalten – und diejenigen, die es versuchen, geraten zuerst bei der Software von Drittanbietern ins Hintertreffen, weil dort die Kosten eines Rückstands im Tagesgeschäft am wenigsten sichtbar sind.
Das automatisierte Patch-Management entlastet das Team von Routineaufgaben: Es erkennt, wenn eine Anwendung ein Update benötigt, ruft das getestete Paket aus dem Katalog ab, führt die Bereitstellung im Rahmen einer automatisierten Installation während des vereinbarten Wartungsfensters durch, kümmert sich um Neustarts und wiederholt fehlgeschlagene Vorgänge. Die Mitarbeiter bleiben weiterhin in die Ausnahmebehandlung, die Genehmigung von Änderungsfenstern für sensible Systeme und den kleinen Prozentsatz an Anwendungen eingebunden, die tatsächlich manuelle Eingriffe erfordern.
Zwei Aspekte, die speziell die Automatisierung durch Drittanbieter betreffen, sollten besonders hervorgehoben werden, da sie in der allgemeinen Diskussion über Automatisierung nicht genügend Beachtung finden.
Der erste Punkt ist die Qualität des Katalogs. Die Automatisierung ist nur so gut wie der Anwendungskatalog, auf dem sie basiert. Eine Plattform, die zwei Wochen benötigt, um ein kritisches Browser-Update bereitzustellen, hat während dieser Zeit denselben Sicherheitswert wie gar keine Plattform. Die Fragen, die man sich bei der Bewertung der Patch-Fähigkeiten eines Drittanbieters stellen sollte, lauten: Wie viele Anwendungen werden standardmäßig unterstützt, wie schnell spiegelt der Katalog neue Hersteller-Releases wider (insbesondere bei Sicherheitsupdates) und welche Qualitätssicherung wird bei jedem Paket durchgeführt, bevor es die Endgeräte in der Produktion erreicht?
Der zweite Punkt ist die Abhängigkeitsfläche. Ein fehlerhafter Betriebssystem-Patch führt häufig dazu, dass das Betriebssystem nicht mehr funktioniert. Ein fehlerhafter Patch eines Drittanbieters führt häufig dazu, dass die davon abhängige Anwendung nicht mehr funktioniert – das kann einen Geschäftsablauf, eine Integration oder ein Produktivitätswerkzeug betreffen, das im gesamten Unternehmen genutzt wird. Die Abhilfemaßnahmen sind dieselben wie bei jedem anderen Patch-Programm: Bereitstellungsringe, Wartezeiten, automatisierte Rollbacks. Die operative Fehlertoleranz ist jedoch geringer, da Nutzer einen Ausfall von Adobe Reader schneller bemerken als ein Kernel-Update.
Der Compliance-Aspekt
Compliance-Rahmenwerke tun nicht mehr so, als sei Software von Drittanbietern ein separates Thema. Die Anforderung 6.3.3 des PCI DSS 4.0 umfasst alle Systemkomponenten, darunter auch Anwendungen, und nicht nur Betriebssysteme. Anhang A 8.8 der ISO 27001:2022 behandelt das technische Schwachstellenmanagement ohne Ausnahmen. Die Sicherheitsvorschrift der HIPAA wurde in Durchsetzungsmaßnahmen so ausgelegt, dass sie das Patchen von Anwendungen als Teil „angemessener und geeigneter“ Sicherheitsmaßnahmen umfasst. NIS2, das in allen EU-Mitgliedstaaten gilt, verlangt den Nachweis einer zeitnahen Schwachstellenbehebung, ohne dabei zwischen Betriebssystem und Anwendung zu unterscheiden. Das SOC 2 Trust Services-Kriterium CC7.1 umfasst die Überwachung und Behebung neuer Schwachstellen im gesamten System.
Die praktischen Konsequenzen sind in jedem Fall dieselben. Ein Audit, bei dem Ihr Patch-Programm überprüft wird und unverwaltete Browser, nicht gepatchte PDF-Reader oder Java-Laufzeitumgebungen am Ende ihrer Lebensdauer entdeckt werden, wird zu Beanstandungen führen – ganz gleich, wie einwandfrei Ihr Windows-Compliance-Bericht auch aussehen mag. Die beste Verteidigung gegen solche Beanstandungen sind operative Nachweise: Compliance-Berichte für jede einzelne Anwendung, datierte Bereitstellungsaufzeichnungen, dokumentierte Ausnahmen sowie SLAs, die in der Praxis und nicht nur auf dem Papier eingehalten werden.
Wie Kaseya die Patch-Verwaltung für Produkte von Drittanbietern vereinfacht
Das Patchen von Anwendungen von Drittanbietern ist kein Wissensproblem. Jedes IT-Team und jeder MSP weiß, dass Anwendungen gepatcht werden müssen. Es handelt sich um ein operatives Problem, und dieses operative Problem ist struktureller Natur: mehr Anbieter, mehr Aktualisierungsrhythmen, mehr Installationsformate, eine größere Erfassungsfläche und ein Standard-Workflow, der das Patchen von Betriebssystemen bevorzugt, da sich dieses einfacher automatisieren lässt.
Die Lösung besteht darin, Drittanbieter nicht mehr als paralleles Programm zu behandeln, sondern sie in dasselbe Rahmenwerk zu integrieren wie die bereits laufenden Prozesse. Gleiche Bestandsaufnahme. Gleiche Risikoeinstufung. Gleiche SLAs in der Richtlinie. Gleiche Bereitstellungsringe. Gleiche Automatisierung. Gleiche Compliance-Berichterstattung pro Anwendung. Die zugrunde liegenden Tools müssen einen getesteten Drittanbieter-Katalog in dem Rhythmus unterstützen, in dem die Anbieter tatsächlich neue Versionen veröffentlichen, aber das Programmdesign ist kein anderes Programm. Es ist dasselbe Programm, in vollem Umfang.
Dieses Designprinzip bildet die Grundlage der RMM-Lösungen von Kaseya: Patches für Betriebssysteme, Drittanbieter-Software und Firmware werden über einen einzigen Agenten, ein einziges Richtlinien-Framework, ein einziges Set von Wartungsfenstern und eine einzige Compliance-Ansicht verwaltet. Das „Advanced Software Management“-Modul von Datto RMMist die genannte Drittanbieter-Funktion, die die Patch-Abdeckung auf über 200 sofort einsatzbereite Anwendungen erweitert – mit einem Katalog, der vor der Veröffentlichung auf Millionen von Geräten getestet wurde und kontinuierlich erweitert wird.
Das Modul unterstützt zudem die Installation und Deinstallation von Anwendungen über dasselbe Richtlinien-Framework, wodurch eine Lücke geschlossen wird, die die meisten Patching-Tools offen lassen: Anwendungen, deren Lebensdauer abgelaufen ist und die entfernt – und nicht nur aktualisiert – werden müssen, bevor sie ausgenutzt werden können. Für MSPs bedeutet dies die Konfiguration von Richtlinien und die Erstellung von Compliance-Berichten für jeden einzelnen Kunden über eine einzige Konsole. Für interne IT-Teams bietet es einen einheitlichen Überblick über den Patch-Status von Betriebssystemen und Drittanbieter-Software mit dem von Compliance-Rahmenwerken erwarteten Prüfpfad – und zwar als Nebenprodukt des Workflows und nicht als vierteljährliche Maßnahme zur Evidenzsammlung.
Die Alternative wäre, eine dokumentierte Angriffsfläche ungeschützt zu lassen, während das Dashboard für Betriebssystem-Patches weiterhin „grün“ anzeigt. Genau diese Lücke nutzen Angreifer aus – und aktuelle Daten zu Exploits deuten darauf hin, dass sie damit richtig liegen.
