Lesezeit: 14 Min.

Gilt der Cyber Resilience Act für ein typisches TYPO3-Website-Projekt?

Die Engineering-Perspektive eines CEO — aktualisiert nach der CRA-Leitlinie der Europäischen Kommission vom 27. Juli 2026.

András OttóAndrás Ottó · CEO & TYPO3-Architekt27. July 2026

Haftungsausschluss: Dieser Artikel gibt meine persönliche Meinung und Engineering-Perspektive als Geschäftsführer eines TYPO3-Entwicklungsunternehmens wieder. Er ist keine Rechtsberatung, stellt keine rechtliche Stellungnahme dar und ersetzt nicht die Beurteilung eines konkreten Geschäftsmodells oder Vertrags durch eine qualifizierte Rechtsanwältin oder einen qualifizierten Rechtsanwalt.

Die Engineering-Perspektive eines CEO — aktualisiert nach der CRA-Leitlinie der Europäischen Kommission vom 27. Juli 2026.

Eine wichtige Klarstellung kam genau zur richtigen Zeit

Als wir begannen, uns mit dem Cyber Resilience Act zu befassen, kehrte eine Frage immer wieder: Wenn eine Agentur eine Website mit TYPO3 baut — wird die Agentur dann zum Hersteller eines Produkts mit digitalen Elementen?

Die vorsichtige Antwort musste lauten, dass eine gewöhnliche Website anders aussieht als die Softwareprodukte, für die der CRA geschrieben wurde — insbesondere, weil Erwägungsgrund 12 ausdrücklich Websites nennt, die die Funktionalität eines Produkts mit digitalen Elementen nicht unterstützen. Dennoch gab es Raum für Kritik. TYPO3 ist Software, Extensions sind Software, individueller PHP-Code ist Software, und eine Agentur wird dafür bezahlt, diese Komponenten zu einem funktionierenden System zu verbinden. Warum sollte das kein Produkt sein?

Am 27. Juli 2026 veröffentlichte die Europäische Kommission eine neue Leitlinie zur Anwendung des CRA. Obwohl diese Leitlinie unverbindlich ist, behandelt sie die Unterscheidung direkt und liefert 67 praktische Beispiele sowie mehrere Flowcharts.

Die maßgebliche Klarstellung ist überraschend eindeutig: Eine Website ist nicht schon deshalb selbst ein Produkt mit digitalen Elementen, weil Teile von ihr technisch im Browser der Besucher:innen ausgeführt werden. Auch eine ausschließlich über einen Browser genutzte Webanwendung ist selbst kein solches Produkt, es sei denn, sie unterstützt die Funktionalität eines anderen Produkts mit digitalen Elementen.

Diese Leitlinie bedeutet nicht, dass Agenturen Cybersicherheit vergessen dürfen, und sie schließt nicht jede kommerzielle Tätigkeit rund um TYPO3 aus. Sie stützt aber die Position, die ich vertreten habe, als wir ein typisches kundenspezifisches TYPO3-Website-Projekt erstmals betrachteten, deutlich stärker.

Meine Position

Für die TYPO3-Website-Projekte, die Agenturen und spezialisierte Entwicklungsdienstleister typischerweise gemeinsam umsetzen, lautet meine Position:

Eine gewöhnliche Unternehmenswebsite, die über einen Browser genutzt wird und die Funktionalität eines anderen Produkts mit digitalen Elementen nicht unterstützt, ist selbst kein Produkt mit digitalen Elementen im Sinne des CRA.

Daraus folgt, dass eine Agentur nicht schon deshalb zum Hersteller eines CRA-Produkts wird, weil sie TYPO3 einsetzt, Extensions installiert, projektspezifischen Code schreibt und für diese Arbeit bezahlt wird.

Diese Schlussfolgerung hängt davon ab, was tatsächlich geliefert wird. Sie sollte nicht automatisch auf eine kommerzielle TYPO3-Extension, eine wiederverwendbare Software-Distribution, eine lokal installierte Anwendung, lizenzierten Quellcode oder eine Website übertragen werden, die für ein vernetztes Produkt notwendig ist, um eine seiner Funktionen zu erfüllen.

Was der CRA erreichen will

