EU Cyber Resilience Act Makes Cybersecurity a Requirement to Sell in Europe

The European Union’s Cyber Resilience Act is about to change the economics of cybersecurity compliance.

For manufacturers and software companies, the CRA does not simply create another set of security controls, reporting obligations or documentation requirements. It creates a much more direct business consequence:

A product that does not meet the CRA’s requirements may not be legally placed on the EU market.

That makes cybersecurity a condition of market access.

The law applies broadly to “products with digital elements,” including software, connected hardware and certain remote data-processing functionality. It reaches manufacturers, importers, distributors and authorized representatives operating throughout the EU market, and it can also affect companies outside Europe whose products are sold or supplied into the bloc.

The commercial stakes are substantial. Administrative fines can reach €15 million or 2.5% of worldwide annual turnover, whichever is higher. Regulators can also restrict, withdraw or recall noncompliant products. But for many companies, the more immediate risk may be simpler: losing the ability to sell the product in Europe at all.

And the first major deadline is almost here.

Reporting obligations for actively exploited vulnerabilities and severe security incidents begin Sept. 11, 2026. Most of the CRA’s broader product-security obligations become applicable Dec. 11, 2027, while certain notification provisions concerning conformity-assessment bodies have already taken effect.

For companies building software, connected devices, IoT products, networking equipment and digitally enabled products, CRA preparation can no longer be treated as a 2027 problem.

What Is the EU Cyber Resilience Act?

The Cyber Resilience Act establishes cybersecurity requirements for products containing digital functionality.

The law reflects a basic policy concern: connected products frequently enter the market with vulnerabilities, insecure configurations, poor update practices or inadequate long-term support.

Instead of regulating cybersecurity only after a breach occurs, the CRA attempts to move security obligations upstream into product design, development, release and maintenance.

Manufacturers must consider cybersecurity throughout the product lifecycle.

That includes what happens before release and what happens years after the product enters the market.

The IAPP describes the CRA as requiring manufacturers to build products using security-by-design principles while continuing to identify, remediate and report vulnerabilities after those products are sold.

That lifecycle approach is one of the most important changes businesses need to understand.

Cybersecurity can no longer be viewed solely as an IT department function.

It becomes part of:

• product development;
• software engineering;
• procurement;
• legal;
• compliance;
• sales;
• supply-chain management;
• vulnerability management; and
• post-sale product support.

The CRA Applies Far Beyond Traditional Hardware Manufacturers

The word “product” can be misleading.

Companies may assume the CRA is primarily directed at physical devices.

It is not.

The law covers products with digital elements, which can include both hardware and software.

Examples described in the IAPP analysis include:

• smart watches;
• smart televisions;
• connected home appliances;
• virtual assistants;
• mobile applications;
• computer games;
• routers;
• intrusion-detection systems;
• smart machinery;
• transport and logistics IoT devices;
• operating systems;
• browsers;
• cybersecurity software; and
• other software capable of processing, storing or transmitting digital data.

The CRA can also reach functionality that is not physically contained inside the device.

Remote data-processing services supplied by the manufacturer can fall within the product’s regulatory footprint where that functionality is necessary for the product to operate.

That means cloud infrastructure connected to a physical product cannot necessarily be analyzed separately from the device itself.

A connected thermostat, for example, may appear to be one product.

Legally and technically, however, the relevant ecosystem may include the device, firmware, mobile application, authentication service, cloud processing layer, APIs and software dependencies supporting its operation.

CRA compliance requires companies to understand that complete system.

U.S. Companies Can Be Pulled Into the CRA

The CRA has an important extraterritorial dimension.

A manufacturer does not need to be headquartered in Europe for the law to matter.

If its covered products are made available on the EU market, the CRA can apply.

That includes companies supplying products commercially in any EU member state.

The IAPP also notes that companies supplying components to CRA-regulated manufacturers may face indirect requirements even when they are not independently within the law’s primary scope.

Manufacturers have due-diligence obligations relating to third-party components.

As a result, CRA requirements are likely to flow down supply chains contractually and operationally.

This is particularly important for U.S. software vendors.

A company may conclude that its product does not directly trigger a particular CRA obligation, only to discover that a major European customer now requires:

• vulnerability-disclosure commitments;
• SBOM information;
• security certifications;
• patching obligations;
• development-security documentation;
• vulnerability notification deadlines; or
• contractual security representations

because that customer needs the information to satisfy its own CRA obligations.

This is how large regulatory frameworks spread through supply chains.

The First Question Is Whether the Product Is in Scope

Organizations should begin with a comprehensive product inventory.

That sounds basic, but for large organizations it can be surprisingly difficult.

A global business may maintain:

• current product lines;
• legacy products;
• mobile applications;
• customer portals;
• embedded software;
• device firmware;
• cloud-supported functionality;
• open-source components;
• acquired product portfolios;
• regional versions;
• white-label products; and
• discontinued products still receiving maintenance.

