Cyber Resilience Act - Your Buggy Product Is About to Disappear from the EU Market

A bug among the bugs

Imagine the following. A Polish company — with a regional capital in its name — makes LTE routers. A complete business: electronics design, its own firmware, assembly in Poland, distribution to wholesale operators and retail customers across the EU. Sales of twenty-odd million euros a year, four hundred employees, an ISO 9001 certificate hanging in the corridor between the front office and the server room.

One morning, in the third quarter of 2027, an inspector from the Office of Electronic Communications (UKE) walks into the company's headquarters with two administrative decisions. The first — a ban on placing the flagship router model on the market. The second — an order to recall the one hundred and eighty thousand units sold over the previous sixteen months. The reason? Failure to meet the essential requirements of Annex I to Regulation (EU) 2024/2847 — the Cyber Resilience Act. Specifically: no vulnerability handling process, no SBOM, no guarantee of security updates for a period matching the product's expected lifetime, failure to meet the "secure by default" requirement, and no declaration of conformity covering cybersecurity. The fine — up to 2.5% of global annual turnover or EUR 15 million, whichever is higher.

Does that sound like a worst-case scenario? After 11 December 2027 it will be routine. And it applies not only to routers — it applies to every Bluetooth door handle, every smart thermometer, every SaaS application for accountants, every cash register with a Wi-Fi module and every PLC controller your company manufactures, imports or distributes under its own brand. The Cyber Resilience Act — the EU regulation that entered into force on 10 December 2024 and applies in full from December 2027 — rebuilds the entire liability regime for digital products.

What exactly the CRA regulates

The CRA regime imposes harmonised cybersecurity requirements on "products with digital elements" — PDEs for short. The definition is deliberately broad: any hardware or software product whose intended use involves direct or indirect data communication with another device or a network. Put more simply: anything with "a chip and Wi-Fi", and also pure code — software placed on the market as a product, including SaaS in its on-premise variant and commercially distributed mobile applications.

Excluded from scope are: medical devices covered by the MDR and IVDR regulations, vehicles subject to Regulation (EU) 2019/2144, certain aircraft, defence and nuclear products, selected goods covered by sectoral transport legislation, and free and open source software distributed outside the course of a commercial activity. Everything else — from a cash register, through a smart thermostat, to an on-premise ERP system — falls under the CRA.

The Regulation divides products with digital elements into four risk categories. The default one — a typical consumer product — requires self-assessment of conformity with the essential requirements of Annex I. Important Class I and II covers products whose compromise may lead to greater harm: password managers, antivirus software, identity authentication systems, class A smart home devices, PLC controllers, industrial routers, CCTV monitoring. Here, verification by a notified body is required for selected aspects (Class II) or the application of harmonised standards (Class I). The "critical" category — products whose failure may have far-reaching consequences for public safety, including enterprise-class cryptographic modules and certain public key infrastructure components — will be covered by dedicated certification schemes within the meaning of the Cybersecurity Act.

Every product — before it reaches the market after 11 December 2027 — must have a CE declaration of conformity in which the manufacturer states that it meets CRA requirements. This is the same mechanism most manufacturers know from the EMC and Low Voltage directives, only enriched with a new area — cybersecurity — and with a third, hitherto unknown component: "bug-related" notification to ENISA.

Essential requirements — what a product must have

Annex I to the CRA consists of two parts. Part one describes the cybersecurity properties of the product itself, which the manufacturer must document and declare. Part two describes the vulnerability handling process, which the manufacturer must maintain throughout the expected lifetime of the product, with a lower limit of five years from the last time the model was placed on the market, however short a commercial cycle the manufacturer may have planned.

From part one, the most significant are: supplying the product free of known exploitable vulnerabilities at the moment it is placed on the market; a default configuration that is "secure by default" — no factory passwords such as admin/admin, no open ports that are not essential, no unnecessary services; protection of the confidentiality and integrity of data processed and transmitted using state-of-the-art cryptographic mechanisms; authentication and access control, including multi-factor authentication wherever that makes functional sense; logging of security events in a way that lets the user monitor and analyse them after the fact; and mechanisms for automatic security updates delivered to the user free of charge for the expected lifetime of the product.

From part two, two obligations are key — and they dispel any last illusion among Polish manufacturers that the CRA is a "paper regulation". First, the obligation to create and maintain a software bill of materials — SBOM — in a machine-readable format. Without an SBOM there is no management of third-party vulnerabilities: if a manufacturer does not know which libraries it uses, it also does not know where the next CVE will land. Second, a coordinated vulnerability disclosure process (CVD/VDP): a published policy in which every security researcher finds a contact channel, response timeframes, embargo rules and the manufacturer's commitment to publish a patch within a defined period.

Three clocks that started on 11 December 2024

Three separate clocks have been running since the Regulation entered into force. Ignoring them will be costly — and each of them triggers different obligations.