Der Cyber Resilience Act, formell die Verordnung (EU) 2024/2847, legt Cybersicherheitsanforderungen für Produkte mit digitalen Elementen fest, die auf dem Markt der Europäischen Union bereitgestellt werden.

Sein Ziel ist vernünftig und notwendig. Hersteller sollten die in ihren Produkten enthaltenen Komponenten kennen, Cybersicherheitsrisiken bewerten, bekannte Schwachstellen beheben, Sicherheitsupdates liefern und ihre Produkte über einen definierten Lebenszyklus hinweg unterstützen. Sicherheit sollte nicht mit der Veröffentlichung eines Produkts enden.

Der CRA führt daher Pflichten in Bereichen wie diesen ein:

  • Cybersicherheits-Risikobewertung;
  • Schwachstellen-Handling;
  • Sicherheitsupdates und Supportzeiträume;
  • technische Dokumentation;
  • Konformitätsbewertung;
  • EU-Konformitätserklärungen;
  • CE-Kennzeichnung;
  • Meldung aktiv ausgenutzter Schwachstellen und schwerwiegender Vorfälle.

Wir teilen den Geist dieser Anforderungen. In einer Welt, in der Softwareprodukte aus Hunderten oder Tausenden von Abhängigkeiten zusammengesetzt sind, sollte ein Hersteller ein Produkt nicht verkaufen und danach den Überblick verlieren können, was es enthält.

Zugleich ist der CRA eine Produktregulierung. Bevor über Konformitätsbewertungen, CE-Kennzeichnung oder Herstellerpflichten gesprochen wird, müssen wir zunächst ein auf dem Markt bereitgestelltes Produkt mit digitalen Elementen identifizieren.

Diese Produktgrenze ist die zentrale Frage für Agenturen.

Was die neue Leitlinie der Kommission zu Websites sagt

Artikel 3 Nummer 1 des CRA definiert ein Produkt mit digitalen Elementen als ein Software- oder Hardwareprodukt und dessen Fernverarbeitungslösungen, einschließlich separat auf dem Markt bereitgestellter Software- oder Hardwarekomponenten.

Die Leitlinie der Kommission erläutert, wie diese Definition auf Software anzuwenden ist.

Laut Randnummer 20 kann Software ein Produkt mit digitalen Elementen sein, wenn sie einem Nutzer bereitgestellt, von diesem bezogen und auf einem elektronischen Informationssystem auf der Seite des Nutzers oder als Teil davon betrieben wird. Eine heruntergeladene Desktop-Anwendung, eine Browser-Extension oder eine für die lokale Ausführung paketierte Anwendung kann daher als Produkt gelten.

Randnummer 21 beschreibt die andere Seite dieser Unterscheidung. Software, die aus der Ferne ausgeführt und vom Nutzer lediglich genutzt wird, ist allein deshalb kein Produkt mit digitalen Elementen. Die Leitlinie stellt fest, dass dies typischerweise für Webanwendungen gilt, einschließlich Progressive Web Apps, wenn sie ausschließlich über einen Browser genutzt werden.

Anschließend wendet sie dieselbe Argumentation ausdrücklich auf Websites an:

„Websites sind selbst nicht als Produkte mit digitalen Elementen zu betrachten."

Die Leitlinie liefert zwei besonders nützliche Beispiele. Beispiel 5 besagt, dass eine ausschließlich über einen Webbrowser genutzte Webanwendung kein Produkt mit digitalen Elementen ist; sie fällt nur dann unter den CRA, wenn sie die Funktionalität eines anderen Produkts mit digitalen Elementen unterstützt. Beispiel 6 besagt, dass eine Website, die Besucher:innen lediglich Informationen präsentiert und die Funktionalität eines Produkts mit digitalen Elementen nicht unterstützt, selbst kein Produkt mit digitalen Elementen ist und daher nicht unter den CRA fällt.

Das ist nicht länger nur eine Ableitung aus dem Wortlaut von Erwägungsgrund 12. Es ist nun die ausdrückliche Auslegung der Kommission, wie die Verordnung auf Websites und browserbasierte Anwendungen anzuwenden ist.

Aber TYPO3 ist Software. Warum macht das die Agentur nicht zum Hersteller?

Das ist die stärkste Kritik an meiner Position, und sie verdient eine direkte Antwort.

