Cyber Resilience Act: what changes for anyone selling digital products

The Cyber Resilience Act (Regulation (EU) 2024/2847, CRA for short) is the first European law imposing cybersecurity requirements on "products with digital elements" sold in the European Union — in other words, practically anything that contains software or connects to a network. It entered into force on 10 December 2024, but the main obligations only become operative from 11 December 2027.

It's being talked about now precisely because there's a transition window: those who design and sell digital products have time to adapt, but some intermediate deadlines (such as the notification obligations) already arrive in 2026.

GiBSeS — Understanding whether and how the CRA affects you is the first diagnosis we do with SMEs that develop connected products.

It's any hardware or software product whose intended use involves a connection — direct or indirect, logical or physical — to a device or network. In practice this covers connected objects (IP cameras, routers, smart appliances, industrial sensors, IoT devices), but also software sold on its own (applications, operating systems, libraries, firmware).

Also included are remote data processing solutions necessary for the product to function (for example, the cloud component of a device). Excluded, on the other hand, are products already covered by specific sector-specific rules, such as many medical devices, automotive and aviation.

GiBSeS — Often the trickiest point is understanding where your product ends and a service begins: it's a distinction we help map out from the very start.

The CRA applies to anyone placing products with digital elements on the EU market, with different obligations depending on the role: manufacturers (those who design or make the product, or have it designed/manufactured under their own brand) have the most stringent obligations; importers (those who bring products from non-EU companies into the EU) must verify that the manufacturer has done its part; distributors must act with due diligence within the supply chain.

Even if you resell under your own brand a product manufactured by someone else, in the eyes of the regulation you become the "manufacturer". It's worth clarifying your role before assuming the obligation belongs to someone else.

GiBSeS — Precisely defining your role in the chain — manufacturer, importer or distributor — radically changes the list of requirements, and that's where we start.

Yes. The CRA explicitly covers software placed on the market as a standalone product, not just software embedded in a device. This includes applications, operating systems, firmware, libraries and software components sold separately.

What matters is that the product is made available on the EU market in the course of a commercial activity. The way it's distributed (download, licence, subscription) doesn't exempt you from the obligations.

GiBSeS — For a software house, the "security by design" requirements and vulnerability handling directly affect the development cycle: this is an adjustment worth planning, not improvising.

At the heart of the CRA are two families of obligations. First, "security by design": the product must be designed, developed and produced to ensure an appropriate level of cybersecurity, based on a risk assessment (for example: secure default configuration, data protection, reduced attack surface).

Second, vulnerability handling throughout the product's lifecycle: identifying and fixing vulnerabilities promptly, distributing security updates (free of charge and, where possible, automatic), maintaining a software bill of materials (SBOM) and a coordinated vulnerability disclosure policy. On top of this come technical documentation, the declaration of conformity and CE marking.

GiBSeS — Translating these principles into concrete processes inside a company without a dedicated security department is exactly the kind of operational work we support SMEs with.

The manufacturer must handle vulnerabilities and provide security updates for the entire "support period", which must reflect how long the product is reasonably expected to be used. As a rule this period should not be shorter than five years; if the product is intended for shorter use, the period can be shorter, but it must be clearly communicated.

The support period must be made known to the purchaser in an understandable way at the time of purchase. This has a real economic impact, because it commits you to maintaining development and security resources for years.

GiBSeS — Sizing the support period is as much a technical choice as an economic-financial one: it's a balance we help evaluate with the numbers in hand, without over-committing.

Yes, but with an important clarification: the obligation doesn't cover every vulnerability, but actively exploited vulnerabilities and severe incidents that impact the product's security. In these cases the manufacturer must trigger a notification within very tight timeframes.

The timeline requires an "early warning" without undue delay and in any case within 24 hours of becoming aware of the issue, followed by a more complete notification within 72 hours, and finally a final report. So you need an internal procedure ready in advance that kicks in automatically when something happens.