The IAPP recommends that organizations map products geographically and organizationally, beginning with design and planning and extending through delivery and maintenance. Product engineering, security and sales teams all need to participate because CRA applicability can directly affect whether sales targets can be achieved in Europe.

Companies should therefore build a product register that answers several basic questions:

What products do we sell into Europe?

Which contain digital elements?

Which have network connectivity?

Which rely on remote cloud processing?

Which products are still supported?

Which product versions will remain on the market after December 2027?

Who manufactured them?

Who imports them?

Who distributes them?

Which third-party components are embedded?

Which open-source libraries are present?

That inventory becomes the foundation of the entire CRA program.

Product Classification Determines the Compliance Path

The CRA effectively creates several levels of product risk.

Most covered products fall into a default category.

Other products are classified as “important” or “critical,” with increasing levels of cybersecurity concern and corresponding conformity requirements.

The default category covers products not otherwise classified as important or critical.

Manufacturers of those products generally have greater flexibility when demonstrating conformity and may, in some circumstances, rely on internal conformity procedures rather than mandatory independent assessment.

Important products are divided into Class I and Class II.

Class I examples include technologies such as:

• smart-home virtual assistants;
• wearable health products;
• web browsers;
• operating systems;
• security information and event management systems; and
• malware detection or removal software.

Class II includes more security-critical technologies such as certain firewalls, intrusion-detection and prevention systems and microprocessors.

Class II products generally face stricter conformity requirements because of their cybersecurity significance.

Critical products occupy the highest tier.

Examples include certain hardware devices containing security boxes, smart cards and smart-meter gateways. These products perform security-sensitive functions where compromise could produce significant adverse effects across other systems.

Classification therefore is not an academic exercise.

It determines how the company proves compliance.

Security by Design Becomes a Legal Requirement

The CRA requires covered products to be designed, developed and produced with cybersecurity appropriate to their risks.

That moves security-by-design from a best practice into a regulatory expectation.

The IAPP identifies several characteristics organizations should be prepared to validate, including:

• absence of known exploitable vulnerabilities;
• secure-by-default configuration;
• protection against unauthorized access;
• appropriate confidentiality and integrity protections;
• modern encryption for data at rest and in transit;
• data minimization;
• resilience against denial-of-service attacks; and
• reduction of attack surfaces.

The practical consequence is significant.

Security review needs to begin before a product is released.

Companies should no longer build a product, launch it and then attempt to document its cybersecurity posture afterward.

Engineering decisions themselves become part of compliance.

That requires closer coordination between privacy, security, engineering and legal teams.

Secure by Default May Be Just as Important as Secure by Design

One particularly important CRA concept is secure-by-default configuration.

Historically, many technology companies offered optional security settings that users could activate themselves.

The CRA pushes companies toward the opposite model.

Security should be configured appropriately from the beginning.

That can influence decisions involving:

• default passwords;
• authentication;
• encryption;
• exposed network services;
• administrator privileges;
• remote access;
• telemetry;
• data collection;
• software permissions; and
• automatic security updates.

A product that technically supports strong security but ships with insecure settings may create a materially different CRA risk than a product where those protections are active automatically.

This reflects a broader movement in digital regulation.

Regulators increasingly care not merely whether users can protect themselves, but whether products protect users without requiring technical expertise.

Data Minimization Is Now a Cybersecurity Requirement Too

The CRA’s security requirements also include data minimization.

Privacy professionals will recognize that concept immediately from the GDPR.

But under the CRA, minimization also serves a cybersecurity purpose.

Every piece of unnecessary information stored, transmitted or exposed by a digital product expands the consequences of compromise.

Reducing unnecessary data can reduce:

• breach impact;
• attack surface;
• credential exposure;
• unauthorized secondary use;
• retention risk; and
• downstream vendor exposure.

This is another example of privacy and cybersecurity governance converging.

Organizations increasingly cannot run one privacy program and one separate security program without connecting them.

The same architecture can create risk under both.

The Software Supply Chain Moves Into the Regulatory Spotlight

One of the most important operational changes under the CRA concerns software components.

Modern software is rarely built entirely from proprietary code.

Applications can depend on hundreds or thousands of:

• open-source libraries;
• packages;
• APIs;
• SDKs;
• embedded components;
• third-party modules; and
• cloud services.

A vulnerability inside one dependency can compromise the larger product.

The CRA therefore requires manufacturers to understand their software supply chains.

According to the IAPP analysis, manufacturers must generate software bills of materials, commonly referred to as SBOMs, documenting relevant software components.

The SBOM must use a commonly used, machine-readable format and cover at least the product’s top-level dependencies.

For many organizations, this may require substantial operational change.