Eine Agentur verbindet TYPO3 Core, Third-Party-Pakete, Konfiguration und individuellen Code zu einem vollständigen technischen System. Die neue Leitlinie erläutert außerdem, dass ein Integrator zum Hersteller werden kann, wenn er Komponenten zu einem neuen Produkt mit digitalen Elementen zusammenfügt und dieses neue Produkt auf dem Markt bereitstellt.

Der entscheidende Teil dieses Satzes ist nicht nur Komponenten integrieren. Das Ergebnis muss selbst ein Produkt mit digitalen Elementen sein, das auf dem Markt bereitgestellt wird.

Würde jede Integration von Softwarekomponenten automatisch ein neues CRA-Produkt schaffen, könnte die Kommission nicht gleichzeitig zu dem Schluss kommen, dass reine Browser-Webanwendungen und gewöhnliche Websites selbst keine Produkte mit digitalen Elementen sind. Fast jede moderne Website enthält ein Content-Management-System, Bibliotheken, Frontend-Abhängigkeiten, APIs und projektspezifischen Code.

Die Verwendung von Produkten oder Softwarekomponenten innerhalb einer Architektur bestimmt für sich allein nicht die Einordnung des fertigen Angebots.

Für ein TYPO3-Projekt sollten wir mindestens vier Ebenen unterscheiden:

  1. TYPO3 Core als freie Open-Source-Software;
  2. separat verteilte TYPO3-Extensions und andere Pakete;
  3. die mit diesen Komponenten umgesetzte kundenspezifische Website;
  4. die Hosting-, Wartungs- und Betriebsdienste rundherum.

Diese Ebenen haben nicht automatisch denselben regulatorischen Status oder denselben verantwortlichen Wirtschaftsakteur.

TYPO3 Core kann als Software für sich betrachtet werden. Auch eine separat vermarktete Extension kann ein Produkt mit digitalen Elementen sein. Daraus folgt jedoch nicht, dass die mit diesen Komponenten gebaute Unternehmenswebsite zu einem weiteren, von der Agentur auf dem Markt bereitgestellten Softwareprodukt wird.

Die erste Frage lautet nicht „Wer hat TYPO3 integriert?", sondern „Was ist das resultierende Angebot?" Ist das Ergebnis eine gewöhnliche Website, die aus der Ferne läuft, über einen Browser genutzt wird und kein anderes Produkt mit digitalen Elementen unterstützt, so sagt die Leitlinie der Kommission, dass die Website selbst kein Produkt mit digitalen Elementen ist. Ohne ein solches Produkt kann die Agentur nicht allein durch den Akt der Integration zu dessen Hersteller werden.

TYPO3 Core ist Software — aber es zu installieren macht die Agentur nicht zu dessen Hersteller

Es gibt eine weitere Unterscheidung, die nicht hinter dem Website-Argument verschwinden sollte: TYPO3 Core ist zweifellos Software. Es kann heruntergeladen, installiert und auf dem Server des Kunden oder auf der Infrastruktur eines Hosting-Unternehmens betrieben werden.

Dass die resultierende Website selbst kein Produkt mit digitalen Elementen ist, bedeutet nicht, dass TYPO3 Core irgendwie aufgehört hätte, Software zu sein. Es bedeutet, dass wir es mit mehreren verschiedenen Objekten zu tun haben und ihnen nicht denselben regulatorischen Status zuweisen sollten.

Die Leitlinie der Kommission liefert für Agenturen, die mit freier Open-Source-Software arbeiten, eine besonders relevante Klarstellung. Die Randnummern 55 und 56 erläutern, dass allein die Tatsache, dass eine Person, die FOSS veröffentlicht, auch bezahlte professionelle Dienstleistungen anbietet, nicht bedeutet, dass die Software selbst im Rahmen einer kommerziellen Tätigkeit bereitgestellt wird. Die Leitlinie nennt ausdrücklich Beratung, Schulung, Dokumentation, Konfiguration und Deployment. Randnummer 59 behandelt anschließend einen unabhängigen Dienstleister, der technische Unterstützung für FOSS anbietet, die nicht in seiner Verantwortung liegt. Ein solcher Dienstleister gilt nicht als jemand, der diese Software auf dem Markt bereitstellt, sofern er die FOSS nicht als Teil seiner Leistung wesentlich verändert.

