CRA: Are You Ready for September 2026? Webinar Replay

CRA: Are You Ready for September 2026?

Prepare your vulnerabilityreporting process for the Cyber Resilience Act first key deadline.

Are you prepared for the upcoming European Union Cyber Resilience Act (CRA)? With the first major compliance deadline rapidly approaching on September 11, 2026, manufacturers of products with digital elements must act now. Learn from our Nemko Digital experts Pep van der Laan and Gustavo Sánchez in this essential webinar replay as they unpack the CRA's requirements, focusing on the mandatory vulnerability and incident reporting obligations. Whether you produce hardware, software, or rely on remote data processing, this session provides the clarity and actionable steps you need to navigate the new regulatory landscape and avoid significant penalties.

What You Will Learn

Participants will gain a clearer understanding of how to approach AI risk in a practical, scalable, and business-relevant way.

The Scope of the CRA: Understand exactly what constitutes a "product with digital elements" and how the regulation applies to hardware, software, and essential cloud services.
Critical Deadlines: Get a clear timeline of upcoming obligations, distinguishing between the immediate reporting requirements of September 2026 and the full compliance mandate of December 2027.
Strict Reporting Timelines: Learn the precise workflows and deadlines (24 hours, 72 hours, 14 days, and 1 month) for reporting actively exploited vulnerabilities and severe incidents to ENISA.
Required Internal Capabilities: Discover the documentation, record-keeping, and Coordinated Vulnerability Disclosure (CVD) policies you must implement to achieve compliance.
Your Path to Compliance: Gain a strategic roadmap for getting started, emphasizing the importance of foundational cyber risk assessments for your product portfolio.

Key Takeaways

Action is required now: The September 11, 2026, deadline for incident reporting means organizations must immediately establish vulnerability disclosure policies and internal triage workflows.
It's more than just a hardware: The CRA's scope is broad, encompassing standalone software and remote data processing solutions (like APIs and cloud services) essential to a product's function.
Compliance starts with Risk Assessment: Understanding your specific cyber risk is the foundational step to determining your product's classification and the necessary compliance controls.
Lifecycle Responsibility: The CRA shifts cybersecurity from a point-in-time check to a continuous obligation throughout the product's design, supply chain, and support period.

Ready to strengthen your AI governance approach?

Watch the replay to learn how Nemko Digital helps organizations translate AI risk, regulation, and governance requirements into practical controls that support responsible scaling.

Special Offer: Call with our CRA Experts Now!

Don't wait for the next step.

As a special offer for webinar participants, we are providing an exclusive opportunity to discuss your specific CRA compliance challenges directly with our experts.

Open to Webinar Participants
Complete Application Form
Share the topic you want to talk about

Ready to get started? Scan the QR code in the webinar materials or visit the link below to apply for your expert consultation:

CLICK HERE: https://digital.nemko.com/cra-expert-call

Take control of your AI strategy today with Nemko Digital.

Webinar Resources

Webinar Transcript

Webinar Key Takeaways

Webinar Slides

Please correct me - software (if networked and not isolated) is also PwDE? Hardware is not necessary? Yes. A Product with Digital Elements (PwDE) can be software-only; hardware is not required. The CRA applies to hardware products, software products, and their associated remote data processing solutions. Therefore, standalone software can be in scope even if no physical device is involved, provided it is placed on the market and does not fall under an exclusion.

Is it only operating systems, PKI software, or antivirus that fall under the CRA? Definitely not only embedded software? Correct. The CRA is not limited to operating systems, PKI software, antivirus products, or embedded software. Those categories appear in Annex III and Annex IV because they are classified as Important or Critical products, but ordinary software can also be a PwDE and therefore fall under the CRA. Examples may include desktop applications, mobile apps, device management software, monitoring platforms, field service applications, and other software products placed on the market.

Not only software mentioned in Annex III/IV? Do we need to evaluate and later support all software? The key question is not whether software appears in Annex III or Annex IV, but whether it qualifies as a Product with Digital Elements. If software is a PwDE and placed on the EU market, it should be assessed for CRA applicability. If in scope, the manufacturer will need to comply with the relevant CRA obligations, including cybersecurity requirements, vulnerability handling, and support-period obligations. Annex III and IV mainly affect the conformity assessment route, not the basic applicability of the CRA.

