The EU Compliance Handshake: How CRA Product Certification Reduces Your NIS2 Supply Chain Audit Burden

Last verified: April 2026. Based on Regulation (EU) 2024/2847 (Cyber Resilience Act) and Directive (EU) 2022/2555 (NIS2) via EUR-Lex and official EU sources.

Two EU cybersecurity laws entered force within two months of each other in late 2024. NIS2 (Directive 2022/2555) sets security obligations for organisations in critical sectors. The Cyber Resilience Act — CRA (Regulation 2024/2847) — sets product security requirements for manufacturers of connected hardware and software before those products reach the market. Most compliance commentary treats them as separate problems and leaves it there.

They are not separate at the point of supply chain security — and that distinction has direct operational value. CRA Recital 125 states explicitly that the regulation “aims to facilitate compliance of NIS2 entities, in particular digital infrastructure providers, with their supply chain security obligations, by ensuring that the products with digital elements they use are developed securely” [8]. If your organisation manages supplier risk under NIS2 Article 21(2)(d), understanding this linkage will reduce your audit burden in a specific, actionable way — not in the vague “they complement each other” framing that fills most comparison guides.

This guide explains who each regulation targets, where they overlap operationally, and — the insight no competitor article covers — how CRA product certification can serve as documented supply chain evidence under NIS2 Article 21(2)(d).

Scope at a Glance — Two Laws, Two Targets

The most important structural difference between NIS2 and CRA is the type of legal instrument. NIS2 is a Directive: it required each EU member state to enact national cybersecurity legislation by October 2024. The result is 27 national laws that implement the same obligations differently in detail. CRA is a Regulation: it applies identically across all 27 member states from the moment of entry into force, with no national transposition required.

	NIS2	CRA
Instrument	Directive (national transposition required)	Regulation (applies directly in all member states)
What is regulated	Organisational cybersecurity	Product cybersecurity
Primary targets	Organisations providing essential or important services	Manufacturers, importers, distributors of connected products
Sectors covered	18 critical sectors (Annexes I and II)	All sectors — horizontal regulation
Size threshold	50+ employees or €10M+ annual turnover	None — applies regardless of company size
Geographic trigger	Services provided in EU member states	Products placed on the EU market
Enforced by	National competent authorities	National market surveillance authorities
Main obligations active	October 2024	December 2027 (reporting from September 2026)

Can both apply to the same organisation? Yes — if your organisation operates critical infrastructure in one of NIS2’s 18 covered sectors AND manufactures or distributes connected hardware or software. A medical device manufacturer in the EU healthcare sector is the clearest example: it faces NIS2 obligations as an operator and CRA obligations as a manufacturer simultaneously. Managed security service providers that also ship endpoint software face the same dual exposure.

If your organisation is only a service operator with no product manufacturing role, CRA applies indirectly: your suppliers will be subject to it, and their CRA compliance status will become relevant to your Article 21(2)(d) supply chain assessments. That indirect impact is where the compliance handshake described below becomes useful.

NIS2 Obligations That Matter for This Comparison

NIS2 Article 21(2) defines ten mandatory security measure categories that every in-scope entity must implement. Three create territory that CRA also covers; the third — supply chain security — is where the regulations interact most directly.

Supply chain security — Article 21(2)(d): Entities must address “supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers.” Article 21(3) specifies exactly what this assessment must include: evaluation of supplier-specific vulnerabilities, the “overall quality of products and cybersecurity practices” of each direct supplier, and their secure development procedures [4]. In large vendor ecosystems, meeting this requirement through bespoke questionnaires and audit rights for every supplier is a significant operational burden. This is the specific obligation that CRA certification can reduce — explained in detail in the handshake section below.

Vulnerability handling — Article 21(2)(e): Entities must maintain policies for vulnerability identification, disclosure, and remediation. CRA Article 13 imposes a parallel coordinated vulnerability disclosure requirement on manufacturers. Both obligations apply independently; organisations subject to both must coordinate disclosure processes across the organisational and product tracks.