Diese Unterscheidung entspricht sehr genau einem normalen TYPO3-Projekt. Der Kunde kann TYPO3 eigenständig herunterladen. Die Agentur wird für ihre Expertise bezahlt: Architektur, Installation, Konfiguration, Integration, Frontend-Entwicklung, Qualitätssicherung, Deployment und Support. Die Bezahlung erkauft keine Erlaubnis, auf TYPO3 Core zuzugreifen.

Noch direkter beschreibt Beispiel 19 einen Dienstleister, der einem Kunden hilft, freie Open-Source-Software auf dessen On-Premise-Server zu installieren. Sofern der Anbieter diese FOSS nicht wesentlich verändert, kommt die Kommission zu dem Schluss, dass der Dienstleister nicht als jemand gilt, der die FOSS auf dem Markt bereitstellt. Das ist eine ungewöhnlich enge Analogie zu der Arbeit, die in vielen TYPO3-Projekten geleistet wird.

Die Agentur veröffentlicht TYPO3 Core nicht unter eigenem Namen, kontrolliert dessen Releases nicht und bestimmt nicht dessen allgemeine Roadmap. TYPO3 zu installieren und zu konfigurieren macht die Agentur daher nicht zum Hersteller von TYPO3 Core. Auch der Kunde, der die Installation betreibt, wird nicht allein durch deren Nutzung zu dessen Hersteller.

Es gibt eine wichtige Grenze. Beispiel 19 setzt ausdrücklich voraus, dass der Dienstleister die FOSS nicht wesentlich verändert. Eine Agentur, die einen wesentlich veränderten TYPO3-Fork erstellt und bereitstellt, kann nach Artikel 22 eine andere Rolle haben. Die normale Nutzung der vorgesehenen Extension- und Konfigurationsmechanismen von TYPO3 — Site-Konfiguration, TypoScript, Fluid-Templates, Content-Elemente und Extensions — sollte nicht automatisch mit einer wesentlichen Veränderung von TYPO3 Core verwechselt werden. Eine schwierigere Frage stellt sich, wenn eine Agentur Core forkt, dessen Zweckbestimmung ändert oder Änderungen einführt, die dessen CRA-Konformität oder Cybersicherheits-Risikoprofil wesentlich beeinflussen.

Auch deshalb müssen proprietäre Extensions separat bewertet werden. Die Agentur kann in Bezug auf TYPO3 Core nur Installateur und Dienstleister bleiben und zugleich zum Hersteller einer Extension oder Distribution werden, die sie unter eigenem Namen entwickelt, kontrolliert und bereitstellt.

Wie wir tatsächlich mit Agenturen arbeiten

Digital Zombies wirkt meist als TYPO3-Expertenteam mit, das mit einer anderen Agentur zusammenarbeitet. Je nach Projekt steuern wir Architektur, Extension-Entwicklung, Integrationen, Upgrades, Deployment-Unterstützung oder langfristige technische Wartung bei.

Wir verlangen von Agenturen oder Kunden nicht, ein proprietäres Digital-Zombies-Basis-Theme oder eine verpflichtende Produkt-Extension zu kaufen, um ein Projekt zu bauen. Wir machen nicht jede Kundenumsetzung zu einer weiteren Installation eines standardisierten „Digital-Zombies-Website-Produkts".

Ein typisches Projekt hat Merkmale wie:

  • es wird für einen bestimmten Kunden erstellt;
  • Design, Inhaltsmodell und Integrationen sind kundenspezifisch;
  • es läuft unter der Domain und Identität des Kunden;
  • Besucher:innen nutzen es über ihre Browser;
  • Besucher:innen erhalten oder installieren das zugrunde liegende TYPO3-System nicht;
  • die Website ist für den Betrieb eines anderen digitalen Produkts nicht erforderlich;
  • TYPO3 Core und Third-Party-Pakete behalten ihre eigene Identität und Lizenz;
  • die beteiligten Unternehmen erbringen Entwicklungs- und Integrationsleistungen, statt ein wiederverwendbares Website-Produkt zu lizenzieren.

