Cyber Resilience Act: Obligations, Deadlines, and Impact on Business Data Protection

The Cyber Resilience Act is not simply another European directive to file away in a compliance folder. It represents a structural shift in how the European Union approaches the security of digital products, with implications that extend far beyond software developers to include every organization that purchases, integrates, and relies on digital tools to manage sensitive data every day.

For companies operating in regulated sectors such as banking, healthcare, and public administration, the Cyber Resilience Act introduces concrete new responsibilities: from supplier evaluation to the protection of files and emails, to the need to demonstrate that business data is handled using tools that meet essential security requirements. This guide analyzes the CRA regulation in practical terms, focusing on the 2026 deadlines, real obligations, and how encryption and data protection become fundamental levers for building solid, lasting compliance.

What the Cyber Resilience Act Is and Why It Changes the Rules

The Cyber Resilience Act, formally EU Regulation 2024/2847, was published in the Official Journal of the European Union on November 20, 2024, and entered into force on December 10, 2024. Its primary objective is to ensure that all products with digital elements placed on the European market meet minimum cybersecurity requirements throughout their entire lifecycle, from design to retirement.

Before the CRA, cybersecurity for digital products was governed in a fragmented way: sector-specific regulations, voluntary standards, and a regulatory framework that left wide margins of discretion. The CRA introduces, for the first time, a horizontal and binding obligation: digital products must be secure by design and by default, and manufacturers must actively manage vulnerabilities throughout the declared support period.

The regulation’s scope is broad. Manufacturers (including software producers), importers, and distributors operating in the European market are all covered. But, as this guide will explore, purchasing organizations also carry indirect obligations that cannot be ignored.

Which Products and Software Fall Under the CRA

The CRA applies to “products with digital elements”: any hardware or software product that includes digital components capable of communicating with networks or devices. Standalone software, operating systems, applications, firmware, and physical devices with connected components all fall within the scope.

The regulation distinguishes three main categories:

• Standard products: the majority of digital products, subject to conformity assessment through self-assessment (Module A).
• Important products (Annex III): divided into Class I and Class II, these include browsers, password managers, firewalls, industrial control systems, VPNs, and other tools with significant security impact. They require more rigorous conformity pathways.
• Critical products (Annex IV): hardware and software with critical infrastructure impact, such as smartcards, HSMs, and advanced authentication systems. These mandatorily require the involvement of a notified body.

Some relevant exclusions apply: products already covered by specific sectoral regulations (such as medical devices governed by the MDR or motor vehicles), open source software developed outside commercial activities, and pure cloud services not embedded in a product. However, SaaS software that forms an integral part of a product with digital elements may fall within the CRA’s scope. The distinction is not always straightforward and requires case-by-case analysis.

The CRA Obligation Timeline: Key Deadlines in 2026 and 2027

The CRA provides for a phased entry into force, with three fundamental dates that organizations must monitor closely.

June 11, 2026: Entry into Force of Chapter IV

From this date, provisions related to market surveillance authorities and the notification of notified bodies become applicable. Member States must have designated competent authorities and supervisory channels. For organizations, this date marks the beginning of the period in which compliance governance must already be fully operational.

September 11, 2026: Vulnerability and Incident Reporting Obligations

From this date, obligations to report actively exploited vulnerabilities and security incidents become binding. Manufacturers must send an early warning within 24 hours of discovering an actively exploited vulnerability, followed by a complete notification within 72 hours and a final report within 14 days. The primary notification channels are ENISA and the relevant national authorities (in Italy, ACN, the National Cybersecurity Agency).

December 11, 2027: Full Application of All Requirements

This is the date on which all CRA requirements become fully applicable, including essential cybersecurity requirements, documentation obligations, CE marking, and conformity assessments. Products placed on the market after this date must comply in every respect.

The operational message is clear: organizations do not have until 2027 to begin preparing. September 2026 is already approaching rapidly and demands incident management and vulnerability disclosure processes that are already well-established and tested.

Structural Obligations for Software Manufacturers and Suppliers

For those who produce or distribute software, the CRA introduces substantial obligations that fundamentally transform the approach to product development and maintenance.

The essential cybersecurity requirements mandate that products be designed and developed according to the security by design principle: no known vulnerabilities at the time of market placement, secure default configurations (by default), minimized attack surface, protection of data in transit and at rest, robust authentication mechanisms, and the ability to deliver automatic security updates.

On the documentation front, manufacturers must prepare a comprehensive technical file demonstrating compliance with essential requirements. This file includes the product description, cybersecurity risk analyses, tests performed, the vulnerability management policy, and the Software Bill of Materials (SBOM).