Incident reporting — Article 23: Significant incidents — those causing severe operational disruption or considerable damage to third parties — must be reported to the national CSIRT: early warning within 24 hours, full notification within 72 hours, final report within one month. The same timelines that CRA Article 14 imposes on manufacturers, reported to different recipients [4].

On penalties: essential entities face fines up to €10 million or 2% of total worldwide annual turnover, whichever is higher. Important entities face fines up to €7 million or 1.4% of global annual turnover [5]. Management bodies that approve and oversee security measures can also face temporary suspension from management roles where gross negligence is established.

For a comprehensive breakdown of all ten Article 21 requirements and the documentation they require, see the NIS2 supply chain security guide and the full directive text analysis.

CRA Obligations That Matter for This Comparison

The Cyber Resilience Act (Regulation EU 2024/2847) applies to “products with digital elements” placed on the EU market that have a direct or indirect data connection to a device or network [1]. This covers connected devices (routers, industrial controllers, smart sensors, medical devices), software (operating systems, applications, firmware), and SaaS products where the remote data processing is integral to a connected hardware product.

What is explicitly excluded: Products not distributed commercially, pure professional services without product distribution, and open-source software published without a commercial model fall outside CRA scope [1].

Classification structure: CRA divides products into tiers that determine how manufacturers must demonstrate compliance. For NIS2 procurement teams, this classification directly affects the strength of supply chain evidence available:

Class	Examples	Conformity path	Evidence quality for NIS2 audits
Default	Most consumer IoT, general software	Manufacturer self-assessment	Manufacturer declaration — lower external verification
Class I (important)	Identity management software, browsers, password managers, VPNs	Harmonised standards or third-party assessment	Standards conformance or independent review
Class II (critical)	Firewalls, HSMs, industrial control systems, smart grid devices	Mandatory independent certification by notified body	Strongest evidence — independent third-party verified

What manufacturers must deliver from December 2027 [1]:

• Cybersecurity risk assessment conducted during product design and development
• Secure-by-default configuration (no unnecessary features or open ports by default)
• Coordinated vulnerability disclosure policy (Article 13)
• Software bill of materials (SBOM) maintained and available to market surveillance authorities
• Security updates provided throughout the declared product support period
• Technical documentation maintained for regulatory review
• EU Declaration of Conformity issued and CE marking affixed

Reporting obligations from 11 September 2026 (Article 14) [2]: Manufacturers must notify actively exploited vulnerabilities and severe security incidents simultaneously to their CSIRT coordinator and to ENISA using the single reporting platform:

• Early warning: within 24 hours of becoming aware
• Full notification: within 72 hours
• Final report: within 14 days for vulnerabilities (after a fix is available); within one month for severe incidents
• Affected users must also be informed when a product vulnerability or incident puts them at risk

Penalties (Article 64) [3]: Failing the essential cybersecurity requirements in Annex I, or failing Articles 13–14 obligations: up to €15 million or 2.5% of global annual turnover. Failing other CRA obligations: up to €10 million or 2%. Providing incorrect or misleading information to market surveillance authorities: up to €5 million or 1%. Small and micro enterprises are exempt from fines specifically for missing Article 14 reporting deadlines — not from other obligations.

Three Areas Where Both Regulations Apply Simultaneously

Despite targeting different actors — organisations versus product manufacturers — NIS2 and CRA converge in three operational domains. Controls designed with both regulations in mind can often satisfy both simultaneously, avoiding duplicate compliance tracks [7].

1. Vulnerability disclosure

CRA Article 13 requires manufacturers to establish and maintain a coordinated vulnerability disclosure (CVD) policy, effective from December 2027. NIS2 Article 21(2)(e) requires in-scope entities to include vulnerability handling as part of their security risk-management framework — already enforceable since October 2024. Where the same organisation operates critical infrastructure and produces connected products, both CVD tracks apply independently. The practical approach: design a unified disclosure process that feeds CRA’s mandatory CVD policy and NIS2’s vulnerability management documentation, with clear internal routing for each regulatory output.

