Cyber Resilience Act:
CE marking for software,
deadlines and impact on SMEs

What the Cyber Resilience Act is

The Cyber Resilience Act is EU Regulation 2024/2847, published in the Official Journal of the European Union on 20 November 2024 and formally entered into force on 10 December 2024. For the first time the EU introduces mandatory security requirements for all "products with digital elements" (PDEs) placed on the European market: stand-alone software, operating systems, firmware, consumer and industrial IoT devices, network equipment, cryptographic hardware, security solutions. It is the missing piece of the EU cybersecurity regulatory mosaic: it sits alongside the NIS2 Directive (security of organisations delivering essential services) and the AI Act (artificial intelligence), closing the loop on the other side of the equation: the security of the products that those organisations use to deliver their services.

The logic is the same that has shaped the CE mark on washing machines, toys and medical devices over the years: anyone placing a product on the EU market is required to demonstrate, under their own responsibility, that the product meets the essential requirements set by the regulation. With the CRA, for the first time, the CE mark also covers cybersecurity. For buyers, the mark becomes the prerequisite for market access — exactly as it is today for a toy or a power adapter.

The two critical deadlines to put in your calendar

The CRA does not kick in all at once: the EU has set a progressive application, with two operational milestones that should be marked now in the IT plan of European SMEs.

• 111 September 2026 — vulnerability notification to ENISA in 24 hours. Manufacturers of products with digital elements must notify ENISA, through a European single reporting platform, about actively exploited vulnerabilities in their products, within 24 hours of discovery or confirmation of exploitation. The logic mirrors NIS2 incident notification, but applied to the product lifecycle and managed centrally at EU level.
• 211 December 2027 — full application of the CRA. From that date, every product with digital elements placed on the EU market must comply with the regulation’s requirements and carry the CE mark attesting it. No CE mark, no market entry. For buyers, from that date every new software or connected device entering the company must come with CRA documentation.

Between the two deadlines, there is a 15-month window in which the market adapts. This is where the game is played for European SMEs: the more structured IT suppliers are already aligning their products, others will arrive late or not at all. Knowing where each supplier sits on this curve is already a concrete vendor risk management action.

The three product classes under the CRA

Not all products follow the same conformity path. The CRA introduces a three-tier classification, with stricter rules as the systemic risk grows:

• Default class — the vast majority of products fall here: business applications, utilities, productivity software, non-critical consumer IoT devices. Conformity is demonstrated by the manufacturer through self-assessment and a declaration of conformity under their own responsibility.
• Class I — important products — an intermediate category that covers products whose malfunction can have significant effects: password managers, antivirus software, consumer VPN solutions, smart-home devices with security functions, IoT microcontrollers. Conformity assessment can still happen via self-assessment, but the manufacturer must follow stricter documentation and vulnerability management procedures.
• Class II — important critical products — the most demanding class, requiring conformity assessment by a third-party notified body. This includes general-purpose operating systems, hypervisors, industrial and network firewalls, public key infrastructure (PKI), cryptographic hardware, smart cards. These are the products that form the "trust substrate" of digital infrastructure: for them, self-assessment is not enough.

For buyers, knowing the class of a product is the first step to reading its documentation: it tells you how strict the verification was, and how reasonable it is to rely on the declaration of conformity.

The CRA technical obligations in five points

Under the "CE marking" label, the CRA asks manufacturers for five concrete things, which permanently change the quality of software entering companies:

• 1Security by design and by default — the product must be designed to be secure in its initial configurations. No more shared default passwords, unnecessary open ports, services enabled that nobody uses. Security stops being an optional feature.
• 2SBOM (Software Bill of Materials) — the manufacturer must maintain and make available the structured list of all software components in the product, in a standard interoperable format. The two reference formats are SPDX (standardised as ISO/IEC 5962:2021) and CycloneDX (from OWASP). The SBOM lets buyers answer in hours — not weeks — the question "does this product contain library X affected by the new vulnerability Y?".
• 3Security support for at least 5 years — the manufacturer must provide security patches and updates for at least 5 years, or for the expected useful life of the product if longer. The end of end-of-life software sold as if still supported. For buyers, the contractual support horizon becomes a clear and verifiable data point.
• 4Coordinated Vulnerability Disclosure — the manufacturer must have a public, documented channel to receive vulnerability reports from researchers and customers, structured processes to handle them and defined timelines for patch release. Transparency on vulnerabilities becomes the rule, not the exception.
• 5Notification of actively exploited vulnerabilities to ENISA in 24 hours — when a product vulnerability is being actively exploited in real incidents, the manufacturer has 24 hours to notify the European single reporting platform run by ENISA. It is the same stopwatch as the NIS2 pre-notification, applied to the product lifecycle.

What European SMEs that buy software should do

For the average European SME — manufacturing, services, structured professional firms — the CRA does not require becoming a software producer. It requires managing purchased software differently. Four concrete actions to put in the roadmap over the next 18 months:

• 1Audit the software portfolio in use — build an up-to-date inventory of digital products in the company, noting for each: vendor, version, expected CRA class, planned compliance date, current support deadline. It is the "land registry" of software, often missing in SMEs today. Without this step, the next three actions are impossible.
• 2Contractual clauses in 2026-2027 renewals — every new software contract or renewal must include four elements: a CRA conformity declaration with the product class, delivery of the SBOM in SPDX or CycloneDX format, an explicit SLA on security patch release times, guaranteed duration of security support (≥ 5 years), vulnerability disclosure procedure with the supplier. SMEs that ask for these clauses early find a market that responds better than expected.
• 3Enriched vendor risk management — the CRA stacks on top of NIS2 (article 21, ICT supply chain security) and ISO/IEC 27001:2022 control A.5.21 on managing security in the supply chain. For SMEs already on the NIS2 path, the CRA does not add a second parallel track: it enriches the same vendor evaluation process with sharper criteria on the products purchased. For SMEs not in NIS2 scope, it is a chance to introduce a first, simple structured process.
• 4Procurement training — those who negotiate software contracts must learn to recognise SBOMs, CE marking, product classes, support clauses. It is short-duration but high-impact work: half a day of focused training for three or four people, once, prevents years of badly-covered purchases.

How AtWorkStudio supports the CRA journey

AtWorkStudio supports European SMEs on the journey to comply with EU cybersecurity regulations — NIS2, DORA, AI Act and now CRA — with a hands-on approach. We start from auditing the client’s software portfolio, then move on to mapping suppliers and reviewing contractual clauses (in coordination with the company’s legal team), and we accompany the gradual realignment as the market adjusts. Our experience implementing control A.5.21 of ISO/IEC 27001:2022 — security of the ICT supply chain — is the natural foundation for tackling the CRA part of the work.

We have been operating from Piacenza, Italy since 2000. We hold ISO/IEC 27001, 27017, 27018 and ISO 9001 certifications, with ACN qualification for SaaS cloud services (QC1 qualification for Email Security Gateway and Microsoft 365 Backup), members of Clusit (Italian Association for Information Security) and affiliated with Confindustria Piacenza in the RICT cluster. For SMEs evaluating the investment, assessment and adaptation activities can fall within the eligible expenses of the MIMIT cloud and cybersecurity voucher.