Software ohne Updates: Der schleichende Verfall

«Dafür geben wir kein Geld mehr aus.»

Ich sehe in Unternehmen Anwendungen, die weiterhin gebraucht werden, für deren Pflege aber niemand mehr bezahlen möchte. Die Rechnung wird erstellt, der Auftrag verarbeitet, die Produktion läuft. Aus dieser sichtbaren Funktion wird geschlossen, dass sich weitere Investitionen nicht lohnen.

Gleichzeitig werden Updates verschoben, Wartungsverträge beendet und Ersatzvorhaben vertagt. Die Anwendung bleibt geschäftskritisch, verliert aber die Menschen, das Wissen und den technischen Unterbau, die ihren verlässlichen Betrieb ermöglichen. Genau diese Kombination halte ich für gefährlich: weiter abhängig bleiben und die Pflege einstellen.

Eine Ablösung kann teuer sein. Ein sorgfältiges Update kann Tests und ein Wartungsfenster verlangen. Diese Kosten sind real. Auch das Nichtstun hat Kosten und Risiken; sie erscheinen nur selten im selben Budgetantrag.

Code rostet nicht. Seine Umgebung verändert sich.

Eine unveränderte Programmdatei zerfällt nicht wie ein Stück Metall. Aber Betriebssysteme, Bibliotheken, Schnittstellen und Sicherheitsanforderungen entwickeln sich weiter. Neue Schwachstellen werden bekannt. Zertifikate laufen aus, Hersteller beenden den Support und Mitarbeitende mit Spezialwissen verlassen das Unternehmen.

Die Degeneration liegt in dieser wachsenden Lücke zwischen Anwendung und Umgebung. Mit jedem ausgelassenen Wartungszyklus kann es schwieriger werden, noch einmal kontrolliert aufzuschliessen. Irgendwann hängt ein kleiner fachlicher Wunsch an einem grossen technischen Umbau.

Wenn niemand mehr Fehler beheben, Sicherheitslücken schliessen oder den Betrieb nachvollziehbar wiederherstellen kann, ist die Software für mich organisatorisch bereits gestorben. Sie kann noch laufen. Ihre Fähigkeit, auf Veränderungen zu reagieren, ist verloren gegangen.

Dabei ist das Alter allein kein Urteil. Eine ältere, aktiv gepflegte Version kann eine vernünftige Wahl sein. Eine neue Anwendung mit ungepflegten Abhängigkeiten kann bereits ein Problem darstellen. Entscheidend sind Wartung, Support und der tatsächliche Schutz.

Individualsoftware braucht dieselbe Pflege.

Das gilt auch für Software, die eigens für ein Unternehmen entwickelt wurde: für ganze Applikationen ebenso wie für einzelne Artefakte – etwa ein Skript, eine Schnittstellenanbindung, eine Erweiterung oder eine Vorlage zur automatischen Dokumenterstellung. Auch ein kleiner Bestandteil kann einen wichtigen Geschäftsprozess tragen und von Bibliotheken, Laufzeitumgebungen oder externen Diensten abhängen.

Mit der Abnahme ist diese Arbeit deshalb nicht beendet. Solange die Lösung im Einsatz bleibt, braucht sie kontinuierliche Betreuung durch Fachkräfte: Abhängigkeiten prüfen und aktualisieren, Änderungen an Schnittstellen nachführen, Sicherheitskorrekturen einspielen und das Zusammenspiel testen. Dazu gehören auch verständlicher Code, aktuelle Dokumentation und Wissen, das nicht bei einer einzigen Person verbleibt. Ein automatisch vorgeschlagenes Update ersetzt diese fachliche Verantwortung nicht.

Wer diese Pflege aufschiebt, sollte nicht mit sinkenden Kosten rechnen. Der Rückstand kann den Aufwand vielmehr wachsen lassen: Mehrere Versionswechsel müssen zusammen bewältigt, nicht mehr unterstützte Bausteine ersetzt und verlorenes Wissen neu erarbeitet werden. Eine kleine Anpassung zieht dann plötzlich Änderungen durch die ganze Anwendung nach sich. Die eingesparte Wartung wird zur aufwendigen Sanierung.

