Adapted from the Polish article, originally published on 26 June 2026. The English version was published on 01 October 2026.
A software product reaches its first customers. The feature work is complete, but a dependency later needs a security patch. Who monitors the vulnerability, prepares the fix, informs users and continues doing that work after the development project ends?
The Cyber Resilience Act brings security into the product lifecycle. For startups and software suppliers, its practical effect reaches maintenance, documentation and contracts as well as code. Those arrangements need to explain how the product will remain supported, rather than leave security updates to an informal understanding.
The CRA is an EU regulation relevant to businesses supplying products with digital elements to the EU market. CERT Polska’s practical CRA material, used in the original article, provides guidance in Polish. The contractual allocation of tasks needs a separate assessment under the contract’s governing law.
What you will learn
- Why security work continues beyond delivery.
- How maintenance, vulnerability handling and SLAs connect.
- Why a software development supplier is not automatically the CRA manufacturer.
- What to clarify when an MVP or beta reaches real users.
- Which responsibilities to settle before an incident.
What is changing in the product lifecycle?
The CRA addresses products with digital elements within its scope. It sets requirements for their security and for handling vulnerabilities. The relevant work extends across planning, design, development and maintenance.
For the team, that means agreeing how to assess risks, document the product, monitor and handle vulnerabilities, deliver updates and communicate important fixes. An update process has owners, resources and an end point. It should be designed alongside the product’s commercial offering.
According to the European Commission’s CRA overview, the main obligations apply from 11 December 2027, while reporting obligations apply from 11 September 2026. The phases matter: do not treat every lifecycle requirement as already applicable merely because reporting has started.
Delivery ends a project phase. It does not answer how security will be maintained during the product’s supported life.
Why this matters to a software development supplier
Writing software for a customer does not automatically make every development company the manufacturer under the CRA. Examine the product, how it is supplied and the role of each party. The regulation can also affect a supplier indirectly through its customer’s contract requirements.
An implementation agreement, maintenance arrangement or SLA may need to allocate:
- Vulnerability monitoring and assessment.
- Preparation of a patch or workaround.
- Response times and escalation.
- Technical information the customer needs.
- Communication to users.
- Work continuing after initial delivery.
- Responsibility for third-party components.
A promise to provide “security fixes as part of good cooperation” does not say who will do these tasks, how long support lasts or how it will be paid for. The commercial agreement should match the actual process.
An MVP or beta still needs a defined use
A founder may see an unfinished experiment while a customer sees a usable service. Calling a product “beta” does not by itself settle its legal treatment or the responsibilities owed to its users.
Consider this hypothetical situation: a startup provides an early version to a customer for a real business workflow. The product handles live data and the customer depends on it, while the founders expect informal testing and occasional fixes. The label hides a disagreement about the product’s use and support.
Record the intended purpose, limitations, whether production use is permitted, available support and how defects or vulnerabilities will be handled. Any specific testing treatment under the CRA needs to be assessed against its conditions; the name of the release is not enough.
A beta label can describe development progress. Users still need clear information about use, limitations and support.
Maintenance as part of the compliance process
Maintenance clauses need to connect the security work with the people and evidence needed to carry it out. Identify the support period, update process, incident cooperation, technical documentation and treatment of open-source or other external components.
These terms should also explain the handover. If one supplier stops maintaining the product, what information and access allow the customer or another supplier to continue? What will be communicated to users when support ends?
An availability target is a separate promise. A product can meet its monthly uptime target while a serious vulnerability remains unaddressed. Conversely, urgent security work may need a planned interruption. Our SaaS SLA guide explains how to connect the measurement, maintenance window and remedy without confusing them.
What should be agreed before an incident?
During an incident, customers need an answer quickly, users ask about their exposure and the team is preparing a fix. That is a difficult time to discover that nobody owns the notification process or the affected component.
Use a pre-incident review to settle:
- Which products and versions the arrangement covers.
- The maintenance scope and support period.
- How vulnerabilities are received, assessed and escalated.
- Who prepares, approves and distributes updates.
- Who handles reporting and user communication where required.
- Responsibility for third-party and open-source components.
- What documentation and evidence each party provides.
- How support ends and what handover is needed.
- Which party holds the manufacturer role and which tasks a supplier performs for it.
The contractual allocation supports the process; it does not remove a regulated party’s own legal obligations. Assess the relevant CRA role and scope separately from the price and task allocation in the supplier agreement.
Product security also depends on control of IP, repositories and components. An investor or larger customer may ask both how the product will be supported and whether the business has the rights and access needed to deliver that support. For the early ownership decisions, see our founders agreement guide.
Define how long the product will remain supported
A customer will increasingly ask how long a product can operate securely, alongside whether its features work today. The answer should be consistent across the offer, contract, support process and documentation.
If you develop or maintain software for the EU market, review those arrangements together. Our IT and software legal services can help align Polish-law contracts with product responsibilities. Contact us about your product or supplier agreement.
Sources and further reading
- CERT Polska: CRA – nowe obowiązki dla producentów oprogramowania i korzyści dla użytkowników, guidance in Polish.
- European Commission: Cyber Resilience Act, overview and application dates.
- Regulation (EU) 2024/2847, the Cyber Resilience Act, official English legal text.