The Cyber Resilience Act is coming, and the product isn't ready for it.

The moment

With the CRA it usually starts in product development or at the quality department that manages the CE marking. A distributor asks about the CRA conformity of your devices, a major customer wants to know how long you'll deliver security updates, or the engineering manager works out that the December 2027 requirements mean the next product generation has to be designed differently now. Then it turns out the team is strong on the product and thin on security, and that the reporting obligation of September 2026 already requires a working process before the rest of the regulation applies.

What the CRA asks of you

The regulation (EU 2024/2847) applies to manufacturers, importers and distributors of products with digital elements placed on the EU market: hardware with software in it, standalone software, and everything in between. The core is security-by-design: risks assessed, no known vulnerabilities at delivery, secure defaults, updates during the support period, and a process to receive, fix and report vulnerabilities. Since its entry into force on 10 December 2024 two deadlines are running: from 11 September 2026 manufacturers must report actively exploited vulnerabilities and severe incidents (early warning within 24 hours, notification within 72 hours, final report afterwards), and from 11 December 2027 all requirements apply, including conformity assessment and CE marking. Which product category and which assessment route apply to you is a question for the standards and the notified body; we come into the picture once it's clear someone has to lead it.

What needs to happen now

1. Product portfolio and classification. Which products are in scope, in which category, and which assessment route goes with it. Work for a product security lead with the quality and compliance department.
2. The reporting process before September 2026. A way to receive vulnerabilities (also from researchers), assess them and report within the deadlines. A security officer or product security lead, together with support and engineering.
3. Security-by-design in development. Threat models, secure defaults, a software bill of materials, secure update mechanisms. A security architect or AppSec engineer embedded in the development team.
4. The support period and updates. How long you deliver updates, and how they reach the product securely. Engineering with a security engineer who safeguards the process.
5. Technical documentation and conformity. The file that goes with the CE marking, and for some categories the third-party assessment. Compliance specialist with the product security lead.

Who leads this

Manufacturers here look for a product security lead who sets up the programme and bridges engineering, quality and management, a security architect or AppSec engineer for the design and development work, a firmware or embedded security engineer when it's about devices, or a compliance specialist for the documentation and the CE route. Which of those roles it is for you depends on the product and the team; that's where the intake starts. If you need someone permanently, that's simply permanent recruitment; temporarily, it's interim. We've been doing both for years.

Interim: within two days, and what it costs

Fast doesn't mean sloppy. We start with a proper intake: which products, which deadline, what's already in place, who this person needs to bring along. Then we search a network of interim professionals we have usually known for years, which is how, for an interim assignment, you'll have your first candidate interviewed within two days. If you need someone permanently, it works differently and takes longer. The best permanent candidates are rarely actively looking: they're settled somewhere and only move for the right arguments, from someone who knows them and what drives them. That is exactly our work, and it produces the best match, but not within two days. Interim professionals are entrepreneurs: more commercial, more flexible in both directions, and therefore faster to propose from the network we actively maintain. If we don't have someone who truly fits, we'll say so, and in product security that honestly happens more often than for a CISO role, because it's a narrower field. You always see the professional's rate and our margin separately, and that margin is never more than €15 per hour on a full-time assignment. You can contract the freelancer directly or through your own broker, in which case we invoice only our margin, or entirely through Gruzzy with a single invoice. Who is available right now, and in which rate band, is listed anonymously with the available interim professionals.

Freelance, and the Dutch DBA Act

Setting up a CRA programme, establishing a reporting process or designing a product generation securely is an assignment with a clear beginning and end: there's a result, the professional decides how the work gets done, and there's no employer-style line of authority. That is what the Dutch tax authority wants to see now that enforcement on false self-employment has resumed since 2025, so freelance fits well here, with a model agreement. If the work is in fact a job, say a product security engineer who is a permanent part of the development team, we'll say so. Usually that's a permanent role through recruitment; if you really want someone temporarily on payroll, secondment is possible, although it isn't our core business. We're happy to advise on this before you sign.