Reading time: 14 min

Does the Cyber Resilience Act Apply to a Typical TYPO3 Website Project?

A CEO's engineering perspective, updated following the European Commission's CRA guidance of 27 July 2026.

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

Disclaimer: This article reflects my personal opinion and engineering perspective as CEO of a TYPO3 development company. It is not legal advice, does not constitute a legal opinion and should not be used as a substitute for an assessment of a specific business model or contract by a qualified lawyer.

A CEO's engineering perspective, updated following the European Commission's CRA guidance of 27 July 2026.

An important clarification arrived at exactly the right time

When we began examining the Cyber Resilience Act, one question kept returning: if an agency builds a website with TYPO3, does the agency become the manufacturer of a product with digital elements?

The cautious answer had to be that a conventional website looked different from the software products for which the CRA was written, particularly because Recital 12 expressly mentioned websites that do not support the functionality of a product with digital elements. Nevertheless, there was room for criticism. TYPO3 is software, extensions are software, custom PHP code is software, and an agency is paid to combine these components into a working system. Why should this not be considered a product?

On 27 July 2026, the European Commission published new guidance on the application of the CRA. Although this guidance is non-binding, it addresses the distinction directly and provides 67 practical examples and several flowcharts.

The relevant clarification is surprisingly clear: a website is not itself a product with digital elements merely because parts of it technically execute in a visitor's browser. A web application accessed exclusively through a browser is also not itself such a product, unless it supports the functionality of another product with digital elements.

This guidance does not mean that agencies can forget cybersecurity, and it does not exclude every commercial activity involving TYPO3. It does, however, give much stronger support to the position I expressed when we first examined a typical customer-specific TYPO3 website project.

My position

For the TYPO3 website projects that agencies and specialist development providers typically deliver together, my position is:

A conventional corporate website that is accessed through a browser and does not support the functionality of another product with digital elements is not itself a product with digital elements under the CRA.

It follows that an agency does not become the manufacturer of a CRA product merely because it uses TYPO3, installs extensions, writes project-specific code and receives payment for that work.

This conclusion depends on what is actually being supplied. It should not automatically be transferred to a commercial TYPO3 extension, a reusable software distribution, a locally installed application, licensed source code, or a website that is necessary for a connected product to perform one of its functions.

What the CRA is trying to achieve

The Cyber Resilience Act, formally Regulation (EU) 2024/2847, establishes cybersecurity requirements for products with digital elements made available on the European Union market.

Its goal is reasonable and necessary. Manufacturers should understand the components contained in their products, assess cybersecurity risks, address known vulnerabilities, deliver security updates and support their products throughout a defined lifecycle. Security should not end when a product is released.

The CRA therefore introduces obligations concerning areas such as:

  • cybersecurity risk assessment;
  • vulnerability handling;
  • security updates and support periods;
  • technical documentation;
  • conformity assessment;
  • EU declarations of conformity;
  • CE marking;
  • reporting of actively exploited vulnerabilities and severe incidents.

We agree with the spirit of these requirements. In a world in which software products are assembled from hundreds or thousands of dependencies, a manufacturer should not be able to sell a product and then lose sight of what it contains.

At the same time, the CRA is a product regulation. Before discussing conformity assessments, CE marking or manufacturer obligations, we first need to identify a product with digital elements that has been made available on the market.

That product boundary is the central question for agencies.

What the new Commission guidance says about websites

Article 3(1) of the CRA defines a product with digital elements as a software or hardware product and its remote data-processing solutions, including software or hardware components placed on the market separately.

The Commission's guidance explains how this definition should be applied to software.

According to paragraph 20, software can be a product with digital elements when it is provided to a user, obtained by that user and operated on, or as part of, an electronic information system on the user's side. A downloaded desktop application, a browser extension or an application packaged for local execution can therefore qualify as a product.

Paragraph 21 describes the other side of this distinction. Software that executes remotely and is merely accessed by the user is not, on that basis alone, a product with digital elements. The guidance says this is typically the case for web applications, including progressive web applications, when they are accessed exclusively through a browser.

It then applies the same reasoning expressly to websites:

