The Cyber Resilience Act—Regulation (EU) 2024/2847—turns cybersecurity into a legal requirement for access to the European market for any connected product, with the CE marking as proof of conformity. If you first need to resolve the scoping—what products are in scope, what role applies to you, how your portfolio is classified, and what penalties apply—start with Cyber Resilience Act (CRA): what it is, who it applies to, and how products are classified.
This second part gets into the real work: what Annex I technically requires, how to set up the notification process for vulnerabilities and incidents, what the CE marking technical file contains, how the CRA fits with NIS2 and ISO 27001 without duplicating effort, and the most sensible order to tackle it all.
September 11, 2026 — obligations to notify actively exploited vulnerabilities and severe incidents, through the single platform managed by ENISA. It applies also to products already on the market, with no transitional period. This is the first enforceable requirement—and it is only weeks away.
December 11, 2027 — Annex I essential requirements, conformity assessment, technical documentation, EU Declaration of Conformity, and CE marking.
A practical note: the Commission has proposed delaying the deadlines by two months for the standardization request. The horizontal standards for vulnerability management are expected towards the end of October 2026, and the product-specific (vertical) standards throughout December 2026. Since the self-assessment of Class I important products depends on being able to apply harmonized standards, it is advisable to review their status before finalizing the compliance plan.
Annex I essential requirements: security by design and vulnerability management
The CRA’s technical core is its Annex I, divided into two parts that correspond to two different moments in the lifecycle: how the product is designed and delivered, and how it is maintained once sold.
Part I — Product cybersecurity properties
The product must be designed, developed, and manufactured in a way that ensures a level of cybersecurity appropriate to the risk. Requirements include:
- Be placed on the market without known exploitable vulnerabilities.
- Be delivered with a secure-by-default configuration, with the ability to restore it.
- Allow vulnerabilities to be fixed through updates, automatic where appropriate and with user notification.
- Protect against unauthorized access with authentication, identity management, and access control mechanisms.
- Ensure confidentiality and integrity of data and commands, with encryption at rest and in transit.
- Apply data minimization: process only the data necessary for the intended use.
- Protect the availability of essential functions and reduce the attack surface.
- Log and monitor security-relevant internal activity (logs).
- Enable secure deletion and portability of data and configurations.
None of these requirements is exotic for a team already working with secure development practices. The novelty is not the “what”, but that from December 2027 onwards you must be able to demonstrate it with documentation, product by product, to a market surveillance authority.
Part II — Vulnerability management during the support period
The second part requires keeping the product secure after sale. This is where the three new items with the greatest operational impact appear:
Software bill of materials
The manufacturer must identify and document the product’s components and produce an SBOM in a machine-readable format that covers, at a minimum, first-level dependencies.
Support period
A support period of at least five years—or the expected lifetime of the product, if shorter—must be declared, with an explicit end date (month and year) known at the time of purchase.
Coordinated disclosure
A coordinated vulnerability disclosure policy must be published, along with a point of contact to report them, and security patches must be provided free of charge and without delay.
These three pieces are linked: without an SBOM you cannot know whether a published vulnerability affects the product; without knowing that, you cannot patch within the declared support period; and without a patch there is nothing to communicate within the notification deadlines that follow.
Vulnerability and incident notification: 24 hours, 72 hours, and 14 days
From September 11, 2026, manufacturers must notify simultaneously the CSIRT designated as coordinator—that of the Member State where they have their main establishment; in Spain, INCIBE-CERT—and ENISA, via the single notification platform. Two cases must be notified: actively exploited vulnerabilities and severe incidents affecting the security of the product.
Early warning
From the moment the manufacturer becomes aware. It is enough to indicate that it exists and, if known, the affected Member States.
Notification
General information about the affected product, the nature of the issue, and the corrective or mitigating measures available.
Final report
14 days from when a corrective measure is available, for actively exploited vulnerabilities. 1 month from notification, for severe incidents.
In parallel with those three milestones, the manufacturer must inform affected users without undue delay—and, where appropriate, the public—about the incident and the corrective measures they must apply. This is not a fourth deadline: it is a simultaneous obligation that should be scripted, because it involves communications and support, not only security.
Micro and small enterprises do not face fines for specifically failing to meet the 24-hour early warning deadline, but they still retain the other notification obligations.
CE marking and conformity assessment
Before placing the product on the market—and with a deadline of December 11, 2027—the manufacturer must complete and retain a conformity file. In order:
- Carry out and document a product cybersecurity risk assessment.
- Complete the applicable conformity assessment procedure for its class—internal control self-assessment, EU type examination, full quality assurance, or European certification, depending on the product classification.
- Prepare the technical documentation demonstrating compliance with Annex I requirements.
- Issue the EU Declaration of Conformity.
- Affix the CE marking to the product, its packaging, or the accompanying documentation.
- Provide instructions for use and user information, including the end date of the support period.
That documentation must be kept for at least ten years—or the support period, if longer—and made available to market surveillance authorities.
In Spain, the planned institutional allocation is as follows:
| Function | Body |
|---|---|
| Market surveillance authority Inspects, requests documentation, and may order the product to be withdrawn. |
Ministry for Digital Transformation and the Civil Service |
| Notifying authority Designates and supervises conformity assessment bodies. |
National Cryptologic Centre (CCN) |
| Coordinating CSIRT Recipient of vulnerability and incident notifications, together with ENISA. |
INCIBE-CERT |
Do you need to have the notification process ready before September 2026? We show you how to manage the 24-hour, 72-hour, and 14-day clocks with an auditable record of every communication.
Request a demoCRA, NIS2, and ISO 27001: how they fit together without duplicating work
This is the most common confusion, and it has a clear answer: the CRA regulates products; NIS2 regulates organizations. A company may be subject to both—as an essential or important entity under NIS2 and as a manufacturer under the CRA—and in that case the two frameworks overlap in governance, risk management, and incident notification, but not in the regulated object.
Siloed approach
- A separate project for each standard: CRA, NIS2, ISO 27001, ENS.
- Duplicate and misaligned asset and product inventories.
- Evidence collected three times for controls that are the same.
- Notifications managed by email, with no deadline traceability.
- No consolidated view of risk for management.
Integrated approach
- A single control framework with traceability to each legal requirement.
- A shared inventory of products, components, and suppliers.
- One piece of evidence satisfies the CRA, NIS2, and ISO 27001 at the same time.
- Notification workflows with 24-hour/72-hour clocks and an auditable record.
- A single risk and compliance dashboard for the committee.
The good news is that an Information Security Management System based on ISO/IEC 27001:2022 covers much of the common ground with Part I and Part II of Annex I: risk analysis, technical vulnerability management, security in development, supplier relationships, and incident management. For the product lifecycle, the sector reference is the IEC 62443 series (especially 62443-4-1 and 4-2) and, for secure software development, ISO/IEC 27034. No certification on its own replaces CRA compliance, but all of them drastically reduce the effort of the gap analysis that comes next.
How to prepare for the CRA: a 7-step roadmap
With September 2026 just around the corner and December 2027 as the horizon for full application, this is the work order that works best:
Inventory and classify your portfolio
List all products with digital elements that you place on the EU market and classify them under Annex III/IV and Implementing Regulation 2025/2392. Also determine your role: manufacturer, importer, or distributor.
Perform a gap analysis against Annex I
Compare each essential requirement with what your development process does today. Identify what is covered by your ISMS, what requires engineering changes, and what requires new documentation.
Prioritize the notification block
It is the first enforceable requirement. Define the process, on-call roles, templates, and the 24-hour, 72-hour, and 14-day clocks, and rehearse it before September 2026.
Generate SBOMs and component traceability
Automate SBOM generation in a machine-readable format and integrate it with vulnerability monitoring for your dependencies.
Set and publish the support period
Decide the period by product family, document the criteria, and coordinate commercial communications: the end date must be visible at the time of purchase.
Extend requirements to your supply chain
Flow CRA requirements into contracts with component suppliers and third-party software providers, and request SBOMs and patching commitments. Your compliance depends on theirs.
Prepare the file and the conformity route
Set up the technical documentation, the EU Declaration of Conformity and, if your product is Class II important or critical, engage the notified body or certification scheme in advance.
How can GRC software help you comply with the Cyber Resilience Act?
At GlobalSuite Solutions, we approach the CRA for what it really is: a governance, risk, and compliance challenge with fixed legal deadlines, not a spreadsheet of technical requirements. Our GlobalSuite® platform enables you to trace each essential Annex I requirement to a control, an owner, and specific evidence, reusing what you already have in place in your ISO 27001-based ISMS, so that the gap analysis stops being a standalone document and becomes an action plan with owners and due-date alerts. On that same foundation, you can manage the product cybersecurity risk assessment, the vulnerability lifecycle linked to the component inventory and the SBOM, the supplier and supply chain assessment, and the notification workflows with 24-hour, 72-hour, and 14-day clocks and an auditable record of every communication to INCIBE-CERT and ENISA. And because almost no organization faces the CRA alone, the platform’s multi-standard approach makes it possible to map common controls once across NIS2, ISO 27001, IEC 62443, DORA, or the ENS, so that one piece of evidence serves multiple frameworks and management has a single dashboard of compliance status and residual risk, ready for an audit or an inspection by the market surveillance authority.
Frequently asked questions about CRA compliance
What is an SBOM and why does the CRA require it?
The Software Bill of Materials (SBOM) is the list of components and dependencies that make up a software product, in a machine-readable format. Annex I, Part II, of the CRA requires it to be produced and maintained—covering at least first-level dependencies—because without knowing the components it is impossible to know whether a published vulnerability affects the product and act within the notification deadlines.
How long must the manufacturer maintain product security?
During the support period, which must be at least five years—or equal to the expected lifetime of the product if that is shorter—and whose end date (month and year) must be known to the buyer at the time of purchase. During that period, the manufacturer manages vulnerabilities and provides security patches free of charge.
Who must an exploited vulnerability be notified to, and within what timeframe?
Simultaneously to the CSIRT designated as coordinator—that of the Member State of the main establishment; in Spain, INCIBE-CERT—and to ENISA, via the single notification platform. The deadlines are 24 hours for the early warning, 72 hours for the notification with product details and measures, and 14 days from when a corrective measure is available for the final report (1 month in the case of severe incidents). In parallel, affected users must be informed.
What technical documentation must be retained, and for how long?
The cybersecurity risk assessment, the technical documentation demonstrating compliance with Annex I, the results of the conformity assessment procedure, and the EU Declaration of Conformity. It must be kept for at least ten years from the product being placed on the market—or for the support period, if longer—and made available to market surveillance authorities.
What is the difference between the CRA and NIS2?
The CRA regulates products and NIS2 regulates organizations. The CRA imposes cybersecurity requirements on what is manufactured and sold, with the CE marking as proof of conformity; NIS2 requires essential and important entities in critical sectors to implement risk management measures and notify incidents. A company may be subject to both, and it is advisable to address them in an integrated way to avoid duplicating controls and evidence.
Does ISO 27001 help with CRA compliance?
It does not replace CRA compliance, but it shortens the path considerably. An ISMS compliant with ISO/IEC 27001:2022 already covers risk management, technical vulnerability management, security in development, supplier relationships, and incident management. For product lifecycle-specific requirements, it should be complemented with the IEC 62443 series and secure development practices.
CRA compliance rests on three blocks. Annex I sets the product’s cybersecurity properties (Part I) and vulnerability management during the support period (Part II), with SBOM, a minimum five-year support period, and a coordinated disclosure policy as the new items with the greatest operational impact. Notification imposes 24-hour, 72-hour, and 14-day clocks to INCIBE-CERT and ENISA. And the CE marking technical file—risk assessment, technical documentation, and EU Declaration of Conformity—must be kept for ten years.
Order matters: first the notification block, because it is enforceable from September 11, 2026 and also applies to products already sold; then the gap analysis against Annex I, the SBOM, the support period, the supply chain, and the file, with a view to December 11, 2027. The more integrated the approach with NIS2 and ISO 27001, the lower the total cost: one piece of evidence can serve multiple frameworks.
Prepare your CRA compliance on a single platform
Traceability from Annex I to control, owner, and evidence; vulnerability management linked to the SBOM; notification workflows with 24-hour and 72-hour clocks and an auditable record; supplier assessment and multi-standard mapping with NIS2 and ISO 27001. We will show you with a real case.
Request a demo
