The EU Cyber Resilience Act: a practical guide for SMBs

A safer digital future for SMBs

What if every tool your business runs on, from your CRM to payroll to your team chat app, had to prove it was secure before you bought it?

That’s what the EU Cyber Resilience Act (CRA) brings to the market. It will change how small and medium-sized businesses (SMBs) across Europe choose, buy and trust their software and connected devices.

You don’t need to be a cybersecurity expert to benefit. You need to know which questions to ask, which red flags to spot, and how CRA compliance can turn from a legal checkbox into a competitive edge. This guide gives you all three.

Too many products still ship with weak security: outdated components, default passwords, no long-term support. When attackers exploit these gaps, SMBs often pay the highest price in downtime, data loss and damage to their reputation.

The CRA flips the script. Manufacturers have to show their products are secure before they reach the EU market. For you, that means stronger guarantees from suppliers and a firm basis to demand proof before you sign.

Think of the CE marking on physical products. Just as that label signals safety, CRA conformity will become the trust signal for digital products. Security stops being optional.

What makes this law different

GDPR protects personal data. The CRA is about the security of the product itself, by design and over its whole life. It requires manufacturers to:

• fix vulnerabilities quickly and ship security updates free of charge
• be open about security updates and how long a product is supported
• document the third-party components in their products
• prove conformity before the product is sold

For SMBs this means you can hold your suppliers accountable and expect safer products.

SMBs as product makers

The CRA isn’t only something to expect from your suppliers. It also applies to you if you make products with digital elements and sell them in the EU. If your business builds hardware, embeds software in devices or develops software that you sell, you carry the same obligations as large manufacturers. Importers and distributors that resell products have their own, lighter duties, unless they sell the product under their own name.

The first step is your supply chain. As a manufacturer, you must apply due diligence to every component you integrate, open-source libraries included. If a supplier’s component is insecure, its risk becomes your risk.

The second step is looking inward. The CRA turns security by design from good practice into a legal requirement. That includes:

• evaluating your development or integration processes
• finding and patching vulnerabilities quickly
• documenting how security is built into every stage of your product lifecycle

We cover the practical steps further down.

The CRA at a glance

Timeline

For SMB buyers: ask your suppliers now how they’re preparing. From 11 December 2027, products that don’t meet the CRA can’t be placed on the EU market.

Who is affected

The CRA covers products with digital elements: software and hardware that connect to a device or a network. Many tools SMBs use every day fall under it:

• installed business software, such as accounting, CRM and office apps
• collaboration and video conferencing clients
• laptops, phones, routers and printers
• security software, such as VPN clients and password managers

Pure SaaS is outside the CRA; NIS2 covers many cloud providers instead. But a cloud backend that a product needs to work, such as the server behind a smart lock’s app, counts as part of the product. Downloadable apps and agents that come with a SaaS service generally fall under the CRA too.

These are the parties the CRA affects:

Product classes

The CRA sorts products with digital elements into four categories. The higher the risk, the stricter the conformity assessment. Here’s an overview, with what to ask your supplier for each:

Default: the lowest-risk category

The European Commission estimates that about 90% of the products covered by the CRA fall into the default category. They carry less inherent risk than the listed categories, but they still have to meet all of the CRA’s essential cybersecurity requirements.

Examples of default products that SMBs buy:

• general-purpose software: office suites, note-taking and project management tools, accounting and invoicing software, email clients, chat and video conferencing apps, photo and video editors, and installed CRM, HR and ERP software
• office hardware: laptops, desktops, tablets, smartphones, monitors, mice, keyboards and webcams
• smart office devices without a security function: smart lighting, thermostats, HVAC controllers, printers and connected projectors
• consumer-style devices used at work: smart TVs, connected whiteboards and conference systems, and digital signage

A default product can still contain class I components. A laptop is a default product, but the operating system it runs is a class I product in its own right.

Manufacturers of default products assess conformity themselves. That doesn’t lower the bar: your suppliers still need security by design, vulnerability handling and documentation. Use the vendor checklist below to ask for evidence.

Important class I: elevated risk

Class I products (Annex III, part I) perform security functions or control access to networks and systems, so a compromise has wider effects than for a default product. The list:

• identity management and privileged access management software and hardware, including authentication readers such as badge and biometric readers
• browsers, password managers and anti-malware software
• VPN products, network management systems and SIEM systems
• boot managers, PKI and certificate issuance software, physical and virtual network interfaces, and operating systems
• routers, modems and switches
• microprocessors, microcontrollers, ASICs and FPGAs with security functions
• smart home virtual assistants, and smart home security products such as smart locks, security cameras, baby monitors and alarm systems
• connected toys with social interaction or location tracking, and wearables that monitor health or are meant for children