"Websites are not themselves to be considered as products with digital elements."

The guidance provides two particularly useful examples. Example 5 states that a web application accessed exclusively through a web browser is not a product with digital elements; it falls within the CRA only where it supports the functionality of another product with digital elements. Example 6 states that a website which merely presents information to visitors and does not support the functionality of a product with digital elements is not itself a product with digital elements and therefore does not fall within the CRA.

This is no longer only an inference from the wording of Recital 12. It is now the Commission's explicit interpretation of how the Regulation applies to websites and browser-based applications.

But TYPO3 is software. Why does that not make the agency a manufacturer?

This is the strongest criticism of my position, and it deserves a direct answer.

An agency combines TYPO3 Core, third-party packages, configuration and custom code into a complete technical system. The new guidance also explains that an integrator can become a manufacturer when it assembles components into a new product with digital elements and places that new product on the market.

The important part of that sentence is not only integrates components. The result must itself be a product with digital elements that is placed on the market.

If every integration of software components automatically created a new CRA product, the Commission could not simultaneously conclude that browser-only web applications and ordinary websites are not themselves products with digital elements. Almost every modern website contains a content management system, libraries, frontend dependencies, APIs and project-specific code.

The use of products or software components inside an architecture does not by itself determine the classification of the completed offering.

For a TYPO3 project, we should distinguish at least four layers:

  1. TYPO3 Core as free and open-source software;
  2. separately distributed TYPO3 extensions and other packages;
  3. the customer-specific website implemented with those components;
  4. the hosting, maintenance and operational services surrounding it.

These layers do not automatically have the same regulatory status or the same responsible economic operator.

TYPO3 Core may be examined as software in its own right. An extension marketed separately may also be a product with digital elements. However, it does not follow that the corporate website built with those components becomes another software product placed on the market by the agency.

The first question is not, "Who integrated TYPO3?" It is, "What is the resulting offering?" If the result is an ordinary website that executes remotely, is accessed through a browser and does not support another product with digital elements, the Commission's guidance says that the website is not itself a product with digital elements. Without such a product, the agency cannot become its manufacturer merely through the act of integration.

TYPO3 Core is software — but installing it does not make the agency its manufacturer

There is another distinction that should not be hidden behind the website argument: TYPO3 Core is unquestionably software. It can be downloaded, installed and operated on the customer's server or on infrastructure provided by a hosting company.

The fact that the resulting website is not itself a product with digital elements does not mean that TYPO3 Core has somehow stopped being software. It means that we are dealing with several different objects and should not assign the same regulatory status to all of them.

The Commission's guidance provides particularly relevant clarification for agencies working with free and open-source software. Paragraphs 55 and 56 explain that the mere fact that a person publishing FOSS also offers paid professional services does not mean that the software itself is supplied in the course of a commercial activity. The guidance expressly mentions consultancy, training, documentation, configuration and deployment. Paragraph 59 then addresses an independent service provider offering technical assistance for FOSS that is not under its responsibility. Such a provider is not considered to be placing that software on the market unless it substantially modifies the FOSS as part of its delivery.

This distinction corresponds closely to a normal TYPO3 project. The customer can download TYPO3 independently. The agency is paid for its expertise: architecture, installation, configuration, integration, frontend development, quality assurance, deployment and support. The payment does not purchase permission to access TYPO3 Core.

Even more directly, Example 19 describes a service provider that helps a customer install free and open-source software on the customer's on-premises server. Where the provider does not substantially modify that FOSS, the Commission concludes that the service provider is not considered to be placing the FOSS on the market. This is an unusually close analogy to the work performed in many TYPO3 projects.

The agency does not publish TYPO3 Core under its own name, control its releases or determine its general roadmap. Installing and configuring TYPO3 therefore does not make the agency the manufacturer of TYPO3 Core. The customer operating the installation does not become its manufacturer merely through using it either.

There is an important limit. Example 19 expressly assumes that the service provider does not substantially modify the FOSS. An agency that creates and supplies a substantially modified TYPO3 fork may have a different role under Article 22. Normal use of TYPO3's intended extension and configuration mechanisms — site configuration, TypoScript, Fluid templates, content elements and extensions — should not automatically be confused with substantially modifying TYPO3 Core. A more difficult question arises where an agency forks Core, changes its intended purpose or introduces changes that materially affect its compliance with the CRA or its cybersecurity risk profile.

