The Cyber Resilience Act's First Obligation Gate Is 90 Days Away. Most Smaller Product Companies Still Cannot Prove They Are Ready.

The EU Cyber Resilience Act has been binding law since 10 December 2024. For most of the eighteen months since, that fact has sat quietly on the regulatory horizon while product companies treated December 2027 as the date that mattered. This week the horizon moved closer. On 11 June 2026, the CRA's provisions on the notification of conformity assessment bodies took effect, and Member States began designating the national authorities that will appoint the bodies responsible for certifying products. The machinery that will eventually judge whether a product conforms is now being built.

The first obligation that lands directly on manufacturers is 90 days away. From 11 September 2026, Article 14 requires that actively exploited vulnerabilities and severe incidents be reported to ENISA and the relevant national CSIRT on a 24-hour, 72-hour, and 14-day clock. Full application, which adds CE marking, technical documentation, and the complete set of essential cybersecurity requirements, follows on 11 December 2027.

For boards and executive teams at smaller software and hardware companies, the consequential question is narrower than the headline regulation suggests. It is not whether the CRA is a serious obligation; it is. It is whether the company can yet prove it does the things the CRA requires. On the evidence we see across smaller product organizations, most cannot, and not because they lack security capability, but because they have never had to turn that capability into a documented, repeatable, auditable record. That gap is the work, and 90 days is enough time to close the first part of it only if it starts now.

Key Takeaways

• The CRA (Regulation (EU) 2024/2847) entered into force on 10 December 2024, but its obligations apply in phases. In force is not the same as in effect
• 11 June 2026: the conformity-assessment-body provisions took effect and Member States began designating notifying authorities. The certification apparatus is now being stood up; sufficient bodies must be notified across Member States by 11 December 2026
• 11 September 2026 (90 days out): Article 14 reporting obligations apply. Actively exploited vulnerabilities and severe incidents go to ENISA and the national CSIRT within 24h / 72h / 14 days
• 11 December 2027: full application, covering CE marking, technical file, and all Annex I essential requirements. Without conformity, an in-scope product cannot be placed on the EU market
• Scope is broader than most companies assume: SaaS with downloadable agents, embedded software, IoT, industrial tech, developer tools, and security software are all routinely in scope, and Article 3 pulls in the cloud back-ends those products depend on
• The binding constraint for smaller companies is evidence, not capability. They patch, they test, they manage components, but cannot show who decided what, when, and why. The CRA requires the proof, not just the activity
• Penalties reach €15M or 2.5% of global turnover, but the sharper commercial risk is loss of EU market access from December 2027

In Force Is Not the Same as In Effect

The single most common misreading of the CRA is binary: either the company believes it must already comply, or it believes it has until the end of 2027 to think about it. Both are wrong, and the gap between them is where the planning happens.

The regulation became binding law on 10 December 2024. What that started was a transition, not an obligation. The dates that actually impose requirements arrive in sequence, and each one assumes the previous groundwork is in place.

Scroll right to see more

Scroll right to see more

The structure matters for an executive deciding where to spend the next two quarters. The September 2026 gate is operational: it requires a vulnerability-handling and incident-reporting process that already works, because a 24-hour early-warning obligation cannot be met by a process invented after the first exploited vulnerability appears. The December 2027 gate is evidentiary and procedural: it requires a technical file, demonstrated conformity to the essential requirements, and CE marking, none of which can be credibly assembled in the final quarter. The conformity-assessment bodies that will support that 2027 gate are being designated now, which is the practical reason not to wait: their capacity is finite, and every in-scope manufacturer in Europe is heading for the same deadline.

Who Is In Scope, and Does Not Know It

The CRA applies to products with digital elements placed on the EU market. The phrase is deliberately broad, and it captures a large population of companies that do not file themselves under "regulated."

