The EU Cyber Resilience Act Is Enforced Starting Today — Is Your Product Architecture Ready?

Your board approved your EU market strategy. Your product team shipped on schedule. Your legal counsel filed the right registrations. And as of today, September 11, 2026, your vulnerability disclosure workflow either meets the EU Cyber Resilience Act's Article 14 requirements, or your company is already in breach. There is no grace period. There is no warning letter. The clock started this morning.

Most boards treat cybersecurity as an IT operations problem. The CRA makes that assumption expensive.

The Cyber Resilience Act represents a fundamental shift in how the EU treats software security, positioning cybersecurity as a product safety requirement, much like the standards that have governed hardware for decades.

That parallel is deliberate.

The CRA starts earlier in the story, asking why the product was allowed onto the market in insecure form in the first place.

That question now has a regulator, a deadline, and a fine attached to it.

The pressure falls hardest on companies that have confused organizational security maturity with product-level compliance readiness. These are not the same thing. A company can hold ISO 27001 certification, run a mature SOC, and still be materially non-compliant with the CRA today, because

while ISO 27001 certifies organizational security management systems, the CRA requires each individual product to meet specific security requirements and undergo conformity assessment. This product-level focus means compliance cannot be achieved through organizational policies alone. Each product requires documented evidence that security was considered and implemented throughout its development, starting at the design phase.

Boards that have not verified this distinction are carrying unquantified market access risk.

What Enforcement Looks Like Starting Today

Reporting obligations concerning actively exploited vulnerabilities and severe incidents impacting product security came into effect on September 11, 2026, and organizations must have incident reporting processes and procedures in place.

This is not a soft launch.

The Article 14 reporting duties apply from September 11, 2026, and they are in the top penalty tier.

The reporting cascade is precise and unforgiving.

Manufacturers must file an early warning within 24 hours, submit a triage report including a resolution path within 72 hours, and submit a final report within 14 days after remediation is available.

Notifications go to the competent CSIRT at the manufacturer's main establishment and are shared with ENISA and other relevant EU CSIRTs.

A company without a documented incident triage runbook, a designated security contact, and an established ENISA reporting channel cannot meet these windows. Discovering a breach and simultaneously standing up a reporting workflow is not a viable contingency plan.

The financial stakes justify board attention immediately.

Non-compliance can trigger fines of up to €15 million or 2.5% of global annual turnover, whichever is higher.

For any company with meaningful EU revenue, the 2.5% figure will exceed the flat cap. At a $2 billion company, that exposure reaches $50 million per enforcement action, before reputational damage or customer churn.

Product security is no longer a feature shipped by engineering teams. Under the CRA, it is an auditable lifecycle obligation governed at the board level, backed by fine authority that scales directly with the size of your global business.

The Scope Problem Most Boards Have Not Solved

The EU Cyber Resilience Act sets mandatory cybersecurity requirements for any product with digital elements placed on the EU market, and the obligations extend across the full product lifecycle to manufacturers, importers, and distributors. Non-EU companies must comply to keep market access.

That last sentence is the board-level issue. Geographic incorporation does not create a compliance exemption. If a product connects to a network and reaches an EU customer, the CRA applies.

These obligations are not limited to new launches or current development projects: they also cover legacy products placed on the EU market before the CRA applies in full.

Companies often assume their existing product portfolio is grandfathered. It is not. Every connected product already in the EU market carries Article 14 reporting obligations as of today.

The supply chain dimension compounds the problem.

The CRA mandates a machine-readable Software Bill of Materials (SBOM), secure-by-design engineering, coordinated vulnerability disclosure, and security updates for the product's expected lifetime.

If you place a product on the market commercially, the components you integrate are your responsibility.

Open-source dependencies, third-party SDKs, and firmware libraries are not exempt simply because you did not write them. Your SBOM must account for all of them, and your vulnerability management process must handle disclosed CVEs affecting any component in the bill.

CRA vs. NIS2 vs. ISO 27001: What Actually Governs Your Product

Boards frequently conflate these frameworks. They govern different things, and compliance with one does not substitute for another.

ISO/IEC 27001 defines a voluntary information security management system at the organizational level, while the CRA imposes mandatory, product-level obligations.

A software vendor selling into the EU can be subject to both NIS2 and the CRA simultaneously.

NIS2 focuses on entities and their cybersecurity risk-management obligations. The CRA focuses on products with digital elements. A software vendor can be affected by both: NIS2 as an entity and CRA as a product manufacturer.

How the CRA Rewires the SDLC

