Am 27. September 2026 hat die US-Cybersicherheitsbehörde CISA zwei kritische Citrix-NetScaler-Lücken in ihren Known-Exploited-Vulnerabilities-Katalog aufgenommen, CVE-2026-88772 und CVE-2026-88771, beide mit einem CVSS-Wert von 9,5. Die Frist für Bundesbehörden lautet 30. September 2026, also drei Tage nach Veröffentlichung dieses Artikels. Wer in einem deutschen oder Schweizer Unternehmen für IT-Sicherheit zuständig ist, kennt das Muster: Eine Lücke wird bekannt, der Patch liegt vor, und trotzdem dauert es im Schnitt 54,81 Tage, bis er auf kritischen Anwendungen landet. Das ist keine Schätzung, sondern der Wert aus dem Edgescan 2026 Vulnerability Statistics Report. Genau in dieser Lücke zwischen Patch-Verfügbarkeit und Patch-Installation entscheiden sich Sicherheitsvorfälle. Dieser Vergleich stellt drei der meistgenutzten Patch-Management-Plattformen gegenüber, NinjaOne, Automox und ManageEngine Patch Manager Plus, mit echten Preisen, echten Spezifikationen und echten Kundenbeispielen. Wer heute entscheidet, welches Werkzeug den nächsten KEV-Eintrag schneller schließt als die eigene bisherige Routine, trifft eine Entscheidung, die über die Citrix-Lücke von dieser Woche hinausreicht, denn die nächste kritische Meldung kommt erfahrungsgemäß binnen weniger Wochen.
Der Auslöser: CVE-2026-88772 und die neue KEV-Dringlichkeit
Die beiden neuen Citrix-Einträge stehen nicht allein. Parallel dazu warnt CISA vor CVE-2026-5430, einer Schwachstelle im WSO2 API Manager mit dem höchstmöglichen CVSS-Wert von 10,0, die eine nicht authentifizierte Admin-Übernahme über ein JWT mit nicht unterstütztem Algorithmus erlaubt. Der CISA-KEV-Tracker listet zum Stichtag 28. September 2026 zusätzlich aktiv ausgenutzte Lücken bei Cisco ISE, Arista VeloCloud Orchestrator und GitLab. Für Bundesbehörden in den USA gilt üblicherweise eine Frist von 14 Kalendertagen ab Aufnahme in den Katalog, ältere Katalogeinträge folgten teils einer kürzeren Sechs-Werktage-Regel unter der Binding Operational Directive 22-01. Deutsche und Schweizer Unternehmen sind an diese US-Fristen zwar nicht gebunden, orientieren sich aber zunehmend daran, weil viele Auditoren und Cyberversicherer die KEV-Liste als Maßstab für zumutbare Reaktionszeit heranziehen.
Der Citrix-Fall ist historisch kein Ausreißer. Bereits frühere NetScaler-Schwachstellen, im Branchenjargon unter Namen wie Citrix Bleed bekannt geworden, führten in der Vergangenheit zu wochenlangen Aufräumarbeiten in Unternehmen, weil viele Administratoren VPN-Gateways und Application-Delivery-Controller seltener patchen als klassische Windows-Server. Genau diese Geräte stehen aber meist direkt im Internet und sind damit das erste Ziel automatisierter Scan-Kampagnen. Die WSO2-Lücke CVE-2026-5430 verschärft das Bild zusätzlich, weil API-Management-Plattformen wie WSO2 oft zentrale Schnittstellen zwischen internen Systemen und externen Partnern bilden. Ein erfolgreicher Angriff dort wirkt sich selten auf ein einzelnes System aus, sondern auf die gesamte angebundene Systemlandschaft.
Wie stark die Bedrohungslage im DACH-Raum bereits ist, zeigt der Blick auf aktuelle Ransomware-Fälle: Anfang September 2026 musste die Berliner Landesregierung nach einem Datenleck zweier Senatsverwaltungen eine Krisenreaktion einleiten, wie Reuters berichtete. Solche Fälle sind kein Einzelschicksal, sondern Teil eines Trends, den auch der Bundeskriminalamt-Bericht regelmäßig dokumentiert. Wer wissen will, wie die Zahlen zur Cyberkriminalität in Deutschland insgesamt aussehen, findet Kontext in unserem Bericht zur BKA-Cybercrime-Statistik 2025. Der gemeinsame Nenner in fast allen dieser Fälle ist derselbe: Angreifer suchen nicht nach neuen Lücken, sie suchen nach alten, bereits gepatchten Lücken, die in der Praxis liegen geblieben sind.
Drei Wege zum selben Ziel: Die Kandidaten im Überblick
NinjaOne, Automox und ManageEngine Patch Manager Plus lösen dasselbe Grundproblem auf drei unterschiedliche Arten. NinjaOne ist in erster Linie eine cloudbasierte RMM-Plattform (Remote Monitoring and Management), bei der Patch-Management ein Baustein unter vielen ist, neben Fernzugriff, Skripting und Asset-Monitoring. Das Unternehmen mit Sitz in Austin, Texas, gibt an, knapp 40.000 Kunden in über 140 Ländern zu betreuen, darunter laut eigenen Angaben Marken wie Lyft, Cintas, Vimeo, HelloFresh und Porsche. NinjaOne wurde laut eigener Pressemitteilung als Leader im Gartner Magic Quadrant 2026 für Endpoint Management Tools geführt, Details dazu liefert die offizielle NinjaOne-Referenzseite.
Automox verfolgt einen schlankeren Ansatz: eine reine, cloud-native Patch- und Endpoint-Automatisierungsplattform ohne den vollen RMM-Funktionsumfang von NinjaOne. Zentrales Werkzeug sind sogenannte Worklets, kleine Skripte, mit denen sich Patches, Konfigurationsänderungen und Remediation-Schritte über Windows, macOS und Linux hinweg automatisieren lassen. Das Modell zielt auf Teams, die Patch-Automatisierung wollen, aber keine komplette Fernwartungssuite brauchen.
ManageEngine Patch Manager Plus ist die IT-Management-Sparte von Zoho Corporation und unterscheidet sich von den beiden anderen durch eine echte Wahlmöglichkeit: Cloud-Betrieb oder klassische On-Premises-Installation im eigenen Rechenzentrum. Für Unternehmen mit strengen Datenresidenz-Anforderungen, etwa Behörden, Kliniken oder Finanzdienstleister im DACH-Raum, ist das oft der entscheidende Unterschied. Das Produkt deckt laut Herstellerangaben mehr als 1.100 Drittanbieter-Anwendungen ab, mehr als bei den beiden anderen Kandidaten öffentlich dokumentiert ist.
Die drei Anbieter zielen damit auf unterschiedliche Käufergruppen, auch wenn sich ihre Funktionslisten auf den ersten Blick ähneln. NinjaOne wirbt gezielt um Managed Service Provider, die Dutzende oder Hunderte Kundenumgebungen gleichzeitig verwalten und dafür eine Plattform mit Mandantentrennung brauchen. Automox positioniert sich eher als Ergänzung zu bestehender Infrastruktur, für Teams, die schon ein Ticketing- oder Monitoring-System besitzen und nur die Patch-Lücke schließen wollen. ManageEngine wiederum spricht traditionell IT-Abteilungen an, die aus einer On-Premises-Welt kommen und den Wechsel in die Cloud schrittweise statt abrupt vollziehen wollen. Diese Positionierung erklärt auch, warum ein direkter Feature-für-Feature-Vergleich nur die halbe Wahrheit zeigt, die andere Hälfte entscheidet sich an der bestehenden IT-Landschaft des jeweiligen Käufers.
Unterschiede zeigen sich auch bei der Transparenz über das Unternehmen selbst. NinjaOne kommuniziert Kundenzahlen, Länderreichweite und Analysten-Platzierungen relativ offen über eigene Presseseiten und Fallstudien-Verzeichnisse. Automox veröffentlicht zwar regelmäßig einzelne Kunden-Case-Studies, hält sich bei unternehmensweiten Kennzahlen wie Gesamtkundenzahl oder Finanzierungsrunden aber öffentlich bedeckter. ManageEngine wiederum tritt bewusst als Teil der größeren Zoho Corporation auf und verzichtet auf eigenständige Presse-Kommunikation im Stil eines separat finanzierten Start-ups, was für Käufer, die auf langfristige Unternehmensstabilität achten, ein eigenes Kriterium sein kann. Wer belastbare aktuelle Zahlen zu Kundenzahl, Umsatz oder Finanzierung sucht, sollte diese direkt bei den Anbietern anfragen, da sich solche Angaben schneller ändern als Produktspezifikationen.
Technische Spezifikationen im direkten Vergleich
Die folgende Tabelle fasst die dokumentierten technischen Eigenschaften aller drei Plattformen zusammen. Sie basiert auf den öffentlich zugänglichen Produktseiten und Herstellerangaben von NinjaOne, Automox und ManageEngine, Stand September 2026. Wo ein Hersteller eine konkrete Zahl nicht öffentlich dokumentiert, etwa die genaue Größe des Drittanbieter-Katalogs bei NinjaOne und Automox, ist das in der Tabelle explizit vermerkt, statt eine Schätzung als Fakt auszugeben.
| Merkmal | NinjaOne | Automox | ManageEngine Patch Manager Plus |
|---|---|---|---|
| Bereitstellung | Ausschließlich Cloud | Cloud-nativ | Cloud und On-Premises |
| Windows-Patching | Ja | Ja | Ja |
| macOS-Patching | Ja | Ja | Ja |
| Linux-Patching | Ja | Ja | Ja |
| Drittanbieter-Katalog | Breit, laut Anbieter kuratiert, keine öffentliche Stückzahl | Keine öffentlich dokumentierte Stückzahl | Über 1.100 Anwendungen dokumentiert |
| Automatisierung | Richtlinien, Skripte, Workflow-Automatisierung | Richtlinien und Worklets (Skripte) | Automatisierte Bereitstellung, Zeitpläne, Genehmigungs-Workflows |
| Patch-Test und Freigabe | Über Richtlinien und Automatisierung | Über Richtlinien und Skripte | Automatisches Testen und Freigeben (Enterprise Edition) |
| Rollback | Nicht einheitlich dokumentiert | Nicht einheitlich dokumentiert | Dediziertes Patch-Rollback als Feature gelistet |
| Architektur | Agent-basiert | Agent-basiert | Agent-basiert |
| RMM-Funktionsumfang | Vollständige RMM-Plattform inklusive Fernzugriff | Kein vollständiges RMM, Fokus auf Patch/Endpoint-Automatisierung | Teil des breiteren ManageEngine-Endpoint-Ökosystems |
| Reporting/Compliance | Endpoint-, Patch-, Alarm- und Compliance-Reporting | Patch-Status- und Endpoint-Reporting | Patch-Compliance-, Schwachstellen- und Audit-Reporting |
| API-Zugriff | Vorhanden | Vorhanden | Vorhanden |
| Kostenlose Testversion | Verfügbar | Verfügbar | Verfügbar, zusätzlich dauerhaft kostenlose Free Edition |
Auffällig ist vor allem die Rollback-Frage. Nur ManageEngine listet ein dediziertes Patch-Rollback explizit als Produktmerkmal auf der eigenen Edition-Vergleichsseite. Bei NinjaOne und Automox lässt sich ein fehlgeschlagener Patch zwar über Skripte und Automatisierungsregeln rückgängig machen, ein eigenständiges, dokumentiertes Rollback-Werkzeug ist öffentlich aber nicht in gleicher Form beschrieben. Für Umgebungen, in denen ein einzelner missglückter Patch einen Produktionsausfall auslösen kann, ist das ein Kriterium, das schwerer wiegt als jede Katalog-Statistik.
Ein zweiter, oft unterschätzter Punkt ist die Integration in bestehende Sicherheitsprozesse. Patch-Management läuft selten isoliert, in den meisten Unternehmen speisen die Reports aus NinjaOne, Automox oder ManageEngine zusätzlich ein SIEM-System oder ein Ticketing-Tool, um Compliance-Nachweise und Vorfallsdokumentation an einer zentralen Stelle zu bündeln. Alle drei Plattformen bieten dafür eine API an, die Tiefe der Integration unterscheidet sich aber deutlich: ManageEngine punktet durch die Nähe zum größeren Zoho- und ManageEngine-Ökosystem, NinjaOne durch native Anbindungen an gängige PSA-Tools (Professional Services Automation) aus dem MSP-Umfeld, Automox durch eine schlankere, aber dafür leichter scriptbare REST-API. Welche Variante am besten passt, hängt stark davon ab, welche Werkzeuge im jeweiligen Unternehmen bereits im Einsatz sind.
Preise 2026: Von 1 Dollar bis 345 Dollar
Patch-Management-Preise folgen selten einem einheitlichen Modell, und das macht den direkten Vergleich tückisch. NinjaOne und Automox rechnen pro Endpoint und Monat ab, ManageEngine dagegen in Paketen für eine feste Anzahl an Rechnern. Wer nur auf die nackte Zahl schaut, vergleicht schnell Äpfel mit Birnen. Die folgende Tabelle zeigt die offiziell veröffentlichten Einstiegspreise, wie sie auf den jeweiligen Hersteller- und Marktplatzseiten Stand September 2026 gelistet sind.
| Anbieter / Tarif | Preis | Abrechnungsmodell |
|---|---|---|
| NinjaOne, ab 10.000 Endpoints | ab ca. 1,50 $ pro Endpoint/Monat | Volumenbasiert, individuelles Angebot |
| NinjaOne, bis 50 Endpoints | ca. 3,75 $ pro Endpoint/Monat | Volumenbasiert, individuelles Angebot |
| Automox PatchOS | 1,00 $ pro Endpoint/Monat | Jährliche Abrechnung |
| ManageEngine Free Edition | 0 € | Begrenzte Geräteanzahl, dauerhaft kostenlos |
| ManageEngine Professional Cloud | ab 34,50 $/Monat | Pauschalpreis (Flat Rate) |
| ManageEngine Enterprise Cloud | ab 44,50 $/Monat | Pauschalpreis (Flat Rate) |
| ManageEngine Professional On-Premises | ab 245 $/Jahr | Für 50 Rechner, ein Techniker-Account |
| ManageEngine Enterprise On-Premises | ab 345 $/Jahr | Für 50 Rechner, ein Techniker-Account |
Rechnet man die On-Premises-Pakete von ManageEngine auf einzelne Geräte herunter, landet man bei etwa 0,41 US-Dollar pro Rechner und Monat für die Professional-Variante, deutlich unter dem Einstiegspreis von Automox und NinjaOne. Der Haken: Dieser Preis gilt nur für die feste Paketgröße von 50 Computern, wächst das Unternehmen, braucht es ein größeres Lizenzpaket, keine granulare Pro-Endpoint-Abrechnung. NinjaOne und Automox verlangen keinen öffentlichen Festpreis, sondern ein individuelles Angebot, das nach eigenen Angaben von Region, Endpoint-Zahl und gebuchten Zusatzmodulen abhängt. Die genauen Zahlen auf der offiziellen ManageEngine-Preisseite und im Automox-Preisrechner lohnt sich vor jeder Kaufentscheidung ein eigener Blick, da sich Konditionen unterjährig ändern.
Um die abstrakten Tarife greifbarer zu machen, hilft eine Beispielrechnung für ein mittelständisches Unternehmen mit 500 Endpoints, wie es in Deutschland zwischen produzierendem Gewerbe und IT-Dienstleistung häufig vorkommt. Bei Automox ergeben 500 Endpoints zu 1,00 US-Dollar pro Monat einen Jahrespreis von etwa 6.000 US-Dollar. Bei NinjaOne liegt der Preis pro Endpoint mit steigender Stückzahl niedriger als bei kleinen Kontingenten, ein realistischer Mittelwert für 500 Geräte dürfte nach den veröffentlichten Eckwerten zwischen den genannten 1,50 und 3,75 US-Dollar liegen, macht grob 9.000 bis 22.500 US-Dollar im Jahr, je nach ausgehandeltem Rabatt. ManageEngine würde für 500 Rechner mehrere Enterprise-On-Premises-Pakete zu je 345 US-Dollar pro 50 Geräte benötigen, macht zehn Pakete und damit 3.450 US-Dollar Lizenzkosten im Jahr, allerdings ohne die Kosten für Server-Hardware und Betrieb der On-Premises-Infrastruktur, die bei den beiden Cloud-Konkurrenten entfallen. Wichtig ist: Diese Rechnung ist eine Näherung auf Basis der veröffentlichten Einstiegspreise, keine verbindliche Kalkulation, reale Angebote hängen von Rabattstaffeln, Support-Level und Vertragslaufzeit ab. Trotzdem zeigt sie ein Muster, das sich durch alle drei Anbieter zieht: Wer viele Endpoints und wenig internes Server-Know-how hat, fährt tendenziell mit den Cloud-Lösungen NinjaOne oder Automox günstiger, wer bereits über eigene Serverkapazität und Administrationswissen verfügt, kann mit ManageEngines On-Premises-Paketen die Lizenzkosten niedrig halten und zahlt den Ausgleich in Form von Betriebsaufwand statt in Abo-Gebühren.
Benchmark-Daten: Wie langsam patcht die Praxis wirklich?
Ein Patch-Management-Tool ist nur so gut wie die Prozesse, die es automatisiert. Mehrere unabhängige Studien aus 2025 und 2026 zeigen, wie groß die Lücke zwischen Theorie und Praxis tatsächlich ist. Der Edgescan 2026 Vulnerability Statistics Report beziffert die durchschnittliche Zeit bis zur Behebung (Mean Time to Remediate) für hoch- und kritisch eingestufte Anwendungs- und API-Schwachstellen auf 54,81 Tage. Bei Geräte- und Netzwerk-Schwachstellen sind es im Schnitt 39 Tage. Besonders alarmierend: Schwachstellen mit einer hohen Ausnutzungswahrscheinlichkeit (EPSS über 0,1) brauchten im Schnitt 210 Tage bis zur Behebung, und 37 Prozent aller Schwachstellen in großen Unternehmensumgebungen waren nach zwölf Monaten immer noch offen. Wer sich näher mit der Frage beschäftigt, wie Scores wie EPSS überhaupt zustande kommen, findet Hintergrund in unserem Vergleich von CVSS gegen EPSS.
Eine zweite Quelle, die Adaptiva-Studie “The State of Patch Management 2025”, zeichnet ein ähnliches Bild aus der Prozessperspektive: Im Schnitt automatisieren befragte Unternehmen nur 3,9 einzelne Elemente ihres Patch-Prozesses, etwa Scans oder Versionsidentifikation, der Rest bleibt Handarbeit. Eine dritte, separate Erhebung, der “2025 State of Vulnerability Remediation”-Report, kommt zu einem noch deutlicheren Ergebnis: 62 Prozent der befragten Organisationen arbeiten mit überwiegend manuellen Remediation-Workflows, nur 2 Prozent sind vollständig automatisiert. Eine vierte Quelle, ein Whitepaper der Cloud Security Alliance zum sogenannten Collapsing Exploit Window, nennt für komplexe Unternehmensanwendungen sogar eine mittlere Behebungszeit von 5 Monaten und 10 Tagen, während Angreifer neue Schwachstellen im Median innerhalb von unter fünf Tagen ausnutzen. Diese Diskrepanz zwischen Angriffsgeschwindigkeit und Reaktionsgeschwindigkeit ist im Kern das Problem, das Automatisierungsplattformen wie die drei hier verglichenen lösen sollen.
Was bedeuten 54,81 Tage in der Praxis? Ein Unternehmen, das eine kritische Lücke am Tag der Veröffentlichung entdeckt, aber erst am 55. Tag patcht, war für fast acht Wochen einem Zeitfenster ausgesetzt, in dem öffentlich dokumentierte Angriffscode-Beispiele meist längst kursieren. Angreifer brauchen für die Ausnutzung neuer Schwachstellen im Median dagegen unter fünf Tage, wie das erwähnte CSA-Whitepaper zeigt. Die Differenz zwischen diesen beiden Zahlen, rund 50 Tage, ist exakt das Zeitfenster, in dem automatisiertes Patch-Management den größten Unterschied macht: Es verkürzt nicht primär die Erkennung einer Lücke, sondern die Zeit zwischen Erkennung und tatsächlicher Bereitstellung des Patches auf allen betroffenen Geräten, dem Schritt, an dem manuelle Prozesse laut den zitierten Studien am häufigsten ins Stocken geraten.
| Kennzahl | Wert | Quelle |
|---|---|---|
| MTTR hoch/kritisch, Anwendungen/APIs | 54,81 Tage | Edgescan 2026 Vulnerability Statistics Report |
| MTTR hoch/kritisch, Geräte/Netzwerk | 39 Tage | Edgescan 2026 Vulnerability Statistics Report |
| MTTR bei EPSS über 0,1 | 210 Tage | Edgescan 2026 Vulnerability Statistics Report |
| Nach 12 Monaten noch offen | 37 % | Edgescan 2026 Vulnerability Statistics Report |
| Vollständig automatisierte Workflows | 2 % | 2025 State of Vulnerability Remediation Report |
| Überwiegend manuelle Workflows | 62 % | 2025 State of Vulnerability Remediation Report |
| MTTR komplexer Enterprise-Apps | 5 Monate, 10 Tage | Cloud Security Alliance Whitepaper |
| Typische CISA-Bundesfrist ab KEV-Aufnahme | 14 Tage | CISA Binding Operational Directive 22-01 |
NinjaOne im Detail: RMM und Patch-Management aus einer Hand
NinjaOnes größter Vorteil zeigt sich in Umgebungen, in denen IT-Teams ohnehin ein RMM-Werkzeug brauchen: Statt Patch-Management, Fernzugriff, Skript-Ausführung und Asset-Inventar in getrennten Tools zu pflegen, laufen alle Funktionen in einer Konsole zusammen. Das reduziert Werkzeugwechsel im Tagesgeschäft und vereinfacht das Onboarding neuer Techniker. Die Plattform ist konsequent cloudbasiert, es gibt keine On-Premises-Variante, was für Unternehmen mit Cloud-Vorbehalten ein Ausschlusskriterium sein kann, für alle anderen aber schnelle Rollouts ohne eigene Serverinfrastruktur ermöglicht.
Laut eigenen Angaben wurde NinjaOne in 13 G2-Kategorien des Fall-2025-Reports auf Platz eins geführt und erhielt im Rahmen der G2 2026 Best Software Awards den ersten Platz in der Kategorie Security Products sowie eine Top-5-Platzierung im Bereich IT-Management. Diese Zahlen stammen aus Herstellerkommunikation und sollten vor einer Kaufentscheidung mit unabhängigen Bewertungsportalen abgeglichen werden. Technisch überzeugt NinjaOne vor allem durch die Kombination aus Patch-Automatisierung, Skripting-Engine und Workflow-Automatisierung, die sich in Richtlinien bündeln lässt, sodass neue Endpoints automatisch der passenden Patch-Gruppe zugeordnet werden.
Stärken für Managed Service Provider
Für MSPs zählt neben der reinen Funktionsliste vor allem eines: Wie schnell lässt sich ein neuer Kunde onboarden, ohne dass ein Techniker tagelang manuell Richtlinien nachbaut? NinjaOnes Mandantenmodell erlaubt es, einmal definierte Patch-Richtlinien auf neue Kundenumgebungen zu übertragen und nur die Ausnahmen individuell anzupassen. Das Rdata-Beispiel aus dem Praxisteil zeigt, wie stark sich das auf den täglichen Arbeitsaufwand auswirkt, wenn zuvor mehrere getrennte Werkzeuge im Einsatz waren. Wichtig für MSPs im DACH-Raum bleibt trotzdem die Cloud-only-Architektur: Kundenverträge mit expliziten Datenresidenz-Klauseln erfordern eine gesonderte Prüfung, in welcher Region NinjaOne die Kundendaten tatsächlich verarbeitet.
Automox im Detail: Schlanke Cloud-native Automatisierung
Automox verzichtet bewusst auf den großen RMM-Funktionsumfang und konzentriert sich auf eine Kernaufgabe: Patches über Windows, macOS und Linux hinweg zuverlässig und automatisiert auszurollen. Das Herzstück sind Worklets, wiederverwendbare Skript-Bausteine, mit denen sich neben reinen Sicherheitsupdates auch Konfigurationsänderungen und Compliance-Checks automatisieren lassen. Für Teams, die bereits ein separates Monitoring- oder Ticketing-System betreiben und kein zusätzliches RMM wollen, ist das ein schlankeres, potenziell günstigeres Modell.
Der Einstiegspreis von 1,00 US-Dollar pro Endpoint und Monat für den PatchOS-Tarif ist unter den drei Kandidaten der am klarsten öffentlich dokumentierte. Das schafft Planungssicherheit, gerade für kleinere IT-Dienstleister, die Kunden pauschal kalkulieren müssen. Wie schnell sich das in der Praxis auszahlt, zeigt das Fallbeispiel weiter unten: Ein kanadischer Softwareentwickler reduzierte die Zeit für Geräte-Updates laut eigener Automox-Fallstudie um 98 Prozent.
Worklets als Alternative zu klassischen Richtlinien
Während NinjaOne und ManageEngine Patches primär über grafisch konfigurierte Richtlinien steuern, setzt Automox stärker auf Code. Ein Worklet ist im Kern ein Skript, das auf einem oder mehreren Endpoints zu einem definierten Zeitpunkt oder Ereignis ausgeführt wird, etwa um eine Konfigurationsabweichung zu korrigieren oder ein Update außerhalb des regulären Patch-Zyklus einzuspielen. Für DevOps-nahe IT-Teams, die Infrastruktur ohnehin als Code verwalten, fühlt sich dieses Modell vertrauter an als ein reines Klick-Interface. Der Nachteil: Wer keine internen Skripting-Kenntnisse hat, ist stärker auf die von Automox mitgelieferte Worklet-Bibliothek angewiesen als bei den stärker vorkonfigurierten Richtlinien der beiden Mitbewerber.
ManageEngine Patch Manager Plus im Detail: Cloud oder eigenes Rechenzentrum
ManageEngine spielt seine Stärken dort aus, wo Datenresidenz und Compliance über der reinen Bedienfreundlichkeit stehen. Die On-Premises-Variante läuft vollständig in der eigenen Infrastruktur, ein Kriterium, das für Behörden, Krankenhäuser und regulierte Finanzdienstleister im DACH-Raum oft nicht verhandelbar ist. Gleichzeitig bietet der Hersteller mit der Cloud-Variante eine Alternative für Unternehmen, die keine eigene Serverwartung wollen, beide Wege laufen über dieselbe Bedienoberfläche.
Mit mehr als 1.100 dokumentierten Drittanbieter-Anwendungen deckt ManageEngine den größten öffentlich belegten Katalog der drei Kandidaten ab, von Browsern über Java-Laufzeitumgebungen bis zu Kollaborationssoftware. Die Enterprise-Edition ergänzt automatisches Testen und Freigeben von Patches, Antivirus-Definitionsupdates sowie Treiber- und BIOS-Updates, Funktionen, die in der schlankeren Professional-Edition fehlen. In Gartner Peer Insights waren für die ManageEngine-Endpoint-Management-Sparte zum 23. März 2026 insgesamt 1.565 Bewertungen registriert, eine Zahl, die sich auf das gesamte Endpoint-Management-Portfolio bezieht und nicht ausschließlich auf Patch Manager Plus.
On-Premises gegen Cloud: Die Entscheidung im Detail
Die Wahl zwischen den beiden Bereitstellungsarten ist selten eine reine Kostenfrage. On-Premises bedeutet, dass Patch-Metadaten, Geräteinventar und Compliance-Reports das eigene Netzwerk nicht verlassen, ein Argument, das bei Behörden und im Gesundheitswesen häufig durch interne Richtlinien vorgegeben ist statt frei wählbar. Der Preis dafür ist zusätzlicher Betriebsaufwand: Die Software muss selbst gepatcht, die Datenbank gesichert und die Verfügbarkeit des Verteilservers sichergestellt werden. Die Cloud-Variante von ManageEngine nimmt diese Last ab, verlangt im Gegenzug aber dasselbe Vertrauen in externe Infrastruktur, das On-Premises-Befürworter gerade vermeiden wollen. Unternehmen, die zwischen beiden Welten wechseln wollen, profitieren davon, dass ManageEngine beide Modelle über dieselbe Oberfläche anbietet, ein Wechsel erfordert damit keine komplette Neueinarbeitung der Administratoren.
Fünf Praxisbeispiele: Was die Umstellung wirklich bringt
Herstellerversprechen sind das eine, dokumentierte Kundenergebnisse das andere. Die folgenden Beispiele stammen aus öffentlich veröffentlichten Fallstudien der drei Anbieter.
- Executech (NinjaOne): Der nordamerikanische Managed-Service-Provider migrierte laut NinjaOne-Kundenreferenzen rund 30.000 Agents in unter drei Monaten auf die Plattform, steigerte die Patch-Compliance um 42 Prozent und automatisierte 25 Prozent der IT-Tickets.
- Rdata (NinjaOne): Der schwedische MSP mit 2.200 Endpoints und einem 13-köpfigen Team migrierte laut veröffentlichter Fallstudie mehr als 2.000 Endpoints in unter drei Tagen und reduzierte den administrativen IT-Aufwand um 95 Prozent, umgerechnet rund 60 Stunden pro Monat.
- Tekside.iO (Automox): Der kanadische App-Entwickler und IT-Operations-Partner senkte die Zeit für Geräte-Updates laut Automox-Fallstudie um 98 Prozent.
- Ein Softwaretestautomatisierungs-Unternehmen (Automox): Laut veröffentlichter Fallstudie patcht das Unternehmen seit der Umstellung alle kritischen Schwachstellen in unter 48 Stunden über einen zentralisierten Prozess für mehrere Betriebssysteme und Drittanbieter-Anwendungen hinweg.
- Isala (ManageEngine): Die niederländische Krankenhausgruppe automatisierte Betriebssystem- und Drittanbieter-Patch-Workflows und ersetzte laut ManageEngine-Fallstudie einen Großteil der bisherigen manuellen Eingriffe durch konsistente, zeitnahe Patch-Bereitstellung.
- Shoes For Crews (ManageEngine): Der Hersteller für Arbeitsschutzschuhe nutzt Patch Manager Plus laut eigener Fallstudie zur Absicherung von Windows-, Mac- und Linux-Systemen im Tagesgeschäft.
Bemerkenswert ist der Fall Isala, weil er die besondere Dringlichkeit im Gesundheitswesen illustriert: Kliniken können selten ganze Abteilungen für Wartungsfenster abschalten. Automatisierte, getestete Patch-Zyklen sind dort oft der einzige praktikable Weg, Systeme aktuell zu halten, ohne den Betrieb zu gefährden.
Gemeinsam ist allen sechs Beispielen, dass der Nutzen sich selten in der reinen Patch-Geschwindigkeit erschöpft. Executech und Rdata berichten vor allem von eingesparter Arbeitszeit, die frei gewordene Kapazität floss laut den Fallstudien in andere Kundenprojekte statt in Personalabbau. Das zeigt: Automatisiertes Patch-Management ist in den dokumentierten Fällen kein reines Sicherheitsprojekt, sondern zahlt sich auch betriebswirtschaftlich aus, ein Argument, das sich in internen Budgetgesprächen oft leichter durchsetzen lässt als eine abstrakte Risikoreduktion.
Für wen sich welches Tool eignet: Sechs Einsatzszenarien
- MSPs mit vielen Kunden und Standorten: NinjaOne bündelt Fernzugriff, Monitoring und Patching in einer Konsole und spart Werkzeugwechsel im Tagesgeschäft, wie das Executech-Beispiel mit 30.000 Agents zeigt.
- Schlanke IT-Teams ohne RMM-Bedarf: Wer bereits ein Monitoring-Tool nutzt und nur Patch-Automatisierung braucht, fährt mit Automox günstiger, ohne für ungenutzte RMM-Funktionen zu zahlen.
- Behörden, Kliniken und regulierte Branchen: Wo Daten das eigene Rechenzentrum nicht verlassen dürfen, bleibt ManageEngine mit seiner On-Premises-Option die einzige der drei Optionen, die diese Anforderung erfüllt.
- Kleine Unternehmen mit engem Budget: Die kostenlose ManageEngine Free Edition deckt kleinere Umgebungen ab, ohne dass sofort ein bezahlter Vertrag nötig wird.
- Unternehmen mit vielen Drittanbieter-Anwendungen: Der mit über 1.100 Titeln größte dokumentierte Katalog macht ManageEngine zur naheliegenden Wahl, wenn neben Windows-Updates auch Adobe-, Java- und Browser-Patches im großen Umfang anfallen.
- Cross-Plattform-Umgebungen mit skript-affinen Admins: Teams, die Automatisierung lieber selbst als Code schreiben statt über grafische Richtlinien zu konfigurieren, profitieren von Automox’ Worklet-Modell oder NinjaOnes Skripting-Engine.
In der Praxis überschneiden sich diese Szenarien häufig. Ein mittelständisches DACH-Unternehmen mit eigener IT-Abteilung, das gleichzeitig gesetzliche Meldepflichten nach NIS-2 erfüllen muss und ein knappes Budget hat, findet sich womöglich in drei der sechs Kategorien gleichzeitig wieder. In solchen Fällen hilft es, die Kriterien nach Priorität zu ordnen: Datenresidenz und Compliance sind in regulierten Branchen meist nicht verhandelbar und schränken die Auswahl zuerst ein, Budget und vorhandene Skript-Kompetenz entscheiden danach zwischen den verbleibenden Optionen.
Migration: In acht Schritten zum neuen Patch-Management
Der Wechsel von einem Altsystem wie WSUS oder SCCM auf eine der drei Plattformen läuft in der Praxis nach einem ähnlichen Muster ab, unabhängig davon, für welchen Anbieter man sich entscheidet. Der größte Fehler bei solchen Projekten ist nicht die Wahl des falschen Tools, sondern ein zu schneller Komplett-Rollout ohne Testphase, der einen einzelnen fehlerhaften Patch zum unternehmensweiten Vorfall werden lässt.
Realistisch dauert eine vollständige Migration bei mittleren Umgebungen zwischen 500 und 5.000 Endpoints, gestützt auf die zitierten Fallstudien, zwischen wenigen Tagen und drei Monaten. Rdata schaffte den technischen Teil mit 2.200 Endpoints laut eigener Fallstudie in unter drei Tagen, Executech benötigte für rund 30.000 Agents und eine deutlich komplexere Multi-Mandanten-Struktur knapp drei Monate. Der entscheidende Unterschied liegt selten in der reinen Softwareinstallation, sondern darin, wie viele individuelle Ausnahmeregeln aus dem Altsystem übernommen werden müssen. Je älter und gewachsener die bestehende WSUS- oder SCCM-Umgebung, desto mehr solcher historisch gewachsenen Sonderfälle tauchen erst während der Testphase auf, ein weiterer Grund, die parallele Testphase nicht künstlich zu verkürzen.
- Vollständiges Geräteinventar erstellen, inklusive Betriebssystemversionen und installierter Drittanbieter-Software.
- Kritikalität der Systeme bewerten und priorisieren, welche Gruppen zuerst migrieren.
- Testgruppe von 20 bis 50 unkritischen Geräten für die erste Rollout-Welle festlegen.
- Patch-Richtlinien und Wartungsfenster im neuen System nachbilden, bevor Agents verteilt werden.
- Agents auf der Testgruppe installieren und parallel zum bestehenden System vier bis sechs Wochen mitlaufen lassen.
- Reporting und Compliance-Kennzahlen zwischen Alt- und Neusystem abgleichen, um Lücken zu erkennen.
- Rollout in Wellen auf weitere Abteilungen ausweiten, mit klaren Rollback-Kriterien pro Welle.
- Altsystem erst deaktivieren, wenn zwei vollständige Patch-Zyklen im neuen System ohne kritische Vorfälle gelaufen sind.
Wer während der Migration zusätzlich verfolgen will, welche Schwachstellen gerade als aktiv ausgenutzt gelten, kann die öffentliche CISA-KEV-Liste direkt abfragen. Das folgende Beispiel zeigt, wie sich der aktuelle Katalog per Kommandozeile abrufen lässt, um neue Einträge automatisiert mit der eigenen Patch-Pipeline abzugleichen.
curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
| jq '.vulnerabilities[] | select(.dateAdded == "2026-09-27") | {cveID, vendorProject, dueDate}'Dieser Befehl filtert den offiziellen KEV-Feed auf Einträge vom 27. September 2026, dem Tag, an dem die beiden Citrix-NetScaler-Lücken aufgenommen wurden, und gibt CVE-Kennung, betroffenen Hersteller und Frist aus. Eine solche Abfrage lässt sich in gängigen Automatisierungsplattformen als geplanter Job hinterlegen, um Patch-Teams tagesaktuell zu informieren.
Vor- und Nachteile im Überblick
Nach der Detailanalyse lassen sich die Stärken und Schwächen der drei Plattformen kompakt zusammenfassen. Die folgende Übersicht bündelt die Punkte, die in Kaufentscheidungen laut den ausgewerteten Kundenstimmen und Herstellerdaten am häufigsten den Ausschlag geben.
NinjaOne
- Vorteil: Vollständige RMM-Plattform, Patch-Management ist nur ein Baustein von vielen.
- Vorteil: Große, dokumentierte Kundenbasis mit belastbaren Fallstudien.
- Nachteil: Kein öffentlicher Festpreis, jedes Angebot ist individuell verhandelt.
- Nachteil: Keine On-Premises-Option für Unternehmen mit Cloud-Vorbehalten.
Automox
- Vorteil: Klarster öffentlicher Einstiegspreis der drei Kandidaten, 1 Dollar pro Endpoint.
- Vorteil: Schlankes, fokussiertes Produkt ohne überflüssigen Funktionsballast.
- Nachteil: Kein vollwertiges RMM, zusätzliche Tools für Fernzugriff oder Monitoring oft nötig.
- Nachteil: Öffentlich dokumentierter Drittanbieter-Katalog kleiner als bei ManageEngine.
ManageEngine Patch Manager Plus
- Vorteil: Einzige Option mit echter On-Premises-Bereitstellung.
- Vorteil: Größter dokumentierter Drittanbieter-Katalog und dediziertes Rollback-Feature.
- Vorteil: Kostenlose Free Edition für kleine Umgebungen.
- Nachteil: Paketpreise statt granularer Pro-Endpoint-Abrechnung, weniger flexibel beim Wachstum.
Deutschland und die DACH-Region: Regulatorischer Druck durch NIS-2
Für deutsche Unternehmen ist Patch-Management längst keine rein technische Fleißaufgabe mehr, sondern eine regulatorische Pflicht. Mit dem NIS-2-Umsetzungsgesetz müssen rund 29.500 Unternehmen in Deutschland Risikomanagement-Maßnahmen nachweisen, zu denen ein funktionierendes Schwachstellen- und Patch-Management ausdrücklich zählt, bei Verstößen drohen Bußgelder bis zu 10 Millionen Euro. Details zu den betroffenen Branchen und Fristen haben wir in unserem Beitrag zum NIS-2-Umsetzungsgesetz zusammengefasst. Das Bundesamt für Sicherheit in der Informationstechnik empfiehlt in seinem IT-Grundschutz seit Jahren, Sicherheitsupdates zeitnah und nach dokumentierten Prozessen einzuspielen, mehr Hintergrund liefert die BSI-Website direkt.
Auch in der Schweiz und in Österreich rückt das Thema regulatorisch näher an Deutschland heran, Schweizer Kritische Infrastrukturen unterliegen seit einigen Jahren einer Meldepflicht für Cyberangriffe gegenüber dem Bundesamt für Cybersicherheit, Österreich zieht mit einer eigenen NIS-2-Umsetzung nach. Für internationale Konzerne mit Standorten in allen drei Ländern bedeutet das in der Praxis, dass ein einheitlicher, dokumentierter Patch-Prozess nicht mehr nur guter Stil ist, sondern zunehmend Grundlage dafür, überhaupt prüfungsfähige Nachweise gegenüber unterschiedlichen nationalen Aufsichtsbehörden liefern zu können.
Wer regelmäßig verfolgt, wie viele neue kritische Lücken monatlich hinzukommen, kennt auch das Ausmaß des Problems: Allein der monatliche Microsoft Patch Tuesday brachte im Juni 2026 laut unserem Bericht zum Microsoft Patch Tuesday Juni 2026 über 200 neue Schwachstellen mit mehreren Zero-Days. Kommen dazu noch Drittanbieter-Lücken wie bei Citrix, WSO2 oder Cisco, wächst die Zahl der offenen Baustellen für IT-Teams schneller, als manuelle Prozesse sie schließen können. Genau deshalb verschiebt sich die Debatte in vielen deutschen IT-Abteilungen weg von der Frage, ob man automatisiertes Patch-Management einführt, hin zur Frage, welches der drei hier verglichenen Systeme am besten zur eigenen Infrastruktur passt. Diese Verschiebung ist auch am Interesse an entsprechenden Tools ablesbar, Suchanfragen zu Patch-Management-Software und zu einzelnen Anbietern wie NinjaOne gehören 2026 zu den beständig nachgefragten Themen im deutschsprachigen IT-Fachpublikum, ein Indiz dafür, dass viele Unternehmen die Umstellung gerade erst konkret planen statt nur zu evaluieren.
Das Urteil: Welches Tool gewinnt den Vergleich?
Eine einzelne Gewinnerin gibt es in diesem Vergleich nicht, dafür sind die drei Produkte zu unterschiedlich positioniert. Für MSPs und IT-Abteilungen, die ohnehin ein RMM-Werkzeug brauchen, ist NinjaOne die konsolidierteste Lösung, das belegen Fallstudien wie Executech mit 30.000 migrierten Agents in unter drei Monaten. Für schlanke Teams, die reine Patch-Automatisierung zu einem klar kalkulierbaren Preis suchen, bietet Automox mit 1 Dollar pro Endpoint und Monat den transparentesten Einstieg unter den drei Kandidaten. Für Organisationen mit harten Compliance- und Datenresidenz-Anforderungen, von Kliniken bis Behörden, bleibt ManageEngine Patch Manager Plus die einzige Option mit echter On-Premises-Bereitstellung, dem größten dokumentierten Anwendungs-Katalog und einem expliziten Rollback-Feature.
Die eigentliche Kennzahl, an der sich jede Entscheidung messen lassen muss, bleibt aber dieselbe: Der Edgescan-Report zeigt eine durchschnittliche Behebungszeit von 54,81 Tagen für kritische Schwachstellen, während CISA für aktiv ausgenutzte Lücken wie CVE-2026-88772 eine Frist von wenigen Tagen setzt. Welches Werkzeug diese Lücke am zuverlässigsten schließt, entscheidet am Ende nicht der Funktionsumfang auf dem Papier, sondern wie konsequent ein Team die gewählte Plattform tatsächlich nutzt.
Langfristig lohnt sich der Blick über den reinen Anschaffungspreis hinaus. Ein Tool, das 30 Prozent günstiger ist, aber wegen fehlender On-Premises-Option in einem regulierten Umfeld gar nicht einsetzbar ist, spart am Ende nichts, es verhindert den Kauf von vornherein. Umgekehrt lohnt sich ein höherer Preis dann, wenn die eingesparte Administrationszeit, wie in den Fallstudien von Executech und Rdata belegt, die Mehrkosten überkompensiert. Wer eine Entscheidung trifft, sollte deshalb neben der Tabelle mit Listenpreisen immer auch eine Testphase mit den eigenen, echten Endpoints einplanen, keine der drei Plattformen verlangt dafür laut aktuellem Stand eine sofortige Vertragsbindung.
Häufig gestellte Fragen
Was kostet Patch-Management-Software 2026 im Durchschnitt?
Die Preise reichen von kostenlos bei der ManageEngine Free Edition bis zu individuellen Angeboten bei NinjaOne, die je nach Volumen zwischen etwa 1,50 und 3,75 US-Dollar pro Endpoint und Monat liegen. Automox nennt mit 1,00 US-Dollar pro Endpoint und Monat den klarsten öffentlichen Einstiegspreis.
Ist NinjaOne oder Automox besser für kleine Unternehmen geeignet?
Kleine Teams ohne RMM-Bedarf fahren mit Automox oft günstiger, weil sie nicht für Fernzugriffs- und Monitoring-Funktionen zahlen, die sie nicht nutzen. Braucht das Unternehmen dagegen auch Fernwartung und Skripting in einer Konsole, ist NinjaOne trotz höherem Einstiegspreis oft die wirtschaftlichere Gesamtlösung, weil es ein separates RMM-Werkzeug überflüssig macht. Für sehr kleine Umgebungen unter 50 Rechnern lohnt sich zusätzlich ein Blick auf die kostenlose ManageEngine Free Edition als dritte Option.
Unterstützt ManageEngine Patch Manager Plus Linux-Systeme?
Ja, alle drei verglichenen Plattformen, NinjaOne, Automox und ManageEngine Patch Manager Plus, patchen Windows, macOS und Linux gleichermaßen.
Wie schnell muss ich eine als aktiv ausgenutzt gemeldete Schwachstelle schließen?
US-Bundesbehörden müssen KEV-gelistete Lücken laut CISA Binding Operational Directive 22-01 in der Regel innerhalb von 14 Kalendertagen schließen, ältere Katalogeinträge unterlagen teils einer kürzeren Sechs-Werktage-Frist. Deutsche Unternehmen sind daran rechtlich nicht gebunden, viele Auditoren und Cyberversicherer orientieren sich aber an ähnlichen Zeiträumen.
Kann ich alle drei Tools vor dem Kauf kostenlos testen?
Ja. NinjaOne, Automox und ManageEngine bieten jeweils eine kostenlose Testversion an, ManageEngine zusätzlich eine dauerhaft nutzbare, in der Geräteanzahl begrenzte Free Edition.
Was passiert, wenn ein automatisch ausgerollter Patch ein System zum Absturz bringt?
Nur ManageEngine Patch Manager Plus listet ein dediziertes Rollback-Feature als eigenständige Produkteigenschaft. Bei NinjaOne und Automox lässt sich ein fehlerhafter Patch über zusätzliche Skripte und Automatisierungsregeln zurücknehmen, ein einheitliches, herstellerseitig dokumentiertes Rollback-Werkzeug ist bei beiden aber nicht in gleicher Form beschrieben.
Ersetzt Patch-Management-Software einen Vulnerability Scanner?
Nein. Patch-Management-Tools rollen bekannte Updates aus, sie ersetzen aber keinen Schwachstellenscanner, der neue, noch ungepatchte Lücken überhaupt erst aufspürt. Die sinnvolle Reihenfolge ist meist umgekehrt: Ein Scanner identifiziert offene Lücken und priorisiert sie nach Risiko, das Patch-Management-Tool übernimmt anschließend die eigentliche Verteilung der Updates auf alle betroffenen Endpoints. Einen Vergleich dedizierter Scanner-Plattformen haben wir separat in unserem Beitrag zu Tenable, Qualys und Rapid7 behandelt.
Wie erfahre ich, welche Lücken gerade aktiv ausgenutzt werden?
Die CISA-KEV-Liste ist die meistgenutzte öffentliche Quelle für aktiv ausgenutzte Schwachstellen und lässt sich, wie im Migrationsabschnitt gezeigt, direkt als JSON-Feed abfragen. Einen Vergleich der wichtigsten Schwachstellen-Datenbanken haben wir in unserem Artikel zu NVD, EUVD und CISA KEV zusammengefasst.