GiBSeS — Having a notification procedure ready that meets the 24- and 72-hour deadlines before it's actually needed is one of the most underrated preparations: better to test it cold.

Notifications go through a single coordinated reporting platform at European level, involving ENISA (the European Union Agency for Cybersecurity) and the national CSIRTs designated as points of contact. In essence, you report through the national channel and the information is routed to the competent parties.

The operational details (which portal, which national authorities) are defined at the level of each Member State and through implementing acts, so it's worth checking the specific channel for your country once the obligations become operative.

GiBSeS — Identifying the correct channel for your country in advance, rather than discovering it during an incident, is part of the preparation we set up together.

The regulation entered into force on 10 December 2024, but its application is staggered. The main obligations — security requirements, CE marking, declaration of conformity — apply from 11 December 2027. Before this date, however, some obligations kick in earlier.

In particular, the obligations to notify actively exploited vulnerabilities and severe incidents apply from an earlier date in 2026 (around September 2026), while the provisions on conformity assessment bodies start a few months earlier. Since some exact dates may be specified by implementing acts, it's worth checking them against official sources as the deadlines approach.

GiBSeS — Building a roadmap that starts from the earlier 2026 deadlines rather than 2027 avoids arriving late: it's the first thing we focus on together.

Yes, and it's a point many people miss. Even though most of the CRA becomes operative at the end of 2027, the obligations to notify actively exploited vulnerabilities and severe incidents apply earlier, during 2026. This means you'll need to be ready to report certain events months before having to meet the product's full technical requirements.

This is a deliberate choice by the legislator: securing the flow of information on real threats even before the whole compliance apparatus is fully up and running. The exact date of this intermediate deadline needs to be confirmed against official sources, but the logic that "notification comes first" is certain.

GiBSeS — Distinguishing what's already needed in 2026 from what you can prepare calmly for 2027 is exactly the kind of prioritisation we help put in order.

Yes: the CRA introduces CE marking for products with digital elements as well, software included. The CE marking indicates that the product complies with the requirements of the regulation and, for software, can be affixed in digital form (for example in the documentation or on the interface) when physical affixing isn't possible.

The EU declaration of conformity is the document with which the manufacturer states, under its own responsibility, that the product meets the applicable requirements. It must be drawn up, kept available to the authorities, and accompanied by the technical documentation that shows how you achieved that conformity.

GiBSeS — Preparing solid technical documentation and a defensible declaration is less trivial than it sounds: it's a methodical piece of work you set up once and reuse for every product.

It depends on the product's risk category. For the vast majority of products with digital elements, self-assessment of conformity by the manufacturer is sufficient. For the more sensitive categories — which the CRA calls "important" and "critical" products (for example password managers, firewalls, VPNs, operating systems, some security devices) — more rigorous procedures apply, which in some cases involve a third-party conformity assessment body or the adoption of European certification schemes.

It's therefore essential to correctly classify your product from the outset, because the compliance path's burden depends on it.

GiBSeS — Product classification is a fork in the road that determines costs and timelines: checking it early, before investing in development, is one of the most useful diagnoses.

The CRA splits products according to risk. The base category is subject to self-assessment. "Important" products (listed in the regulation and split into two classes) perform functions relevant to security — think browsers, password managers, operating systems, routers, firewalls, antivirus software — and require more demanding conformity procedures. "Critical" products are those with the most security-sensitive function for the entire chain and may be subject to mandatory European certification.

The lists of these categories can be updated over time by the Commission, so it's worth rechecking them periodically.

GiBSeS — Knowing which tier your product falls into today — and monitoring whether the lists change — is part of the ongoing oversight we help maintain.

Free and open source software developed or supplied outside the course of a commercial activity is, broadly speaking, excluded from the CRA's obligations: a non-profit community project isn't treated as a commercial manufacturer. The situation changes when the open source component is integrated into a commercial product and placed on the market: in that case responsibility falls on whoever markets the finished product.