Diese Umstände sind keine einzelnen rechtlichen Ausnahmen. Individuelle Software kann trotzdem ein Produkt sein, und Bezahlung kann durchaus Teil einer kommerziellen Tätigkeit sein. Sie beschreiben aber, was geliefert wird: eine aus der Ferne betriebene Kundenwebsite, kein unter der Marke der Agentur ausgeliefertes Softwarepaket, das Nutzer:innen zur Ausführung in ihren eigenen elektronischen Informationssystemen erhalten. Diese technische Realität entspricht sehr genau der Unterscheidung, die die Kommission nun trifft.

Für Digital Zombies ist die Herstellerfrage in vielen White-Label-Projekten noch ferner. Wir steuern spezialisiertes Engineering unter der Verantwortung und im Liefermodell der Partneragentur bei. Wir vermarkten die Kundenwebsite nicht unter dem Namen Digital Zombies, und Website-Besucher:innen erfahren oft nie, dass unser Team beteiligt war. Diese Tatsache allein würde den Anwendungsbereich des CRA nicht klären, aber sie macht die Behauptung, Digital Zombies vermarkte ein Website-Produkt unter eigenem Namen, besonders schwer haltbar.

Öffentlicher Zugang ist nicht dasselbe wie der Erhalt eines Softwareprodukts

Eine Unternehmenswebsite ist öffentlich zugänglich. Das bedeutet nicht, dass ihre Software jeder besuchenden Person geliefert wird.

Besucher:innen erhalten HTML, CSS, JavaScript, Bilder und Daten, die zur Nutzung der Website nötig sind. Sie erhalten nicht die TYPO3-Installation, deployen sie nicht auf ihren eigenen Systemen und bekommen keine Lizenz, die fertige Website-Software eigenständig zu betreiben.

Die Leitlinie der Kommission erkennt diese technische Unterscheidung an. Sie hält fest, dass Teile einer Website auf dem Gerät der Besucher:innen ausgeführt werden können, kommt aber dennoch zu dem Schluss, dass Websites selbst keine Produkte mit digitalen Elementen sind. Ein paar heruntergeladene Frontend-Assets verwandeln die gesamte, aus der Ferne betriebene Website nicht in ein lokal geliefertes Softwareprodukt.

Auch deshalb kann die Tatsache, dass eine Website ein Netzwerk nutzt, die Frage nicht entscheiden. Netzwerkkonnektivität ist erst relevant, nachdem wir ein Produkt mit digitalen Elementen identifiziert haben. Sie kann etwas, das die Leitlinie ausdrücklich als Website-Dienst behandelt, nicht von sich aus in ein Produkt verwandeln.

Erwägungsgründe 11 und 12 definieren weiterhin eine wichtige Grenze

Die Auslegung der Kommission baut auf den Erwägungsgründen 11 und 12 des CRA auf.

Erwägungsgrund 11 erläutert, warum Fernverarbeitung Teil eines Produkts mit digitalen Elementen sein kann. Ein Hersteller sollte Produktsicherheitspflichten nicht dadurch umgehen können, dass er eine wesentliche Funktion seines Produkts vom Gerät der Nutzer:innen in sein eigenes Backend verlagert. Ein smartes Gerät kann etwa von einem Fern-Authentifizierungsdienst, einer API oder einem Cloud-Backend abhängen. Würde das Fehlen dieser Fernverarbeitung das Produkt daran hindern, eine seiner Funktionen zu erfüllen, kann die Fernlösung nach dem CRA Teil des Produkts sein.

Erwägungsgrund 12 legt die entsprechende Grenze fest. Websites, die die Funktionalität eines Produkts mit digitalen Elementen nicht unterstützen, fallen aus dieser Beziehung heraus.

Die neue Leitlinie liefert einen praktischen Test. Bloß Informationen über ein digitales Produkt zu veröffentlichen, reicht nicht aus, selbst wenn das Produkt auf die Website verlinkt. Eine externe Seite mit Anleitungen ist nicht automatisch eine Fernverarbeitungslösung. Ein Authentifizierungsportal hingegen, das für den Betrieb des Produkts erforderliche Anmeldedaten oder Tokens ausstellt, kann eine Produktfunktion unterstützen und daher als Fernverarbeitung unter den CRA fallen.