How do you place a CE mark on software? Software covered by EU product legislation can bear a CE marking even when distributed digitally. The practical implementation (e.g., within the installation package, installer, user interface, documentation, or accompanying materials) depends on the applicable legislation and conformity assessment route. The manufacturer must be able to demonstrate compliance and provide the required documentation and declaration of conformity. Specific implementation details continue to evolve through guidance and harmonized standards.

Is there any requirement in law or standards describing exactly how to place the CE mark on software? The requirements stem from the applicable EU product legislation and general CE-marking rules. The CE marking must be visible, legible, and appropriately associated with the product. For software distributed digitally, manufacturers commonly place the CE marking within the software, accompanying documentation, packaging, download portal, or installation materials. Additional guidance and harmonized standards are expected to provide further practical detail.

What exactly is considered a “Remote Data Processing Solution” in the context of the CRA? A Remote Data Processing Solution is a remote or cloud-based functionality that is necessary for a product with digital elements to perform one or more of its intended functions. Examples may include cloud analytics platforms, device management portals, telemetry processing services, customer dashboards, or backend APIs that the product depends on. If the product relies on the remote service to provide its intended functionality, that service should generally be considered part of the product context for CRA purposes.

What is the relation between the Machinery Regulation (EU) 2023/1230 and the CRA? The two regulations are complementary. The Machinery Regulation focuses on safety, including cybersecurity-related risks that may create hazardous situations. The CRA focuses on cybersecurity throughout the product lifecycle. Connected machinery can fall under both regulations simultaneously. In practice, manufacturers of connected machinery will often perform one integrated risk assessment covering both cybersecurity impacts and safety impacts resulting from cyber threats.

What kind of resources need to be monitored for actively exploited vulnerabilities? Is CISA KEV enough? CISA KEV is a good source, but it is not sufficient on its own. Manufacturers should also monitor sources such as EUVD (European Vulnerability Database), CVE / NVD feeds, vendor security advisories, etc. along with vulnerability disclosures received through CVD processes. The objective is to identify vulnerabilities affecting both the product and its dependencies/components.

Do the September 2026 and December 2027 obligations also apply to products already deployed in the field? Generally yes, but the answer depends on the specific obligation and product situation. Article 14 reporting obligations begin applying on 11 September 2026, while most other CRA obligations apply from 11 December 2027. Products placed on the market before those dates are not automatically re-certified. Applicability should therefore be evaluated based on the product lifecycle, support period, and specific CRA provisions rather than solely on the original placement date. A product inventory and support-period review is recommended.

Does "aware of incident" mean receipt of an email, or validation of the report? When does the 24h/72h clock start? The CRA requires reporting when the manufacturer becomes aware of an actively exploited vulnerability or severe incident. The regulation does not explicitly define awareness as the mere receipt of an unverified report. A practical and defensible approach is to document a formal validation and triage step. The reporting clock should start when sufficient evidence exists that the vulnerability or incident is valid, applicable to the product, and meets the reporting criteria. Manufacturers should maintain an auditable "Awareness Date/Time" field in their incident or vulnerability register.

Does the 14-day deadline mean a fix must be found within 14 days? For actively exploited vulnerabilities, the requirement is to submit a notification that includes a mitigation within 72 hours after being aware of the exploitation. Then, a full report within 14 days.

This only applies to products newly delivered into the market, correct? Not entirely. The CRA primarily regulates products placed on the EU market, but manufacturers should not assume that only newly delivered products are relevant. Existing products that remain supported, products undergoing substantial modification, and products affected by Article 14 reporting obligations may still require assessment. Applicability should therefore be evaluated based on the product lifecycle, support period, and specific CRA provisions rather than solely on the original placement date.

Any minimum support period, or is it completely up to the company? The CRA does not allow manufacturers to choose an arbitrary support period. The support period must be determined based on the expected product lifetime and documented appropriately. In general, the CRA establishes a minimum expectation of five years, unless the expected use period of the product is shorter. Manufacturers must communicate the support period to users.

Book Your Free Consultation Call

Ready to elevate your AI product’s trustworthiness and compliance?
Don’t wait - connect with our experts for a free 15-minute consultation call to discuss how our trusted services can help your business thrive in today's competitive landscape.

Schedule Your 15-Minute Call Now