The regulation also introduces an intermediate figure, the "open source software steward" (organisations that structurally support the development of open source used in commercial contexts), with lighter, proportionate obligations compared with actual manufacturers.

GiBSeS — If your product relies on open source components, understanding who answers for what along the chain is a knot we untangle before it becomes a problem.

As an importer you can only place products that comply with the CRA on the EU market. You must verify that the non-EU manufacturer has carried out the conformity assessment, drawn up the technical documentation, affixed the CE marking and provided the instructions. You must also make sure the manufacturer's contact details and your own are indicated.

If you have reason to believe a product isn't compliant, you cannot place it on the market; and if you discover a risk afterwards, you must take action and inform the authorities. In practice you become a filter of responsibility between the foreign manufacturer and the European market.

GiBSeS — Setting up a checklist for vetting non-EU suppliers protects you from products you'd end up having to defend yourself: it's a control worth structuring.

Yes, even though your obligations are lighter than the manufacturer's. As a distributor you must act with due diligence: verify that the product bears the CE marking, that it's accompanied by the required documentation and instructions, and that the manufacturer and importer have met their obligations.

You cannot make available on the market a product you know, or should know, is non-compliant, and if you become aware of a risk you must cooperate and inform the parties upstream and, if necessary, the authorities.

GiBSeS — Even "light" diligence needs clear criteria for what to check: defining them once spares you disputes case by case.

Market surveillance authorities can order corrective measures, impose the withdrawal or recall of the product, and prohibit or restrict its being made available on the EU market. Besides reputational damage, there are financial penalties that can be very significant.

So the risk isn't just the fine: it's the real possibility of having to pull the product from the market, with the economic impact that has on revenue and customers. Surveillance decisions are entrusted to the national authorities of the Member States.

GiBSeS — Assessing the real exposure — not just the theoretical fine but the risk of market withdrawal — is the kind of risk/benefit analysis we start from before any decision.

The regulation sets high maximum caps. For violations of the essential security requirements and the manufacturer's main obligations, penalties can reach up to EUR 15 million or 2.5% of total worldwide annual turnover, whichever is higher. For violations of other obligations, the cap is EUR 10 million or 2% of turnover; for inaccurate or misleading information provided to the authorities, up to EUR 5 million or 1%.

These are maximum amounts: the actual penalty is decided by the national authorities, who must take into account the severity, duration, and also the size of the company, with specific attention to SMEs and microenterprises. The exact amounts applicable in your country therefore depend on the competent authorities.

GiBSeS — The caps are striking, but the useful question is how exposed you actually are: sizing the real risk against your own situation is more concrete than looking at the maximum figure.

They deal with different but complementary things. The CRA regulates product security: whoever designs and sells hardware and software must make it secure and keep it that way. The NIS2 directive, instead, regulates the security of organisations and their processes: it imposes cyber risk management measures on entities operating in sectors considered essential or important.

In short: the CRA looks at the product you place on the market, NIS2 looks at how your organisation manages security. A company can fall under both, for different aspects.

GiBSeS — Understanding which regulation affects you and why avoids both duplication and compliance gaps: it's a mapping exercise we carry out in an integrated way.

Both can apply, but on different planes. The AI Act governs the risks linked to artificial intelligence systems (transparency, risk management, obligations for high-risk systems); the CRA governs the cybersecurity of the product with digital elements. A connected AI product may therefore need to meet both the CRA's security requirements and, at the same time, the AI Act's obligations.

The legislator has tried to coordinate the two regulations to avoid duplication, but in practice a combined case-by-case reading is needed to understand which requirements apply to your specific product.

GiBSeS — Reading the AI Act and the CRA together without doing the same work twice is a real advantage when an independent advisor coordinates both fronts.

