Am 10. November 2026 stellt Microsoft die Sicherheitsupdates für zwei .NET-Versionen am selben Tag ein: .NET 8 und .NET 9. Nach diesem Datum wird keine in der Plattform entdeckte Schwachstelle mehr in einer der beiden Versionen gepatcht. Wenn Ihr Buchhaltungssystem, Ihr Kassensystem oder Ihr ERP auf einer davon aufgebaut ist — und auf dem saudischen Markt gilt das für viele —, haben Sie weniger als zwei Monate Zeit zu entscheiden, wohin die Reise geht. Für die meisten Unternehmen ist das richtige Ziel .NET 10, unterstützt bis zum 14. November 2028, und nicht .NET 11, dessen erster Release Candidate erst vor zwei Tagen erschienen ist.

Was am 8. September geschah

Am 8. September 2026 gab Microsoft bekannt, dass .NET 11 den Release Candidate 1 erreicht hat, und zwar mit einer Go-live-Supportlizenz — Microsoft unterstützt also offiziell den Einsatz in echter Produktion, bevor das finale Release erscheint. Am selben Tag wurden die routinemäßigen Wartungsupdates für .NET 10, .NET 9 und .NET 8 veröffentlicht.

Das ist die technische Nachricht. Die Nachricht, die für einen Unternehmer zählt, steht auf einer ganz anderen Seite: der offiziellen Seite zur Supportrichtlinie, am selben Tag aktualisiert, auf der klar steht, dass .NET 8 und .NET 9 am 10. November 2026 aus dem Support fallen. Die glänzende Release-Ankündigung bekommt die Aufmerksamkeit; die Zeile, die Sie echtes Geld kostet, steht in einer langweiligen Tabelle.

Warum ein Release mit "Langzeitsupport" aus dem Support fällt

Microsoft veröffentlicht jeden November ein großes .NET-Release. Gerade Releases haben Langzeitsupport und erhalten drei Jahre kostenlose Patches; ungerade Releases haben Standardsupport und erhalten zwei.

.NET 8 erschien am 14. November 2023, also laufen seine drei Jahre im November 2026 ab. .NET 9 erschien am 12. November 2024, also laufen seine zwei Jahre ungefähr zum selben Zeitpunkt ab. Deshalb fallen beide auf den 10. November. Genau hier werden Teams kalt erwischt: "Langzeitsupport" heißt nicht Support für immer. Es heißt drei Jahre ab dem Veröffentlichungstag, und ein guter Teil dieser Uhr ist bereits abgelaufen, während niemand hingesehen hat.

Das richtige Ziel ist .NET 10, nicht .NET 11

Die Reflexreaktion auf eine solche Nachricht lautet: "Dann aktualisieren wir eben auf die neueste Version." Für die meisten Unternehmenssysteme ist das die falsche Entscheidung, und der Grund steht in derselben Supporttabelle.

.NET 10 erschien am 11. November 2025, ist ein Release mit Langzeitsupport und wird bis zum 14. November 2028 unterstützt. Ein einziges Upgrade verschafft Ihnen etwas mehr als zwei Jahre Stabilität, ohne das Thema erneut aufzurollen. .NET 11 ist ein ungerades Release, hat also nur zwei Jahre Standardsupport und fällt trotz seines jüngeren Alters vor .NET 10 aus dem Support. Ein Upgrade auf eine neuere Version, die früher ausläuft, ist kein Upgrade — es ist ein Aufschub mit einer zusätzlichen Rechnung im Anhang.

Es gibt einen zweiten Punkt. Der Release Candidate von .NET 11 selbst wird nur bis zum 13. Oktober 2026 unterstützt, weil er ein Übergangs-Build ist, den Sie wieder verlassen sollen — zum nächsten Candidate und dann zum November-Release. Wer "Go-live" als Einladung versteht, einen Release Candidate in ein Buchhaltungssystem zu installieren und ihn dort zu belassen, hat sich für einen monatlichen Upgrade-Zyklus angemeldet, statt einem zu entkommen.

Die praktische Regel für ein Unternehmen mit Buchhaltungs- oder Betriebssoftware: Steuern Sie immer das gerade Release mit Langzeitsupport an. Überlassen Sie die ungeraden Releases Produktteams, die kontinuierlich aktualisieren und Funktionen früh haben wollen.

Was .NET 11 tatsächlich mitbringt

Damit die Entscheidung auf Wissen und nicht auf Vermeidung beruht, hier der Inhalt des Release Candidate. In C# hat Version 15 die Union-Typen stabilisiert — eine klarere Möglichkeit, einen Wert auszudrücken, der mehr als eine Form annehmen kann, etwa eine Operation, die entweder gelingt oder aus einem bestimmten Grund fehlschlägt. Bei den Werkzeugen hat der Testbefehl den Umgang mit mobilen Anwendungen verbessert und Steuerungen auf Ausführungsebene hinzugefügt.