The first — the reporting clock. From 11 September 2026, every manufacturer is obliged to report to ENISA, through a new single reporting platform, actively exploited vulnerabilities — those the manufacturer knows are being used against users at that moment — and severe incidents affecting the product. The reporting regime has three stages and will be familiar to anyone who has worked with the GDPR and NIS-2: an early warning within 24 hours of becoming aware, a full notification within 72 hours, and a final report within 14 days. Missing these deadlines is a self-standing basis for an administrative fine.

The second — the product conformity clock. From 11 December 2027, every new product with digital elements placed on the EU market must meet the essential requirements of Annex I and carry a CE declaration of conformity covering the CRA. Products "in transit" (already placed on the market earlier) benefit from a limited transitional period, but every new version, every substantial modification and every new SKU starts again from scratch, under the full regime.

The third — the lifecycle clock. The manufacturer must supply free security updates for a period matching the expected lifetime of the product, and in no case shorter than five years from the last placing of that model on the market. For manufacturers who built their business around "two-year generations", this is a fundamental change to the financial model.

Eighty per cent — not a statistic, a Polish problem

Our conversations with Polish hardware and software manufacturers in the second half of 2025 and the first quarter of 2026 paint a picture that Fib.Code watches with growing concern. Of the roughly two hundred companies identified as PDE-relevant — makers of IoT devices, automation, application software and networking equipment — with which we held diagnostic conversations, more than 80% have no vulnerability handling process at all, more than 70% have never produced an SBOM, more than 60% have no CVD channel, and almost half of the board members surveyed do not even recognise the abbreviation CRA. What is more, among companies implementing ISO/IEC 27001 or already holding the certificate, the figures look much the same. Because 27001 covers the organisation, not the product.

This is not negligence. It is the effect of an information lag. The CRA has no Polish implementing act, because it does not need one — an EU regulation applies directly. So there is no government campaign, no parliamentary debate, no programme about it on national radio. It is quiet — and that silence comes back to haunt the product calendar, in which the date 11 December 2027 looks like "the distant future". In reality it means that by the end of 2026 you need a ready process, the documentation and a designed update pipeline — because a product going to market in 2027 is being created and designed today.

Fines — modelled on the GDPR, calculated on global turnover

The sanctions system is copied from the mechanics familiar from the General Data Protection Regulation. Breach of the essential requirements of Annex I — up to EUR 15 million or 2.5% of global annual turnover, whichever is higher. Breach of the remaining obligations (reporting, CE marking, technical documentation) — up to EUR 10 million or 2% of turnover. Misleading a market surveillance authority — up to EUR 5 million or 1% of turnover.

Importantly, the fines are imposed by the market surveillance authorities of individual member states. In Poland's case this will most likely be the Office of Electronic Communications, although discussion continues about the role of the Office of Competition and Consumer Protection and the Cybersecurity Department of the Ministry of the Interior and Administration. Whatever the final division of competences, an administrative fine is not the only risk. Alongside it come decisions to recall the product, decisions banning it from the market, and the dramatic reputational risk arising from the product being entered in the Safety Gate database (formerly RAPEX) and the non-compliance being published.

For context: one Western European manufacturer that was caught out by the Batteries Regulation in 2025 paid a five-figure fine in euros but lost two wholesale contracts worth eight figures. The pattern will repeat itself.

The CRA, NIS-2 and the GDPR — a knot that cannot be untied strand by strand

A manufacturer producing routers for a telecoms operator falls under the CRA — as the manufacturer of a product with digital elements — and under NIS-2 at the same time, as part of an essential entity's supply chain. And if the product processes user data, it also falls under the GDPR, as an entity designing a tool that affects personal data protection within the meaning of Article 25 (privacy by design). The same applies to makers of software for local authorities, video surveillance equipment, telemedicine devices outside the scope of the MDR, and ERP systems.

In practice this means that CRA technical documentation, NIS-2 security policies and the GDPR record of processing activities must be consistent, not competing. Implementing the CRA "alongside" an existing information security management system is a diplomatic way of describing doubled costs and a doubled risk of error. We wrote about integrating NIS-2 and the GDPR into a single security system in our article on the amendment to the Polish NIS-2 implementing act (the KSC Act) — the CRA adds a third layer, but the logic of integration is the same: one risk analysis methodology, one set of policies, one management board signing off on all of it.

Nine steps to CRA readiness

Based on the projects Fib.Code is currently running with manufacturers in three EU countries, we have worked out a sequence we recommend to every management board for which the CRA still sounds abstract. The order of the steps matters.

Step one — product qualification. Is the product a PDE within the meaning of the CRA? Which risk category — default, important class I, important class II, critical? Do any sectoral exclusions apply? This is a one-page document, but without it all the work that follows may turn out to be compliance with the wrong regime.

Step two — gap analysis against Annex I. A list of all the essential requirements set against the current state of the product and its processes. What is already there, what has to be built, what has to be redesigned. This is usually where the scale of the work becomes apparent — and where it emerges that the key gaps are not in the code but in the procedures.

Step three — SBOM and dependency inventory. Choosing a format (CycloneDX, SPDX), configuring tools for automatic generation, wiring it into the CI/CD pipeline, correlating it with CVE databases. Without an SBOM, no vulnerability management process will work beyond a team of five.

