The EU CRA Compliance Clock Is Already Ticking—Are You Ready?

The CRA timeline: More compressed than it looks

Three dates define the CRA’s compliance arc, and each one has strategic implications that extend well beyond simply meeting a bureaucratic deadline.

September 11, 2026, is the first mandatory activation point. From this date forward, if you discover an actively exploitable vulnerability in your product, you are legally required to report it to the EU Vulnerability Database through its reporting platform. This is not a soft launch. Reporting obligations are live, and noncompliance opens you to regulatory scrutiny at precisely the moment when you are least prepared to absorb it. With this date already less than six months away, organizations that have not established their vulnerability monitoring and reporting infrastructure are already behind.

October 30, 2026, is when the majority of the harmonized standards—the technical translation of the CRA’s policy requirements into specific, actionable security practices—will be published. Note that one critical horizontal standard (a standard that applies across product categories) is not scheduled until October 2027. That gap is important, because you’ll be required to report vulnerabilities months before all the requirements are clear. That is precisely why early investment in baseline security practices is not optional—it’s the only defensible posture.

December 11, 2027, is when it all comes due: full compliance with CRA product requirements and vulnerability handling obligations across your portfolio. For most organizations, this sounds like a generous runway. It isn’t. Consider the supply chain math: If your product is a component purchased by other manufacturers, your customers need you to be compliant before their deadline. In practice, this shifts your effective compliance date months earlier than the official end-state deadline. Account for that reality in your planning now.

Classification: The decision that shapes everything

Before you can make any meaningful progress on CRA technical requirements, you need to know which category your product falls into. The CRA divides products into three tiers—the default class, class 1, and class 2—and the classification you land in directly determines which conformity assessment pathway applies to you.

The CRA implementing acts are the authoritative source for this determination. These acts lay down uniform conditions for the implementation of the CRA—such as formats for reporting severe incidents, templates for EU declarations of conformity, and rules for market surveillance. “These should be your bible when you are classifying your product,” advises Angelo D’Amato, cybersecurity expert and founder of Vulnir. (D’Amato also serves as rapporteur for two of the three horizontal CRA standards.) These acts provide explicit product lists and criteria that determine which tier you’re in, and critically, what you’re required to do to demonstrate compliance.

• Default class products are subject to self-assessment. You evaluate your own compliance posture against the CRA’s requirements, document your findings, and take responsibility for the accuracy of that assessment. This is the most common pathway and the most flexible—but flexibility here does not mean leniency. Regulators will scrutinize your documentation, and a superficial self-assessment is as dangerous as no assessment at all.
• Class 1 products are subject to more prescriptive requirements, including the mandatory use of applicable harmonized standards. In many cases, these standards are not optional—they are required to demonstrate conformity, depending on the product category. Organizations must actively monitor the development of these standards and be ready to update their security practices as new guidance is published.
• Class 2 products represent the highest-risk category. For these, third-party assessment is mandatory. You cannot self-certify your way to compliance. This pathway requires external validation, which adds cost, time, and coordination complexity to your compliance program. If any of your products fall into class 2, your preparation timeline should have already started.

The critical discipline here is rigor. Work through the implementation acts systematically for every product in your portfolio. If a product sits at the boundary between classes, the conservative classification is always the defensible one. Misclassifying a product, even inadvertently, creates regulatory exposure.

Harmonized standards: Your technical compass

Once you know your product’s classification, harmonized standards become your most practical implementation tool. These are not the regulation itself; they are the technical translation of CRA’s policy requirements into specific, actionable security practices that manufacturers can build against.

The relationship between the CRA and harmonized standards is nuanced in one important way: Compliance with a harmonized standard—that is, the specific security practices—is not legally mandatory in most cases, but it creates a presumption of conformity. If a harmonized standard carries that presumption and you follow it, regulators will treat your product as compliant with the requirements that standard covers. That’s a powerful protection—essentially a documented, defensible shield against enforcement challenges.

Harmonized standards are being developed for both horizontal and vertical standards. Horizontal standards apply across product categories. They address foundational security requirements like vulnerability management, secure update mechanisms, and encryption. Vertical standards address the specific risk profile of product types, such as industrial control systems, healthcare devices, and consumer IoT devices. Your compliance program needs to account for both types. (Note again that the horizontal standard for product security requirements arrives in October 2027 as the final piece of the puzzle.)

Given that most harmonized standards won’t be published until late 2026 or 2027, the practical move right now is to invest in the practices that are universally recognized as foundational security requirements.

• Component inventory and SBOM generation
• Continuous vulnerability monitoring
• Secure-by-design development processes
• Documented vulnerability response procedures

These are not speculative. They are explicitly woven into the CRA’s Annex 1 requirements, and every harmonized standard will reflect them.

The documentation imperative: Proving compliance

Classification and standards are the framework. Documentation is how you demonstrate compliance with the framework. Under the CRA, due diligence is a deliverable that regulators, market surveillance authorities, and potentially customers will evaluate.

This means your compliance program needs to generate verifiable evidence, not just internal processes. Document your product classification rationale, the security requirements you’ve identified for each product tier, the testing and validation practices you’ve applied, the vulnerability management policies you’ve established, and the support periods you’ve defined. The regulation is explicit that manufacturers that perform due diligence are in a fundamentally different position from those that cannot show their work.

The practical implication is that if you’re building or modernizing an AppSec program in response to the CRA, treat documentation as a first-class output, not an afterthought. Every security practice you implement should produce an artifact that supports a compliance narrative.

The timeline: What you need to do now

With September 2026’s reporting obligations looming and full compliance required by December 2027, your immediate priority list is clear.

• Classify every product in your portfolio using the CRA implementation acts. Don’t estimate or approximate. Work through the product lists and criteria systematically and document your rationale for each classification decision.
• Audit your current security practices against the CRA’s Annex 1 requirements. Identify the gaps between where you are and where you need to be, particularly around SBOM generation, continuous vulnerability monitoring, and vulnerability response workflows.
• Map your supply chain dependencies. If your product is a component that other manufacturers will purchase, your compliance deadline is their constraint. Proactively communicating your compliance posture—and building the SBOM and vulnerability reporting infrastructure to support it—is a competitive differentiator, not just a regulatory box to check.
• Begin tracking harmonized standard development for the product categories that apply to you. Standards bodies are active, drafts are circulating, and early engagement gives you lead time to align your practices before publication deadlines create urgency.

The manufacturers navigating this transition most effectively are those that recognize that the CRA’s compliance architecture—classification, harmonized standards, conformity assessment—is not an arbitrary bureaucratic construction. It is a structured pathway to demonstrable, defensible security practice. Follow it with rigor and start early, and your compliance investment becomes not just a regulatory obligation but a durable competitive asset.