This is also why proprietary extensions must be assessed separately. The agency may remain only an installer and service provider in relation to TYPO3 Core while simultaneously becoming the manufacturer of an extension or distribution that it develops, controls and supplies under its own name.

How we actually work with agencies

Digital Zombies usually participates as a TYPO3 expert team working together with another agency. Depending on the project, we contribute architecture, extension development, integrations, upgrades, deployment support or long-term technical maintenance.

We do not require agencies or customers to purchase a proprietary Digital Zombies base theme or a mandatory product extension in order to build a project. We do not turn every customer implementation into another installation of a standard "Digital Zombies Website Product."

A typical project has characteristics such as:

  • it is created for one identified customer;
  • its design, content model and integrations are customer-specific;
  • it runs under the customer's domain and identity;
  • visitors access it through their browsers;
  • visitors do not receive or install the underlying TYPO3 system;
  • the website is not required for another digital product to operate;
  • TYPO3 Core and third-party packages retain their own identities and licences;
  • the participating companies provide development and integration services rather than licensing a reusable website product.

These circumstances are not individual legal exemptions. Custom software can still be a product, and payment can certainly form part of a commercial activity. They do, however, describe what is being delivered: a remotely operated customer website, not an agency-branded software package supplied to users for execution in their own electronic information systems. That technical reality corresponds closely to the distinction now made by the Commission.

For Digital Zombies, the manufacturer question is even more remote in many white-label projects. We contribute specialist engineering under the responsibility and delivery model of the partner agency. We do not market the customer website under the Digital Zombies name, and website visitors will often never know that our team participated. That fact alone would not resolve the scope of the CRA, but it does make the suggestion that Digital Zombies is marketing a website product under its own name particularly difficult to sustain.

Public access is not the same as receiving a software product

A corporate website is publicly accessible. That does not mean its software is supplied to every visitor.

Visitors receive HTML, CSS, JavaScript, images and data needed to use the website. They do not obtain the TYPO3 installation, deploy it on their own systems or receive a licence to operate the completed website software independently.

The Commission's guidance recognises this technical distinction. It notes that parts of a website may execute on the visitor's device, but it nevertheless concludes that websites are not themselves products with digital elements. A few downloaded frontend assets do not transform the entire remotely operated website into a locally supplied software product.

This is also why the fact that a website uses a network cannot decide the question. Network connectivity is relevant only after we have identified a product with digital elements. It cannot turn something the guidance explicitly treats as a website service into a product by itself.

Recitals 11 and 12 still define an important boundary

The Commission's interpretation builds upon Recitals 11 and 12 of the CRA.

Recital 11 explains why remote data processing can form part of a product with digital elements. A manufacturer should not be able to avoid product-security obligations simply by moving an essential function of its product from the user's device into its own backend. For example, a smart device may depend on a remote authentication service, API or cloud backend. If the absence of that remote processing would prevent the product from performing one of its functions, the remote solution may form part of the product under the CRA.

Recital 12 establishes the corresponding limit. Websites that do not support the functionality of a product with digital elements fall outside this relationship.

The new guidance provides a practical test. Merely publishing information about a digital product is not enough, even if the product links to the website. An external page with instructions is not automatically a remote data-processing solution. By contrast, an authentication portal issuing credentials or tokens required for the product to operate may support a product function and can therefore fall within the CRA as remote data processing.

For most corporate TYPO3 websites, the distinction is straightforward. Presenting services, locations, case studies, articles, vacancies or contact information does not normally enable another product with digital elements to function. A CRM integration, newsletter connection, search service or contact form also does not automatically change that conclusion. The relevant question is not whether the website communicates with another system. It is whether another product with digital elements would be prevented from performing one of its functions without the website or its remote processing.

Where our conclusion changes

The new guidance strengthens the position for ordinary websites, but it also helps identify the cases that agencies must assess separately.

A commercial TYPO3 extension