Step four — the CVD/VDP process. A coordinated vulnerability disclosure policy: a security@ channel, a PGP key, framework rules, declared SLAs, integration with a ticketing system. This is one of those elements best written once, published, and then left for the researcher community to audit free of charge.

Step five — Secure Development Lifecycle (SDL). Secure software development practices integrated into the existing engineering process: threat modelling early in design, static and dynamic code analysis, penetration testing before release, security-focused code review. ISO/IEC 27034 — a standard worth looking at — does not replace 27001, but complements it in an area 27001 does not cover deeply enough.

Step six — the update pipeline. A mechanism for distributing security patches, ideally automatic and cryptographically signed, that solves the problem which almost always comes back: how to deliver a patch to a device you sold to a customer a year ago and with which you have no permanent communication channel. This is where public keys, firmware signing, secure bootloaders and OTA return, depending on the type of product.

Step seven — technical documentation and declaration of conformity. A pack that must be maintained for ten years from the product being placed on the market and be available to the supervisory authority at any moment. Risk analysis, test results, design diagrams, a user manual with security elements, the CE declaration of conformity.

Step eight — reporting procedures. The decision path from the first signal of a vulnerability or an incident to notification to ENISA — within 24 hours. This requires a defined role (security officer, PSIRT — Product Security Incident Response Team), an on-call procedure, ready-made notification templates and a rehearsal. Without one full-scale tabletop exercise, the first real incident will end in the 24-hour window being missed.

Step nine — training and culture. Engineers, product managers, support, the legal department, the marketing department — everyone has to understand what a vulnerability is, why a patch must not be published without coordinating with the person who reported it, and why marketing materials cannot promise "100% security". This is a culture that is not bought with an e-learning course but built over a year or more.

The 30/60/90-day plan — what you can get done in a quarter

A manufacturer who starts work today, in April 2026, and finishes in the third quarter of 2026 will not only make the September ENISA reporting deadlines but will also gain a buffer ahead of December 2027.

In the first thirty days — product qualification, gap analysis, dependency mapping, choice of SBOM format, and an estimate of the budget and competence gap. A phase of intensive diagnostic work.

In the next thirty — a published CVD policy, a working security@ channel, the first version of the SBOM in the pipeline, preliminary technical documentation, a designed incident reporting path. The phase in which progress starts to show in the tools and procedures.

In the final thirty — an incident tabletop exercise carried out, SDL changes implemented, the first full declaration of conformity for a reference product, a training plan for the team, a roll-out plan for the remaining SKUs. After day ninety the organisation knows what it will cost to reach 11 December 2027 — and can present that in numbers to the board, to B2B customers and to any prospective investor.

Why choose Fib.Code for a CRA implementation

The CRA is not a single regulation that can be handled with a template. It weaves together at least four layers — product, process, organisational and legal — each of which calls for a different competence. A security engineer has to understand threat modelling, applied cryptography and SBOMs. An ISO consultant — how to embed SDL in an existing quality management system. A lawyer — how to draft the declaration of conformity and the user manual with minimum legal risk. An information security officer — how to tie the CRA together with NIS-2 and the GDPR in a single risk register.

The Fib.Code team has worked with this tangle since 2023, combining legal advice for manufacturers within the scope of the CRA with engineering work — first on pilot projects with networking equipment manufacturers, then on production implementations in three EU countries. Our approach follows three principles. First, the CRA is implemented for a product, not for a company — which is why the first decision always concerns the choice of a pilot product on which we test the processes before transferring them to the remaining SKUs. Second, documentation is produced in equity mode, not compliance mode — it builds value for the customer and for the investor, rather than merely satisfying an auditor. Third, integration with the existing ISMS is mandatory — because without it the organisation acquires a parallel regime that becomes a burden to itself within six months.

The result of that collaboration is a pack you can show to a B2B customer in a tender, to a supervisory authority during an inspection and to an investor in due diligence: documented CRA compliance, a single CE declaration, a working vulnerability handling process, completed training, a synchronised risk register. All of it consistent with the existing information security management system — or, if there is none, built from the ground up at the same time.

What to do this week — a manufacturer's checklist

One thing. An internal email to the CTO, the production director, the information security officer and legal counsel, in which the board asks four questions. First — are our products PDEs within the meaning of the CRA? Second — which of them qualifies as the pilot? Third — who here is responsible for the vulnerability handling process? Fourth — do we have an SBOM? If the answer to any of those four questions is "I don't know" or "we don't", you have twenty-one months left; it is time to start.

Fib.Code will gladly take a seat at that table. We start with a one-hour diagnostic conversation in which we can pinpoint where you stand today — and how far you are from the point at which the CRA turns from a barrier to entry into a competitive advantage in EU tenders and on export markets.

Get in touch: l.grabowski@fibcode.com | fibcode.com/en/contact. We have written on related topics in Shadow AI — the invisible employee who carries company data out every day, The AI Act and information security — what the new regulations have in common and The 2026 KSC Act amendment — what you need to know after 3 April — the CRA is directly interwoven with each of them.