A manufacturer can only assess a class I product itself if it applies harmonised standards, common specifications or European cybersecurity certification in full. Otherwise a notified body has to be involved. Few harmonised standards are cited so far (see our overview of the CRA harmonised standards), so expect many class I products to go through a notified body at first.

When you buy a class I product, check that the supplier commits to keeping it secure over time: a CE marking and EU declaration of conformity, regular security updates, a clear support period and end-of-life policy, and secure defaults such as strong authentication and encryption. Ask where your business data will be stored, how long the product will be supported, and how quickly the supplier has fixed problems in the past. Choose suppliers that take responsibility for security, not only for features.

Important class II: high risk

Class II (Annex III, part II) is a short list:

• hypervisors and container runtime systems
• firewalls and intrusion detection and prevention systems, which includes next-generation firewalls and UTM appliances
• tamper-resistant microprocessors and microcontrollers

Manufacturers can’t assess these products themselves, even when they apply harmonised standards. They need a notified body, or a European cybersecurity certificate at assurance level “substantial” or higher.

When you buy a class II product, ask for the CE marking, the EU declaration of conformity and the details of the notified body. The declaration shows that the manufacturer has assessed the product’s cybersecurity risks and commits to keeping it secure with updates. If a supplier can’t provide it once the CRA applies, look for another product.

Critical products: the highest assurance

Annex IV lists three product types:

• hardware devices with security boxes
• smart meter gateways and other devices for advanced security purposes, including secure cryptoprocessing, such as hardware security modules (HSMs)
• smartcards and similar devices, including secure elements

The Commission can require a European cybersecurity certificate for these products through a delegated act, for example under EUCC, the scheme based on Common Criteria. Where it hasn’t, critical products follow the class II route.

Only buy critical products if the supplier can show valid certification. Check that the certificate is current, that the product gets security updates for its full support period, and that the supplier has a plan to fix problems quickly. These devices protect your most sensitive data and business functions.

Choosing CRA-compliant products

Vendor checklist for SMBs

Use this checklist in conversations with suppliers. CRA conformity, regular updates and vulnerability handling are non-negotiable. The rest strengthens your position.

1. CRA conformity

• The supplier provides an EU declaration of conformity and the product carries the CE marking.
• The product's category is clear: default, class I, class II or critical.
• Where a certificate is required, it's current and covers the version you're buying.

2. Security updates

• Security updates come regularly and free of charge.
• The support period is stated. For most products the CRA requires at least five years.
• Updates can install automatically and are digitally signed.

3. Vulnerability handling

• The supplier has a formal process for reporting and fixing vulnerabilities.
• A coordinated vulnerability disclosure policy and a security contact are published.
• Vulnerabilities are communicated and patched promptly.
• Bonus: the supplier runs a bug bounty program.

4. Data protection and privacy

• It's clear where your business data is stored.
• The product supports your GDPR obligations.
• Data is encrypted at rest and in transit.

5. Built-in security features

• Secure defaults: no default passwords, multi-factor authentication available, encryption on.
• Role-based access control is available.
• Logging and audit trails exist.

6. Accountability and documentation

• The supplier provides security guidance and user instructions.
• The end-of-life policy is clear.
• The supplier takes responsibility for security, not only for features.

7. Interoperability and portability

• The product supports open standards.
• You can export your data if you switch suppliers.
• The product works with your existing IT systems.

8. Independent assurance (optional but recommended)

• The supplier holds third-party certifications such as ISO/IEC 27001, SOC 2 or, for industrial products, IEC 62443.
• The supplier shares penetration test or security audit reports.
• Security test results are published or can be verified.

Going further: verify secure-by-design practices

If you want more than basic CRA conformity, ask for more evidence that the product was built secure by design:

• Ask for the supplier’s secure software development lifecycle (SSDLC) policy. It should describe the security activities in detail. For each activity, ask for evidence that it was carried out in the past year.
• Ask how threats are identified and mitigated during design. Threat modeling should be part of the SSDLC policy.
• Ask for the software bill of materials (SBOM) and load it into a free tool such as OWASP Dependency-Track to see known vulnerabilities in the listed components. Manufacturers must draw up an SBOM but don’t have to publish it, so some will share it only under NDA.
• Ask for the incident response plan, including how the supplier meets the CRA’s 24-hour early warning for actively exploited vulnerabilities and severe incidents.
• Ask whether the product has known critical vulnerabilities and how they’re being handled. The CRA requires products to ship without known exploitable vulnerabilities.