So wird eine passgenaue Individualsoftware schleichend zu einer schwer veränderbaren Altanwendung – zu Legacy-Software, deren Ablösung irgendwann wirtschaftlicher erscheint als ihre Weiterentwicklung. Das ist kein zwangsläufiges Schicksal jeder älteren Lösung. Regelmässige Pflege hält Änderungen beherrschbar und bewahrt die Wahl zwischen Weiterentwicklung und geplanter Ablösung. Für mich gehört dieses Budget von Anfang an zu den Kosten einer Individualsoftware.

KI macht das Aufschieben riskanter.

Das britische NCSC erwartet in seiner Einschätzung bis 2027, dass KI unter anderem die Schwachstellenanalyse und die Entwicklung von Angriffscode beschleunigt. Es rechnet mit mehr Angriffen auf Systeme, bei denen verfügbare Sicherheitskorrekturen fehlen, und mit einem weiter schrumpfenden Zeitfenster zwischen Bekanntwerden und Ausnutzung einer Lücke. Das ist eine behördliche Prognose, keine Gewissheit für jeden einzelnen Angriff. NCSC: KI und Cyberbedrohungen bis 2027.

Für mich folgt daraus eine klare Priorität: Bekannte Schwachstellen dürfen nicht monatelang auf ihre Budgetrunde warten. Besonders bei öffentlich erreichbaren Anwendungen muss die Organisation rasch entscheiden und handeln können. Updates verhindern nicht jeden Angriff, schliessen aber die jeweils behobenen Lücken.

Auch intern betriebene Software braucht eine Risikobewertung. Ein fehlender direkter Internetzugang ist eine Schutzmassnahme, aber kein Beleg dafür, dass ein System über Fernzugänge, andere Anwendungen oder kompromittierte Konten unerreichbar wäre.

Die EU-Regel heisst Cyber Resilience Act.

Der Cyber Resilience Act (CRA), Verordnung (EU) 2024/2847, betrifft erfasste Produkte mit digitalen Elementen auf dem EU-Markt. Seine zentralen Pflichten richten sich an Hersteller; auch Importeure und Händler haben Aufgaben. Dazu gehören sichere Produkte und die Behandlung von Schwachstellen während des vorgesehenen Supportzeitraums. Einordnung der EU-Kommission.

Die Hauptpflichten gelten ab 11. Dezember 2027. Die Meldepflichten nach Artikel 14 für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle gelten bereits seit 11. September 2026. Aktuelle Durchführungshinweise der Kommission.

Der CRA ist damit keine pauschale Verpflichtung jedes Unternehmens, ständig die neueste Funktionsversion einzukaufen. Für bestehende Produkte gelten Übergangsregeln. Schweizer Anbieter können betroffen sein, wenn sie erfasste Produkte auf dem EU-Markt bereitstellen. Welche Rolle und Pflichten ein Unternehmen hat, muss anhand seines Angebots geprüft werden.

Meine Schlussfolgerung für die Beschaffung: Supportende, Sicherheitsupdates und der Umgang mit Schwachstellen gehören vor dem Kauf auf den Tisch. Eine Anwendung ohne tragfähige Pflegeperspektive kann schon bei ihrer Einführung ein schlechtes Geschäft sein.

Datenschutz wartet nicht auf 2027.

Wer Personendaten bearbeitet, hat bereits heute Sicherheitsanforderungen zu erfüllen. In der Schweiz ist die Datensicherheit in Artikel 8 DSG verankert. Der EDÖB konkretisiert technische und organisatorische Schutzmassnahmen und behandelt dabei auch Aktualisierungen, Zugriffsschutz und Datensicherung. EDÖB: Leitfaden zu den technischen und organisatorischen Massnahmen.

