End-of-Life-Daten als Kalendereinträge: So vermeiden Sie Sicherheitsrisiken

End-of-Life-Daten sind keine abstrakten Fristen, sondern klare Deadlines: Vor dem Stichtag gibt es Sicherheitsupdates, danach nicht mehr. Jede entdeckte Schwachstelle nach diesem Datum wird öffentlich dokumentiert, einem CVE zugewiesen und oft von Angreifern ausgenutzt – ohne dass ein Hersteller jemals einen Patch bereitstellt. Diesen als CVE-Blindspot bekannten Risikofaktor kennen viele, doch kaum jemand handelt rechtzeitig. Der Grund? Die Fristen landen selten auf dem Radar der Verantwortlichen. Sie lösen keine Alarme aus, öffnen keine Tickets und stehen selten im Sprint-Plan. Doch genau das ändert sich jetzt.

Kalendereinträge mit drei Vorlaufzeiten – direkt aus dem Browser

Auf jeder Produktseite von endoflife.ai mit einem zukünftigen End-of-Life-Datum findet sich nun ein „Zu Kalender hinzufügen“-Button direkt unter dem Statusbalken. Ein Klick genügt: Es wird eine standardisierte Kalenderdatei (.ics) heruntergeladen, die den End-of-Life-Termin sowie drei automatische Erinnerungen enthält – 90, 30 und 7 Tage vorher. Alternativ lässt sich das Ereignis mit einem zweiten Button direkt in Google Calendar einfügen.

Die Lösung funktioniert in Apple Calendar, Outlook und Google Calendar – ohne Anmeldung, ohne E-Mail-Registrierung und ohne zusätzliche Software. Die Erinnerungen werden lokal in Ihrem Kalender angezeigt und bleiben aktiv, selbst wenn Sie die Website nie wieder besuchen. Ob Node.js, PHP, Kubernetes oder eines der über 455 weiteren Produkte: Wählen Sie die genutzte Version aus, und die Frist ist in Sekunden auf Ihrem Kalender vermerkt.

Warum die drei Vorlaufzeiten? Sie orientieren sich am typischen Migrationsprozess: 90 Tage vorher dient der Grobplanung, der Zielversion und der Integration in den Sprint. 30 Tage vorher sollte die Migration bereits laufen und getestet werden. 7 Tage vorher erfolgt die finale Prüfung – und falls die Frist nicht eingehalten wird, müssen kompensierende Maßnahmen ergriffen und dokumentiert werden. Der entscheidende Faktor ist der Zeitvorsprung: Er verwandelt eine Notfallaktion in eine geplante Maßnahme.

Zeitvorlauf als Sicherheitsmaßnahme – die Kosten sind entscheidend

Die Kosten einer Migration hängen nicht von der Software ab, sondern vom Zeitpunkt des Starts. Ein Upgrade von Node.js 18 auf eine unterstützte Version, das während eines normalen Entwicklungszyklus durchgeführt wird, kostet Entwicklungszeit im Bereich weniger Tage. Dieselbe Migration, die erst dann beginnt, wenn ein kritisches CVE gegen die nicht mehr gepatchte Version veröffentlicht wird, verursacht nicht nur zusätzlichen Aufwand für die Fehlerbehebung und Notfalländerungen, sondern erhöht auch das Risiko, dass Angreifer die Schwachstelle bereits ausnutzen.

Die Cybersecurity and Infrastructure Security Agency (CISA) benennt das Problem unmissverständlich: In ihrem Katalog Bad Practices führt sie den Einsatz von veralteter oder nicht mehr unterstützter Software als eine der gefährlichsten Praktiken auf. Die Behörde stuft sie als „besonders schwerwiegend“ ein, wenn die Technologie aus dem Internet erreichbar ist – und stellt sie damit auf eine Stufe mit Standardkennwörtern oder fehlender Zwei-Faktor-Authentifizierung für Administratoren. Wenn eine nationale Cyberabwehrbehörde eine Praxis in diese Kategorie einreiht, ist das kein Appell, sondern eine klare Warnung.

Die Ausnutzung von Schwachstellen bestätigt diese Einschätzung. Sobald ein Produkt das End-of-Life erreicht hat, existiert für jede neue Lücke in CISAs Known Exploited Vulnerabilities (KEV) Catalog kein Patch mehr. Die einzige Lösung ist der Austausch der Software – und je früher dieser geplant wird, desto geringer fallen die Kosten aus.

Warum Prüfer auf den End-of-Life-Termin achten