These checks tell you whether security was part of the product from the start or bolted on afterwards.

Red flags

Treat a product as high-risk, and look at alternatives, if you see any of these:

No proof of CRA conformity

• The supplier can’t provide an EU declaration of conformity or CE marking once the CRA applies.
• Certification is outdated, incomplete or unclear.

No transparency

• There’s no documentation on how vulnerabilities are handled.
• There’s no published security contact, such as a security@ address, a PSIRT or a disclosure policy.
• There’s no clear statement about CRA conformity.

Outdated or unsupported software and hardware

• Devices ship with an end-of-life operating system or unpatched libraries.
• There’s no commitment to security updates for the product’s support period.
• Release notes are missing or vague.

A poor update process

• Updates must be applied by hand, are downloaded from an arbitrary website or aren’t digitally signed.
• There’s no automatic or secure update mechanism.
• The supplier won’t say how long updates will be provided.

Weak or insecure defaults

• The product ships with default passwords that can’t be changed.
• There’s no support for multi-factor authentication.
• The product uses outdated protocols such as SSL or TLS 1.0.

No secure development practices

• There’s no evidence of security by design or secure coding.
• The supplier can’t explain how it tests for vulnerabilities.
• There’s no mention of penetration testing, code reviews or threat modeling.

No independent assurance

• There’s no ISO/IEC 27001 or, for industrial products, IEC 62443, and no third-party security evaluation, not even a voluntary one.
• The supplier dismisses compliance questions as “not needed” or “too expensive”.

Risky business behavior

• There’s no clear process for handling incidents or breaches.
• The supplier has a history of ignoring vulnerability reports or delaying fixes.

Obligations for SMBs that make connected products

As the introduction explained, the CRA applies to every manufacturer that sells products with digital elements in the EU, not only to software vendors. SMBs that build hardware, embed software in devices or sell their own software face the same obligations as large manufacturers. And it goes well beyond purchasing: it affects design, development, manufacturing and maintenance after sale.

The rest of this guide goes into more technical detail for product development teams.

Core security obligations

The CRA’s aim is that every product with digital elements on the EU market is built secure by design and supported after sale for a reasonable period. Manufacturers must be able to show evidence of their security activities, from governance and design through to end-of-life.

The CRA expects established security practices throughout the development lifecycle. Here’s a sample secure software development lifecycle (SSDLC) with the matching security activities:

Security by design

Security has to be part of the product from the first design, not added later. Manufacturers apply secure-by-design and secure-by-default principles across the development lifecycle. That includes:

• carrying out a cybersecurity risk assessment and defining security requirements during planning and architecture, for example through threat modeling
• applying secure coding practices and automated testing
• shipping with secure default configurations that minimize exposure

You document these practices in the technical documentation for your conformity assessment.

Vulnerability handling

Security after release matters as much as secure development. Manufacturers need a vulnerability handling process that includes:

• identifying the components in the product and monitoring them for known vulnerabilities, in your own code and in third-party components
• publishing security advisories and fixing vulnerabilities without delay
• distributing security updates free of charge, separately from feature updates where possible

The support period must reflect how long the product is expected to be in use, and must be at least five years unless the product is expected to be in use for less. Each security update must stay available for at least ten years, or for the rest of the support period if that’s longer.

Transparency

Manufacturers must provide:

• an SBOM in a commonly used, machine-readable format, covering at least the top-level dependencies. It’s part of the technical documentation, so you don’t have to publish it.
• technical documentation describing the product’s security features and how conformity was assessed
• an EU declaration of conformity
• user information, including the end date of the support period and a single point of contact for vulnerability reports

Products carry the CE marking under the usual CE rules: on the product where possible, otherwise on the packaging and in the documentation. For software, the CE marking goes in the EU declaration of conformity or on the website that accompanies the software.

Transparency extends to the supply chain: you must apply due diligence so that third-party components, open source included, don’t compromise the product’s security.

Incident reporting

Since 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents through ENISA’s single reporting platform. The report goes to the national CSIRT designated as coordinator and to ENISA:

• an early warning within 24 hours of becoming aware
• a notification with more detail within 72 hours
• a final report within 14 days after a fix is available for a vulnerability, or within one month for a severe incident

You must also inform affected users and tell them how to mitigate the problem. These obligations apply to all products with digital elements, software-only products included, and also to products that were already on the market before December 2027.