2. Incident reporting

Both frameworks use identical base timelines: 24-hour early warning, 72-hour full notification, one-month final report. But they route reports to different recipients and define “incident” differently. CRA Article 14 triggers on actively exploited product vulnerabilities and severe product security incidents; NIS2 Article 23 triggers on significant service disruptions. A single cyberattack that exploits a product vulnerability to disrupt a critical service can trigger both frameworks simultaneously — requiring two parallel but coordinated notification streams with different audiences and different information requirements.

3. Supply chain security

NIS2 requires organisations to assess and verify their suppliers’ security practices. CRA requires manufacturers to ensure their component suppliers contribute to product security. Both frameworks apply supply chain pressure in both directions. The critical asymmetry is that CRA provides a standardised, EU-recognised conformity mechanism for demonstrating product security — precisely the evidence NIS2 entities need when auditing their vendors. That asymmetry is the basis of the compliance handshake.

The Compliance Handshake — CRA Certification as NIS2 Supply Chain Evidence

NIS2 Article 21(3) requires entities to evaluate the “overall quality of products and cybersecurity practices” of their direct suppliers, including their secure development procedures [4]. The directive does not specify exactly how to conduct that evaluation — it requires a documented risk-management process, leaving the methodology to the entity.

That methodological flexibility creates an opening. CRA provides a standardised, EU-level conformity process that systematically documents product security quality. When a supplier’s product carries a CRA CE mark with an accompanying EU Declaration of Conformity, it provides structured evidence directly addressing the Article 21(3) evaluation criteria:

• Design security: The manufacturer conducted a cybersecurity risk assessment during product development
• Requirements conformance: The product meets the essential cybersecurity requirements in CRA Annex I
• Vulnerability process: A coordinated disclosure policy is in place and active
• Update commitment: A declared support period with security updates is contractually committed
• Third-party verification (Class I and II): An independent notified body or harmonised standards process has verified these claims — not just the manufacturer’s assertion

CRA Recital 125 is the regulatory basis for this connection. It states that the CRA “aims to facilitate compliance of NIS2 entities, in particular digital infrastructure providers, with their supply chain security obligations, by ensuring that the products with digital elements they use are developed securely” [8]. The intent is deliberate: product security certification under CRA is designed to reduce the NIS2 supply chain audit burden, not create a parallel one.

Dallmeier, a security system manufacturer operating under both frameworks, confirms the operational reality: “CRA certified precursors make [NIS2 supply chain compliance] much easier.” When suppliers provide CE conformity certifications with security validation, NIS2-affected organisations can “more readily fulfil” their supply chain security obligation without conducting independent assessments of every product component [6].

Practical procurement workflow using the handshake:

Step 1 — During vendor evaluation: Add CRA conformity status to procurement scoring criteria. For Class II products (firewalls, HSMs, industrial controllers): require third-party notified body certification evidence. For Class I products: harmonised standards compliance or third-party assessment. For default-class products: manufacturer self-declaration with technical documentation available on request. Record the product class and conformity path in the vendor risk register as the basis for your Article 21(3) product quality evaluation.

Step 2 — Before December 2027: Request CRA compliance roadmaps from existing high-criticality suppliers. Which product versions will carry CE marks? When is their conformity assessment scheduled? What product class does your vendor expect to apply? Document responses as part of the ongoing supplier risk review required under Article 21(2)(d).

Step 3 — From December 2027: Update vendor risk assessments to log CE mark status, EU Declaration of Conformity reference numbers, and product class as structured evidence against Article 21(3) criteria. This creates an auditable supply chain assessment record without requiring a bespoke security questionnaire for every product.