Für die meisten Unternehmens-TYPO3-Websites ist die Unterscheidung eindeutig. Leistungen, Standorte, Case Studies, Artikel, Stellenangebote oder Kontaktinformationen zu präsentieren, ermöglicht normalerweise nicht den Betrieb eines anderen Produkts mit digitalen Elementen. Auch eine CRM-Integration, eine Newsletter-Anbindung, ein Suchdienst oder ein Kontaktformular ändern diese Schlussfolgerung nicht automatisch. Die relevante Frage ist nicht, ob die Website mit einem anderen System kommuniziert, sondern ob ein anderes Produkt mit digitalen Elementen ohne die Website oder ihre Fernverarbeitung daran gehindert wäre, eine seiner Funktionen zu erfüllen.

Wo sich unsere Schlussfolgerung ändert

Die neue Leitlinie stärkt die Position für gewöhnliche Websites, hilft aber auch, die Fälle zu identifizieren, die Agenturen separat bewerten müssen.

Eine kommerzielle TYPO3-Extension

Entwickelt eine Agentur eine Extension, veröffentlicht oder lizenziert sie unter eigenem Namen und stellt sie zur Nutzung in TYPO3-Installationen bereit, so kann diese Extension ein Softwareprodukt mit digitalen Elementen sein. Die Agentur kann dann Herstellerin der Extension sein. Das ist das Szenario, in dem SBOM-Erstellung, Transparenz über Abhängigkeiten, Schwachstellen-Monitoring, koordinierte Offenlegung, Sicherheitsupdates, technische Dokumentation und ein definierter Supportzeitraum unmittelbar relevant werden. Es spielt keine Rolle, dass die Extension nur einen Kunden hat, wenn sie als fertiges Softwareprodukt bereitgestellt wird; die Produkteinordnung erfordert keine Massenverteilung.

Als Produkt bereitgestellter Quellcode

Die Unterscheidung zwischen einer Entwicklungsleistung und einem Softwareprodukt lässt sich nicht darauf reduzieren, ob der Kunde Quellcode erhält. Beispiel 7 der Leitlinie beschreibt ein Unternehmen, das Quellcode für eine anpassbare interne Plattform lizenziert. Obwohl der Kunde den Code anpassen und kompilieren muss, betrachtet die Kommission den Quellcode als ein auf dem Markt bereitgestelltes Produkt. Ein Vertrag über Engineering-Arbeit innerhalb eines Kundenprojekts ist nicht automatisch dasselbe wie die Lizenzierung einer definierten Plattform, Distribution oder Codebasis als Produkt. Agenturen sollten verstehen, welches dieser Modelle ihre Verträge und Lieferprozesse tatsächlich schaffen.

Lokal installierte Anwendungen

Eine Desktop-Anwendung, Browser-Extension, mobile App oder eine mit Webtechnologien gebaute, aber für die lokale Installation paketierte Anwendung kann ein Produkt mit digitalen Elementen sein. Dass sie HTML und JavaScript nutzt, macht sie nicht zu einer Website. Der entscheidende Unterschied ist, dass die Anwendung an die Nutzer:innen geliefert wird und in deren Umgebung ausgeführt wird.

Eine Website, die ein anderes Produkt unterstützt

Eine TYPO3-Website kann unter den CRA fallen, wenn sie die Funktionalität eines anderen Produkts mit digitalen Elementen unterstützt. Beispiele könnten ein Portal sein, das von einem vernetzten Gerät benötigte Anmeldedaten ausstellt, ein Backend, das zur Konfiguration eines lokal installierten Produkts nötig ist, oder Fernverarbeitung, ohne die ein Produkt eine seiner Funktionen nicht erfüllen kann. In dieser Situation ist die Website oder das Backend nicht zwingend ein eigenes Produkt; sie kann Teil der Fernverarbeitungslösung des vernetzten Produkts sein und muss in die Bewertung des Herstellers einbezogen werden.

SaaS und reine Browser-Geschäftsanwendungen

Die neue Leitlinie erfordert außerdem eine Präzisierung der verbreiteten Aussage, eine bezahlte SaaS-Anwendung sei automatisch ein CRA-Produkt. Eine reine Browser-Webanwendung ist nicht schon deshalb selbst ein Produkt mit digitalen Elementen, weil Kunden für den Zugang bezahlen. Sie ist in der Regel ein aus der Ferne bereitgestellter Dienst, und Cloud-Service-Modelle können stattdessen NIS2 und anderen anwendbaren Rechtsvorschriften unterliegen. Der CRA kann dennoch relevant werden, wenn dieser Dienst eine Funktion eines anderen Produkts mit digitalen Elementen unterstützt. Die Architektur und das Verhältnis zwischen dem aus der Ferne betriebenen Dienst und dem Produkt zählen daher mehr als das Etikett „SaaS".