A SaaS product with a downloadable agent or desktop client is in scope. Embedded software in a physical device is in scope. IoT and connected devices, industrial technology, developer tools, and security software are in scope. Article 3 extends the boundary further by treating remote data-processing solutions necessary for the product to function as part of the product, which means the cloud back-end behind an otherwise on-premise tool is pulled in with it.

Two scoping facts catch companies off guard. The first is that the real scope is usually wider than the initial estimate, because a product is rarely just the code the company wrote: it bundles third-party libraries, an update mechanism, device integrations, and components the customer deploys. The second is that the obligations differ by role. A company may be a manufacturer for one product, a distributor or importer for another, and an open-source steward for a third, and the CRA assigns different duties to each. A company that cannot state, product by product, which role it occupies and which provision applies has not yet completed the first step of readiness.

This is also why the CRA does not stand alone. The same product evidence, from the component inventory to the vulnerability-handling records to the secure-by-default configuration, feeds directly into the obligations a company carries under NIS2, DORA, the revised Cybersecurity Act, and the EU AI Act. The cross-framework exposure is real, and building the CRA evidence base once, deliberately, is what keeps it from being rebuilt five times. We mapped that overlap in Five Frameworks, One Vendor: how NIS2, DORA, CRA, the revised CSA, and the EU AI Act create cross-framework exposure.

The Gap Is Evidence, Not Capability

Most product companies already do a meaningful amount of security work. They have multi-factor authentication, endpoint protection, backups, access reviews, and an incident-response channel. Their engineers patch vulnerabilities, assess open-source components, and run security tests. None of that is in question.

What the CRA requires is different in kind. It is product security, demonstrated. The questions it asks are not "do you do security" but "can you prove how":

• Does the product ship without known exploitable vulnerabilities, and can you show the check?
• Are secure settings the default, by design and on the record?
• Can the product receive security updates, and are they provided free for the support period?
• Do you have a complete inventory of the components and dependencies inside the product?
• Do you operate a coordinated vulnerability disclosure process with a documented intake channel?
• Can you assess, triage, fix, and communicate a vulnerability, with the decisions recorded?
• Can you produce technical documentation showing how cybersecurity risk was considered across the product's design?

The recurring failure mode is not absence of activity. It is absence of proof. A company says, with justification, "we already manage vulnerabilities," and then cannot show who assigned the severity and on what basis, when the fix shipped, which customers were notified, whether exploitation was assessed, or whether a reporting obligation was even considered. The activity happened. The evidence trail that an auditor or a conformity assessment body will ask for did not. CRA readiness is the discipline of turning existing security work into a reliable, repeatable, evidence-based process. That is a documentation and governance problem far more often than it is an engineering one.

The Two Areas That Carry the Most Weight

For a smaller organization, the highest-value starting point is not a deep technical audit. It is a practical baseline across two areas, because between them they cover the structure and the operational credibility the CRA demands.

Scroll right to see more

Scroll right to see more

Governance, risk and compliance gives the structure. It answers who owns CRA readiness, which products are in scope, which obligations apply, what evidence already exists, what risk the company is accepting, and what has to be fixed. This is not a heavyweight policy exercise; it is structured clarity on the baseline. Product security cannot sit only with engineering, or only with legal, or only with compliance. It needs a cross-functional owner with explicit responsibility for product risk, vulnerability handling, customer communication, and the evidence trail.

Vulnerability management gives the operational credibility. It answers how the company finds, receives, assesses, prioritizes, fixes, discloses, and reports vulnerabilities, repeatably and on the record. This is precisely the area the September 2026 reporting gate depends on, and it is the area where smaller companies most often operate informally. The CRA makes informality risky, because Article 14's clock cannot be met by a process that exists only in people's heads.