The CRA moves cybersecurity from reactive to proactive. Security by design, structured vulnerability handling, transparency and fast reporting become the standard for selling digital products in the EU.

A practical compliance roadmap

Isolated security fixes won’t get you to CRA compliance. You need a structured, measurable approach to secure software development. SSDLC maturity models are one of the most effective ways to get there, for example:

• OWASP SAMM (Software Assurance Maturity Model)
• BSIMM (Building Security In Maturity Model)

These frameworks help you:

• assess your current software security posture
• set realistic improvement targets
• align development practices with the CRA’s core obligations: security by design, vulnerability handling, transparency and incident reporting

With a maturity model in your roadmap, these principles become part of how your engineering teams work instead of a set of regulatory checkboxes.

OWASP SAMM: structured guidance for secure development

The diagram below shows the security practices defined in OWASP SAMM.

The OWASP SAMM model. Source: owaspsamm.org, CC BY-SA 4.0.

SAMM’s modular structure supports:

• a baseline assessment of your organization’s current security maturity
• target maturity levels based on risk, business goals and CRA requirements
• a tailored roadmap to close the gaps you find
• prescriptive guidance for activities across governance, design, implementation, verification and operations

That flexibility makes SAMM well suited to CRA preparation: you can prioritize improvements by product class, market exposure and the capabilities you already have.

Step 1: Assess your product portfolio against the CRA’s scope

Start by identifying which of your products are products with digital elements under the CRA.

• Include software-only products as well as hardware with embedded software.
• Map each product to a category: default, class I, class II or critical.
• Determine which products need a notified body and which can use internal control (module A).

This defines your compliance perimeter and shows where to focus first, based on risk and regulatory exposure.

Step 2: Find the gaps in development and post-sale processes

Use SAMM to evaluate your current software security posture across its five business functions: Governance, Design, Implementation, Verification and Operations.

• Run a baseline maturity assessment with SAMM’s scoring system.
• Identify missing or weak practices, such as no threat modeling, slow patching or unclear incident response roles.
• Pay special attention to post-sale obligations like vulnerability monitoring and support periods, which are often overlooked.

The OWASP SAMM website has guidance to help you start, plus free tools to assess, visualize and communicate your software security maturity. They make it easier to find gaps, plan improvements and track progress. The chart below shows a sample assessment, with current strengths and the progress planned over four quarters.

Step 3: Put secure development practices in place

Based on your gap analysis, set a target maturity level for each business function and start on the improvements with the highest priority.

• Start with the areas tied directly to CRA obligations, such as secure coding standards, SBOM generation and secure update mechanisms.
• Use SAMM’s guidance to build security into daily development work.
• Match the depth of controls and documentation to the product class. Critical products need more of both.

Step 4: Prepare vulnerability disclosure and patch management

The CRA requires a vulnerability handling process and timely updates.

• Publish a coordinated vulnerability disclosure (CVD) policy.
• Define internal workflows for triage, remediation and communication, including the 24-hour reporting deadline.
• Make sure your patch delivery is secure, reliable and documented.

SAMM’s Operations function describes practices for incident management and patching in detail.

Step 5: Train your teams on ongoing obligations

Compliance isn’t a one-time event. It needs continuous awareness and clear ownership.

• Train engineering, product and support teams on CRA obligations and secure development practices.
• Include CRA topics such as CE marking, reporting deadlines and documentation in onboarding and ongoing training.
• Use SAMM’s Governance function to formalize roles, responsibilities and metrics.

Our EU CRA Practitioner Training covers these obligations for engineering, product and compliance teams. If you’d rather not do it alone, the EU CRA Compliance Journey runs these steps with you, from product classification to the EU declaration of conformity.

Open source software

The CRA doesn’t regulate open-source development itself. Its obligations apply when software is made available on the market as part of a commercial activity. Volunteers and communities that share code without commercial intent aren’t directly affected.

Non-commercial open source

Open-source software developed and shared without commercial intent, such as hobby projects, research tools or community libraries on GitHub, falls outside the CRA. Contributors don’t need conformity assessments or documentation.

Commercial use of open source

A company that integrates open source into a product it sells in the EU is responsible for the CRA compliance of the whole product, open-source parts included. It must apply due diligence to these components, handle their vulnerabilities and document them. Liability lies with the company that places the product on the market, not with the individual contributor. If you find and fix a vulnerability in an open-source component, you must also report it and share the fix with the project’s maintainers.

Open-source software stewards