If an agency develops an extension, publishes or licenses it under its own name and supplies it for use in TYPO3 installations, that extension can be a software product with digital elements. The agency may then be the manufacturer of the extension. This is the scenario in which SBOM generation, dependency visibility, vulnerability monitoring, coordinated disclosure, security updates, technical documentation and a defined support period become directly relevant. It does not matter that the extension has only one customer if it is supplied as a finished software product; product classification does not require mass distribution.

Source code supplied as a product

The distinction between a development service and a software product cannot be reduced to whether the customer receives source code. The guidance's Example 7 describes a company licensing source code for a customisable internal platform. Even though the customer must adapt and compile the code, the Commission considers the source code to have been placed on the market as a product. A contract to provide engineering work within a customer project is not automatically identical to licensing a defined platform, distribution or codebase as a product. Agencies should understand which of those models their contracts and delivery processes actually create.

Locally installed applications

A desktop application, browser extension, mobile app or application built with web technologies but packaged for local installation can be a product with digital elements. The fact that it uses HTML and JavaScript does not make it a website. The decisive difference is that the application is supplied to the user and executes in the user's environment.

A website supporting another product

A TYPO3 website can fall within the CRA where it supports the functionality of another product with digital elements. Examples could include a portal that issues credentials required by a connected device, a backend necessary to configure a locally installed product, or remote processing without which a product cannot perform one of its functions. In that situation, the website or backend is not necessarily a separate product; it can form part of the connected product's remote data-processing solution and must be included in the manufacturer's assessment.

SaaS and browser-only business applications

The new guidance also requires a refinement of the common statement that a paid SaaS application is automatically a CRA product. A browser-only web application is not itself a product with digital elements merely because customers pay to access it. It is generally a remotely provided service, and cloud service models may instead be subject to NIS2 and other applicable legislation. The CRA can still become relevant when that service supports a function of another product with digital elements. The architecture and the relationship between the remotely operated service and the product therefore matter more than the label "SaaS."

Outside the CRA does not mean outside responsibility

The wrong conclusion from this article would be that an ordinary TYPO3 website requires less serious security engineering.

The website may process personal data, connect to internal systems, accept applications or enquiries and represent a critical communication channel. It can be attacked regardless of its classification under product law.

Agencies should still maintain:

  • an inventory of TYPO3 and frontend dependencies;
  • reproducible deployments;
  • vulnerability monitoring;
  • timely security updates;
  • documented responsibilities between customer, agency, hosting provider and specialist development partner;
  • tested backup and recovery procedures;
  • a process for receiving and responding to vulnerability reports.

In practice, many of the engineering disciplines encouraged by the CRA are also good practices for websites that fall outside its product scope. An SBOM can still help an agency understand what is installed. Security advisories still need to reach the right people. An unsupported extension remains a risk even if no CE marking is required.

The legal classification changes the formal obligations. It does not remove the technical risk.

Conclusion: TYPO3 does not turn a website into a product

The CRA has a valuable objective, and we agree with its underlying principle: companies that place digital products on the market must take responsibility for their security throughout the product lifecycle. However, responsibility begins with identifying the correct product boundary.

The fact that TYPO3 is software does not mean that every website implemented with TYPO3 becomes a new software product manufactured by the agency. The European Commission's July 2026 guidance now says explicitly that a website is not itself a product with digital elements, and that a web application accessed exclusively through a browser is also not such a product unless it supports another product's functionality.

For a typical customer-specific corporate website, this supports a clear conclusion: the agency is providing architecture, development, integration and operational services around a remotely accessed website. It is not automatically placing a website product with digital elements on the market.

The boundary changes when the agency supplies a commercial extension, licenses source code as a product, provides locally executed software or builds remote functionality required by another product with digital elements.

This is why agencies should neither fear the CRA indiscriminately nor dismiss it completely. They should map what they actually supply, separate products from services and components, identify who markets each product, and then apply the relevant obligations to the correct layer. That is a more useful engineering response than attempting to classify every line of custom PHP as a new CE-marked product.

References

← Previous articleFrom Internal Tool to TYPO3 Product: What Extension Manufacturers Should Know About SBOMs