Was Kai liest.

Die Primärquelle, und kurz genug, dass jeder Produktverantwortliche sie einmal selbst lesen sollte. Ab dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle melden. Frühwarnung binnen 24 Stunden, Vollmeldung binnen 72, Abschlussbericht spätestens 14 Tage nachdem eine Korrektur verfügbar ist. Was dabei unterschätzt wird: Die Uhr läuft ab dem Moment, in dem eine unverzügliche Erstbewertung hinreichende Sicherheit ergibt, und die Kommission erwartet diese Bewertung sofort, nicht zum nächsten Release-Termin. Wer keinen Prozess hat, der innerhalb eines Arbeitstages eine Erstmeldung erzeugt, hat kein künftiges Compliance-Problem. Er hat eines ab September.

Der Ort, an dem die Meldung tatsächlich landet, und der Grund, warum ich bei diesem Termin unruhig werde. Die Single Reporting Platform der ENISA soll am 11. September betriebsbereit sein, jede nationale CSIRT bekommt darin ihren eigenen Meldeeingang. Der Registrierungsleitfaden für Bevollmächtigte trägt als Stand den 3. August 2026. Fünf Wochen zwischen der Anleitung für die Plattform und der Pflicht, über sie zu melden. Die 24-Stunden-Uhr wartet nicht, bis Ihr Zugang eingerichtet ist. Registrierung ist deshalb keine Formalie für später, sondern die erste Aufgabe.

Die praktische Einordnung, die genau die Definitionsfrage klärt, an der sonst jede Diskussion hängen bleibt. Phillip Ansorge, Managing Security Consultant bei der usd AG, hält fest, was „aktiv ausgenutzt" bedeutet: Belege für reale Angriffe, nicht theoretische Ausnutzbarkeit. Reine Proof-of-Concepts oder Forschungsergebnisse reichen nicht. Das entlastet weniger als es klingt, denn es dreht die Aufgabe um. Sie müssen erkennen können, ob eine Schwachstelle in Ihrem Bestand tatsächlich ausgenutzt wird. Wer seine Geräte im Feld nicht beobachtet, kann diese Frage nicht beantworten und muss sie ab September trotzdem beantworten.

Der Verordnungstext selbst, weil die entscheidende Unterscheidung in den Zusammenfassungen meist verlorengeht. Artikel 69 Absatz 2 sagt: Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, fallen nur dann unter die Verordnung, wenn sie ab diesem Datum wesentlich verändert werden. Absatz 3 nimmt das für die Meldepflichten ausdrücklich zurück, Artikel 14 gilt für alle. Ihr Bestand ist also ab September meldepflichtig, auch wenn Sie ihn nie wieder anfassen, und die Kommission stellt in ihrer Leitlinie klar, dass für diese Altprodukte keine Schwachstellenbehandlung nach Anhang I dazukommt. Melden ja, beheben nein. Für alles, was danach in Verkehr kommt, gilt Artikel 13: Die Support-Frist muss die erwartete Nutzungsdauer abbilden, fünf Jahre sind der Boden und nicht die Antwort. Recital 60 nennt industrielle Anwendungen ausdrücklich. Wer eine Maschine gegen zwanzig Jahre Lebensdauer verkauft, argumentiert um zwanzig Jahre Schwachstellenbehandlung, nicht um fünf.

Der Teil, der am härtesten umkämpft war und am unsaubersten geblieben ist. Die Verordnung schafft mit dem Open-Source-Steward eine eigene Rolle für Organisationen, die ein Projekt tragen ohne Hersteller zu sein, aber wo kommerzielle Tätigkeit genau anfängt, ist bis heute unscharf. Der Gedanke aus der Diskussion, der die Lage am besten trifft: Wer tausend Open-Source-Projekte einsetzt, ist für Fehler in tausend Projekten verantwortlich. Ich habe vier Jahre im OSGi-Vorstand gesessen und vier im Steering Committee bei der Eclipse Foundation. Governance für gemeinsam genutzten Code funktioniert. Sie entsteht nur nicht dadurch, dass man Haftung nach unten weiterreicht.