Step 4 — Contractually: Embed CRA Article 14 notification obligations in supplier contracts. Require vendors to notify you of actively exploited product vulnerabilities within CRA’s 24-hour window — giving your organisation the advance notice needed to assess whether NIS2 Article 23 incident reporting is triggered by the resulting service impact.

What the handshake does not cover: CRA certification addresses product security only — the security of the device or software itself. Article 21(3) requires evaluation of both product quality AND the supplier’s overall organisational cybersecurity practices: their access controls, incident response procedures, HR security, and training. The handshake reduces the product assessment burden; a separate assessment of the supplier’s organisational security posture remains necessary for a complete Article 21(2)(d) record.

For how this supply chain framework compares to the ISO 27001 approach, see the NIS2 vs ISO 27001 guide.

Incident Reporting Under Both Frameworks

When an incident simultaneously triggers both CRA and NIS2 reporting — for example, an actively exploited vulnerability in a CRA-covered product causing service disruption for a NIS2 entity — two parallel notification tracks must run simultaneously with different recipients, different information requirements, and slightly different final report timelines.

	NIS2 Article 23	CRA Article 14
Trigger	Significant service disruption or damage to third parties	Actively exploited vulnerability or severe product security incident
Early warning (24h)	To national CSIRT	To CSIRT coordinator + ENISA
Full notification (72h)	National CSIRT and competent authority	CSIRT coordinator + ENISA
Final report	Within 1 month	14 days (vulnerabilities) / 1 month (severe incidents)
User notification	Not applicable (institutional only)	Required — affected users must be informed
Applies from	October 2024	11 September 2026

The critical operational risk is inconsistency between the two tracks. A CRA vulnerability notification to ENISA describing one version of the impact, followed by a NIS2 notification to the national CSIRT describing a different version, creates regulatory exposure on both tracks simultaneously. Incident response procedures should explicitly map both reporting obligations — including which team owns each notification and what information each requires — before an incident occurs, not during one.

Does This Apply to Your Organisation?

Use this decision framework to identify which obligations apply and where the compliance handshake is relevant:

Does your organisation operate in one of NIS2’s 18 covered sectors with 50+ employees or €10M+ in annual turnover?

• Yes → NIS2 applies. Proceed to the next question.
• No → NIS2 is unlikely to apply directly to your organisation. Proceed to the manufacturer question below.

Does your organisation also manufacture, import, or distribute hardware or software products for the EU market that include a direct or indirect data connection?

• Yes → Both NIS2 and CRA apply. You face dual organisational and product security obligations — and can use the compliance handshake to reduce the supply chain audit burden under Article 21(2)(d).
• No → NIS2 applies only. Focus on Article 21 organisational measures. Your suppliers, however, may be subject to CRA — and from December 2027, their CRA conformity status becomes structured evidence in your supply chain assessments.

If NIS2 does not apply to you: do you produce or distribute connected hardware or software on the EU market?

• Yes → CRA applies. Main obligations from 11 December 2027; Article 14 reporting from 11 September 2026. Determine your product classification (default / Class I / Class II) as the first step.
• No → Neither regulation applies directly. However, if you supply connected components or software to organisations in NIS2 sectors, your customers will request CRA conformity evidence as part of their Article 21(2)(d) assessments from December 2027 onwards. Preparing a CRA compliance roadmap is commercially relevant even if you are not formally in scope.

Action Timeline