Beim Veröffentlichen von Containern ist die Image-Erzeugung jetzt reproduzierbar und lädt bereits vorhandene Layer nicht erneut hoch, was die Bereitstellungszeit verkürzt und die Prüfung dessen, was Sie ausgeliefert haben, erleichtert. In der Paketverwaltung funktioniert das Aktualisieren von Paketen mit bekannten Schwachstellen jetzt auch dann, wenn Warnungen als Fehler behandelt werden — ein alter Stolperstein, der Teams zwang, die Sicherheitsprüfung abzuschalten, nur um einen Build durchzubringen. In ASP.NET Core wurden die APIs zur Authentifizierungserneuerung von SignalR fertiggestellt, und Blazor-Server-Circuits aktualisieren ihren Zustand nach einer Erneuerung, statt an einer veralteten Identität festzuhalten. Auf Unix-Systemen gibt es nun In-Process-Absturzberichte, also bessere Diagnosen, wenn ein Server um drei Uhr morgens abstürzt.

Das sind echte Verbesserungen. Keine davon wiegt das Risiko auf, ein Finanzsystem auf einer Version zu betreiben, die früher ausläuft als die Alternative.

Warum das ein Compliance-Thema ist und kein technisches

Eine Plattform zu betreiben, die keine Sicherheitspatches mehr erhält, ist keine Frage technischer Vorlieben. Das Gesetz zum Schutz personenbezogener Daten (PDPL) verpflichtet jede Organisation, die Kundendaten verarbeitet, angemessene Schutzmaßnahmen zu ergreifen, und jede ernsthafte Sicherheitsprüfung wird fragen, welche Plattformversion Sie einsetzen und wann deren Support endet. "Wir sind auf einer Version, die vor acht Monaten aus dem Support gefallen ist" ist keine Antwort, die Sie vor einem Prüfer, vor einem Großkunden, der Ihnen vor der Unterschrift einen Sicherheitsfragebogen schickt, oder vor einem Cyberversicherer verteidigen können.

Dasselbe gilt für E-Invoicing-Systeme, die an die Plattform Fatoora angebunden sind. Ein System, das Rechnungen digital signiert und an eine Regierungsbehörde übermittelt, muss auf einer Plattform laufen, die noch kryptografische Patches erhält. Das ist kein internes Detail — es ist Teil der Vertrauenskette, auf der Ihre Rechnung beruht.

Ein Aktionsplan von jetzt bis November

  • Diese Woche — klären Sie, wo Sie stehen. Bitten Sie Ihren Anbieter oder Ihr technisches Team um eine Bestandsaufnahme der .NET-Version hinter jedem System, das Sie betreiben, einschließlich der kleinen internen Tools und Hintergrunddienste, an die niemand denkt. Auf einem Server zeigt dotnet --list-runtimes sie an; im Projekt selbst ist es der Eintrag für das Zielframework in der Projektdatei.
  • Nächste Woche — priorisieren. Markieren Sie alles auf .NET 8 oder älter und alles auf .NET 9. Was bereits auf .NET 10 läuft, ist bis 2028 sicher. Was auf .NET 6 oder 7 läuft, ist seit Jahren ohne Support und braucht dringende Behandlung, keinen Zeitplan.
  • Innerhalb von zwei Wochen — lesen Sie die Breaking Changes. Microsoft veröffentlicht für jedes Release eine Liste der Breaking Changes. Der Umstieg von 8 auf 10 verläuft meist reibungslos, aber vorher zu lesen spart Tage.
  • Innerhalb eines Monats — zuerst die Testumgebung aktualisieren. Ändern Sie das Zielframework, bauen Sie, führen Sie die Tests aus und lassen Sie das System dann vor allem anderen mit einer Kopie echter Daten laufen.
  • Vor November — ausrollen. Planen Sie mindestens zwei Wochen Sicherheitspuffer vor dem 10. November ein und rollen Sie nicht während eines Monatsabschlusses oder in einer Hochsaison des Verkaufs aus.
  • Einmal, dauerhaft. Tragen Sie heute den 14. November 2028 in den Firmenkalender ein und legen Sie eine Regel fest: Jedes Upgrade geht auf das nächste gerade Release. So wird aus einer jährlichen Überraschung ein bekannter Budgetposten.

Wenn das System von einem Anbieter stammt

Viele Unternehmen besitzen den Quellcode nicht; sie kaufen ein fertiges System bei einem Lieferanten. In diesem Fall stellt die eine E-Mail, die Sie heute senden, drei Fragen: Auf welcher .NET-Version läuft das System, wann liefern Sie einen Build auf .NET 10, und ist das Upgrade durch unseren Supportvertrag abgedeckt oder wird es separat berechnet? Wie Ihr Anbieter antwortet, verrät Ihnen mehr über das Produkt als jede Präsentation. Und ein Anbieter, der die Antwort nicht kennt oder hinhält, ist derselbe, den Sie am 11. November anrufen werden.

Quellen

  • Microsoft — Announcing .NET 11 Release Candidate 1, 8. September 2026: devblogs.microsoft.com
  • Microsoft — offizielle .NET-Supportrichtlinie und Daten zum Supportende: dotnet.microsoft.com
  • Microsoft — Breaking Changes in .NET 11: learn.microsoft.com
  • Saudische Behörde für Daten und Künstliche Intelligenz (SDAIA) — Gesetz zum Schutz personenbezogener Daten (PDPL): sdaia.gov.sa