Does the EU Cyber Resilience Act apply to my small software company?

If you sell software, an app or a connected device under your own name in the EU, probably yes. The size of your business makes little difference. This isn't legal advice, but it should help you work out where you stand and what to do first.

What the Cyber Resilience Act is

The Cyber Resilience Act (CRA) is an EU regulation that sets security rules for "products with digital elements": software and hardware, together with any remote data processing they need to work. Because it is a regulation rather than a directive, it applies directly in every EU country, including Ireland. It does not wait for national law, unlike NIS2.

It arrives in stages. The duty to report certain vulnerabilities and incidents has applied since 11 September 2026. Most of the other requirements, including the product security requirements and CE marking, apply from 11 December 2027.

Are you a manufacturer?

Under the CRA, a manufacturer is anyone who develops a product with digital elements, or has one developed, and markets it under their own name or trademark, whether it is paid for, monetised or free. The test is commercial activity, not company size. That can include:

• Desktop software, downloadable clients and mobile apps
• Firmware and connected devices
• Freemium products and open-source software you earn money from
• Cloud features that the product needs in order to work

Some things usually fall outside it. A standalone cloud service (SaaS) is covered by other rules, such as NIS2, unless it is part of how a product works. Free, open-source software supplied outside any commercial activity is out of scope. If you build software for a client and they sell it under their name, the client is normally the manufacturer. Medical devices, vehicles and some other products have their own sector rules.

The NCSC runs a CRA helpdesk but says it will not advise on whether a particular product is in scope. That decision is yours, so take advice if you are unsure.

What applies now: reporting

Since 11 September 2026, manufacturers must report two things through ENISA's Single Reporting Platform to their national CSIRT (for companies based in Ireland, CSIRT-IE within the NCSC):

• An actively exploited vulnerability in one of their products
• A severe incident affecting a product's security

The deadlines run from the moment you become aware:

• An early warning within 24 hours
• A notification within 72 hours, with an initial assessment
• A final report within 14 days of a fix being available (for a vulnerability) or within one month of the notification (for an incident)

You must also tell the users of the affected product what has happened and what they should do. The 24-hour clock does not stop for weekends, so the most important step is deciding now who makes the call to report, and who covers for them. Waiting for a decision to go up the chain is one of the most common ways to miss the deadline.

What comes in December 2027

From 11 December 2027, products in scope must meet the Act's essential requirements before they can be sold in the EU. In plain terms:

• Secure by design and secure by default, for example no shared default passwords
• Protection against unauthorised access
• A vulnerability handling process, with a public way to report problems
• A software bill of materials (SBOM) listing the product's components
• Free security updates for a stated support period, normally at least 5 years
• Technical documentation, a conformity assessment, an EU declaration of conformity and CE marking

Fines for the most serious breaches can reach €15 million or 2.5% of worldwide annual turnover, whichever is higher.

What to do first

• List your products and decide, product by product, whether each one is in scope. Write down your reasons.
• Name the person who decides on CRA reports, and a deputy. Add them to your incident response plan.
• Find out how the Single Reporting Platform works before you need it, and read the NCSC's guidance on reporting.
• Publish a vulnerability disclosure policy and a security.txt file, so researchers know where to report problems.
• Start an SBOM: list each product's components and versions, and check them for known vulnerabilities.
• Set a support period for each product and tell customers what it is.
• Plan the December 2027 work early, especially if a product may need an assessment by an independent body.

Customers are already asking for some of this. Procurement questionnaires increasingly ask for an SBOM and a vulnerability disclosure policy, and treat the answers as a sign of whether you are a safe supplier. If questionnaires are part of your sales process, our guide to supplier questionnaires covers the rest.

How PolicyPack helps

If you tell us in the questionnaire that you make software, an app or a connected device, your pack includes a Secure Development Policy, a Vulnerability Disclosure Policy with a ready-made security.txt file, and a Product Security Register for your products, support periods, SBOM and CRA reports. Your Incident Response Policy also gets the Act's 24-hour and 72-hour reporting steps. This is included in Essentials and Pro, and Pro maps the documents to the Act's main duties. See what's inside.

These documents help you prepare. They do not by themselves make a product compliant, and they are not legal advice.