Patch-Management im Mittelstand: Prozess und Best Practices
Ungepatchte Software ist ein häufiges Einfallstor. So schließt Patch-Management im Mittelstand Sicherheitslücken: Prozess, Priorisierung, Software, Best Practices.
- Patch-Management ist der geordnete Prozess, Sicherheitsupdates zuverlässig auf alle Geräte zu bringen – nicht das gelegentliche Klicken auf 'Jetzt aktualisieren'.
- Laut BSI-Lagebericht 2025 wurden weltweit durchschnittlich 119 neue Schwachstellen pro Tag bekannt – das ist manuell im Mittelstand nicht mehr zu bewältigen. Entscheidend ist deshalb die Priorisierung: Schweregrad (CVSS), ob die Lücke bereits ausgenutzt wird, und wie exponiert das System im eigenen Netz ist.
- Der Prozess folgt fünf Schritten: Inventar, Bewertung, Test, Rollout, Dokumentation. Das BSI beschreibt ihn im IT-Grundschutz-Baustein OPS.1.1.3 als eigenständigen Betriebsprozess.
- Arbeitsplätze und Server brauchen getrennte Regeln: Arbeitsplätze zeitnah automatisch, Server über Testgruppe, Wartungsfenster und Rollback-Plan.
- Software ohne Herstellersupport lässt sich nicht patchen – End-of-Life-Systeme sind der einzige Fall, in dem nur Austausch oder Isolation hilft.
Viele erfolgreiche Cyberangriffe beginnen nicht mit einem raffinierten Trick, sondern mit einer Lücke, für die längst ein Patch bereitliegt – nur eingespielt wurde er nie. Patch-Management ist damit die unspektakulärste unter den wirksamen Sicherheitsmaßnahmen. Dieser Beitrag zeigt, wie ein funktionierender Patch-Prozess im Mittelstand aussieht – Ablauf, Priorisierung, Werkzeuge und die Frage, was man selbst stemmt und was besser betreut läuft.
Warum ungepatchte Software das größte vermeidbare Risiko ist
Die schiere Menge macht das Problem greifbar: Laut dem BSI-Lagebericht zur IT-Sicherheit in Deutschland 2025 wurden im Berichtszeitraum weltweit durchschnittlich 119 neue Schwachstellen pro Tag bekannt – rund ein Viertel mehr als im Zeitraum davor, teils bedingt durch eine geänderte Zählweise. Jede davon ist eine potenzielle offene Tür – und viele betreffen nicht exotische Software, sondern Windows, Browser, PDF-Reader, die Firewall oder die Fachanwendung in der Buchhaltung.
Das Tückische: Ein veröffentlichter Patch beschreibt, welche Lücke er schließt – und liefert Angreifern die Bauanleitung gleich mit. Bekannte Sicherheitslücken sind deshalb das am besten vermeidbare Einfallstor überhaupt; gefährlich ist vor allem die Zeitspanne zwischen Veröffentlichung und Rollout.
Patch, Update, Upgrade – kurz sortiert
Die Begriffe werden oft vermischt. Alle drei bezeichnen eine Softwareaktualisierung, meinen aber Unterschiedliches — für die Praxis reicht diese Unterscheidung:
- Patch: eine kleine, gezielte Korrektur am bestehenden Programmcode. Sicherheits-Patches schließen eine konkrete Lücke, funktionale Software-Patches beheben einen Programmfehler. Der erste Fall ist der dringende.
- Update: kann darüber hinaus neue Funktionen und Verbesserungen bringen.
- Upgrade: der Wechsel auf eine neue Hauptversion (etwa von einer Windows-Version auf die nächste).
Eine ausführlichere Begriffsklärung steht im Wissens-Eintrag zum Patch-Management.
Microsoft-Patchday: der feste Takt im Monat
Microsoft veröffentlicht seine Sicherheitsupdates gesammelt am zweiten Dienstag im Monat – so beschreibt es der Update-Releasezyklus für Windows-Clients; im Sprachgebrauch heißt der Termin schlicht Patchday. Welche Produkte betroffen sind und wie kritisch eine Lücke eingestuft ist, listet der Security Update Guide des Microsoft Security Response Center öffentlich auf. Für IT-Teams ist das der planbare Ankerpunkt, um neue Patches zu sichten, kritische Sicherheitslücken zu priorisieren und den Rollout zu steuern.
Ausgerollt wird gestaffelt: Die Windows-Update-Ring-Richtlinien in Intune versorgen Gerätegruppen mit unterschiedlicher Verzögerung – eine kleine Pilotgruppe zuerst, der Rest Tage später. So wird der Patchday zum kontrollierten Vorgang statt zum Stichtag; wie das im Alltag aussieht, zeigt Intune als Managed Service.
Der Patch-Management-Prozess in fünf Schritten
Patch-Management ist kein einmaliges Aufräumen, sondern ein Kreislauf. Das BSI führt ihn im IT-Grundschutz-Kompendium als eigenen Baustein (OPS.1.1.3 Patch- und Änderungsmanagement) – also nicht als Nebentätigkeit, sondern als Betriebsprozess mit klarer Verantwortung, Bewertung und Dokumentation.
- Inventarisieren. Man kann nur patchen, was man kennt: ein aktuelles Verzeichnis aller Assets – Geräte, Betriebssysteme und Anwendungen, dazu Firmware und Netzwerktechnik, inklusive der Notebooks im Homeoffice. Zu jedem Asset gehören Version, Standort und ein Verantwortlicher; ohne diese drei Felder ist der Eintrag eine Zeile ohne Aussagekraft.
- Bewerten. Welches Update schließt eine kritische Lücke, welches hat Zeit? Die Einstufung des Herstellers ist der erste Anhaltspunkt, die eigene Exponiertheit der zweite.
- Testen. Kritische Patches vorab auf einer kleinen Gruppe prüfen. Für Server und Fachanwendungen ist dieser Schritt Pflicht.
- Ausrollen. Über eine zentrale Verwaltung, automatisiert wo sicher, kontrolliert wo kritisch – mit definiertem Wartungsfenster für Neustarts.
- Dokumentieren. Prüfen und festhalten, dass die Patches überall angekommen sind – erst das macht aus dem Vorsatz einen belastbaren Zustand.
Der fünfte Schritt fehlt am häufigsten. Ohne Nachweis bleibt Patch-Management ein Gefühl – und ein Gefühl hilft weder bei der nächsten Prüfung noch nach einem Vorfall. Erst wenn dieser Patching-Prozess in festem Takt wiederkehrt, halten sich die Systeme auf dem neuesten Stand, statt einmal aufgeräumt worden zu sein.
Priorisieren: welcher Patch zuerst?
An einem Patchday erscheinen selten ein oder zwei Updates, sondern Dutzende. Schritt zwei entscheidet deshalb über den ganzen Monat – und ist der, an dem sich kleine IT-Teams am häufigsten verschätzen. Drei Fragen führen zu einer belastbaren Reihenfolge:
- Wie schwer wiegt die Lücke? Der CVSS-Wert aus der Herstellermeldung gibt die erste Einordnung; die CVSS-v4.0-Spezifikation ordnet 9,0 bis 10,0 als „Critical” ein und 7,0 bis 8,9 als „High”. Sie hält aber selbst fest, dass der Wert nur eine Eingangsgröße für das eigene Vulnerability Management ist – die Entscheidung nimmt er niemandem ab.
- Wird die Schwachstelle bereits ausgenutzt? Die US-Behörde CISA führt im Known-Exploited-Vulnerabilities-Katalog die Lücken, die nachweislich in freier Wildbahn angegriffen werden, und empfiehlt ihn ausdrücklich als Eingangsgröße für die eigene Priorisierung. Eine mittelschwere Lücke, für die es fertigen Angriffscode gibt, ist dringender als eine kritische, die noch niemand ausnutzt.
- Wie exponiert ist das System in Ihrer IT-Umgebung? Ein aus dem Internet erreichbarer Dienst trägt ein anderes Sicherheitsrisiko als dieselbe Software auf einem internen Endgerät. Deshalb lässt sich Priorisierung nicht einkaufen: Die ersten beiden Fragen beantwortet die Welt, die dritte nur das eigene Inventar.
Aus den drei Antworten wird eine Frist statt eines Bauchgefühls – etwa: Sicherheits-Patches für kritische, von außen erreichbare Systeme innerhalb weniger Tage, hoch eingestufte im laufenden Patchzyklus, der Rest im Monatstakt. Wer diese Fristen einmal schriftlich festlegt, muss sie nicht jeden Monat neu verhandeln und kann begründete Ausnahmen mit Enddatum festhalten, statt sie zu vergessen.
Manuell oder automatisiert? Was Automatisierung wirklich abnimmt
Bei einer Handvoll Rechner geht Patchen noch von Hand. Ab etwa einem Dutzend Geräten, verteilt auf Büro und Homeoffice, wird die manuelle Pflege zum Blindflug – und genau da entstehen die Lücken, die niemand bemerkt. Über eine zentrale Geräteverwaltung (RMM) läuft die Bereitstellung der Software-Updates dagegen automatisiert.
Automatisierung heißt dabei mehr, als „automatische Updates” anzuschalten. Der eigentliche Gewinn liegt im Rückkanal: Ein Agent auf den Endgeräten meldet den Ist-Stand, und erst diese Rückmeldung zeigt, welche Systeme stets auf dem neuesten Stand sind und welche zurückfallen – auch das Notebook, das drei Wochen offline war.
Patch-Management-Software: von Windows Update bis Unified Endpoint Management
Vier Werkzeugkategorien begegnen einem im Mittelstand – sie decken unterschiedlich viel ab:
- Bordmittel des Betriebssystems – Windows Update, zentral gesteuert über Windows Server Update Services (WSUS). Deckt Microsoft-Produkte ab, keine Fremdsoftware.
- Unified Endpoint Management (UEM), etwa Intune – Richtlinien, Update-Ringe und Wartungsfenster für Windows-, Mac- und Mobilgeräte aus einer Konsole.
- RMM-Plattformen des betreuenden Dienstleisters – Betriebssystem plus gepflegter Katalog an Drittanbieter-Anwendungen, inklusive Reporting.
- Spezialisierte Patch Management Software – setzt neben WSUS oder UEM auf und schließt die Lücke bei den Anwendungen von Drittanbietern.
Welche Kategorie passt, entscheidet sich weniger am Funktionsumfang als an drei Punkten: eine Patch-Verwaltung, die alle Assets im gesamten Netzwerk führt – Büro, Homeoffice und Server statt drei getrennter Werkzeuge; die Bereitstellung von Software-Updates für Betriebssysteme und Software von Drittanbietern aus einer Konsole; und ein Bericht über fehlende Patches, der ohne Handarbeit entsteht – sonst ist nicht belegbar, dass die Sicherheitslücken geschlossen sind.
Wie diese Steuerung im Alltag aussieht, zeigt das Geräte-Management bei kjello; die Einordnung für kleinere Betriebe steht im Beitrag zur Geräteverwaltung im Mittelstand.
Gegen Zero-Days – Lücken, für die es noch keinen Patch gibt – hilft kein Werkzeug dieser Art. Dafür braucht es eine zweite Schicht, die verdächtiges Verhalten erkennt: Endpoint Detection & Response (EDR). Und weil zeitnahes Patchen inzwischen gesetzlich erwartet wird, gehört es zu den Maßnahmen nach dem NIS2-Umsetzungsgesetz.
Nicht nur Windows: Drittanbieter-Software im Blick
Ein verbreiteter Denkfehler ist, Patch-Management auf das Betriebssystem zu verengen. Microsoft Windows – in aktuellen Flotten Windows 11 – hält sich mit den beschriebenen Werkzeugen vergleichsweise komfortabel aktuell. Das eigentliche Risiko liegt bei den Anwendungen von Drittanbietern: Browser, PDF-Reader, Java, Archivprogramme und vor allem Fachanwendungen werden seltener zentral aktualisiert – und stehen genau deshalb häufig im Zentrum erfolgreicher Angriffe.
Dazu kommt die Ebene, an die kaum jemand denkt: die Firmware der Hardware – Notebooks, Router, Switches, Drucker, NAS. Sie meldet sich nicht auf dem Desktop und wird deshalb oft jahrelang nicht angefasst, obwohl sie tief im System sitzt. Sie gehört genauso in den Prozess wie alles, was auf dem Endgerät läuft – siehe Endpoint Security. Wer nur Windows patcht, schließt einen Teil der Türen und lässt den Rest offen.
Wenn es keinen Patch mehr gibt: End-of-Life-Software
Es gibt einen Fall, in dem der beste Prozess nichts ausrichtet: Software, deren Herstellersupport ausgelaufen ist. Microsoft veröffentlicht die Support-Enddaten seiner Produkte in der Microsoft Lifecycle-Richtlinie; nach diesem Datum erscheinen keine Sicherheitsupdates mehr. Jede danach bekannt werdende Lücke bleibt dauerhaft offen – und ist öffentlich dokumentiert.
Ein System ohne Herstellersupport ist kein „etwas älteres" System, sondern ein dauerhaft offenes. Erfassen Sie im Inventar deshalb nicht nur Versionen, sondern auch die Support-Enddaten – dann wird aus einer bösen Überraschung ein Budgetposten mit Vorlaufzeit.
Praktisch bleiben drei Wege: aktualisieren, ersetzen oder – wenn eine Fachanwendung an alter Technik hängt – das System vom übrigen Netz isolieren und den Zugriff eng begrenzen. Isolation ist die schlechteste der drei Optionen, aber besser als Hoffnung. Besser ist, gar nicht erst in diese Lage zu kommen: nur Software einsetzen, für die es Patches von unterstützten Anbietern gibt – und das Support-Ende schon bei der Beschaffung notieren.
Schwachstellen-Management: der größere Zusammenhang
Patch-Management – englisch patch management – ist der ausführende Teil einer größeren Disziplin: des Schwachstellenmanagements, englisch Vulnerability Management. Der Unterschied liegt in der Reihenfolge: Das Schwachstellenmanagement fragt zuerst, welche Lücken in der eigenen IT-Umgebung existieren, scannt die Systeme regelmäßig und priorisiert die Funde nach Kritikalität. Die Behebung von Schwachstellen übernimmt dann das Patch-Management. Ein Scanner kann bei der Analyse und Behebung von Schwachstellen helfen, indem er fehlende Patches und Fehlkonfigurationen sichtbar macht und nach Kritikalität sortiert – schließen muss die Lücke aber der Rollout.
Für den Mittelstand muss das kein aufwendiges Programm sein. Wichtig ist der Kreislauf aus Scannen, Priorisieren, Beheben und Nachweisen – kontinuierlich statt als einmalige Aktion.
Compliance: die Einhaltung von Vorschriften verlangt Nachweise
Seit dem NIS2-Umsetzungsgesetz steht das nicht mehr nur in Empfehlungen. § 30 Absatz 2 BSIG zählt unter Nummer 5 ausdrücklich „Sicherheitsmaßnahmen bei Erwerb, Entwicklung und Wartung von informationstechnischen Systemen, Komponenten und Prozessen, einschließlich Management und Offenlegung von Schwachstellen” zu den verpflichtenden Risikomanagementmaßnahmen betroffener Einrichtungen.
Patchen ist damit kein technisches Detail mehr, sondern ein prüfbarer Baustein der Informationssicherheit. Für die Compliance zählt nicht die Absicht, sondern die Dokumentation – und was dabei verlangt wird, ist überschaubar:
- eine schriftliche Patch-Richtlinie mit Fristen je Kritikalität und benannter Verantwortung,
- eine Liste der Ausnahmen, jede mit Begründung, Ersatzmaßnahme und Enddatum,
- den Nachweis, dass die Fristen im Rückblick eingehalten wurden – über alle Endgeräte hinweg, nicht als Stichprobe.
Wer den fünften Prozessschritt ernst nimmt, hat diese Belege ohnehin; sie fallen im laufenden Betrieb an, statt vor dem Audit rekonstruiert werden zu müssen. Und auch außerhalb des NIS2-Kreises fragen Auftraggeber-Audits und Cyberversicherer zunehmend genau danach.
Server und Arbeitsplätze brauchen unterschiedliche Regeln
Ein pauschaler Umgang mit allen Geräten führt zu Problemen. Arbeitsplatz-Rechner (Workstations) vertragen zeitnahe, automatisierte Updates gut – hier überwiegt das Sicherheitsrisiko den seltenen Störfall. Server sind das Gegenteil: An ihnen hängen zentrale Dienste, ein fehlgeschlagener Patch legt schlimmstenfalls die halbe Firma lahm.
| Arbeitsplätze | Server und Fachanwendungen | |
|---|---|---|
| Rollout | automatisch, zeitnah nach Freigabe | nach Test, gestaffelt |
| Test | kleine Pilotgruppe genügt | verbindliche Testgruppe vor jedem Rollout |
| Zeitpunkt | im laufenden Betrieb, Neustart geplant | definiertes Wartungsfenster, oft nachts |
| Rückweg | Neuinstallation aus dem Standard-Image | dokumentierter Rollback-Plan plus Sicherung |
| Leitgedanke | Tempo schlägt Kontrolle | Kontrolle schlägt Tempo |
Beides gehört zentral gesteuert und nachweisbar dokumentiert. Wie der Rückweg im Ernstfall organisiert ist, gehört übrigens in denselben Ordner wie der IT-Notfallplan – ein Rollback ist nichts anderes als ein kleiner, geplanter Notfall.
Best Practices für das Patch-Management
In der Praxis scheitert Patch-Management an wiederkehrenden Mustern. Fünf Grundregeln kehren sie um – jede ist die Antwort auf einen typischen Fehler:
- Zentral statt verteilt. Eine Patch-Verwaltung für Büro, Homeoffice und Server. Der klassische Fehler: Notebooks außerhalb des Firmennetzes fallen aus dem Raster, obwohl sie am stärksten exponiert sind.
- Automatisieren, wo es sicher ist. Aber nicht nach dem Muster „einmal einrichten und vergessen” – auch automatisches Patching braucht die Kontrolle, ob es überall ankommt.
- Testen, wo es kritisch ist. Jeder Patch kann eine Unterbrechung auslösen; Testgruppe und Rollback-Plan machen daraus eine geplante Rückwärtsbewegung statt einer Notlage.
- Nur aus offiziellen Quellen. Patches kommen aus dem Herstellerkanal oder der zentralen Verwaltung – nie über ein Pop-up. Gefälschte Update-Hinweise sind ein gängiger Weg, Schadsoftware zu verteilen; zentrale Verteilung nimmt Mitarbeitenden diese Entscheidung ab.
- Nachweisen statt vermuten. In denselben Nachweis gehört nicht nur das Betriebssystem, sondern auch die Anwendungen von Drittanbietern.
Der häufigste Einwand lautet: „Uns ist doch noch nie etwas passiert.” Das stimmt meist – und sagt nichts über morgen. Automatisierte Massenangriffe scannen das Netz nach bekannten Lücken, ohne vorher nach der Unternehmensgröße zu fragen.
Ob Sie 5 oder 500 Mitarbeitende haben — einem automatisierten Massenangriff ist das egal. Der verschlüsselt Sie, weil er kann. Deshalb braucht heute jedes Unternehmen einen Grundschutz.
Selbst patchen oder als Service?
Die ehrliche Frage für den Mittelstand lautet selten „automatisiert oder manuell”, sondern „selbst oder betreut”. Intern ist es möglich – es verlangt aber eine zentrale Verwaltungslösung, definierte Prozesse und jemanden, der die Endgeräte kontinuierlich im Blick behält, Updates bewertet und den Nachweis führt. In kleinen IT-Teams – oft ist es genau eine Person – konkurriert das mit dem Tagesgeschäft, und das Patchen rutscht nach hinten. Am meisten hilft dann Standardisierung: Je einheitlicher Gerätemodelle und Softwarestand, desto weniger Sonderfälle bleiben übrig, die sich nicht automatisieren lassen.
Wir wären ein leichtes Opfer, das weiß ich. Da hätte ich gern jemanden, der davon mehr versteht als ich.
Als Service über einen Managed Service Provider wird Patch-Management zu einem Prozess, der einfach läuft: Betriebssysteme und Anwendungen bleiben stets auf dem neuesten Stand, neue Patches werden bewertet und priorisiert, um zuerst die gefährlichsten Sicherheitslücken zu schließen; fehlende Patches fallen sofort auf. Bei kjello ist genau das im Portal-Kern zu 29 € pro Nutzer und Monat enthalten – kein Projekt, das man startet und wieder vergisst, sondern Teil des laufenden Betriebs. Die Rechnung dahinter ist schlicht: Sicherheitsverletzungen binden Zeit und Geld für Wiederherstellung und Meldepflichten – Aufwand, der beim laufenden Patchen nie anfällt.
30 Minuten, kostenlos, ohne Vertriebsdruck – wir sehen uns an, wo bei Ihnen offene Lücken liegen.
Gespräch vereinbaren10-Punkte-Checkliste Patch-Management
- Inventar steht. Alle Geräte und die installierte Software erfasst, inklusive Support-Enddaten.
- Zentrale Verwaltung statt Gerät-für-Gerät-Pflege. Eine Konsole für Büro, Homeoffice und Server.
- Automatische Updates für Standard-Arbeitsplätze aktiv. Und stichprobenartig geprüft.
- Testgruppe für Server- und Fachanwendungs-Patches. Klein, aber repräsentativ.
- Fester Rhythmus rund um den Patchday. Als Termin, nicht als Zufall.
- Priorisierung nach Kritikalität und Ausnutzung. Fristen je Stufe schriftlich festgelegt.
- Wartungs- und Patch-Fenster definiert. Neustarts außerhalb der Arbeitszeit.
- Nicht nur Windows. Browser, Treiber, Firmware, Fachsoftware gehören dazu.
- Nachweis vorhanden. Belegbar, dass Patches überall angekommen sind.
- Verantwortung geklärt. Wer patcht, wer haftet, mit welcher Reaktionszeit.
Fazit: aus Pflicht Routine machen
Patch-Management ist keine Frage des Könnens, sondern der Konsequenz. Es scheitert selten am Wissen, sondern an Zeit und Übersicht – lösbar, indem Aktualität kein Sonderprojekt bleibt, sondern Teil des laufenden Betriebs wird. Wer die Grundlagen selbst prüfen möchte, findet in unserer IT-Sicherheits-Checkliste für den Mittelstand den passenden Einstieg.
Geschrieben von
Jens Hagel
Gründer & Geschäftsführer
Jens Hagel gründete 2004 das Systemhaus hinter kjello und betreut mit seinem Team über 150 mittelständische Unternehmen. Er schreibt über das, was er in echten Firmen erlebt – praxisnah, ehrlich und ohne Fachchinesisch.
Häufige Fragen
Wie schnell muss ein Sicherheits-Patch nach dem Patchday installiert werden?
Was ist ein Zero-Day?
Wer haftet, wenn ein Patch selbst einen Schaden verursacht?
Was ist ein Patch-Fenster?
Was kostet automatisiertes Patch-Management für ein mittelständisches Unternehmen?
Was tun mit Software, für die es keine Sicherheitsupdates mehr gibt?
Geräte automatisch aktuell halten lassen
Bei kjello ist zentrales Patch-Management Teil des laufenden Betriebs – Updates werden überwacht und ausgerollt, damit bekannte Lücken geschlossen sind, bevor sie zum Problem werden.