Reading time: 10 Minuten

The Cyber Resilience Act is here

The Cyber Resilience Act (CRA) has been in force since October 2024 and also applies to digital agencies and hosting providers — sooner than many realise. From September 2026, the obligation to report actively exploited vulnerabilities will already apply. Anyone who fails to scrutinise their own range of services now risks regulatory surprises. The crucial question here is: are we offering a service here — or are we placing a product on the market? This is because bespoke client projects and in-house software that is marketed repeatedly—such as extensions, starter packages or SaaS tools—are subject to fundamentally different obligations. This article explains what this distinction means, what consequences it has for contracts and processes — and why the TYPO3 ecosystem has a structural advantage in this regard.

Two deadlines, not one

Most people know that the Cyber Resilience Act is expected to come into full effect in December 2027. What is less well known is that the first deadline is already in September 2026. From then on, anyone offering digital products commercially will be obliged to report actively exploited vulnerabilities. That’s not two years’ lead time — it’s six months until the first critical milestone.

Service or product? That is the real question.

For agencies, the most important distinction in the CRA is not between large and small, or between open source and proprietary. It is between what we build for clients and what we bring to market as our own offering.

A bespoke client project — a custom-built website, a configured TYPO3 system, or a digital platform tailored to a specific client — constitutes a service. The client is the commissioning party; the end result becomes part of their infrastructure. The CRA obligations lie primarily with the client as the operator, not with the agency as the service provider. This does not relieve the agency of its contractual duty of care, but it does mean that the individual client project is not a product containing digital elements within the meaning of the CRA.

The situation is different for anything an agency develops itself and repeatedly brings to market. A TYPO3 extension that is sold commercially. A starter package or theme offered as a reusable product. A SaaS tool or managed service offering where software is provided as part of the service. In this case, the agency is the manufacturer within the meaning of the CRA — with all the resulting obligations: 

• Vulnerability Management
• Security updates at set intervals
• Documentation
• Evidence of conformity
• Reporting requirements

The practical question that every agency must answer for its portfolio is therefore: 
Are we selling a service here — or are we marketing a product?

What does the Cyber Resilience Act mean for contract drafting?

This distinction has a direct impact on the way agencies enter into contracts with clients. Anyone offering managed hosting or ongoing maintenance as part of a service contract should check whether software is being provided commercially — and, if so, what obligations this entails. Maintenance contracts, SLAs for security updates, documentation requirements: These are no longer just nice extras, but potentially mandatory components of a service relationship under regulatory requirements.

The same applies to customers: those who operate digital products – particularly in public authorities, hospitals or utility companies – will increasingly need to specify in tenders whether the software used is managed by a recognised steward and whether the appointed agency can demonstrate that its processes comply with CRA standards.

What role does the TYPO3 Association play in relation to the Cyber Resilience Act?

For agencies within the TYPO3 ecosystem, there is a structural advantage: the TYPO3 Association did not simply invent the steward role, but is required to fulfil it because the Cyber Resilience Act mandates it. It has been practising this for years — with vulnerability disclosure processes, a cybersecurity policy and a willingness to take responsibility towards the authorities. This means that the foundation upon which client projects and our own products are built is recognised by regulators.

What agencies need to build on this is their own framework: clearer product definitions within their own portfolio, more transparent contractual arrangements with clients, and documented processes in case one of their own extensions or tools becomes a compliance issue.

The CRA is forcing us to grow up. And that’s a good thing.

The distinction between a project and a product has long been blurred in the agency world — because there were no consequences for ignoring it. That is changing. Those who now scrutinise their own range of services and clearly define what constitutes a service and what constitutes a product will not only achieve regulatory clarity. They will also lay the foundations for fairer pricing, more robust contracts and more credible discussions with clients, who will increasingly be asking for precisely these answers.

Betrifft der CRA Ihr Portfolio? Wir klären das gemeinsam.