For years, software cybersecurity was often treated primarily as a technical task. The development team was responsible for securing the code, administrators for configuring the infrastructure, and after deployment the organization was expected to respond to reported issues and publish fixes. This model is still used in many organizations.
The EU Cyber Resilience Act, or CRA, reinforces a different approach: the security of a digital product should be considered from the start of its design and maintained throughout its support period. This is not just about securing a system on launch day, but also about vulnerability management, updates, documentation, manufacturer responsibility, and the ability to respond to incidents.
For companies that create software, develop their own digital products, or place them on the European market, this means they need to review not only their code, but also their business and organizational processes.
Importantly, the CRA is no longer just a regulation that companies can start preparing for in the distant future. The regulation entered into force on 10 December 2024. Obligations to report certain vulnerabilities and serious incidents began to apply on 11 September 2026, while the main body of requirements will apply from 11 December 2027. These are two distinct stages that should not be confused.
What is the Cyber Resilience Act?
The Cyber Resilience Act is an EU regulation on the cybersecurity of products with digital elements. Its aim is to raise the security level of such products available on the European Union market and reduce situations in which users receive solutions that are vulnerable to attack, improperly secured, or lacking appropriate support.
The regulation covers a broad category of hardware and software products whose intended use or reasonably foreseeable use involves a direct or indirect logical or physical connection to a device or network. This may include both finished products and digital components placed on the market separately.
In practice, this means that the CRA does not apply only to devices associated with the Internet of Things. In the appropriate circumstances, the regulation may also cover software, operating systems, applications, and other digital components offered on the market.
However, the distinction between simply creating software and placing a product on the market is important. Not every software development service, website, or custom-built system is automatically subject to identical obligations. Relevant factors include the nature of the solution, how it is made available, the role of each company, and any exemptions provided for by the rules.
Therefore, the first step should not be to implement every possible procedure without considering whether it is necessary. First, it is important to determine whether a particular product falls within the scope of the CRA and what role the organization in question plays.
Why does the CRA change the approach to software development?
The most important change is that cybersecurity is no longer just a set of activities carried out during deployment or after a problem is discovered. It becomes part of the product's entire lifecycle.
In this model, security should be considered during requirements analysis, architecture design, implementation, testing, release preparation, maintenance, and end-of-support planning. It is not enough to say that an application works correctly. You also need to understand the risks associated with its features, dependencies, update methods, and integrations.
For example, a team may secure its own code properly while using a library in which a vulnerability has been discovered. A product may have a login mechanism but manage permissions improperly. Updates may be available, but without a clearly defined distribution procedure. The company may also not know which product versions remain in use by its customers.
Each of these cases shows that security does not depend solely on developers' skills. It also requires control over dependencies, a process for handling reports, documentation, and responsibility for the product after it has been made available.
The CRA therefore reinforces the direction in which a mature software development process should be heading, regardless of the regulation itself: security must be designed, verified, and maintained, not merely declared.
Who is covered by the rules, and why is it important to determine a company's role?
The CRA places its main obligations on manufacturers of products with digital elements. Under the regulation, a manufacturer is an entity that develops a product or has it developed, and then makes it available on the market under its own name or trademark.
This distinction matters for software houses and technology companies.
If a company develops a system on behalf of a client, that does not automatically mean it will be the manufacturer under the CRA in every case. The specific cooperation model, how the product is made available, and which party acts as the entity responsible for it on the market are all relevant. Nor can it be assumed in advance that responsibility always rests solely with the customer. The situation may differ under certain business models.
It is worth reviewing several typical scenarios:
-
A company developing its own SaaS product or application under its own brand. It should check whether the product falls within the scope of the CRA and whether the way it is made available and its architecture bring it under the regulation.
-
A software house developing a system for a client. It is necessary to determine who will make the solution available on the market, under whose brand, and in what role the parties are acting. The fact that a company wrote the code does not resolve every legal question.
-
A manufacturer integrating components from other suppliers. It may be necessary to analyze not only its own solution, but also its dependencies, how they are updated, and the security information provided by suppliers.
-
A company selling a product under its own brand that was developed by another entity. This model may have different consequences from simply providing a software development service and requires a separate assessment.
-
A supplier of a software component. If the component is made available on the market separately, it may require its own assessment of whether it falls within the scope of the regulation.
This is not a complete list of cases or a formal legal classification. It is intended to show why it is worth starting by mapping products and roles rather than making the general claim that “the CRA applies to all developers.”
The Regulation also provides for exclusions and specific rules, including for certain categories of products regulated by separate legislation and certain cases involving open-source software. However, the details of these exclusions should not be interpreted based solely on a product name or licensing model. The specific circumstances must be analysed.
CRA deadlines: what applies now, and what comes in 2027?
Dates are key when planning regulatory compliance. It is worth distinguishing between the Regulation’s entry into force, the start of reporting obligations, and the start of application of the main body of requirements.
10 December 2024 — the CRA enters into force. The Regulation was adopted and entered into force, but this did not mean that all obligations began to apply at the same time.
11 September 2026 — reporting obligations under Article 14 begin to apply. Manufacturers of products covered by the Regulation must report actively exploited vulnerabilities and serious incidents affecting product security when they become aware of such an event. These obligations have their own deadlines and reporting procedure.
11 December 2027 — the main body of the CRA begins to apply. From this date, the Regulation’s main requirements for products with digital elements will apply, including requirements related to product security, vulnerability handling and conformity assessment procedures, in accordance with the applicable provisions.
An important detail: the reporting obligations that began to apply in September 2026 also cover CRA-regulated products made available on the market before 11 December 2027. Therefore, it should not be assumed that all obligations under the Regulation begin only in December 2027.
There are also transitional provisions, and the situation for products already available on the market may depend on the specific circumstances, including whether a product undergoes a substantial modification after the main body of the Regulation begins to apply. For this reason, dates should be treated as a starting point for analysis, not as a stand-alone answer to questions about a particular company’s obligations.
The primary sources of information are the European Commission’s official summary and its page on reporting under the CRA.
Reporting vulnerabilities and incidents: an obligation that has already begun
One of the most practical aspects of the CRA is the obligation to report certain product security events.
This does not mean reporting every minor defect, every application bug, or every potential vulnerability mentioned in an unverified comment. The provisions identify specific categories of events, including actively exploited vulnerabilities and serious incidents affecting product security.
Put simply, an actively exploited vulnerability is one for which there is credible evidence that it has been exploited by an unauthorised attacker. A serious incident is an event that has a significant impact on product security. Determining whether an event meets the statutory criteria requires consideration of the circumstances and the relevant definitions, not just the team’s intuitive assessment.
For manufacturers subject to the reporting obligation, the main deadlines include:
-
24 hours to submit an early warning from the moment they become aware of an event subject to the obligation;
-
72 hours to submit the main notification;
-
for an actively exploited vulnerability, a final report no later than 14 days after a corrective or mitigating measure has been made available;
-
for a serious incident, a final report within one month of the 72-hour notification.
Deadlines and requirements should be interpreted in accordance with the relevant provisions and current guidance. The summary above should not be treated as complete legal instructions for every case.
Reports are submitted through the EU CRA Single Reporting Platform, operated by ENISA. Under the system’s rules, the manufacturer submits a report through this platform, with the relevant CSIRT and ENISA participating in the subsequent process.
What does this mean operationally? A company should not wait until a problem is detected to decide who will assess its severity, who will decide whether to report it, and where to obtain the information needed to prepare the report.
It is worth having a process in place in advance that covers at least:
-
receiving reports from customers, security researchers and other sources;
-
verifying whether a report concerns a genuine vulnerability or incident;
-
assessing the impact on the product and determining whether the event may be subject to a reporting obligation;
-
identifying the people responsible for technical, organisational and formal decisions;
-
preparing the required information and managing deadlines;
-
developing a patch or other measures to reduce risk;
-
informing the appropriate recipients in accordance with the relevant obligations;
-
documenting actions and drawing lessons after the incident has been resolved.
Not every company needs to build a large security department for this purpose. The scale of the process should match the product’s nature, the risk and the organisation’s structure. However, it must be specific enough to enable swift action in a crisis, rather than requiring the basic rules of responsibility to be worked out from scratch.
Security by design and security by default
Two concepts aptly describe the direction in which the CRA is moving: security by design and security by default.
Security by design means taking security into account from the product design stage. Security by default, in turn, means that the default configuration should support secure use of the solution, rather than requiring users to fix unsafe settings themselves.
In practice, this is not limited to a single feature or a list of controls in an admin panel. It is a set of architectural and implementation decisions that affect the security of the entire product.
Depending on the nature of the solution, it is worth analysing, among other things:
-
authentication and session management;
-
the permissions model and access controls for data;
-
secure storage of secrets and authentication data;
-
protection of data in transit and at rest;
-
update mechanisms and their security;
-
error handling and event logging;
-
reducing the attack surface and disabling unnecessary features;
-
default configuration, including the absence of unsafe initial settings;
-
handling vulnerabilities in both in-house and third-party components.
Not every measure will be needed in the same form for every product. A mobile application requires different solutions from an embedded system, and both differ from a large business platform. Risk analysis should therefore precede the selection of specific mechanisms.
It is also important that security does not end with the code itself. Misconfigured environments, excessive permissions, uncontrolled access to the repository, or an ill-considered update release process can undermine the quality of even a well-designed solution.
Risk analysis and technical documentation
The CRA provides for an approach based on assessing a product’s cybersecurity risks. This analysis should inform decisions concerning the design, development, production, delivery, and maintenance of the solution.
It is worth starting with a few basic questions:
-
What data does the product process, and what would be the consequences if it were disclosed, modified, or became unavailable?
-
Which devices, networks, and external services does the system communicate with?
-
What permissions does the application have, and who can use them?
-
What are the most important technological dependencies?
-
What will happen if one of the dependencies turns out to be vulnerable?
-
How can the manufacturer deliver a patch and verify that it has been applied?
-
What risks remain after security measures have been implemented?
The answers should not exist only in the developers’ heads. Depending on the product and the manufacturer’s obligations, technical documentation will be important. It should show, among other things, what solution was placed on the market, what risks were identified, and how the relevant requirements are being met.
Good documentation is not merely material prepared for an audit. It also helps to develop the system, transfer responsibility between teams, reconstruct architectural decisions, and respond to problems after deployment.
This does not mean that every company should immediately prepare a huge document describing every possible scenario. The scope of the documentation should depend on the type of product and the applicable requirements. The key is for documents to be up to date, consistent with the actual solution, and useful in practice.
Dependencies and external components: securing the entire supply chain
Modern software is rarely built entirely from scratch. It uses libraries, frameworks, off-the-shelf components, database engines, operating systems, and external services. This speeds up development, but also means that product security depends in part on elements the manufacturer does not fully control.
If a vulnerability is discovered in a popular library, the problem may affect many unrelated products. The fact that a library comes from a reputable project does not guarantee that it will remain secure throughout its use.
That is why it is worth knowing the product’s technological composition and being able to determine which components were used, in which versions, and in which parts of the system. Useful measures include dependency management, vulnerability scanning, change logging, and update procedures.
More mature processes also use software component inventories, known as SBOMs (Software Bill of Materials). Such an inventory can make it easier to identify libraries and other elements affected by a newly discovered vulnerability. However, an SBOM alone should not be assumed to ensure compliance with the CRA. It is a tool that supports component management, not a substitute for the entire security process and the documentation required for a particular product.
Relationships with suppliers are also important. A company should know how it receives information about vulnerabilities, who is responsible for updating the components it uses, and how quickly it can respond to a critical issue.
This is especially important in long-lived business systems, where replacing a single library can affect integrations, compatibility, or the stability of the entire solution.
Updates and the product support period
One of the most important issues is maintaining a product after it has been made available on the market. For products covered by the CRA, the manufacturer must define a support period and provide appropriate vulnerability handling throughout that period, in accordance with the regulation’s requirements.
This means that security must be planned not only for the moment the product is launched, but also for the following months and years of its use.
In practice, it is worth determining:
-
who monitors information about new vulnerabilities;
-
how their impact on the product is assessed;
-
who decides whether to prepare a patch;
-
how updates are tested and released;
-
how users or customers are informed;
-
how long the product will be supported;
-
how the end of the support period is communicated.
Predictability is also important. Users should receive clear information about product security and support. Simply stating that the manufacturer “will prepare an update if necessary” does not replace a process that makes it possible to actually address a discovered vulnerability.
Not every update needs to follow the same process. However, the team should be able to distinguish ordinary functional changes from security patches and assess when the risk calls for accelerated action.
From a business perspective, it is also worth remembering that maintaining software costs money. If the sales model does not account for the support period, dependency monitoring, vulnerability response, and patch delivery, the company may promise customers more than it can responsibly provide.
The CRA is therefore not only a topic for the technical team. It can affect the offering, contracts, product pricing, development planning, and how support terms are communicated.
Security testing and the release process for new versions
Product security cannot be reliably confirmed with a single test carried out just before launch. A process is needed to help detect issues as the software develops.
Depending on the type of product and its level of risk, this may include code reviews, static analysis, dependency testing, configuration scanning, dynamic testing, and penetration testing. Automated tools are useful, but their results require interpretation. Not every alert indicates a real threat, and the absence of alerts does not prove that the system is secure.
It is also worth integrating security activities into the CI/CD process, which automates software build, testing, and deployment. This allows selected checks to run regularly, rather than only when someone remembers to run them.
The aim is not to block every change with dozens of uncoordinated checks. It is to select tests based on risk and establish clear rules for what to do when a check detects a problem. The team should know which errors prevent a release, which require further analysis, and who can accept the remaining risk.
The release process should also make it possible to identify a specific product version, reconstruct significant changes, and link a patch to the problem it is intended to resolve. This makes incident analysis easier and helps demonstrate what actions were taken.
In the case of the CRA, the detailed set of required actions depends on the product and the relevant conformity assessment procedure. It is therefore worth treating testing and automation as elements that support compliance with requirements, rather than as a standalone certificate of compliance.
Does the CRA also apply to small businesses and software houses?
An organization’s size should not be the sole criterion for deciding whether the topic is worth examining. What matters is what product the company develops or makes available, what role it plays, and what obligations arise under the regulations.
Small businesses may have fewer resources than large manufacturers, but they also develop digital products, integrate components, and maintain systems used by customers. That is why it is worth starting with measures proportionate to the scale of the business, rather than assuming that preparing for the CRA has to mean launching a costly compliance program from day one.
For a smaller company, a sensible first step may be to draw up a list of products, determine legal roles, identify the most important dependencies, describe the vulnerability handling process, and assign people responsible for security. Only then can the company determine which additional controls, documents, or consultations are actually needed.
At the same time, you should not assume that every smaller entity is exempt from its obligations. The CRA includes specific rules and proportionate arrangements in certain cases, but these cannot be reduced to a general rule that a small business does not need to prepare.
It is also worth distinguishing the manufacturer’s obligations from its customers’ expectations. Even if a given software house is not the manufacturer of a particular product within the meaning of the CRA, a customer may expect information about the components used, vulnerability handling, updates, or technical documentation. Clear agreements reduce the risk that, after implementation, each party will assume that someone else is responsible for security.
How to prepare your company for the CRA: a practical action plan
The best starting point is a plan based on actual products, processes, and responsibilities. The steps below are not a complete list of legal requirements for every case, but they can help organize your preparations.
1. Compile an inventory of digital products. Identify the solutions offered on the market, their intended use, distribution method, and key components. Do not limit the list to products the company is actively developing. Also include versions that are maintained and made available to customers.
2. Determine the company’s role for each product. Check who develops the solution, who commissions its development, under whose brand it is made available, and who is responsible for the product on the market. In an unusual cooperation model, do not base your decision solely on the colloquial name of the service.
3. Verify the scope of the regulation and possible exclusions. For each product, assess whether it falls within the scope of the CRA, which provisions may apply, and whether there are circumstances requiring particular interpretation. If in doubt, consult the European Commission’s current guidance and seek appropriate legal advice.
4. Conduct a risk assessment. Identify the most important threats, data, integrations, dependencies, and potential consequences of an incident. Use this as the basis for determining which safeguards and controls are appropriate for the product.
5. Describe the vulnerability handling process. Determine where reports are received, how they are verified, who assesses their severity, how fixes are produced, and how decisions are documented. The process should also work when a problem arises outside standard working hours.
6. Prepare a reporting procedure. Since the reporting obligations under Article 14 are already being applied, entities subject to these obligations should know the reporting criteria, required deadlines, and how to use the CRA Single Reporting Platform. The internal procedure must make it possible to gather information without undue delay.
7. Review technological dependencies. Check the libraries, frameworks, and other components used by the product. Consider whether the company can quickly determine which versions of its software are exposed to a newly discovered vulnerability.
8. Verify updates and the support period. Determine how security fixes are prepared, tested, and released, and how support terms are communicated. Assess whether the current maintenance model is consistent with commitments to customers and the requirements applicable to the product.
9. Check the documentation. Gather the technical and process information needed to manage security and demonstrate compliance with the relevant requirements. The documentation should reflect the actual product, not just the plan for how it should work.
10. Define responsibilities within the team and in contracts. Specify who is responsible for product security, who makes decisions during an incident, and how the manufacturer, software house, component suppliers, and customer will work together. Ensure that the scope of support and updates is clearly defined.
11. Test your readiness in practice. Rehearse a scenario involving the discovery of a serious vulnerability. Check whether the team can determine the scope of the problem, identify vulnerable versions, make decisions, and prepare a fix. Merely having a procedure in a document does not guarantee that it will work in a real-world incident.
12. Monitor current guidance. Details of CRA implementation are being developed in European Commission materials, and the regulation includes mechanisms and requirements that must be interpreted in the context of the specific product. It is worth checking official publications regularly and updating the preparation plan.
The most common preparation mistakes
The first mistake is putting the issue off until the end of 2027. This overlooks the fact that reporting obligations for certain events have already begun, and that preparing security processes may require organizational, technical, and contractual changes.
The second mistake is assuming that the CRA applies only to hardware manufacturers. The regulation also covers relevant categories of software and digital components, although its scope must be assessed in relation to the specific product.
The third mistake is assuming that buying a vulnerability scanning tool is enough. A tool can help detect issues, but it cannot replace risk assessment, accountability for decisions, the update process, handling reports, or the required documentation.
The fourth mistake is treating compliance as a one-off project. Products change over time, new vulnerabilities emerge, components are updated, and the way a solution is used may evolve. The security process must take this dynamic into account.
The fifth mistake is failing to clearly divide responsibilities between the manufacturer, contractor, and customer. Contracts and team practices should make clear who monitors vulnerabilities, prepares fixes, communicates issues, and makes decisions.
The sixth mistake is creating documentation that does not reflect the actual state of the product. A document describing an architecture from several years ago, an outdated list of components, or a procedure no one knows about will not provide a sound basis for responding to incidents.
CRA as an impetus to bring order to the software development process
New regulatory requirements may be seen as an additional obligation, but preparing for the CRA also offers an opportunity to review how a company manages the security of its products.
Is it known which components make up the system? Can the team quickly determine which versions require a fix? Is there a clearly defined process for security updates? Does the customer know how long the product will be supported? In the event of an incident, is it clear who makes decisions and what actions need to be taken?
If the answers to these questions are unclear, the problem does not start with the regulation. The CRA simply increases the importance of areas that have already affected product security, maintainability, and reliability.
Mature software development is not about promising that bugs will never occur. It is about reducing risk, detecting problems quickly, responding responsibly, and keeping the product in a state that meets its intended purpose and the manufacturer's obligations.
What is worth doing now?
You do not need to implement every possible procedure at once. Start by listing your products, identifying the roles of your organization, checking whether the CRA applies, and verifying that basic vulnerability and incident management processes are in place. This is especially urgent for entities that are already subject to reporting obligations.
The next step is to analyze risks, dependencies, updates, support periods, and documentation. Only then can you plan specific technological and organizational changes, and assess whether additional legal advice or a specialist conformity assessment is needed.
The Cyber Resilience Act should not be reduced to a single date on the calendar. This regulation strengthens the approach to cybersecurity throughout the entire life cycle of a digital product. The sooner a company understands which product and role its situation concerns, the easier it will be to prepare a proportionate, practical action plan.
Important: This article is for informational purposes only and does not constitute legal advice or a formal conformity assessment. The scope of obligations should be determined based on the full text of the regulation, current guidance, and the circumstances of the specific product.
Sources and further reading
-
European Commission: Cyber Resilience Act - summary of the rules
-
European Commission: Cyber Resilience Act - manufacturers' obligations
-
European Commission: Cyber Resilience Act - reporting obligations