SBOM and Software Supply Chain Transparency

The Software Bill of Materials is one of the CRA’s most impactful obligations for software companies. It is a detailed inventory of all software components included in a product: third-party libraries, open source dependencies, and commercial modules. The obligation to produce and maintain an up-to-date SBOM addresses a concrete need: the majority of critical vulnerabilities in recent years have exploited unmonitored third-party components (consider Log4Shell or vulnerabilities in widely used open source libraries).

For organizations that purchase software and integrate it into their systems, the SBOM becomes a supplier evaluation tool. Being able to request and analyze a product’s SBOM before purchase is a practice that the CRA indirectly encourages and that security teams should adopt systematically.

If You Buy Software Rather Than Build It: CRA Obligations That Apply Regardless

The dominant narrative around the CRA focuses on manufacturers. But organizations that purchase, integrate, or distribute software carry concrete responsibilities that cannot be delegated to the supplier.

Importers and distributors have explicit obligations under the regulation: they must verify that the products they place on the European market comply with the CRA, carry CE marking, have available technical documentation, and that manufacturers have implemented vulnerability management processes. If an importer or distributor places a non-compliant product on the market, they are directly liable.

Even organizations that do not formally fall within the category of importers or distributors, but that purchase software for internal use, have a direct interest in their suppliers’ compliance. A product that does not comply with the CRA introduces security risks that fall on the purchasing organization, with potential implications under the GDPR and NIS2 as well.

In practice, a CIO or CISO at a bank, hospital, or public institution must update their vendor assessment processes to include CRA compliance checks, request technical documentation and vulnerability management policies from software suppliers, and insert specific contractual clauses that guarantee ongoing compliance over time.

Software Supplier Contracts: Clauses to Update for CRA Compliance

This is one of the most urgent issues for purchasing organizations, yet it is rarely addressed in practical terms. Contracts with software suppliers entered into before the CRA do not contain the guarantees necessary for effective compliance governance. The following are the contractual areas to update as a priority:

• CRA compliance warranties: the supplier must explicitly declare that the product complies with EU Regulation 2024/2847 and that it will maintain compliance for the duration of the contract.
• Vulnerability notification obligation: the supplier must commit to promptly communicating any relevant vulnerability affecting the supplied product, with timelines aligned to CRA obligations (early warning within 24 hours, complete notification within 72 hours).
• SBOM provision: the contract must include an obligation to provide and update the Software Bill of Materials, with a defined frequency and in a standardized format (for example, SPDX or CycloneDX).
• Support period and security updates: the minimum support period during which the supplier commits to releasing security patches must be specified.
• Audit rights: the purchaser should have the right to request documentary evidence of CRA compliance, including access to the technical file or a certified summary thereof.
• Termination clause for non-compliance: in the event of confirmed CRA non-compliance by the supplier, the purchaser must be able to terminate the contract without penalty.

Conformity Assessment, CE Marking, and Notified Bodies

The conformity pathway under the CRA depends on the product category. For standard products, the manufacturer can proceed with self-assessment (Module A), internally documenting compliance with essential requirements. For Class I important products, harmonized technical standards or European cybersecurity standards may be used to support self-assessment. For Class II important products and critical products, involvement of a notified body is mandatory, with an independent conformity assessment required.

CE marking for digital products compliant with the CRA is not merely a label: it is the public declaration that the product meets essential cybersecurity requirements and that the manufacturer has completed the prescribed assessment process. For purchasing organizations, the presence of CE marking becomes a selection criterion in IT procurement processes.

On the harmonized technical standards front, the European standardization process is still ongoing: standardization bodies (CENELEC, ETSI) are developing standards that will provide a presumption of conformity with CRA requirements. Organizations must monitor the evolution of this framework, as harmonized standards will significantly simplify self-assessment pathways.

The CRA Reshapes Corporate Governance: What Changes for CIOs, CISOs, and Compliance Teams

The CRA redefines internal responsibilities within organizations that produce or use digital products. The CISO is no longer solely the guardian of operational security: they become a key actor in regulatory compliance governance, with responsibilities extending to the software supply chain, document management, and incident response processes.

For IT procurement teams, the CRA introduces new supplier evaluation criteria that must be integrated into procurement processes. CRA compliance of a software product must become a contractual requirement, not an option.

On the regulatory integration front, the CRA does not operate in isolation. Organizations in the banking, healthcare, and public administration sectors must already navigate GDPR, NIS2, and, for the financial sector, DORA. The CRA adds to this framework with specific obligations on digital products, creating potential overlaps but also synergies that, when managed correctly, can reduce the overall compliance burden.