Generally speaking, the CRA applies to products placed on the market after the date the main obligations apply. There are, however, transitional rules and specific points of attention for products already on the market that are substantially modified after that date, or regarding the documentation to be maintained.

The vulnerability handling and notification obligations are also tied to the product's lifecycle, so it's not advisable to assume your existing product range is entirely out of scope. The dates and transitional details need to be checked against the official text based on your specific situation.

GiBSeS — Taking inventory of what you already have on the market and understanding what needs attention is a practical step that often reveals surprises: better to get ahead of it.

There's no single figure: it depends on the product's complexity, its risk category, how much security is already built into your development process, and the support period you'll have to guarantee. The main costs are generally adapting development processes (security by design, SBOM, vulnerability handling), technical documentation and, for higher-risk products, possible third-party involvement.

The good news is that much of this is "one-off" work on processes, which is then reused across all products. For an SME, the costliest mistake is tackling it at the last minute or over-sizing it relative to the actual risk.

GiBSeS — Sizing the investment to the actual risk — without under-complying or over-engineering — is how we approach compliance: analysis first, then spending.

Three concrete steps. First, take inventory: list the products with digital elements you place on the EU market and establish your role for each (manufacturer, importer, distributor). Second, classify the risk: check whether you fall into the base, "important" or "critical" category, because this determines how burdensome the path will be. Third, assess the gap: compare your current development, vulnerability handling and documentation processes against what the CRA requires.

From here you build a roadmap that takes into account the earlier 2026 deadlines (notifications) and the main 2027 ones. The goal isn't to do everything at once, but to do the right things in the right order.

GiBSeS — This inventory-classification-gap analysis is exactly the starting diagnosis we carry out with manufacturing SMEs, independently and without tying you to any particular technology or supplier.

Yes. The Cyber Resilience Act (Reg. (EU) 2024/2847) follows a market-based logic, not a residence-based one: it applies to anyone placing a "product with digital elements" (connectable hardware or software) on the Union market, regardless of where the manufacturer is based. If your IoT device, your app, your firmware or your library is sold or made available in the EU, you are a manufacturer within the meaning of the regulation and must meet its obligations.

There's no turnover or volume threshold that exempts you as a foreign company: what counts is the very fact of marketing in Europe.

GiBSeS — GiBSeS helps non-EU companies understand, before they invest, whether and how the CRA affects their product on the European market.

The CRA doesn't require a non-EU manufacturer to appoint an authorised representative: the appointment is optional, formalised through a written mandate, which lets you delegate to a party established in the EU certain tasks such as keeping the technical documentation available and cooperating with the authorities.

The party that is instead almost always essential is the importer established in the EU, because without a European entity placing the product on the market, many obligations remain effectively impossible to fulfil. In practice an authorised representative can simplify dealings with surveillance authorities, but the choice needs to be assessed case by case.

GiBSeS — GiBSeS helps you decide whether an EU authorised representative is worthwhile or whether relying on the importer is enough, without tying you to a heavier structure than necessary.

Primary responsibility stays with the manufacturer, even if based outside the EU: cybersecurity risk assessment, compliance with the essential requirements, technical documentation, declaration of conformity, vulnerability handling.

The importer established in the EU has a checking role: it can only place compliant products on the market and must verify that the manufacturer has carried out the conformity assessment, that the product bears the CE marking and is accompanied by the declaration of conformity and instructions. The distributor, further downstream, must act with due diligence and verify the presence of the marking and documents.

If the importer or distributor substantially modifies the product or sells it under its own brand, it can take on the manufacturer's obligations.

GiBSeS — GiBSeS helps map out who does what along your European sales chain, so responsibilities are clear before you sign agreements with importers.

Yes. To be placed on the EU market, the product with digital elements must bear the CE marking, which certifies compliance with the CRA's requirements (as well as any other applicable regulations). The marking must be accompanied by the EU declaration of conformity, drawn up and signed by the manufacturer, who takes responsibility for it.

