Cyber Resilience Act – Was deutsche KMU und Behörden ab dem 11. September 2026 von Microsoft und ihren Software-Lieferanten fordern müssen

In zehn Wochen – am 11. September 2026 – greifen die Meldepflichten des Cyber Resilience Act (CRA) nach Artikel 14. Ab diesem Stichtag muss jeder Hersteller von Produkten mit digitalen Elementen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle innerhalb von 24 Stunden über die ENISA Single Reporting Platform (SRP) melden. Der CRA ist zwar erst am 11. Dezember 2027 in vollem Umfang anwendbar, aber die Meldepflicht ist der operative Anker, der die Beschaffungspraxis in deutschen KMU, Schulen und Behörden ab sofort verändern muss.

Wir nehmen die Lage Anfang Juli 2026 nüchtern auseinander: Was Artikel 14 wirklich fordert, warum Microsoft in den Geltungsbereich fällt, welche vier Vertragsklauseln jetzt in jedem Software-Einkauf stehen müssen, wo die Verzahnung mit NIS2 unsauber ist, und welche souveränen Fallback-Bausteine bis September vorbereitet sein sollten.

Was Artikel 14 CRA ab dem 11. September 2026 fordert

Der Cyber Resilience Act (Verordnung (EU) 2024/2847) ist am 10. Dezember 2024 in Kraft getreten. Er verpflichtet Hersteller von Produkten mit digitalen Elementen (Products with Digital Elements, PDE) – also praktisch alles, was direkt oder indirekt eine Netzwerkverbindung nutzt – zu einem definierten Sicherheitsniveau über den gesamten Produktlebenszyklus. Am 11. Juni 2026 wurde bereits Kapitel IV zur Notifizierung von Konformitätsbewertungsstellen scharfgestellt. Am 11. September 2026 folgen die Meldepflichten aus Artikel 14. Alle übrigen Pflichten – CE-Kennzeichnung, Secure-by-Design, technische Dokumentation – greifen am 11. Dezember 2027.

Konkret verlangt Artikel 14 vier Meldungen bei einer aktiv ausgenutzten Schwachstelle:

1. Frühwarnung binnen 24 Stunden an die zuständige nationale CSIRT und ENISA über die SRP.
2. Vollständige Meldung binnen 72 Stunden mit Details zu Angriffscharakter, betroffenen Produkten und ersten Gegenmaßnahmen.
3. Abschlussbericht binnen 14 Tagen nach Verfügbarkeit einer Korrekturmaßnahme.
4. Bei schwerwiegenden Vorfällen ohne aktive Ausnutzung: Abschlussbericht binnen eines Monats.

Bußgelder für Verstöße gegen die Meldepflicht liegen bei bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Konzernumsatzes, je nachdem, welcher Betrag höher ist.

Warum Microsoft in den Geltungsbereich fällt

Der CRA gilt für alle Hersteller, die PDE auf dem EU-Binnenmarkt bereitstellen, unabhängig vom Sitz des Herstellers. Windows 11, Microsoft 365, Azure, Exchange Online, SharePoint, Teams, Copilot – alles fällt in den Geltungsbereich. Microsoft muss ab dem 11. September 2026 aktiv ausgenutzte Schwachstellen in diesen Produkten binnen 24 Stunden über die ENISA-SRP an die zuständige CSIRT melden. In Deutschland ist das das CERT-Bund beim BSI.

Die operative Konsequenz für Kundenunternehmen ist zweischneidig. Positiv: das BSI und ENISA erfahren neue Angriffskampagnen früher, und die staatliche Threat-Intelligence-Lage verbessert sich. Negativ: die Meldung an ENISA heißt nicht, dass Kunden binnen 24 Stunden einen Patch oder auch nur eine offizielle Kundenkommunikation bekommen. Der Zeitraum zwischen Meldung und Patch-Verfügbarkeit ist strukturell nicht durch den CRA geregelt – er wird erst durch die vertragliche Beziehung zwischen Hersteller und Kunde definiert. Genau hier setzt der Handlungsbedarf in der Beschaffung an.

