CRA and NIS2: Where Cybersecurity Regulations Overlap for Product Companies

You manufacture IoT devices for the energy sector. You're subject to both NIS2 (as an operator of essential services) and CRA (as a product manufacturer). Two regulations, overlapping requirements, one compliance budget.

This guide explains how CRA and NIS2 interact and how to manage compliance with both.

CRA vs NIS2: Fundamental Difference

CRA: Product Regulation

What it regulates: Products with digital elements placed on the EU market

Who it applies to: Manufacturers, importers, distributors of products with digital elements

Focus: Product security throughout lifecycle

• Secure design and development
• Vulnerability handling for products
• Security updates for products
• Product-level incident reporting

NIS2: Organizational Regulation

What it regulates: Cybersecurity of essential and important entities

Who it applies to: Organizations in specified sectors meeting size thresholds

Focus: Organizational cybersecurity

• Governance and risk management
• Incident handling for services
• Supply chain security
• Business continuity

The Overlap Zone

NIS2 SCOPE                          CRA SCOPE
+----------------------+          +----------------------+
| - Your IT systems    |          | - Products you       |
| - Your services      |          |   manufacture        |
| - Your operations    |          | - Products you       |
| - Your supply chain  |          |   import             |
|   (as procurer)      |          | - Products you       |
|                      |          |   distribute         |
+----------+-----------+          +-----------+----------+
            \                                /
             \                              /
              +----------------------------+
              |          OVERLAP           |
              |                            |
              | - Vulnerability management |
              | - Incident reporting       |
              | - Supply chain security    |
              | - Security governance      |
              +----------------------------+

Who Faces Both Regulations?

Scenario 1: Essential Entity That Manufactures Products

Example: Energy company that manufactures smart grid components

• NIS2 applies: Energy sector entity above threshold
• CRA applies: Manufacturer of products with digital elements

Both regulations require:

• Cybersecurity risk management
• Vulnerability handling
• Incident reporting (to different bodies, different triggers)
• Supply chain security

Scenario 2: Important Entity That Manufactures IoT

Example: Manufacturing company that makes industrial IoT sensors

• NIS2 applies: Manufacturing sector entity above threshold
• CRA applies: Manufacturer of products with digital elements

Scenario 3: Digital Infrastructure Provider

Example: Cloud provider that also sells hardware appliances

• NIS2 applies: Digital infrastructure provider
• CRA applies: Manufacturer of hardware products

Scenario 4: Healthcare Product Manufacturer

Example: Medical device adjacent company (not MDR-covered devices)

• NIS2 applies: Healthcare sector entity
• CRA applies: Products not covered by MDR exclusion

Overlapping Requirements

Vulnerability Management

Coordination opportunity: Unified vulnerability management program covering both products and organizational systems.

Incident Reporting

Key distinction: A vulnerability in your product might trigger CRA reporting even if your services aren't affected. A service outage might trigger NIS2 reporting even if no product vulnerability exists.

Supply Chain Security

Coordination opportunity: Integrated supplier management covering both product components and organizational suppliers.

Reporting Comparison

CRA Reporting Path

PRODUCT VULNERABILITY (actively exploited)
         |
         ▼
    24-HOUR EARLY WARNING
    To: ENISA Single Reporting Platform
         |
         ▼
    72-HOUR DETAILED NOTIFICATION
    To: ENISA + relevant CSIRTs
         |
         ▼
    14-DAY FINAL REPORT (vulnerability)
    30-DAY FINAL REPORT (incident)

NIS2 Reporting Path

SIGNIFICANT INCIDENT (affecting services)
         |
         ▼
    24-HOUR EARLY WARNING
    To: National competent authority or CSIRT
         |
         ▼
    72-HOUR INCIDENT NOTIFICATION
    To: National competent authority or CSIRT
         |
         ▼
    1-MONTH FINAL REPORT
    To: National competent authority or CSIRT

When Both Apply

A single event could trigger both:

Example: Zero-day in your product is actively exploited, affecting customers who are essential entities (like energy companies using your smart grid equipment).