These two areas are not arbitrary. They map onto the two parts of the CRA's Annex I. Part I describes the security properties a product must have: secure by default, integrity, confidentiality, availability, a minimized attack surface, the ability to receive updates. Part II describes the vulnerability-handling processes the manufacturer must operate: a software bill of materials, remediation, coordinated disclosure, a reporting channel, free security updates. GRC underwrites the first; vulnerability management underwrites the second. A company that cannot explain its product scope, its security responsibilities, its vulnerability-handling process, and its documentation model will struggle under scrutiny regardless of how strong its engineering team is.

What Readiness Looks Like in Practice

A practical readiness program for a smaller organization moves through a predictable sequence, and none of the steps require a large up-front project.

It begins with product scoping: identifying which products, modules, firmware, cloud-connected elements, agents, APIs, and bundled tools fall under CRA obligations, and confirming the answer rather than assuming it. Role mapping follows, because manufacturer, importer, distributor, and open-source steward carry different duties. Governance comes next: a named owner and a cross-functional model, so that product risk, vulnerability handling, customer communication, and evidence are someone's explicit responsibility rather than everyone's assumption.

Vulnerability management is then formalized end to end, across intake, triage, severity scoring, exploitation assessment, remediation tracking, patch release, customer notification, and reporting readiness, so that the September 2026 obligation can actually be met. Technical documentation is built and, critically, maintained as the product evolves: the product description, intended use, cybersecurity risk assessment, design controls, dependencies, update mechanism, and evidence of security testing. Supplier and dependency control addresses the reality that most products rely on open-source components, third-party libraries, and outsourced development, which means a software bill of materials and a way to manage that risk.

The final step is a roadmap. Not everything must be fixed at once. But the organization should know what is missing, what is high risk, what must be ready before 11 September 2026, and what must be complete before 11 December 2027. The roadmap is what converts an open-ended regulatory anxiety into a sequenced, fundable plan.

What This Changes for the Executive Team

Three executive decisions follow directly from the timeline.

The September gate is a readiness test, not a documentation deadline. Meeting Article 14 requires an operational vulnerability-handling and incident-reporting capability that works on a 24-hour clock. If that process is informal today, the executive question is not "when do we write the policy" but "when does the process start running for real," because the only way to know it works is to have run it before it is needed.

Conformity-assessment capacity is a scheduling risk, not just a cost. The bodies that will support the 2027 gate are being designated now, and sufficient capacity across Member States is not mandated until December 2026. Every in-scope manufacturer in Europe is converging on the same December 2027 deadline. A company that begins engaging late competes for finite assessor capacity at the worst possible moment, with evidence it cannot retroactively create. Beginning the baseline now is a hedge against that queue.

The evidence base is a multi-framework asset, not a single-regulation cost. The component inventory, vulnerability-handling records, and risk assessments built for the CRA are the same artifacts that NIS2, DORA, the revised CSA, and the AI Act ask for. Treating CRA readiness as a standalone compliance line item understates its value; treating it as the first build of a reusable evidence base reflects what it actually is.

This readiness posture also becomes a transaction asset. For companies that may raise, sell, or acquire, CRA exposure is now something deal teams should be reading in tech and cyber diligence, and the absence of an evidence trail is exactly what surfaces as a priced risk or a warranty gap. We cover the deal-side view in CRA exposure in M&A: a proportionate diligence lens, not a conformity audit.

How Innovaiden Approaches CRA Readiness

The starting point is deliberately small. Before any remediation program, the two questions worth settling are: which of our products are in scope, and under which provision? Most of the cost, delay, and anxiety in CRA programs comes from skipping that step and treating the whole portfolio as uniformly exposed.

The Innovaiden CRA pre-readiness assessment is a short, 20-question instrument designed to answer exactly those questions and to produce a first read on where the evidence gaps are: which obligations bind by 11 September 2026, which by 11 December 2027, and which products carry the most exposure. It is not a legal certification and it does not replace a formal conformity assessment. It is the baseline that tells an executive team whether they are broadly ready, or whether specific areas need remediation now, while there is still time to build the evidence rather than improvise it.