Wer die CRA-Meldelogik mit dem im April 2026 dokumentierten Flex Routing außerhalb der EU Data Boundary und der bestehenden CLOUD-Act-Zugriffslage kombiniert, sieht das strukturelle Problem: eine US-Muttergesellschaft steuert Meldezeitpunkt, Patch-Priorisierung und Kundenkommunikation. Ein europäisches Kundenunternehmen ist auf Kommunikationsketten angewiesen, die es weder kontrolliert noch verhandeln kann.

Vier Vertragsklauseln, die jetzt in jeden Software-Einkauf gehören

Die deutsche Beschaffungspraxis muss ab Juli 2026 vier neue Standardklauseln aufnehmen. Sie ersetzen keine bestehenden IT-Sicherheitsklauseln, sondern ergänzen sie.

• Weitergabepflicht. Der Hersteller informiert den Kunden über CRA-Meldungen, die dessen Produkte betreffen, innerhalb einer vertraglich definierten Frist – üblich sind 48 Stunden nach eigener ENISA-Meldung. Ohne diese Klausel erfährt das Kundenunternehmen erst über allgemeine Medien, dass ein von ihm eingesetztes Produkt betroffen ist.
• Patch-SLA für aktiv ausgenutzte Schwachstellen. Maximale Zeitdauer zwischen ENISA-Meldung und Verfügbarkeit einer Korrekturmaßnahme. Realistisch sind 14 Tage für kritische Schwachstellen und 30 Tage für hohe. Kürzere Fristen sind bei Hyperscalern verhandelbar, bei On-Premises-Software oft nicht.
• Secure-by-Design-Zusicherung. Der Hersteller sichert vertraglich zu, dass sein Produkt bis zum 11. Dezember 2027 die Anforderungen aus Anhang I CRA erfüllt und die CE-Kennzeichnung mit Konformitätsbewertung nachweisbar ist. Ohne diese Zusicherung übernimmt der Kunde das Produkthaftungs-Risiko, wenn der Hersteller die Frist reißt.
• Support-End-of-Life-Regelung. Der CRA verlangt Sicherheitsupdates über die erwartete Nutzungsdauer, mindestens fünf Jahre. Der Vertrag muss die genaue Support-Dauer, Verlängerungsoptionen und Kommunikationswege beim EoL festhalten.

Diese Klauseln sind keine akademische Übung. Der BSI-IT-Grundschutz verlangt bereits heute strukturierte Lieferantensteuerung, und der DORA-Rahmen für den Finanzsektor fordert Exit-Strategien für kritische IKT-Drittanbieter. Der CRA gibt der Praxis nun einen dritten Rechtsrahmen, der auf denselben Kern zielt.

Sonderfall Schulen und Behörden

Für Schulträger, Kommunen und Landesbehörden wird die CRA-Lage doppelt eng. Erstens: die Beschaffungsregeln nach GWB, VgV und UVgO verlangen zunehmend die vertragliche Absicherung von IT-Sicherheitsanforderungen. Eine Ausschreibung ohne CRA-konforme Klauseln ist ab September 2026 angreifbar. Zweitens: der Cloud and AI Development Act (CADA) verlangt seit dem 3. Juni 2026 Sovereignty-Stufen. Für CADA-Stufe 3 – europäische Eigentümerschaft, keine US-Sub-Prozessoren – ist Microsoft strukturell nicht qualifiziert. Für Stufe 1 und 2 sind die CRA-Klauseln zwingend, aber verhandelbar.

Für Schulen kommt die datenschutzrechtliche Ebene dazu. Die Datenschutzkonferenz hat Microsoft 365 in Schulen weiterhin als nicht rechtssicher eingestuft. Wer jetzt zusätzlich die CRA-Klauseln nicht vertraglich verankert, verstärkt die Angreifbarkeit der eigenen Beschaffungsentscheidung. Ein Schulträger, der 2026 einen neuen Microsoft-Rahmenvertrag ohne CRA-Klauseln unterzeichnet, wird sich 2028 im Audit rechtfertigen müssen.