The CRA is not a compliance audit that happens after a product ships. It is a mandate that engineering architecture decisions must produce auditable security evidence from the earliest phases of development.

Secure-by-design must be baked into engineering, with CRA controls added to the secure SDLC, threat-modeling, code-review, dependency-update, and release-gate processes.

Companies that have not restructured their software development lifecycle around these requirements face a significant remediation gap, not just a documentation gap.

The product you sell on day one opens a maintenance obligation that runs for a minimum of five years, with security updates required free of charge for at least ten.

That commitment affects product roadmap decisions, support staffing, and customer contract terms, all of which require board-level budget authorization.

The SBOM Is Not Optional

The CRA transforms product security from a best practice into an auditable lifecycle requirement: manufacturers must maintain machine-readable Software Bill of Materials and similar evidence which can be audited by the regulator.

Generating an SBOM at a single point in time is not sufficient. The SBOM must track changes across the product lifecycle, because a dependency vulnerability disclosed six months after launch triggers the same 24-hour reporting obligation as a zero-day on release day.

Legacy Products Are Immediately In Scope

The most common board-level misconception is that the December 2027 full-compliance deadline provides breathing room on existing products. It does not, for Article 14.

The reporting obligations apply from September 11, 2026, to all products with digital elements within the CRA's scope that have been made available on the EU market before full CRA application.

Your 2019 firmware product, your 2022 SaaS platform, and your 2024 IoT device are all in scope for vulnerability reporting today.

Supply Chain Accountability Flows Upstream

The CRA places direct legal accountability on manufacturers and software providers to build secure products, maintain them throughout their lifecycles, disclose vulnerabilities promptly, and demonstrate compliance with technical evidence.

Contractual indemnification clauses with component suppliers do not satisfy this obligation. If a third-party library in your product carries an actively exploited CVE, the 24-hour clock starts when your organization becomes aware, regardless of who wrote the code.

CRA Readiness: Board-Level Checklist

Use this checklist to assess your organization's current posture. Each gap represents both a regulatory risk and a governance accountability question for the board.

The CRA fine ceiling for essential cybersecurity requirements is high enough to make product security a board-level risk. Compliance should therefore be tracked in product governance, not left only to engineering teams.

The Governance Gap the CRA Exposes

The practical challenge is not the deadline itself but the governance gap between product security, supply chain assurance, and board-level accountability.

Most boards receive cyber risk reporting in operational terms: number of incidents, patch cycle velocity, penetration test findings. The CRA demands a different reporting layer: product-by-product compliance status, SBOM coverage percentages, Article 14 notification readiness, and EU market access risk by revenue segment.

Directors who lack this visibility are not uninformed by accident. The governance structures that feed information to boards were not built to surface product-level regulatory exposure. Building those structures is not an engineering task. It is a board advisory task.

American technology companies that have not yet begun CRA compliance planning are already behind schedule, because meeting the Act's security-by-design mandate requires front-loading security into the earliest stages of the product development cycle.

The same logic applies to any non-EU manufacturer with EU market revenue. Waiting for December 2027 to address secure-by-design obligations means engineering teams are already building products that will fail conformity assessment, and replacing architecture after the fact costs multiples more than embedding it correctly now.

How I Help

My Board Advisory service is the immediate entry point for organizations that have EU market revenue and have not yet verified their CRA governance posture at the board level. I translate product security obligations into financial risk quantification, build board-ready reporting frameworks that surface Article 14 readiness and market access exposure by revenue segment, and establish the governance accountability structures that connect your engineering decisions to your directors' oversight responsibilities. Two sessions with your board can close the gap between what your CISO knows and what your directors can act on, before a regulator makes that conversation mandatory.

For companies that need to close the architectural gap between current SDLC practices and CRA's secure-by-design mandate, my Security Architecture service embeds CRA controls directly into your product development process, from threat modeling gates to SBOM pipeline design. My vCISO service provides ongoing incident response leadership and the cross-functional coordination that Article 14's 24-hour reporting windows demand. If your CRA preparation intersects with AI-generated code or AI-enabled product features, my Secure AI Deployment service ensures those components meet the regulation's security-by-design requirements without slowing your release cadence. For organizations managing the broader EU regulatory stack alongside the CRA, my Compliance Advisory service maps your obligations across NIS2, DORA, and the CRA into a unified control framework that avoids redundant effort.

The enforcement clock started today. A non-compliant disclosure, or a missed 24-hour window on a known exploit, puts both your EU market access and your directors' governance credibility at risk simultaneously. That is not a problem to defer to next quarter's planning cycle.

See if I should be in the room