The short answer for busy CTOs: if you ship software or connected products to the EU market, the Cyber Resilience Act almost certainly applies to you. From 11 September 2026 you must report actively exploited vulnerabilities to ENISA within 24 hours of becoming aware of them; by 11 December 2027 you need full compliance, a continuously maintained SBOM, secure-by-design practices, and ten years of technical documentation, with penalties up to €15M or 2.5% of global turnover, whichever is higher.
If you're a CEO, founder, or board member of a European software company, there's a deadline on your calendar you probably haven't internalised yet.
- 11 September 2026, when reporting obligations under the EU Cyber Resilience Act (CRA) go live.
- 11 December 2027, when full compliance follows.
The penalty for getting it wrong is up to €15 million or 2.5% of global turnover, whichever is higher.
I'll come back to those numbers. First, the more uncomfortable question.
"Are you ready?"
In the next 18 months, every European software business is going to face this question, from a board, an auditor, an acquirer, or a regulator. And in most of the conversations I'm having with engineering leaders right now, the honest answer is some variation of "we think so, but we don't really know."
That's not a failure of effort. It's a failure of definition.
Until very recently, "secure software" was a vibe-based concept enforced through best-effort scanning and the occasional pen test. The CRA changes that. It turns secure software into a regulated, auditable, evidenced category, closer in spirit to how GDPR turned "we respect privacy" into a documented obligation with teeth.
If you've ever lived through the GDPR rollout, you'll recognise the pattern: the companies that got hurt weren't the ones doing the wrong thing. They were the ones who couldn't prove they were doing the right thing.
What does the CRA actually require?
I'll spare you the regulatory tour and focus on what matters operationally.
A Software Bill of Materials (SBOM) for every product with digital elements
In a machine-readable format, CycloneDX or SPDX. Top-level dependencies at minimum. Maintained continuously, not generated once for the auditor and forgotten until the next renewal cycle.
If your current SBOM strategy is "we'll run a one-off scan when someone asks," you do not have an SBOM strategy. You have a Word document with a future regret in it.
A vulnerability handling process with a 24-hour reporting window
Actively-exploited vulnerabilities reported to ENISA within 24 hours of becoming aware of them. This applies from September 2026, including to legacy products you shipped years ago.
If you don't know which products in your catalog are still in scope, that's the first inventory exercise to run. The 24-hour clock starts at awareness, not at triage, remediation, or board sign-off, which is why the workflow needs to be rehearsed, not just documented.
Secure-by-design engineering practices
Technical documentation maintained for ten years. Lifecycle vulnerability monitoring. The ability to demonstrate all of this to a market surveillance authority on request.
What this means in plain English: you need to know what's in your software, you need to know when it becomes vulnerable, and you need to be able to act on that knowledge fast. None of that is exotic. All of it is operational. All of it is expensive to retrofit and cheap to build in.
The gap nobody is talking about
Here's what's interesting. Most of the engineering teams I work with are aware of CRA at some abstract level. They've seen the headlines. They have a Snyk subscription, or Dependabot turned on, or a security engineer who's done a course on it.
The gap isn't awareness. The gap is translation.
CRA is written in regulatory language and lands on engineering teams who think in tickets and sprints. Between those two worlds sits a question nobody owns: what does compliance actually look like in our specific codebase, with our specific architecture, with our specific team, given how we actually ship?
That's not a question a tool can answer. It's a question that needs a senior engineer who's seen enough codebases, sat in enough boardrooms, and read enough of the actual regulation to give you a defensible read.
What does CRA-ready actually look like? The three-deliverable test
In my experience, a software company is genuinely CRA-ready when it can produce three things on twenty-four hours' notice:
- A current SBOM for every shipped product, with vulnerability and license posture clearly stated.
- A written vulnerability handling policy with named owners, escalation paths, and an actual rehearsal of the 24-hour reporting workflow, not a Confluence page that nobody has read since it was written.
- A technical documentation pack that an auditor or acquirer could pick up and understand: architecture decisions, security controls, the support period commitment, the change history that matters.
If you can produce those three things today, you're already in the top decile.
If you can't, the work to get there is between six and eighteen months depending on where you start. The companies that wait until summer 2026 to start will be too late.
CRA isn't a security problem, it's a leadership problem
The reason I'm writing this isn't to scare anyone. It's that I keep seeing the same pattern across companies of every size:
- A CEO assumes their CTO has it covered.
- The CTO assumes their security engineer has it covered.
- The security engineer is already drowning in CVE backlog and assumed someone was going to give them clear priorities.
CRA isn't a security problem. It's a leadership problem with security implications.
It needs someone whose job is to look at the whole picture, engineering capability, codebase reality, regulatory exposure, board narrative, and produce a clear, sequenced answer. That's a Fractional CTO's job. It's not a Snyk integration's job, and it's not your overworked head of security's job either.
How we help: the WeAreFabbrik CRA & Engineering Readiness Audit
At WeAreFabbrik, we've packaged this work into a fixed-scope CRA & Engineering Readiness Audit:
- Two weeks, fixed price, board-ready output
- A current-state assessment against every operational CRA requirement
- A prioritised remediation plan with effort estimates and named owners
- A board-readable executive summary suitable for inclusion in your next investor or audit committee pack
It's designed for the founders, CTOs, and investors who want a defensible answer before someone else demands one, not after.
You can see how this fits into our broader 3-phase engagement model, Technical Blueprint, Build, and Ship & Scale, depending on whether the work needed is assessment-only, assessment-plus-remediation, or full ongoing CTO support.
Get the CRA Audit one-pager
We've put together a one-pager that summarises the audit scope, deliverables, timeline, and pricing, designed to be the document you forward to your board, your CTO, or your audit committee.
Request the CRA Audit one-pager →
It arrives in your inbox within a few minutes. No call required to receive it.
The deadline isn't moving
September 2026 is closer than your next board meeting cycle suggests. The CRA reporting obligation lands first; full compliance follows fifteen months after that. The board question is coming either way. The only variable left is how prepared you'll be when it lands.
If you'd like a defensible read on where you stand, and a fixed-scope plan to get from where you are to where you need to be, request the one-pager, book a 30-minute strategy call, or send us a message.
About the author: Konstantinos Tsolakidis is a Fractional CTO and the Founder of WeAreFabbrik, a senior engineering team based in Athens and Tallinn. He works with software companies and PE-backed scale-ups across the DACH region and the wider European market on architecture, engineering readiness, and regulatory exposure. He writes The Builder's Edge on LinkedIn.