CRA vs GDPR: Where They Overlap and How to Build Unified Compliance

The overlap between the CRA and GDPR is real but manageable. The table below illustrates the most relevant areas of intersection:

Area	GDPR	CRA	Practical Synergy
Privacy/Security by Design	Art. 25: privacy by design and by default	Essential requirements: security by design and by default	A single risk analysis can cover both frameworks
Incident Notification	72 hours for data breach to supervisory authority	24 hours (early warning) + 72 hours (notification) for vulnerabilities to ENISA/national authority	Unified incident response process with differentiated channels
Documentation	Records of processing, DPIA	Technical file, SBOM, declaration of conformity	Integrated document architecture with shared ownership
Encryption	Recommended technical measure for protecting personal data	Essential requirement: protection of data in transit and at rest	Encryption satisfies both frameworks simultaneously
Supplier Management	Art. 28: contracts with data processors	Obligations on importers, distributors, and CRA contractual clauses	Supplier contracts updated to cover both requirements

The guiding principle for building unified compliance is avoiding duplication of effort: a well-structured risk analysis, a security policy that incorporates requirements from both frameworks, and an integrated document governance structure allow organizations to satisfy CRA and GDPR with an optimized organizational investment.

The Penalty Framework: Three Levels of Sanctions

The CRA provides for a graduated penalty system with three levels:

• Maximum sanction: up to 15 million euros or 2.5% of global annual turnover (whichever is higher) for violations of essential cybersecurity requirements and fundamental manufacturer obligations.
• Intermediate sanction: up to 10 million euros or 2% of global turnover for violations of other regulatory obligations, including those applicable to importers and distributors.
• Minor sanction: up to 5 million euros or 1% of global turnover for providing inaccurate, incomplete, or misleading information to market surveillance authorities.

Importers and distributors are expressly subject to the penalty framework: it is not possible to shift responsibility to the manufacturer if a non-compliant product was knowingly placed on the market.

Encryption and Data Protection: How to Meet the CRA’s Essential Requirements

Among the CRA’s essential requirements, the protection of data in transit and at rest is one of the most explicit and verifiable. Encryption is not merely a best practice: it is a direct regulatory requirement that manufacturers must implement and that purchasing organizations must verify in the products they use.

For organizations that handle sensitive data, such as banking institutions, healthcare facilities, and public administrations, file and email encryption represents the first line of defense against data breaches and, at the same time, a concrete tool for demonstrating CRA compliance. A data protection system that encrypts files at rest, protects email communications, and guarantees access control simultaneously satisfies CRA, GDPR, and, in many cases, NIS2 requirements.

The most effective data protection solutions in a CRA-compliant context must guarantee:

• End-to-end encryption of files, regardless of the sharing channel (email, cloud, removable devices).
• Granular access control, with the ability to revoke access to files even after sharing.
• Complete audit trails of file operations, to satisfy traceability and documentation requirements.
• Compatibility with on-premises and hybrid cloud environments, to adapt to existing IT architectures without requiring risky migrations.
• Integration with identity management systems and multi-factor authentication, aligning with the CRA’s robust authentication requirements.

Files, Email, and Business Data: What Changes in Daily Management Under the CRA

The CRA does not only concern software development teams or compliance officers. It has concrete impacts on the daily management of business data, particularly for organizations that handle sensitive information.

On the email front, the CRA requires that software products used for email management satisfy essential security requirements. This means that adopted email security solutions must guarantee data protection in transit, robust authentication mechanisms, and continuous security updates. Organizations must verify that their email security providers are CRA-compliant and request the relevant documentation.

For file sharing, the CRA reinforces the need for solutions that encrypt data before sharing and maintain control over file access even after files have left the organizational perimeter. In a hybrid work context, where files move between personal devices, cloud platforms, and corporate networks, end-to-end protection is no longer an advanced option: it is a basic compliance requirement.

For IT teams, the CRA also introduces the obligation to actively monitor vulnerabilities in internally used software and to act promptly when security patches are released. Patch management processes, often neglected or slowed by operational constraints, must be formalized and documented.

CRA Checklist for Regulated Sectors: Banking, Healthcare, and Public Administration

Organizations in the most regulated sectors have specific needs that require a structured action plan. The following is an operational checklist differentiated by sector.

Banks and Financial Institutions (with DORA Integration)

