Cyber Resilience Act: which security profiles to hire

The Cyber Resilience Act changes what security means for anyone who makes hardware or software sold in the European Union. It is no longer only the job of the team protecting the corporate network: it becomes a property of the product, to be demonstrated before it reaches the market and maintained for years afterwards. This article maps the regulation's requirements to the skills you need to hire, and suggests an order of priority for software vendors and manufacturers.

The Cyber Resilience Act in brief

Regulation (EU) 2024/2847, known as the Cyber Resilience Act (CRA), is available on eur-lex.europa.eu. Like DORA, it is a regulation: it applies directly in every Member State. It covers products with digital elements made available on the EU market, whether connected devices, hardware components or software.

Key points:

• A phased timeline. The text entered into force at the end of 2024. The obligations to report actively exploited vulnerabilities and severe incidents have applied since 11 September 2026. Most other obligations apply from 11 December 2027.
• Essential requirements. Annex I sets out, on one side, security properties of the product (secure by default configuration, no known exploitable vulnerabilities when placed on the market, data protection, a reduced attack surface) and, on the other, vulnerability handling requirements across the product's lifetime.
• Product categories. Most products go through self-assessment by the manufacturer. So-called important products (Annex III) and critical products (Annex IV) follow more demanding conformity assessment procedures, which may involve a third-party body.
• A support period. The manufacturer sets a period during which it handles vulnerabilities. The text expects it to be at least five years, unless the product's expected use time is shorter.
• Exclusions. Some products already covered by sector rules, such as medical devices or vehicles, are excluded.

This article is not legal advice. How your products are classified and which obligations follow should be checked with your compliance and legal teams.

What the text asks for in practice

Designing secure products

The manufacturer must carry out a cybersecurity risk assessment of the product and take it into account during design, development and production. The assessment is part of the technical documentation. In other words, threat modelling, architecture reviews and security testing become evidence of conformity, not just good practice.

Handling vulnerabilities over time

Part II of Annex I requires, among other things:

• identifying and documenting the product's components, including by drawing up a software bill of materials (SBOM);
• addressing and remediating vulnerabilities without delay, including through security updates;
• testing the product's security regularly;
• putting in place a coordinated vulnerability disclosure policy and a contact point for reports;
• publishing information about fixed vulnerabilities.

Reporting fast

Article 14 requires reporting actively exploited vulnerabilities and severe incidents affecting the product's security, through a single platform run by ENISA, to the CSIRT designated as coordinator. The text sets an early warning within 24 hours, a notification within 72 hours, then a final report. These deadlines assume monitoring and triage capabilities are already in place.

Documenting and demonstrating

Before placing a product on the market, the manufacturer draws up technical documentation, runs the applicable conformity assessment procedure, signs an EU declaration of conformity and affixes the CE marking. It must also exercise due diligence on the third-party components it integrates, open source included.

From requirements to profiles

In a smaller company, one person often covers several rows. What matters is that none is left without an owner. Our article on the profiles to hire for NIS2 takes the same approach from the organisation's side, and the one on DORA in finance does so for financial services.

The most contested profiles

The head of product security

This is the central role. They understand the development lifecycle, talk to product managers and lawyers, and can turn a regulatory text into backlog items. Candidates often come from application security, architecture or consulting. Assess their judgement: a case study where they must choose between a release date and a vulnerability fix tells you more than a list of standards.

The PSIRT lead

Many vendors have never had a team dedicated to responding to vulnerabilities in their own products. The CRA makes one essential. This profile combines incident response reflexes, a solid technical grasp of the product and a feel for external communication, since they deal with researchers, customers and authorities. Our guide to hiring an incident response lead gives an assessment baseline to adapt.

The application security and DevSecOps engineer

SBOMs, dependency analysis, automated tests and signed updates all live in the development pipeline. You need engineers who can build them in without slowing teams down. See our guide to hiring an application security engineer and our AppSec and DevSecOps interview questions.

The product security architect

For important or critical products, the quality of the risk assessment and technical documentation carries real weight. An architect who can document design choices and defend them in front of a third-party body is an asset. Our article on hiring a security architect covers what to check.

Prioritising your hires

For a manufacturer getting ready, here is an order that often works:

1. Appoint an owner. A head of product security, internal or hired, who inventories the products in scope and their category.
2. Cover reporting. The reporting obligations already apply. A channel to receive and triage vulnerabilities, with a PSIRT lead, is the first operational priority.
3. Equip the development pipeline. A DevSecOps engineer for SBOMs, dependency analysis and security updates.
4. Strengthen design. An architect or application security engineer for risk assessments and code reviews.
5. Prepare for conformity. A product compliance profile for technical documentation and assessment procedures, especially if some products fall under Annex III or IV.

The order depends on where you start. A vendor with a mature AppSec team will start with the PSIRT; a manufacturer new to the subject will start with ownership and inventory.

Pitfalls to avoid

• Handing the CRA to the corporate security team alone. Protecting the company's systems and securing a product are two different jobs. The second happens with product and R&D teams.
• Looking for "a CRA profile". That job does not exist. Start from the uncovered requirements and hire the matching skills.
• Underestimating the timeframe. The support period commits the manufacturer for years. Hiring should build lasting capability, not a one-off project before 2027.
• Hiring on regulatory vocabulary. A candidate who quotes the annexes cannot necessarily read an SBOM or triage a report. Assess on concrete cases.
• Forgetting embedded products. For connected devices and industrial products, skills in hardware security and remote updates are scarce. Start those searches early.

In short

The Cyber Resilience Act turns security into a feature of the product, to be demonstrated and maintained. It makes essential some functions many manufacturers had never formalised: an owner for product security, a vulnerability response team, a well-equipped development pipeline and solid documentation. Start with reporting, which already applies, then build the lasting capability the rest of the text demands.

Preparing your product teams for the Cyber Resilience Act? At Cyber Recrut, a recruiter and a security practitioner scope the role with you and run the search together. Our shortlisted candidates prove their skills on hands-on labs tailored to the role. See how we work or share your hiring need.