Wo die DSGVO anwendbar ist, verlangt Artikel 32 ein dem Risiko angemessenes Sicherheitsniveau. Der Europäische Datenschutzausschuss betont, dass der Stand der Technik fortlaufend zu beurteilen ist. Kosten dürfen berücksichtigt werden, rechtfertigen aber nicht, erforderlichen Schutz einfach wegzulassen. EDSA: Leitlinien 4/2019, insbesondere Randnummern 18–25.

Bei Datenschutzverstössen können je nach anwendbarem Recht und Sachverhalt behördliche Massnahmen und Sanktionen folgen. Ein altes Versionsdatum allein beweist noch keinen Verstoss; umgekehrt entschuldigt ein funktionierender Geschäftsprozess keinen unzureichenden Schutz. EU-Informationen zu Datenschutzpflichten und Sanktionen.

Die konkrete rechtliche Bewertung gehört zu den zuständigen Fachpersonen. Die Geschäftsentscheidung kann schon vorher getroffen werden: bekannte Risiken sichtbar machen, Schutz organisieren und notwendige Pflege finanzieren.

Pflege braucht einen verlässlichen Platz im Betrieb.

Ich würde bei einer vernachlässigten Anwendung mit fünf konkreten Fragen beginnen:

1. 1. Was betreiben wir? Anwendungen, Versionen, Abhängigkeiten, Daten, Zugänge und Supportenden erfassen. Für jedes wichtige System eine verantwortliche Person benennen.
2. 2. Was ist tatsächlich gefährdet? Bekannte Lücken, Erreichbarkeit, benötigte Rechte und mögliche Auswirkungen prüfen. Öffentlich erreichbare, ausgenutzte Schwachstellen besonders dringlich behandeln.
3. 3. Wie ändern wir sicher? Sicherheitskorrekturen testen, Wiederherstellung erproben und ein Vorgehen für dringende Updates vereinbaren. Ein Backup ist erst belastbar, wenn die Rückkehr in einen nutzbaren Zustand gelingt.
4. 4. Was machen wir ohne Updatepfad? Weiterpflege, unterstützte Version, Ersatz oder Stilllegung entscheiden. Eine zeitlich begrenzte Abschottung kann Zeit gewinnen; sie braucht begründete Schutzmassnahmen, Überwachung und einen verbindlichen Endtermin.
5. 5. Wer trägt den Entscheid? Budget, Verantwortliche, Fristen und verbleibende Risiken festhalten. Eine Unterschrift beseitigt weder die Sicherheitslücke noch gesetzliche Pflichten.

Das bedeutet nicht, jede neue Funktion sofort einzuführen. Es bedeutet, Sicherheitswartung regelmässig und risikogerecht zu leisten. So werden Änderungen wieder zu überschaubaren Arbeitsschritten.

Weiterbetrieb ist eine aktive Entscheidung.

Ein Unternehmen kann eine Anwendung ersetzen, stilllegen oder weiterpflegen. Dauerhaft weiterbetreiben, keinerlei Pflege mehr finanzieren und auf Glück hoffen halte ich für keine verantwortbare Strategie.

Mit wirksameren Angriffswerkzeugen und klareren regulatorischen Anforderungen wird diese Haltung künftig noch schwerer zu vertreten sein. Wer heute einen geordneten Update- und Ablösepfad schafft, gewinnt Handlungsspielraum, bevor ein Vorfall den Zeitplan bestimmt.

Software bleibt nur dann ein verlässliches Arbeitsmittel, wenn jemand ihre Zukunft verantwortet.

Unterstützung bei der Einordnung und beim nächsten Schritt →

Quellenstand und Einordnung

Stand: 15. September 2026. Dieser Beitrag verbindet eine persönliche betriebliche Einschätzung mit den verlinkten Behördenquellen. Er ersetzt keine Prüfung der Pflichten eines konkreten Unternehmens. Massgeblich bleiben die anwendbaren Vorschriften und der jeweilige Sachverhalt.

Zum Nachlesen: Verordnung (EU) 2024/2847, Schweizer Datenschutzgesetz und Datenschutz-Grundverordnung. Die Behördeneinordnungen und die KI-Prognose sind direkt an den jeweiligen Aussagen verlinkt.