Companies that cannot reliably identify what code is inside their own products will struggle to assess vulnerabilities when newly discovered flaws emerge.

Third-Party Components Become Your Compliance Problem

The CRA also imposes due-diligence expectations when manufacturers incorporate third-party or open-source components.

Organizations may need to evaluate factors including:

• whether the component has appropriate CE markings where relevant;
• the supplier’s security-update history;
• known vulnerability databases;
• the component’s SBOM; and
• the security posture of the component manufacturer.

This is a major supply-chain governance issue.

A manufacturer cannot simply say:

“We didn’t write that code.”

If the component becomes part of the covered product, weaknesses inside the component may become part of the manufacturer’s CRA problem.

This has significant implications for procurement teams.

Cybersecurity due diligence increasingly needs to occur before a component is integrated into a product.

Supplier Contracts Will Need to Change

Legal teams should expect procurement agreements to evolve alongside the technical requirements.

The IAPP specifically recommends coordinating supplier contracts so component manufacturers provide strong security representations and agree to aggressive vulnerability-reporting timelines.

Future CRA-related contracts may increasingly address:

• vulnerability notification;
• security patches;
• end-of-life support;
• SBOM delivery;
• cooperation with incident investigations;
• disclosure of known vulnerabilities;
• security testing;
• regulatory assistance;
• component replacement;
• liability allocation; and
• audit rights.

Companies waiting until after a vulnerability appears to negotiate these rights may discover they have little leverage.

The CRA therefore makes cybersecurity procurement a legal and commercial issue as much as a technical one.

The September 2026 Reporting Deadline Is the Immediate Priority

Most CRA obligations begin in December 2027.

But companies should not let that date create a false sense of time.

The law’s vulnerability and incident-reporting obligations begin Sept. 11, 2026.

That makes reporting readiness the immediate compliance issue.

Organizations should already be determining:

• who receives vulnerability reports;
• who decides whether a vulnerability is actively exploited;
• which products are affected;
• how engineering escalates incidents;
• who owns regulatory reporting;
• what evidence must be preserved;
• which customers need notification;
• whether third-party suppliers have reporting obligations; and
• how the company meets extremely short regulatory deadlines.

The biggest problem during a serious vulnerability is often not discovering that something is wrong.

It is determining who knows what, which products are affected and who has authority to make regulatory decisions.

That process needs to exist before the incident occurs.

Existing Products Cannot Be Ignored

Another major issue involves products already on the market.

Companies may be focused on developing new products that will comply with the CRA by December 2027.

But existing products may also need attention if they remain commercially available after the law becomes applicable.

IAPP specifically warns manufacturers to evaluate products already in the market and determine whether changes are required for those products to remain available after Dec. 11, 2027.

That can create difficult decisions.

For every legacy product, manufacturers may need to choose among:

• remediating it;
• redesigning it;
• updating software;
• changing components;
• performing conformity assessments;
• continuing support;
• withdrawing it from Europe; or
• ending the product’s lifecycle.

This can quickly become a portfolio-management issue rather than a pure compliance exercise.

CE Marking Is Moving Into Cybersecurity

The CE mark is already familiar across the European market.

It indicates that products comply with applicable EU requirements governing areas such as health, safety and environmental protection.

The CRA extends this conformity model into cybersecurity.

Covered products will need to satisfy the relevant CRA requirements before the CE marking can validly attest to their cybersecurity conformity.

Depending on the product category, the manufacturer may be able to use internal assessment procedures or may need external conformity assessment.

More sensitive categories, including certain important and critical products, face stricter third-party assessment requirements.

This changes the role of cybersecurity documentation.

Security is no longer merely something companies describe to enterprise customers in questionnaires.

It becomes part of the evidence necessary to legally market the product.

Cybersecurity Now Directly Affects Revenue

This may ultimately be the CRA’s biggest strategic impact.

Many cybersecurity regulations impose penalties after noncompliance.

The CRA can interfere with revenue before the sale happens.

A company could have:

• customers ready to buy;
• sales contracts negotiated;
• distribution channels established;
• marketing campaigns prepared; and
• products physically ready to ship,

but still face problems selling those products in Europe if required conformity has not been achieved.

That puts CRA readiness directly in the path of:

• revenue forecasting;
• European expansion;
• product-launch schedules;
• channel partnerships;
• distribution agreements; and
• M&A due diligence.

Chief revenue officers and product leaders therefore need to understand the CRA alongside security and compliance teams.

CRA Readiness Should Become a Cross-Functional Program

The companies most likely to struggle with the CRA are those that treat it as a cybersecurity department project.

Security teams cannot independently determine product-market scope.

Legal teams cannot independently generate SBOMs.

Engineering teams cannot independently decide regulatory reporting obligations.

Procurement cannot independently evaluate how a vulnerable third-party component affects CRA conformity.