• Map all software and digital products in use, classifying them according to CRA categories.
• Verify CRA compliance of critical software suppliers, requesting technical files and SBOMs.
• Update supplier contracts with CRA-ready clauses (see dedicated section above).
• Integrate CRA notification obligations (24/72 hours) with incident reporting processes already required by DORA.
• Implement encryption solutions for files and communications that satisfy both CRA and DORA requirements.
• Train IT and compliance teams on the new responsibilities introduced by the CRA.

Healthcare Facilities and Health Data Managers

• Identify medical devices with digital components and verify whether they fall under the CRA or the MDR.
• Verify CRA compliance of management software, EHR systems, and clinical applications.
• Implement encryption of health data at rest and in transit, as required by both CRA and GDPR.
• Define vulnerability disclosure procedures for critical systems, with timelines aligned to the CRA.
• Update the Data Protection Impact Assessment (DPIA) to include CRA risk evaluation.
• Verify that cloud healthcare solution providers have documented vulnerability management processes.

Public Administration

• Conduct an inventory of software currently in use, identifying products subject to the CRA.
• Insert CRA compliance requirements into tender specifications and technical procurement documents for software purchases.
• Verify compliance of current suppliers and plan renegotiation of expiring contracts.
• Integrate CRA obligations with security measures already required by national cybersecurity agency guidelines and minimum security measures.
• Implement data protection solutions that guarantee encryption of sensitive administrative documents.
• Define a training plan for IT managers and compliance officers on CRA obligations.

Preparing for the CRA: Data Protection as the Foundation of Compliance

The Cyber Resilience Act is not a bureaucratic obstacle: it is an opportunity for organizations that want to build a solid and demonstrable security posture. For companies operating in regulated sectors, CRA compliance does not simply add to an already complex regulatory framework; it integrates with it, reinforcing the security measures already required by GDPR, NIS2, and DORA.

Encryption and the protection of business data, files, and email communications are not merely technical measures: they are the concrete response to the CRA’s essential requirements and the foundation on which to build lasting compliance. Organizations that invest today in robust data protection solutions, compatible with on-premises and cloud environments, are better positioned ahead of the 2026 and 2027 deadlines.

The path toward CRA compliance begins with a clear mapping of digital products in use, a supplier evaluation process based on verifiable security criteria, and the implementation of technical solutions that satisfy the regulation’s essential requirements. There is no time to lose: September 2026 is close, and incident management and vulnerability disclosure processes must be fully operational before that date arrives.

Frequently Asked Questions About the Cyber Resilience Act

Does the Cyber Resilience Act apply to SaaS and cloud software?

The CRA does not apply to pure cloud services, which are already regulated by NIS2 and other frameworks. However, SaaS software that forms an integral part of a product with digital elements, or that is provided as a component of a physical product, may fall within the CRA’s scope. The distinction requires case-by-case analysis, taking into account how the software is distributed and integrated. Organizations using SaaS must still verify that their providers have implemented adequate security measures.

What must an organization that purchases rather than produces software do to comply with the CRA?

Purchasing organizations must update vendor assessment processes to include CRA compliance checks, request technical documentation and SBOMs from suppliers, update contracts with CRA-ready clauses, and implement data protection solutions that satisfy essential security requirements. Relying solely on the supplier’s compliance is not sufficient: the purchasing organization carries its own responsibility for managing the risks associated with the digital products it uses.

What penalties does the Cyber Resilience Act impose for non-compliance?

The CRA provides for three penalty levels: up to 15 million euros or 2.5% of global turnover for the most serious violations, up to 10 million euros or 2% for other obligation violations, and up to 5 million euros or 1% for providing inaccurate information to authorities. Penalties apply to manufacturers, importers, and distributors.

How do the CRA and GDPR integrate in business data management?

The CRA and GDPR integrate on multiple levels: both require security by design, both include incident notification obligations (with different timelines), and encryption is a technical measure that satisfies requirements of both frameworks simultaneously. An integrated approach, with a single risk analysis and shared document governance, allows organizations to optimize compliance efforts and avoid duplication.

By when must organizations be fully compliant with the Cyber Resilience Act?

Full compliance is required by December 11, 2027. However, vulnerability and incident notification obligations become binding as early as September 11, 2026. Market surveillance authority provisions enter into force from June 11, 2026. Preparation must begin immediately, without waiting for final deadlines.

Is data encryption alone sufficient to satisfy the CRA’s essential requirements?

Encryption is a fundamental element of the CRA’s essential requirements, but it is not sufficient on its own. The regulation requires a comprehensive approach to security that includes: robust authentication, vulnerability management, attack surface minimization, security updates, and technical documentation. Encryption directly satisfies the requirement for protection of data in transit and at rest, but it must form part of a broader security strategy that addresses all essential requirements holistically.