Ein oft unterschätzter Aspekt: Mehrere wichtige Compliance-Rahmenwerke verlangen nicht nur die Vermeidung veralteter Software, sondern explizit die Dokumentation und Planung von Lebenszyklusdaten. Der Kalendereintrag, den Sie gerade angelegt haben, dient dabei als Nachweis.

PCI DSS 4.0.1 – Anforderung 12.3.4

Der Payment Card Industry Data Security Standard (PCI DSS) hat mit der Version 4.0.1 eine neue Anforderung eingeführt, die genau diesen Punkt adressiert. Anforderung 12.3.4 verlangt, dass alle Hardware- und Softwarekomponenten im Geltungsbereich mindestens einmal jährlich überprüft werden, um sicherzustellen, dass sie weiterhin Sicherheitsupdates vom Hersteller erhalten. Zudem müssen alle Ankündigungen zu End-of-Life-Daten dokumentiert und ein von der Geschäftsführung genehmigter Plan zur Behebung veralteter Technologien vorgelegt werden. Diese Regelung ist seit dem 31. März 2025 verbindlich und wird bei Audits vollumfänglich geprüft. Die separate Anforderung 6.3.3 verlangt zudem, dass Komponenten durch zeitnahe Patches vor bekannten Schwachstellen geschützt werden. Ein Lebenszykluskalender mit Vorlaufzeiten ist damit genau das Dokument, das ein Qualified Security Assessor (QSA) für die Anforderung 12.3.4 erwartet.

NIST SP 800-53 & FedRAMP – SA-22

Die Kontrollvorgabe SA-22 („Unsupported System Components“) aus dem NIST SP 800-53 ist eindeutig: Organisationen müssen Komponenten ersetzen, sobald der Hersteller den Support einstellt, oder alternative Unterstützung organisieren. In Kombination mit der Kontrolle SI-2 („Flaw Remediation“) bietet sie Prüfern einen direkten Ansatzpunkt. Da FedRAMP die NIST-Vorgaben übernimmt, gilt SA-22 auch für alle Cloud-Dienste, die mit der US-Regierung zusammenarbeiten. Eine veraltete Komponente ohne entsprechenden Plan wird damit automatisch zu einem Plan of Action and Milestones (POA&M)-Punkt.

ISO 27001:2022 – Anhang A 8.8

Die Kontrolle 8.8 („Management technischer Schwachstellen“) wurde in der Version 2022 des ISO 27001-Standards gestärkt. Sie betont nun einen proaktiven Prozess: Dazu gehören die Führung einer Asset-Inventur mit Versionsnummern, der zeitnahe Erhalt von Informationen über Schwachstellen und die Umsetzung entsprechender Maßnahmen. Software, für die keine Patches mehr verfügbar sind, stellt eine strukturelle Schwachstelle in genau diesem Kontrollmechanismus dar.

SOC 2 – Trust Services Criteria CC7.1

SOC 2 definiert keine spezifischen Technologien, sondern prüft, ob die implementierten Kontrollen den Risiken entsprechen. Das Kriterium CC7.1 verlangt die Erkennung neuer Schwachstellen und Anfälligkeiten. Ein Prüfer wird fragen, wie Sie diese identifizieren – und wenn Ihre Antwort keinen Prozess zur Überwachung von End-of-Life-Daten enthält, wird dies als Lücke gewertet. Sollte im Audit zudem veraltete Software im Einsatz sein, wird daraus zwangsläufig ein Befund.

HIPAA Security Rule

Für Organisationen, die elektronisch geschützte Gesundheitsdaten (ePHI) verarbeiten, schreibt die HIPAA Security Rule vor, dass Risiken für die Integrität, Verfügbarkeit und Vertraulichkeit von Daten minimiert werden müssen. Dazu gehört auch der Schutz vor bekannten Schwachstellen. Ein fehlender Prozess zur Überwachung von End-of-Life-Daten kann hier als Versäumnis in der Risikobewertung gewertet werden.

Die Moral von der Geschicht’: End-of-Life-Daten sind keine abstrakten Termine, sondern handfeste Sicherheitsrisiken – und Prüfer nehmen sie ernst. Mit den neuen Kalendereinträgen und den festgelegten Vorlaufzeiten haben Sie nicht nur ein Werkzeug an der Hand, um Fristen im Blick zu behalten, sondern auch handfeste Nachweise für Compliance-Audits. Der beste Zeitpunkt, damit zu beginnen, ist heute – nicht morgen.

Die Funktion ist seit Kurzem auf endoflife.ai verfügbar und erfordert keine zusätzliche Software oder Anmeldung.