Verzahnung mit NIS2 und DSGVO

Die neue CRA-Meldelogik überlagert die bestehenden Pflichten aus NIS2 und DSGVO, ersetzt aber keine. Wenn Microsoft eine Windows-Schwachstelle über die SRP meldet und ein kritischer oder wichtiger Betrieb nach NIS2 diese Schwachstelle in seinem Netz aktiv ausgenutzt sieht, sind parallel drei Meldungen fällig:

1. CRA-Meldung durch Microsoft an ENISA (nicht durch den Anwender).
2. NIS2-Meldung durch das anwendende Unternehmen an das BSI – 24 Stunden Erst-, 72 Stunden Voll-, 30 Tage Abschlussmeldung.
3. DSGVO-Meldung bei Betroffenheit personenbezogener Daten an die Landesdatenschutzaufsicht – 72 Stunden.

Das ist die praktische Ausprägung des Microsoft-Paradox aus NIS2 und DSGVO: die Meldelast liegt beim anwendenden Unternehmen, die Informationslage aber beim Hersteller. Wer die Weitergabepflicht nicht vertraglich fixiert, hat 24 Stunden Meldefrist auf Basis öffentlich verfügbarer Angriffs-Signale – ein systematisches Problem.

In zehn Tagen zum CRA-tauglichen Lieferanten-Register

Die HowTo-Sektion im Frontmatter dieses Beitrags beschreibt einen konkreten Zehn-Tages-Pfad. Wer am 15. Juli 2026 startet, hat Ende Juli das Register mit den zehn wichtigsten Lieferanten stehen und bis zum 11. September Puffer für Nachverhandlungen und interne Runbooks. Wer erst Ende August anfängt, kommt in den Stichtag ohne dokumentierte Klauseln.

Souveräne Bausteine als Fallback

Der CRA schließt US-Software nicht aus. Er verlangt lediglich, dass sie CRA-konform ist. Für kritische Kernfunktionen empfiehlt sich trotzdem der Aufbau souveräner Bausteine als Fallback. Realistisch sind vier Ersetzungen:

• Nextcloud statt SharePoint und OneDrive – deutscher Anbieter, on-premises oder bei europäischem managed Hoster, CRA-Konformität durch europäische Herstellerkette einfacher belegbar.
• Element und Matrix statt Teams – Föderationsprotokoll, offener Standard, europäische Anbieter mit direktem CRA-Ansprechpartner.
• openDesk statt Microsoft 365 – Zusammenstellung des ZenDiS auf Basis von Open Source, gedacht für Behörden, aber auch für KMU nutzbar.
• Aleph Alpha oder Mistral statt Azure OpenAI – souveräne LLM-Endpunkte, siehe auch die AI-Act-Konsequenzen aus dem 2. August 2026.

Wir begleiten KMU, Schulträger und Behörden bei der Kombination aus CRA-Vertragsprüfung, Lieferanten-Nachverhandlung und Fallback-Aufbau. Sprich uns an, wenn das Lieferanten-Register bis Ende Juli stehen soll, sieh dir die europäischen Alternativen an, die wir betreiben, und vergleiche die Preise für Managed Hosting mit deinem aktuellen Rahmenvertrag.

Fazit

Der 11. September 2026 verändert nicht das Software-Beschaffungsrecht, aber die operative Praxis dahinter. Ein Rahmenvertrag ohne Weitergabepflicht, Patch-SLA, Secure-by-Design-Zusicherung und Support-End-of-Life-Regelung ist ab diesem Stichtag ein dokumentiertes Compliance-Risiko. Wer die zehn wichtigsten Lieferanten bis Ende Juli einmal strukturiert konfrontiert, hat den Sommer für Verhandlungen und den September für den Live-Betrieb. Für die drei bis fünf Positionen, wo Microsoft die Klauseln nicht liefern kann oder will, sollte der souveräne Fallback als vorbereitete Option in der Schublade liegen.