Sales teams may not know that a product’s planned European launch is dependent on conformity assessment.

A credible CRA program therefore needs participation from:

• cybersecurity;
• engineering;
• product;
• privacy;
• legal;
• procurement;
• supply-chain management;
• sales;
• compliance;
• incident response; and
• executive leadership.

The objective should be to integrate CRA controls into existing product-development processes rather than create a separate compliance exercise that occurs just before release.

What Companies Should Be Doing Now

With the first reporting obligations taking effect in September 2026 and the broader requirements following in December 2027, companies selling digital products into Europe should already be working through several areas.

First, identify every potentially covered product and determine which ones are marketed or distributed in the EU.

Second, classify those products under the CRA.

Third, map their software and hardware dependencies.

Fourth, begin generating and maintaining SBOMs.

Fifth, identify known vulnerabilities and establish repeatable vulnerability-management processes.

Sixth, review default security configurations.

Seventh, evaluate encryption, authentication, access controls, data minimization and attack-surface reduction.

Eighth, review third-party component suppliers and contracts.

Ninth, prepare the reporting process required for actively exploited vulnerabilities and severe incidents.

Tenth, determine which products will require external conformity assessment and begin planning for CE marking.

And finally, evaluate legacy products that will remain available in Europe after December 2027.

Waiting until late 2027 may leave companies with an impossible choice between delaying European sales and rushing security work that should have been embedded much earlier in product development.

The Bigger Regulatory Shift: Security Is Becoming Part of Product Safety

The CRA reflects a significant change in how governments conceptualize cybersecurity.

Historically, cybersecurity was often treated as an enterprise-management problem.

Organizations protected networks.

Security teams protected servers.

Incident-response teams dealt with breaches.

The CRA treats cybersecurity differently.

It treats cybersecurity as part of the safety and conformity of the product itself.

That means a vulnerable connected product can increasingly be viewed the same way regulators have historically viewed other unsafe products.

The regulatory question becomes:

Should this product be allowed on the market?

That is substantially more consequential than asking whether the manufacturer followed a cybersecurity framework.

Security Does Not End at the Date of Sale

Another important CRA principle is that cybersecurity obligations continue after the product reaches the customer.

Vulnerabilities will emerge.

Dependencies will change.

Threat actors will discover new exploits.

Software components that were secure when the product launched may become vulnerable later.

Manufacturers therefore need lifecycle security processes capable of identifying and addressing weaknesses over time.

The product cannot simply be declared compliant on launch day and forgotten.

CRA compliance is ongoing.

That means long-term vulnerability management, updates, support processes and security monitoring need to become part of the product’s economic lifecycle.

Companies may ultimately need to reconsider how long they support products and whether their pricing models adequately account for years of security obligations after the original sale.

The CRA Will Reshape Product Development Far Beyond Europe

European digital regulation frequently influences global product design.

Companies do not always maintain completely separate products for European and non-European markets.

If a company must develop:

• secure defaults;
• better vulnerability management;
• SBOMs;
• stronger supply-chain controls;
• improved patching processes;
• reduced attack surfaces; and
• formal incident reporting

to remain in the European market, many of those controls may ultimately become part of the company’s global product-development standards.

The CRA may therefore have influence well outside the EU.

Just as the GDPR affected privacy programs around the world, the CRA could push global manufacturers toward a higher baseline for product cybersecurity.

The Deadline Is Really a Product-Development Deadline

December 2027 sounds distant when viewed as a regulatory date.

It is much closer when viewed through a product-development cycle.

Products expected to be sold in late 2027 may already be:

• in design;
• under development;
• undergoing component selection;
• entering procurement;
• moving through testing;
• being positioned for sales; or
• appearing on future product roadmaps.

The security architecture for those products is being decided now.

That is why CRA preparation cannot wait until conformity assessment begins.

By that point, fixing fundamental architectural weaknesses may require redesigning the product.

The better approach is to make CRA requirements part of design decisions while those decisions can still be changed economically.

Cybersecurity Compliance Has Become a License to Sell

The Cyber Resilience Act represents one of the clearest examples yet of cybersecurity moving from voluntary best practice to mandatory product governance.

For covered manufacturers, the implications are difficult to overstate.

The CRA affects product architecture.

It affects software dependencies.

It affects vendor contracts.

It affects vulnerability management.

It affects incident response.

It affects procurement.

It affects CE marking.

And ultimately, it affects whether the product can legally be sold in one of the world’s largest markets.

That is why the CRA should not be framed internally as another regulatory checklist.

It is a market-access requirement.

Companies that embed security into product design, understand their software supply chains and build the evidence necessary to demonstrate conformity will be positioned to continue operating across the EU.

Companies that wait may discover that cybersecurity debt has turned into something much more expensive:

a barrier between their product and their customers.