Außerhalb des CRA heißt nicht außerhalb der Verantwortung

Die falsche Schlussfolgerung aus diesem Artikel wäre, dass eine gewöhnliche TYPO3-Website weniger ernsthaftes Security-Engineering erfordert.

Die Website kann personenbezogene Daten verarbeiten, mit internen Systemen verbunden sein, Bewerbungen oder Anfragen annehmen und einen kritischen Kommunikationskanal darstellen. Sie kann unabhängig von ihrer produktrechtlichen Einordnung angegriffen werden.

Agenturen sollten dennoch pflegen:

  • ein Inventar der TYPO3- und Frontend-Abhängigkeiten;
  • reproduzierbare Deployments;
  • Schwachstellen-Monitoring;
  • zeitnahe Sicherheitsupdates;
  • dokumentierte Verantwortlichkeiten zwischen Kunde, Agentur, Hosting-Anbieter und spezialisiertem Entwicklungspartner;
  • getestete Backup- und Wiederherstellungsverfahren;
  • einen Prozess zum Empfang und zur Bearbeitung von Schwachstellenmeldungen.

In der Praxis sind viele der vom CRA geförderten Engineering-Disziplinen auch für Websites gute Praxis, die außerhalb seines Produktbereichs liegen. Ein SBOM kann einer Agentur weiterhin helfen zu verstehen, was installiert ist. Security-Advisories müssen weiterhin die richtigen Personen erreichen. Eine nicht mehr unterstützte Extension bleibt ein Risiko, auch wenn keine CE-Kennzeichnung erforderlich ist.

Die rechtliche Einordnung ändert die formalen Pflichten. Sie beseitigt nicht das technische Risiko.

Fazit: TYPO3 macht aus einer Website kein Produkt

Der CRA hat ein wertvolles Ziel, und wir teilen sein Grundprinzip: Unternehmen, die digitale Produkte auf dem Markt bereitstellen, müssen über den gesamten Produktlebenszyklus Verantwortung für deren Sicherheit übernehmen. Verantwortung beginnt jedoch damit, die richtige Produktgrenze zu bestimmen.

Dass TYPO3 Software ist, bedeutet nicht, dass jede mit TYPO3 umgesetzte Website zu einem neuen, von der Agentur hergestellten Softwareprodukt wird. Die Leitlinie der Europäischen Kommission vom Juli 2026 sagt nun ausdrücklich, dass eine Website selbst kein Produkt mit digitalen Elementen ist und dass auch eine ausschließlich über einen Browser genutzte Webanwendung kein solches Produkt ist, sofern sie nicht die Funktionalität eines anderen Produkts unterstützt.

Für eine typische kundenspezifische Unternehmenswebsite stützt das eine klare Schlussfolgerung: Die Agentur erbringt Architektur-, Entwicklungs-, Integrations- und Betriebsleistungen rund um eine aus der Ferne genutzte Website. Sie stellt nicht automatisch ein Website-Produkt mit digitalen Elementen auf dem Markt bereit.

Die Grenze ändert sich, wenn die Agentur eine kommerzielle Extension bereitstellt, Quellcode als Produkt lizenziert, lokal ausgeführte Software liefert oder Fernfunktionalität baut, die ein anderes Produkt mit digitalen Elementen benötigt.

Deshalb sollten Agenturen den CRA weder unterschiedslos fürchten noch vollständig abtun. Sie sollten abbilden, was sie tatsächlich liefern, Produkte von Dienstleistungen und Komponenten trennen, bestimmen, wer welches Produkt vermarktet, und dann die relevanten Pflichten auf die richtige Ebene anwenden. Das ist eine nützlichere Engineering-Antwort als der Versuch, jede Zeile individuellen PHP-Codes als neues CE-gekennzeichnetes Produkt einzuordnen.

Quellen

← Vorheriger ArtikelVom internen Tool zum TYPO3-Produkt: Was Extension-Hersteller über SBOMs wissen sollten