The CRA introduces the open-source software steward: a legal person, other than a manufacturer, that systematically supports the development of open-source software intended for commercial use and keeps it viable. Foundations such as the Eclipse Foundation and the Linux Foundation are typical examples, as are companies that host and maintain open-source projects.

Stewards have a light regime. They must:

• put in place and document a cybersecurity policy that covers vulnerability handling
• cooperate with market surveillance authorities
• report actively exploited vulnerabilities and severe incidents, to the extent that they’re involved in development

Stewards don’t carry out conformity assessments or affix the CE marking. That changes when an organization makes the software available as part of a commercial activity itself, for example by charging for it. It then becomes a manufacturer, with the full set of obligations.

Not every open-source project has a steward. The CRA puts no obligations on individual contributors, but it makes companies fully responsible for the open source they ship. As a result, the quality, transparency and maintenance of open-source components will weigh more heavily when companies choose them.

Common pitfalls and how to avoid them

The CRA sets clear expectations for secure development and lifecycle management, yet many organizations stumble when they implement it. Most missteps come from treating the CRA as a checklist instead of a change in how software is built, maintained and governed. Here are three common pitfalls, and how OWASP SAMM helps you avoid them.

1. Treating the CRA as a one-time project

Many teams approach the CRA as a compliance sprint before a deadline, without building long-term security practices. That leads to superficial fixes that decay over time and leave products vulnerable after release.

SAMM builds in continuous improvement. Its maturity scoring helps you track progress over time, set goals that evolve with your products, and reassess your practices as products and threats change. With SAMM in your SSDLC, CRA compliance becomes an ongoing process.

2. Leaving it all to engineering

Security often lands on engineering alone, without legal, procurement or product management. That creates blind spots in liability, supplier risk and market obligations.

SAMM’s Governance function makes security a cross-functional effort. It helps you define roles and responsibilities across departments, align legal, procurement and product teams with security goals, and give each CRA obligation, such as CE marking, incident reporting and supplier assurance, a clear owner. Security is a responsibility of the whole business, and engineering is one part of it.

3. Underestimating the documentation

Teams often focus on technical controls and neglect the documentation the CRA requires, including the risk assessment, SBOMs, vulnerability handling procedures and the declaration of conformity.

SAMM ties documentation to each business function:

• Design and Implementation capture architecture decisions and secure coding practices.
• Verification records test results and evidence for the conformity assessment.
• Operations keeps patch logs, incident reports and support periods.

Documentation then grows with the work instead of being written under pressure before an assessment.

Looking ahead

The CRA is part of a wider set of EU rules. NIS2 covers the cybersecurity of essential and important entities, and the AI Act governs trustworthy artificial intelligence. They also connect: a high-risk AI system that meets the CRA’s essential requirements is deemed to meet the AI Act’s cybersecurity requirement.

For companies, this convergence is an opportunity. Those that adopt CRA practices early, building in security, transparency and lifecycle management, can position themselves as trusted suppliers while competitors rush to catch up before December 2027.

Key takeaways

The CRA decides your access to the EU market

• From 11 December 2027, CRA conformity is a condition for placing products on the EU market.
• Non-compliant products risk withdrawal, recalls and fines of up to €15 million or 2.5% of worldwide annual turnover.
• The reporting obligations already apply today.
• Preparing early gives you time to build secure-by-design practices instead of rushing fixes at the last minute.

Use a structured approach and a maturity model like SAMM

• Ad hoc security efforts won’t pass a conformity assessment. The CRA demands systematic, demonstrable practices.
• OWASP SAMM helps you assess your current posture, set improvement targets and build a roadmap aligned with CRA obligations.
• A maturity model spreads security across teams and the whole lifecycle, instead of leaving it in one team or reacting to incidents.

Rethink how you select components and suppliers

• You’re responsible for every component in your product, including open-source and third-party software.
• Evaluate suppliers and libraries on security posture, maintenance activity and CRA alignment.
• Expect more questions about SBOMs, licensing and vulnerability disclosure, both from your customers and to your suppliers.

Want to know where you stand? Take the free EU CRA Self Assessment or book a free EU CRA strategy call.

Glossary

Useful resources

• CRA legal text on EUR-Lex: the official publication of the regulation.
• EU cybersecurity policies: the European Commission’s overview, including the CRA and NIS2.
• CRA FAQ on the ORC WG CRA hub: a community-maintained FAQ on common CRA questions.
• ORC WG CRA overview: resources from the Open Regulatory Compliance Working Group.
• OWASP SAMM: the model, tools and guidance.