CRA reporting: You report the actively exploited vulnerability (you're the manufacturer)

NIS2 reporting: Your affected customers may report the incident (they're the essential entities)

Your internal reporting: If you're also an essential entity using your own products, you might report under both

How to Run One Security Program for CRA and NIS2

Unified Security Governance

Instead of separate CRA and NIS2 compliance programs:

UNIFIED CYBERSECURITY GOVERNANCE

Board Level:
- Single cybersecurity risk oversight
- Combined reporting to management

Operational Level:
- One vulnerability management program
  +-- Product vulnerabilities (CRA focus)
  \-- System vulnerabilities (NIS2 focus)

- One incident response capability
  +-- Product incidents (CRA reporting)
  \-- Service incidents (NIS2 reporting)

- One supply chain security program
  +-- Product components (SBOM, CRA)
  \-- Service suppliers (NIS2)

Process Mapping

Documentation Efficiency

Some documentation can serve both:

How CRA and NIS2 Enforcement Differ

CRA Enforcement

• Market surveillance authorities monitor products
• Focus on product compliance
• Penalties up to €15M or 2.5% global turnover
• Product withdrawal/recall possible

NIS2 Enforcement

• National competent authorities supervise entities
• Focus on organizational compliance
• Penalties up to €10M or 2% global turnover
• Personal liability for management possible

Double Jeopardy?

A single failing could theoretically trigger enforcement under both:

Example: Poor vulnerability management leads to unpatched product AND unpatched internal systems.

• CRA: Non-compliance with vulnerability handling requirements
• NIS2: Non-compliance with risk management measures

In practice: Regulators should coordinate. Demonstrating unified compliance helps.

Compliance Timeline Interaction

NIS2 Timeline

• October 2024: NIS2 transposition deadline
• 2024-2025: Member state implementation
• Ongoing: Compliance required

CRA Timeline

• September 2026: Reporting obligations begin
• December 2027: Full compliance required
• Ongoing: Product lifecycle obligations

Coordinated Approach

2024                    2025                    2026                    2027
|                       |                       |                       |
▼                       ▼                       ▼                       ▼
+-----------------------------------------------------------------------+
| NIS2: Organizational compliance required throughout                   |
\-----------------------------------------------------------------------+
                                                |                       |
                                                ▼                       ▼
                                        +-------------------------------+
                                        | CRA: Reporting | CRA: Full    |
                                        \-------------------------------+

RECOMMENDATION:
Build unified cybersecurity program now that serves both.
Don't build separate NIS2 and CRA compliance programs.

Practical Coordination Checklist

Governance Integration

DUAL-REGULATION GOVERNANCE CHECKLIST

ORGANIZATIONAL:
[ ] Single cybersecurity governance structure
[ ] Board-level oversight covers both product and service security
[ ] Combined cybersecurity strategy
[ ] Unified budget allocation

RISK MANAGEMENT:
[ ] Integrated risk assessment (products + services)
[ ] Combined risk register
[ ] Unified risk treatment process
[ ] Single risk reporting framework

VULNERABILITY MANAGEMENT:
[ ] One vulnerability intake channel
[ ] Combined triage process
[ ] Integrated remediation workflow
[ ] Unified metrics and reporting

INCIDENT RESPONSE:
[ ] Combined incident response plan
[ ] Clear routing for CRA vs NIS2 reporting
[ ] Integrated communication procedures
[ ] Unified post-incident review

Reporting Integration

DUAL-REGULATION REPORTING MATRIX

Event Type                        Report Under
-------------------------------------------------------------
Product vuln (not exploited)      Neither (CVD process only)
Product vuln (exploited)          CRA → ENISA
Service incident (no product)     NIS2 → National authority
Both (product vuln → service)     Both (coordinate)
-------------------------------------------------------------

Internal Escalation:
1. Security team assesses event
2. Determine: Product impact? Service impact?
3. Route to appropriate reporting path(s)
4. Coordinate if both apply

Supply Chain Integration

UNIFIED SUPPLY CHAIN SECURITY

For Product Components (CRA focus):
- SBOM maintained
- Component vulnerability monitoring
- Supplier security questionnaire
- Technical due diligence

For Service Suppliers (NIS2 focus):
- Supplier risk assessment
- Security requirements in contracts
- Ongoing monitoring
- Incident notification clauses

INTEGRATED APPROACH:
- Single supplier management system
- Combined risk assessment framework
- Unified contract security requirements
- Coordinated monitoring program

Where Dual-Scope Edge Cases Need Extra Scoping

Industrial Control Systems

IACS (Industrial Automation and Control Systems) face particular complexity:

• CRA: If you manufacture IACS for essential entities (NIS2), it's Important Class II
• NIS2: If you operate IACS as an essential entity, they're in scope

Double requirement: Product must meet CRA; operation must meet NIS2.

Cloud Services + Products

Cloud providers selling hardware appliances:

• NIS2: Cloud service operations
• CRA: Hardware appliances sold

Example: A cloud provider's firewall appliance must comply with CRA; their cloud service operations must comply with NIS2.

Healthcare Adjacent

Medical device manufacturers might have:

• Some products under MDR (excluded from CRA)
• Some products under CRA (not MDR-covered)
• Organization under NIS2 (healthcare sector entity)

Careful scoping required: Map each product to applicable regulation.

CRA and NIS2 FAQ for Product Manufacturers

When does one event trigger both CRA and NIS2 reporting?

When an actively exploited vulnerability in your product also causes a significant incident affecting your services. CRA reporting is triggered by the exploited product vulnerability: you file a 24-hour early warning with ENISA, then a 72-hour notification. NIS2 reporting is triggered separately if your services are disrupted: you file with your national competent authority or CSIRT on the same 24/72-hour schedule. The two reports cover different subjects. CRA focuses on the product and the vulnerability. NIS2 focuses on the service impact and your response. Both can be required for the same root event.

Who files the report if the manufacturer is also an essential entity?

You file both, and you file them separately. As the product manufacturer, you report the exploited vulnerability to ENISA under CRA. As an essential entity, you report the service incident to your national competent authority or CSIRT under NIS2. The two filings are independent: different forms, different recipients, different deadlines in some cases. Assign a named owner for each reporting path before an incident occurs. Do not assume one report satisfies the other.

Can one risk register serve both CRA and NIS2?

Yes, if it separates product risks from organizational risks. Structure the register so product-level risks (component vulnerabilities, update failures, conformity gaps) are clearly distinct from organizational risks (service continuity, governance failures, supply chain disruptions). Both sets of risks can sit in the same document and share a common scoring methodology. What cannot be merged is the treatment: CRA risk treatment leads to product controls and technical file updates; NIS2 risk treatment leads to organizational measures and policy changes. Keep the entries distinct so each audit can find what it needs.

How should supplier due diligence differ for components versus service providers?

For product components under CRA, due diligence is technical: you need an SBOM covering the component, evidence of vulnerability monitoring by the supplier, and a contractual obligation to notify you of exploitable vulnerabilities within a defined window. For service providers under NIS2, due diligence is organizational: you assess their security governance, incident response capability, business continuity, and whether they meet the NIS2 security measures that apply to your sector. Both types can share a common questionnaire template, but the evaluation criteria and the contractual clauses are different.

What evidence should be kept to show coordinated compliance across both regimes?

Keep three things. First, a mapping document showing which internal processes serve which regulatory obligation, so an auditor can trace any CRA or NIS2 requirement to a specific control. Second, incident records that show both reporting paths were triggered correctly when events qualified, with timestamps and recipient confirmations. Third, board or management reporting that covers both product security and organizational security under a single governance structure, showing that oversight is unified. If you are audited under CRA and NIS2 in the same year, this evidence is what demonstrates you run one program, not two disconnected ones.

How do national NIS2 transposition differences affect a cross-border manufacturer?

NIS2 is a directive, not a regulation, which means each EU member state transposes it into national law. The core obligations (risk management, incident reporting, supply chain security) are consistent, but the competent authority, the sector thresholds, and sometimes the penalty structure differ by country. A manufacturer operating in Germany, France, and Poland must identify which national authority supervises each entity, register with the correct body in each jurisdiction, and route NIS2 incident reports to the right national CSIRT. CRA, by contrast, is a regulation and applies uniformly across the EU. If you sell a product in any EU country, the same CRA obligations apply.

Next Steps

Start by confirming whether your company is both a product manufacturer and an essential or important entity under NIS2. Use the product classification guide to map each product to its CRA class. Then map product risks and service risks separately in a single register that keeps them distinct. Define the internal reporting triggers for CRA versus NIS2 and assign a named owner for each path. Unify your supplier and vulnerability intake workflows so both types of suppliers flow through one process. For a full view of CRA deadlines, see the CRA implementation timeline. Then run a joint tabletop exercise simulating a product incident that also affects your services: this will expose gaps in your dual-scope response before a real event does.

This article is for informational purposes only and does not constitute legal advice. For specific compliance guidance, consult with qualified legal counsel.