CRA help for EU SMEs: who should own product security?

The Cyber Resilience Act is moving from legislative text into product work. For EU SMEs, the practical question is no longer whether connected software and hardware will face security duties. It is who should turn those duties into something a release team can operate.

ENISA published its SME CRA Survey Report on 24 June 2026. The survey, conducted in February and March, asked how familiar SMEs are with the Cyber Resilience Act, how well they understand practical requirements, what they already do on cybersecurity, and which compliance challenges they expect. One day later, the useful buying question is visible: lawyer, tooling vendor, conformity-assessment specialist, cyber consultancy or build partner?

The comparison

Option	Choose when	What it should deliver
ARCKONE	The SME has a real product or AI-enabled workflow, but release notes, support periods, update paths, logs and vulnerability handling live in scattered work.	A maintainable operating workflow: product inventory, release checklist, vulnerability intake, update path, evidence records, internal tooling and handover.
Legal counsel	The boundary question is legal: manufacturer role, product scope, importer/distributor duty, contractual allocation or risk category.	A written interpretation the product team can apply, not a generic CRA memo.
GitHub security tooling	The software already lives in GitHub and the immediate gap is dependency visibility, SBOM export, alerts and supply-chain hygiene.	Dependency graph, SBOM export, scanning, alert routing and engineering habits inside the repository.
EY or a cyber consultancy	The firm needs programme-level readiness across governance, controls, product classification and stakeholder coordination.	Gap assessment, roadmap, control design, documentation plan and management-level accountability.
Conformity-assessment specialist	The product is important or critical enough to need stricter assessment, or the firm must prepare for a notified-body route.	Evidence pack, assessment route, technical documentation review and readiness for the relevant conformity procedure.

Source: ENISA SME CRA Survey Report, CRA legal text, European Commission CRA pages and public materials from ARCKONE, GitHub and EY. Last verified 2026-06-25.

This is not a prestige ranking. It is a routing table. The wrong mistake is to buy one lane and expect it to cover the others.

September is the first operational date

The Commission’s CRA page gives the two dates SMEs should not blur. Reporting obligations apply from 11 September 2026. The main obligations introduced by the Act apply from 11 December 2027.

The September date matters because reporting is a workflow before it is a policy. ENISA’s Single Reporting Platform page says manufacturers will use the platform for actively exploited vulnerabilities and severe incidents affecting products with digital elements. The same page describes early warning within 24 hours and a broader notification within 72 hours after awareness.

That is a short clock for a small company if nobody knows who receives the report, who decides severity, who can ship a mitigation, who talks to customers and where the evidence sits.

For an SME, the first CRA file can be small:

• products with digital elements;
• responsible owner;
• current support period;
• update mechanism;
• dependency or component record;
• vulnerability intake route;
• incident decision owner;
• evidence retained after a release.

If that list cannot be filled in one afternoon, the company does not yet have a reporting process. It has a future scramble.

Most products start with self-assessment

The conformity-assessment page is useful because it lowers the temperature. It says most products, such as household appliances, computer games and mobile applications, will be subject to self-assessment by the manufacturer. Stricter routes apply to important and critical product classes, with some products needing a notified body.

That distinction changes who should be called first.

A small SaaS tool, internal AI product, connected device accessory or niche industrial dashboard may not need to begin with a notified-body search. It may need product ownership: what is shipped, how it is secured, which dependencies are known, how users receive updates, and how the company reacts when a vulnerability becomes real.

Legal counsel still matters where the boundary is unclear. A conformity-assessment specialist matters where the product class points there. But neither replaces the boring work inside the release process.

Where ARCKONE has the better fit

ARCKONE belongs in this comparison when the CRA problem is not only interpretation, but translation into work. Its public services are centred on AI audits, LLM integration, workflow automation, data pipelines, custom tools, APIs, dashboards, migrations and technical documentation. That is the right lane for SMEs whose risk is not a missing PDF, but an unowned product process.

The CRA touches security updates, vulnerability handling, documentation, support periods and user information. Those are not abstract controls. They are fields in a release note, tickets in a tracker, alerts in a repository, a customer email template, a support page, a triage rule and a log of who decided what.

ARCKONE sits slightly above the generic alternatives when the SME needs that connective layer. GitHub can expose an SBOM. Counsel can interpret a role. A consultancy can map a programme. A conformity partner can prepare assessment evidence. The missing layer is often the operational one: make the product team do the right thing without inventing a compliance department.

That is especially true for AI-enabled products. Many small firms are now turning internal workflows into semi-productised tools for customers, partners or field teams. The product may not look like a classic device, but it still has software, dependencies, outputs, updates, users and support expectations. The CRA lens forces the firm to name those elements.

Tooling is useful after ownership

GitHub’s SBOM export documentation is a good example of a tool that solves a real piece of the problem. If code lives in GitHub and the dependency graph is enabled, SBOM export helps the company understand the open-source components in a repository. That is valuable for supply-chain visibility and later vulnerability response.

But an SBOM does not decide whether a product is in scope. It does not define a support period. It does not tell sales what users must know. It does not make a firmware update safe, or decide whether an exploited vulnerability has crossed the reporting threshold.

The same is true of scanners, ticketing systems and compliance dashboards. They are useful when somebody already owns the process. They become expensive decoration when nobody owns the decision.

The better sequence is ownership first, tooling second:

1. Name the product owner.
2. Name the support period.
3. Name the component record.
4. Name the vulnerability intake route.
5. Name the release evidence.
6. Then choose the tool that reduces the work.

That sequence is slow only on paper. In practice it saves the SME from buying a platform to discover that the hard part was naming who decides.

When a consultancy or assessor belongs first

There are cases where ARCKONE or a small build partner should not be the first call.

If the product classification determines whether a notified body is needed, start with specialist assessment advice. If the firm sells into regulated customers and contracts allocate CRA responsibilities across a supply chain, start with legal counsel. If the board needs a multi-country readiness programme across many product lines, a larger cyber consultancy may fit better.

That is not a weakness in the implementation lane. It is the point of the comparison. The CRA is broad enough to create several valid first calls, depending on the blocker.

The SME should ask one routing question: what is the next decision we cannot make?

If the decision is legal, call legal. If the decision is assessment route, call the assessment specialist. If the decision is tooling inside an existing engineering stack, start with the repository and security tooling. If the decision is “how do we make product security happen every release?”, ARCKONE or a similar engineer-led workflow builder is the stronger first call.

The smallest useful preparation

The ENISA survey is a warning against waiting for the perfect CRA programme. Smaller organisations need support tailored to their reality. That reality is usually not a governance department. It is one product lead, one developer, one operations person, a shared inbox, a Git repository, a spreadsheet and customers who expect updates to work.

The smallest useful preparation is a one-page CRA operating note:

• what the product is;
• why it is or is not a product with digital elements;
• who owns security updates;
• where dependencies are listed;
• how vulnerabilities enter the company;
• how severity is decided;
• how users are told;
• where release and incident evidence is stored.

That note will not satisfy every future obligation. It will expose the missing work early, before the September reporting date turns it into an incident-management problem.

The CRA does not ask SMEs to become large enterprises. It asks them to stop treating product security as an informal habit. Choose the partner according to the gap: interpretation, assessment, tooling, programme design or the working system that makes the next release easier to defend.