Where the product is designed or manufactured is irrelevant: what matters is that, before being marketed in Europe, the appropriate conformity assessment, the technical documentation and the affixing of the marking have all been completed.

GiBSeS — GiBSeS supports non-EU companies through the path to CRA CE marking, from assessing requirements to the declaration of conformity.

Yes, that's one of the possible scenarios. Market surveillance authorities and customs authorities can intervene on non-compliant products: suspending their placing on the market, imposing withdrawal or recall from the market, prohibiting or restricting their availability and, in the event of significant risk, stopping goods at the border.

Beyond the physical blocking of products, the CRA provides for administrative penalties which, for the most serious violations, can reach substantial amounts (up to millions of euros or a percentage of worldwide annual turnover). For a foreign company, the biggest damage is often the sudden loss of access to the European market.

GiBSeS — GiBSeS helps prevent border stoppages by identifying in advance the non-conformities that EU authorities look for.

Yes. The CRA requires the manufacturer, wherever it's based, to handle vulnerabilities for the entire support period of the product: providing security updates, maintaining a coordinated disclosure policy, and providing a software bill of materials (SBOM) to the authorities on request.

There's also a notification obligation: actively exploited vulnerabilities and severe incidents must be reported through the single European notification platform, with strict timeframes (an initial early warning within 24 hours, followed by more detailed notifications). These obligations follow the product, not the manufacturer's place of residence, and are among the first to become applicable.

GiBSeS — GiBSeS helps set up vulnerability handling and notification processes compatible with EU deadlines, even when operating from outside Europe.

The regulation is already in force, but the obligations kick in on a staggered basis. The obligations to report exploited vulnerabilities and severe incidents apply first (starting from September 2026), while the bulk of the product obligations - essential requirements, CE marking, conformity assessment - become fully applicable starting from December 2027.

For a non-EU company this is precious lead time: secure design, documentation, and any involvement of a notified body take months. It's worth treating these dates as project milestones, not distant deadlines.

GiBSeS — GiBSeS helps build a realistic roadmap toward the CRA deadlines, so you're not shut out of the EU market at the last moment.

Generally, yes. The CRA covers "products with digital elements", a category that includes standalone distributed software - applications, firmware, libraries, components - when made available on the EU market, even free of charge in the course of a commercial activity.

There are, however, exclusions and special regimes: some services (for example pure SaaS services) fall instead under other regulations such as the NIS2 directive, and some product categories already regulated by sector-specific rules follow their own regime. The dividing line depends on how the product is distributed and integrated, so it needs to be checked against the specific case.

GiBSeS — GiBSeS helps non-EU software vendors understand whether they fall under the CRA, NIS2, or both, before opening the European channel.

The CRA distinguishes between "default" products, for which self-assessment of conformity is normally allowed, and "important" and "critical" product categories listed in the regulation's annexes, for which more rigorous procedures are required - up to the possible involvement of a notified body or the use of dedicated certification schemes.

Products such as password managers, firewalls, operating systems, and network identity and security components fall into the higher-risk categories. Determining the correct category is the first fork in the road: it radically changes costs, timelines and the compliance path.

GiBSeS — GiBSeS helps correctly classify the product within the CRA categories, so the non-EU company sizes its compliance effort to the actual level of risk.

The starting point is to understand whether and how the regulation affects you: verify that the product is a "product with digital elements" sold in the EU, identify its category (default, important or critical) and identify the parties in your European chain, in particular the importer.

From there you build the path: analysis of the essential cybersecurity requirements, risk assessment, preparation of the technical documentation and the declaration of conformity, setting up vulnerability handling and notification processes, and finally CE marking. For a non-EU company it's useful to set all this up as a market-access project, prioritising the nearest deadlines.

GiBSeS — GiBSeS supports non-EU SMEs from the initial analysis all the way to CE marking, as an independent advisor that opens the door to the European market without tying you to a single supplier.