The CRA Deadline Is Creating a New Cyber Job Description. Here Is How to Interview for It.

Key Takeaways

• CRA Article 14 reporting obligations begin on 11 September 2026, with a 24 hour, 72 hour, and 14 day notification cascade.
• The duty covers legacy products already on the EU market, not just new releases, which creates immediate work with no existing owner.
• Hiring is shifting from generalist analyst roles toward product security and vulnerability handling, where the skills gap is widest.
• Panels are testing judgement under a clock, not vulnerability trivia.
• The hardest interview questions involve code your employer did not write.

Most cybersecurity career advice is still written as if the job market moves slowly. It does not. Regulation moves it, and one regulatory date is about to reshape a slice of the hiring market that very few candidates are preparing for.

On 11 September 2026, the vulnerability reporting obligations of the EU Cyber Resilience Act come into force. From that date, manufacturers of products with digital elements must notify authorities of actively exploited vulnerabilities and severe incidents , submitting an early warning within 24 hours of becoming aware, a full notification within 72 hours, and a final report within 14 days of a corrective measure being available. Reports route through ENISA's Single Reporting Platform. The broader design and conformity requirements follow on 11 December 2027, but the clock that matters for hiring starts first.

This is not a compliance footnote. It is a staffing problem with a date attached.

Why a reporting rule becomes a hiring wave

A 24 hour clock requires a named human. Someone has to receive the signal, decide whether the vulnerability is genuinely being exploited, judge severity, draft the notification, and route it correctly. That is a role, and in most organisations it does not exist yet.

The scope makes it worse. The reporting duty applies to products already placed on the EU market, not only to what ships next quarter. Companies are discovering that they have obligations attached to software they released years ago, maintained by teams that have since moved on.

Meanwhile the talent picture is not comfortable for employers. The 2025 ISC2 Cybersecurity Workforce Study , based on responses from a record 16,029 practitioners, found that skills gaps have overtaken headcount as the primary workforce concern, with 29 percent of organisations saying they cannot afford to hire staff with the skills they need. ISC2 stopped publishing a global workforce gap estimate entirely, because respondents kept saying the same thing: the problem is not the number of people, it is the specific capabilities missing from the team.

For candidates, that combination is unusually favourable. A regulatory deadline creates demand that cannot be deferred, in a discipline where employers already report they cannot find the skills.

The four capabilities panels are now probing

Job adverts will call this product security, PSIRT, or vulnerability management. Underneath the title, interviews are testing four things.

SBOM literacy. Not the definition. The use. Can you take a software bill of materials and answer "which of our shipped products contain this component" inside an afternoon? A manufacturer cannot report what it cannot detect, which makes component inventory the practical precondition for compliance.

Severity judgement under a clock. The reporting trigger is a vulnerability being actively exploited, not every CVE in your backlog. Panels want to see how you distinguish the two, what evidence you would accept, and how you avoid both over reporting and missing the window.

Legacy archaeology. You will be asked how you would build an inventory for products nobody currently owns. There is no elegant answer. There is a methodical one, and interviewers are listening for method.

Accountability for code you did not write. This is the section candidates most often fumble.

The vendor code question

Very few products are built entirely in house. Front ends, mobile apps, integrations, and customer portals are routinely delivered by external teams, and the CRA does not care who held the keyboard. The manufacturer placing the product on the market carries the reporting duty.

That has a blunt implication. A company that builds through outsourced web and app development partners still owes an early warning within 24 hours, even if the component at fault sits in a codebase maintained somewhere else entirely. The vendor relationship becomes a compliance dependency, and someone in the security team has to make it work.

Interview panels probe this with scenarios. A strong answer moves quickly past trust and into mechanism: contractual notification duties flowing both ways, an SBOM delivered as a build artefact rather than a PDF on request, named technical contacts with an out of hours path, source code and IP ownership settled before the engagement starts, agreed remediation windows tied to severity, and a rehearsed disclosure runbook that includes the vendor. Candidates who mention the rehearsal detail almost always score well, because it signals they have thought about the failure mode rather than the policy.

Five questions worth rehearsing

1. "A researcher emails us about a flaw in a product we shipped in 2022. Walk me through your first two hours."
   They are listening for: confirmation of exploitation, scope check against the product inventory, severity call, and who you wake up.
2. "How would you decide whether something is actively exploited?"
   They are listening for: evidence standards, threat intelligence sources, and comfort with acting on incomplete information.
3. "Our mobile app was built by an agency that no longer works with us. What now?"
   They are listening for: pragmatism, escrow and documentation questions, and whether you propose a control or panic.
4. "What would you put in a supplier contract to make your job possible?"
   They are listening for: specificity. Vague governance language fails here.
5. "We missed the 72 hour notification. What do you do?"
   They are listening for: whether you disclose upward immediately or manage the situation quietly. There is only one acceptable answer.

Reading these is not the same as answering them fluently while someone watches. Scenario questions punish rehearsal gaps in a way knowledge questions do not, which is why running them as AI mock interviews with follow up probes and a scored debrief tends to expose the weak seam faster than solo preparation. It is also worth checking that any product security, vendor management, or vulnerability handling exposure already on your CV is visible rather than buried under generic SOC language. A CV analysis pass usually surfaces that in minutes.

A 30 day preparation plan

Week one. Read Article 14 and the Commission's reporting guidance directly, not a summary of a summary. Note the three deadlines and the exact reporting trigger.

Week two. Generate an SBOM for any open source project using a free tool, then answer a component question against it. The friction you feel is the interview answer.

Week three. Write a one page vulnerability disclosure runbook for a fictional company with two products and one external development vendor. Include who is called at 2am.

Week four. Run the five questions above out loud, twice, and record yourself. Then run them again after cutting every sentence that does not contain a decision.

The window is narrow

Regulatory hiring waves have a shape. Demand spikes just before and just after a deadline, salaries follow, and within roughly eighteen months the skill becomes a baseline expectation rather than a differentiator. September is one month away, and the December 2027 obligations will keep the pressure on well beyond it.

Candidates who can talk credibly about vulnerability handling, supplier accountability, and decision making under a 24 hour clock are walking into a market that has more urgency than supply. That is not a common position to be in, and it will not last indefinitely.

Frequently Asked Questions