Ask a mid-market technology leader which 2027 regulation worries them and you'll usually hear "the AI Act". It's the wrong answer for most product companies. The EU Cyber Resilience Act is the more demanding, more widely applicable, and far less discussed of the two — and unlike the AI Act's high-risk obligations, it wasn't deferred.
From 11 December 2027, any product with digital elements placed on the EU market must meet essential cybersecurity requirements, pass conformity assessment, carry CE marking, maintain technical documentation, and handle vulnerabilities across the product's supported life. Penalties reach €15 million or 2.5% of worldwide annual turnover.
"Products with digital elements" is wider than you think
This is the first thing that catches people out. The scope isn't "software companies" — it's anything placed on the EU market that contains software or firmware, and can connect. Connected hardware. Embedded software. Mobile and desktop applications. A device with a companion app.
If you build something that ships into the EU and contains code, you need to check whether you're a manufacturer under the CRA — and many firms who don't think of themselves as product companies will find that they are.
Part of it is already live
The second surprise: this isn't entirely a future problem. The CRA entered into force in December 2024, and its vulnerability reporting obligations applied from 11 September 2026 — a date that has already passed. If you're in scope and haven't stood up a reporting path for actively exploited vulnerabilities, you're behind now, not in 2027.
Conformity assessment is a practice, not a document
The third and most expensive misunderstanding is treating December 2027 as a paperwork deadline. Conformity assessment isn't a document you write in the autumn of 2027; it's an attestation about how the product is built and supported:
- Secure by design and by default — no default passwords, minimised attack surface, secure configuration out of the box.
- A software bill of materials (SBOM) — you need to know what's in your product, including the open-source components you inherited.
- A vulnerability disclosure and handling process — a real one, with owners and timelines.
- Security updates for the defined support period — which means committing to, and resourcing, a support life for each product.
None of that can be retrofitted in a quarter. It's engineering practice, and the lead time is the reason 2027 planning starts now.
Where to start
The starting point is unglamorous and unavoidable — an inventory:
- Which of your products contain digital elements, and which are actually placed on the EU market?
- Which risk class does each fall into (default, important, or critical)? That drives how heavy the conformity route is.
- What's in them? Generate SBOMs. Most teams discover a longer dependency tail than expected.
- Who owns vulnerability handling, and does a disclosure path exist today?
Scope honestly at step one. Most mid-market firms are in scope for fewer regimes than they fear and more than they assume — and the expensive outcome is discovering which in late 2027. The CRA is one of four deadlines converging in 2027, and several of them draw on the same underlying work: an inventory, secure defaults, and evidence.
The bottom line
The CRA is the 2027 deadline most likely to catch a product company by surprise: broader in scope than people assume, partly live already, not deferred, and demanding engineering practice rather than paperwork. If you ship anything with code into the EU, the inventory belongs in this quarter's plan — because the remediation belongs in next year's. Building security in as practice rather than paperwork is the heart of our cybersecurity and resilience and DevSecOps work.
Not sure whether the CRA applies to what you ship? Let's scope it.