When	Action	Who
Now	Confirm NIS2 applicability by sector and size; begin Article 21 gap analysis against all ten measure categories	NIS2 entities
Now	Determine CRA product classification (default / Class I / Class II) for each product; identify which require third-party notified body engagement	Manufacturers / importers
Now — Dec 2027	Update secure development lifecycle; prepare conformity documentation; engage notified bodies if Class I or II; draft SBOM and vulnerability disclosure policy	Manufacturers
Now — Dec 2027	Request CRA compliance roadmaps from high-criticality product suppliers; document responses in vendor risk register	NIS2 entities
11 Sept 2026	CRA Article 14 reporting begins: actively exploited vulnerabilities and severe incidents must be notified to CSIRT coordinator + ENISA within 24 hours	Manufacturers
11 Dec 2027	Full CRA obligations: CE marking, EU Declaration of Conformity, technical documentation, SBOM, vulnerability disclosure policy all must be in place	Manufacturers
From Dec 2027	Update NIS2 Article 21(2)(d) vendor risk assessments to log CE mark status and DoC reference numbers as structured supply chain evidence	NIS2 entities
Ongoing	Align incident response procedures to cover concurrent NIS2 + CRA reporting; review supplier contracts to include Article 14 notification requirements	Both

Note: The European Commission proposed targeted amendments to NIS2 in January 2026 as part of a broader cybersecurity package that includes a revised Cybersecurity Act (CSA2). These proposals are under legislative review and not yet in force. Monitor ENISA (enisa.europa.eu) for updated implementation guidance as the package progresses.

Frequently Asked Questions

Does CRA CE marking guarantee NIS2 compliance?
No. CE marking under CRA confirms that a product meets the CRA’s essential cybersecurity requirements — not that your organisation complies with NIS2. NIS2 compliance is organisational: it covers how you manage risk, report incidents, train staff, and govern your security program across all ten Article 21 measure categories. CRA certification reduces the evidence burden for one specific obligation (supply chain security under Article 21(2)(d)) — it does not address the other nine.

Can I reduce the supplier security questionnaire if my vendor has CRA certification?
You can simplify the product-focused sections, not eliminate the questionnaire. CRA certification addresses product security. Article 21(3) requires assessment of both product quality AND the supplier’s overall organisational cybersecurity practices — access controls, incident response, HR security. You can substitute or shorten product-specific questions with CRA conformity documentation, but organisational security questions remain necessary for a complete assessment.

My company makes SaaS. Does CRA apply?
It depends on whether the SaaS is part of a product with digital elements. CRA specifically covers remote data processing that is integrated into a connected hardware product — for example, cloud processing that is part of a connected medical device or industrial sensor. Standalone SaaS sold independently without a hardware product component is generally not in scope. If your software connects to customer hardware and the cloud processing is a functional component of that product, CRA assessment is warranted. Pure professional services without product distribution are excluded.

We’re a small manufacturer — do CRA penalties apply to us?
CRA Article 64 includes a narrow exemption: microenterprises and small enterprises are not subject to administrative fines specifically for failing to meet Article 14 reporting deadlines. This covers only the timing aspect of incident reporting. All other CRA obligations — including the essential cybersecurity requirements in Annex I, CE marking, and technical documentation — apply regardless of company size. Small manufacturers face the same conformity requirements as large ones [3].

When does CRA enforcement actually start?
In two stages. Article 14 reporting obligations — the 24-hour early warning for actively exploited vulnerabilities and severe incidents — begin on 11 September 2026. All other main CRA obligations: CE marking, conformity assessment, technical documentation, SBOM, and vulnerability disclosure policy, apply from 11 December 2027. Products already on the market before that date only become subject to full CRA requirements if they undergo substantial modification after December 2027 [1].

Sources

1. The Cyber Resilience Act: Summary of the legislative text — European Commission
2. CRA Article 14: Reporting Obligations of Manufacturers — european-cyber-resilience-act.com
3. CRA Article 64: Administrative Fines — european-cyber-resilience-act.com
4. NIS2 Directive Article 21: Cybersecurity risk-management measures — nis-2-directive.com
5. NIS2 Directive Article 34: Administrative fines — nis-2-directive.com
6. CRA, CE and NIS-2 — Dallmeier
7. Understanding the Relationship Between NIS2 and the EU Cyber Resilience Act — Hyperproof
8. Decoding the Cyber Resilience Act Part 3: Managing CRA Risk in Practice — Freshfields

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.