Module 10: Governance, Contracts, and Supply Chain Responsibilities - Understanding the EU Cyber Resilience Act: What Software Manufacturers Need to Do

Q: A German company buys a smart camera with embedded software from a Korean manufacturer. It rebrands the camera with its own logo, modifies the firmware to add AI analytics, and sells it in the EU. Under the CRA, what role does the German company primarily have?

Manufacturer (with full manufacturer obligations). By **rebranding** and **modifying the firmware** in a way that affects security and functionality, the German company is treated as a **manufacturer** under the CRA. It must meet full manufacturer obligations, including risk assessment, technical documentation, conformity assessment, CE marking, and vulnerability handling. The original Korean company may still have obligations, but the rebranding EU entity cannot rely solely on being an importer or distributor.

1. Where Governance Meets the CRA Supply Chain

In this module we connect the EU Cyber Resilience Act (CRA) to how organisations are governed and how they manage suppliers.

As of late 2024, the CRA has been politically agreed and is in the final stages of formal adoption (Regulation, not a Directive). That means:

It will be directly applicable EU law (no national transposition needed).
Duties apply along the economic operator chain:
Manufacturer (including many software publishers and brand owners)
Authorised representative
Importer
Distributor

This module focuses on:

How to assign internal responsibilities for CRA compliance.
How to write contracts with suppliers and OEMs to cover CRA obligations.
When an importer, distributor, or brander is treated as a manufacturer under the CRA.
How to monitor supplier compliance (audits, documentation, SBOMs).

Keep in mind links to previous modules:

From Module 8: technical documentation and SBOM must often be supported by your suppliers.
From Module 9: conformity assessment and CE marking depend on having a compliant supply chain.

> Visualize a chain: upstream developers → component suppliers → OEM integrator → importer → distributor → end‑user. CRA pushes security and documentation duties all the way up and down that chain.

2. Mapping CRA Roles Inside the Organisation

To comply with the CRA, companies need clear internal governance. Think of it as a RACI chart (Responsible, Accountable, Consulted, Informed) mapped to CRA articles.

Typical internal roles:

Board / Senior Management
Approves security and CRA compliance strategy.
Ensures adequate resources for secure development, vulnerability handling, and documentation.

Product Owner / Product Manager
Owns the product’s CRA lifecycle: from design to updates and end-of-life.
Ensures products are correctly classified (critical, high-risk, etc. under CRA categories) and the right conformity assessment route is used.

Security / Product Security Team (PSIRT)
Runs secure development lifecycle (SDL) practices.
Manages vulnerability handling, incident response, and security updates as required by CRA.
Interfaces with EU cybersecurity authorities if serious vulnerabilities or incidents must be reported (CRA aligns with NIS2-style obligations).

Legal / Compliance
Interprets CRA requirements and translates them into policies and contract clauses.
Checks when the company is acting as manufacturer, importer, or distributor.

Procurement / Supplier Management
Ensures contracts with suppliers include CRA-related obligations (SBOM, security support, vulnerability disclosure, etc.).
Monitors ongoing compliance (e.g., certifications, audit reports).

Engineering / DevOps
Implements secure coding, logging, update mechanisms, and configuration requirements mandated by CRA.
Integrates third‑party components in a way that respects security and documentation duties.

> Governance tip: Many organisations create a CRA Steering Group (security + legal + product + procurement) to coordinate responsibilities.

3. Quick Governance Mapping Exercise

Imagine you are in a mid‑size SaaS company that will place a CRA‑covered product on the EU market.

Task: For each CRA activity below, decide which internal role should be primarily Responsible (R) and which should be Accountable (A). You can write your answers on paper or in a text editor.

Activities:

Approving the vulnerability handling policy and response timelines.
Deciding whether the product is in a higher‑risk CRA class and needs third‑party assessment.
Making sure supplier contracts include SBOM delivery and security update obligations.
Maintaining the technical documentation file and ensuring it is complete for conformity assessment.
Deciding when to end security support for a product and how to notify users.

Roles to choose from:

Board / Senior Management
Product Manager
Security / PSIRT Lead
Legal / Compliance Lead
Procurement Lead
Engineering Lead

> After you assign R and A, compare to a typical setup:

> 1. R: PSIRT Lead, A: Board / Senior Management

> 2. R: Product Manager, A: Legal / Compliance Lead (with input from Security)

> 3. R: Procurement Lead, A: Legal / Compliance Lead

> 4. R: Product Manager or Engineering Lead, A: Legal / Compliance Lead

> 5. R: Product Manager, A: Board / Senior Management

4. When Are You a Manufacturer, Importer, or Distributor?

Under the CRA, responsibilities depend on your role. A single company can wear multiple hats.

Manufacturer (core CRA duties)

You are a manufacturer if you:

Develop software or a product with digital elements and
Place it on the EU market under your own name or trademark, or
Substantially modify a product already on the market (e.g., major software changes that affect security properties).

Key duties (simplified):

Perform risk assessment and implement security by design/by default.
Maintain technical documentation and SBOM (Module 8).
Undergo conformity assessment and affix CE marking (Module 9).
Provide instructions and security updates, handle vulnerabilities.

Importer

You are an importer if you:

Place on the EU market a CRA‑covered product from a non‑EU manufacturer, under the manufacturer’s name.

Duties include:

Check that the non‑EU manufacturer has carried out conformity assessment, has CE marking, and documentation.
Ensure name and contact details of manufacturer and importer are on the product or documentation.
Not place the product on the market if you know it is non‑compliant.

Distributor

You are a distributor if you:

Make a product available in the EU supply chain (e.g., reseller, marketplace) without being manufacturer or importer.

Duties include:

Verify product bears CE marking and required information.
Ensure storage and transport conditions do not compromise security.
Cooperate with authorities and pass on user information and updates as needed.

When importers/distributors become manufacturers

You are treated as a manufacturer (and get full manufacturer duties) if you:

Place a product on the market under your own brand or modify the product name/identity; or
Modify the product in a way that affects its compliance (e.g., replace the main firmware, major software changes, disable security features); or
Change the intended purpose of the product.

> Practical rule: If you change the brand, core software, or intended use, assume CRA will treat you as a manufacturer, with all associated obligations.

5. Role Identification Quiz

Test your understanding of when a company is treated as a manufacturer, importer, or distributor under the CRA.

A German company buys a smart camera with embedded software from a Korean manufacturer. It rebrands the camera with its own logo, modifies the firmware to add AI analytics, and sells it in the EU. Under the CRA, what role does the German company primarily have?

Importer only
Distributor only
Manufacturer (with full manufacturer obligations)
No specific role, because the Korean company is the real manufacturer

Show Answer

Answer: C) Manufacturer (with full manufacturer obligations)

By **rebranding** and **modifying the firmware** in a way that affects security and functionality, the German company is treated as a **manufacturer** under the CRA. It must meet full manufacturer obligations, including risk assessment, technical documentation, conformity assessment, CE marking, and vulnerability handling. The original Korean company may still have obligations, but the rebranding EU entity cannot rely solely on being an importer or distributor.

6. Core CRA Clauses for Supplier and OEM Contracts

To manage CRA risk, you need to flow down obligations into contracts with:

Software component suppliers (libraries, SDKs, APIs)
OEMs and white‑label partners
Cloud and platform providers (where relevant to the product’s security)

Below are key clause topics (simplified for learning). In real life, legal experts must adapt them to actual CRA text and final numbering.

Compliance with CRA and related EU law

Supplier warrants that its products and services support your CRA compliance, including security by design and by default.

Security by design / secure development

Supplier follows a documented secure development lifecycle (SDL).
Uses up‑to‑date encryption, secure coding practices, and security testing.

SBOM and component transparency

Supplier provides an SBOM in a standard format (e.g., SPDX or CycloneDX).
SBOM must be updated with each release and on request by authorities.

Vulnerability handling and disclosure

Supplier maintains a vulnerability management process.
Notifies you of discovered vulnerabilities within an agreed time (e.g., 24–72 hours after confirmation).
Cooperates on coordinated vulnerability disclosure and security advisories.

Security updates and support period

Supplier commits to providing security patches for at least the expected product lifetime or a defined minimum period.
Includes maximum time to patch for critical vulnerabilities.

Technical documentation support

Supplier provides necessary technical documentation for your CRA technical file (architecture, security features, test reports, configuration guidance).

Audit and assessment rights

You may perform security and CRA compliance audits (on‑site or remote) or receive independent certifications (e.g., ISO/IEC 27001, 62443 where relevant).
Supplier must remediate non‑conformities within an agreed timeframe.

Incident and breach cooperation

Supplier must assist you in investigating and mitigating security incidents.
Provides data and logs needed for reporting to EU authorities when required by CRA or NIS2.

End‑of‑life (EoL) and data export

Supplier informs you in advance of end‑of‑support dates.
Provides tools or documentation for secure decommissioning and data export.

> Contract design tip: Many organisations create a CRA Appendix or Cybersecurity Schedule that is attached to all relevant supplier contracts, so requirements are consistent.

7. Sample CRA Supplier Clause (Plain‑Language Pseudo‑Legal)

Below is a simplified example of how a CRA‑related clause could look. This is for learning only, not legal advice.

8. Contract Drafting Exercise

You are negotiating with a supplier of a critical authentication library used in your CRA‑covered product.

Task: Write 3–4 short bullet points you would insist on including in the contract, based on what you learned.

Use this structure in your notes:

SBOM requirement: …
Vulnerability notification: …
Security updates: …
Audit / evidence: …

Example answer (compare after you write your own):

SBOM requirement: Supplier must provide an updated SBOM with each release in CycloneDX format.
Vulnerability notification: Supplier must notify us within 48 hours of confirming any vulnerability that could affect authentication or encryption.
Security updates: Supplier must provide patches for critical vulnerabilities within 7 days and for high‑severity vulnerabilities within 30 days.
Audit / evidence: Supplier must give us an annual summary of their security testing and allow a remote audit of their SDL process on request.

9. Monitoring Supplier Compliance and Audit Strategies

Having contract clauses is not enough. Under the CRA, regulators will expect evidence that you actually monitor compliance, especially for higher‑risk products.

Common monitoring practices:

Onboarding due diligence

Security questionnaires (asking about SDL, certifications, incident history).
Review of third‑party certifications (ISO/IEC 27001, SOC 2, IEC 62443, etc.).

Regular reporting

Annual or quarterly security status reports from suppliers.
Updated SBOMs and vulnerability lists.
Evidence of security testing (e.g., summary of penetration test findings and fixes).

Audit and review meetings

Periodic security review calls to discuss incidents, vulnerabilities, and roadmap.
Right to perform remote or on‑site audits for critical suppliers.

Technical monitoring

Use of vulnerability scanners and SBOM analysis tools to detect known vulnerabilities in supplier components.
Continuous monitoring of security advisories from suppliers and open‑source communities.

Escalation and remediation

Clear escalation paths if a supplier fails to patch or refuses audits.
Contractual right to withhold payment, stop using the component, or terminate the contract for serious non‑compliance.

> Exam‑style insight: If a CRA‑covered product is found non‑compliant due to a vulnerable third‑party library, regulators will still hold the manufacturer responsible. Being able to show supplier control and monitoring can reduce penalties and demonstrate due care.

10. Supplier Monitoring Scenario

Apply your knowledge to a realistic situation.

Your key crypto library supplier refuses to share an SBOM, saying it is 'confidential', and only promises to notify you of 'major issues' without clear timelines. You plan to use this library in a CRA‑covered product classified as higher‑risk. What is the **best** response from a CRA governance perspective?

Accept their position; as long as they are a big, reputable vendor, your CRA risk is low.
Escalate internally and either negotiate stronger SBOM, notification, and audit clauses or find an alternative supplier.
Proceed but add a disclaimer in your user manual saying security depends on the third‑party library.
Rely on your own penetration tests and ignore SBOM and notification issues.

Show Answer

Answer: B) Escalate internally and either negotiate stronger SBOM, notification, and audit clauses or find an alternative supplier.

Under the CRA, the **manufacturer** remains responsible for product security and must be able to demonstrate control over its supply chain. Lack of SBOM and vague notification terms are red flags, especially for higher‑risk products. The correct governance response is to **escalate**, negotiate stronger contractual commitments, and if necessary **switch suppliers**.

11. Key Term Review

Use these flashcards to reinforce the main concepts from this module.

Manufacturer (under the CRA): An entity that develops or has a product with digital elements designed and manufactured, and places it on the EU market under its own name or trademark, or substantially modifies a product in a way that affects compliance. Bears the main CRA obligations (risk assessment, technical documentation, CE marking, updates, vulnerability handling).
Importer: An EU‑based economic operator that places a CRA‑covered product from a non‑EU manufacturer on the EU market. Must verify CE marking, documentation, and not place products that are known to be non‑compliant.
Distributor: An operator in the supply chain (e.g., reseller, marketplace) that makes a CRA‑covered product available on the EU market without being a manufacturer or importer. Must check CE marking and information, and ensure proper handling and cooperation with authorities.
SBOM (Software Bill of Materials): A structured list of all components (including open‑source libraries) in a software product. Under the CRA, it supports transparency, vulnerability management, and technical documentation duties.
Secure Development Lifecycle (SDL): A set of processes integrating security into all stages of software development (requirements, design, implementation, testing, deployment, maintenance). Often required contractually to support CRA security‑by‑design obligations.
Audit rights (in contracts): Clauses giving a customer the right to review a supplier’s processes, documentation, or facilities, or to receive independent audit reports, to verify compliance with security and CRA obligations.
Vulnerability handling: Processes for receiving, assessing, prioritising, fixing, and communicating vulnerabilities. Under the CRA, manufacturers must have formal vulnerability handling and coordinate with suppliers and users.

Key Terms

Importer: An EU‑based operator that places a CRA‑covered product from a third country on the EU market. Must verify that the manufacturer has fulfilled CRA obligations before placing the product on the market.
Distributor: Any operator in the supply chain, other than the manufacturer or importer, who makes a product available on the EU market. Has duties to check CE marking and cooperate on safety and security.
Audit rights: Contractual rights that allow a customer to verify a supplier’s compliance with agreed standards and legal obligations, often through inspections or review of audit reports.
Manufacturer: Under the CRA, an entity that develops or has a product designed and manufactured, and markets it under its own name or trademark, or substantially modifies it. Holds primary responsibilities for compliance.
Conformity assessment: The process of demonstrating that a product meets CRA requirements, which may involve internal checks, third‑party assessment, or certification, leading to CE marking.
Cyber Resilience Act (CRA): Forthcoming EU Regulation establishing cybersecurity requirements for products with digital elements placed on the EU market. It imposes obligations on manufacturers, importers, and distributors related to security by design, vulnerability handling, documentation, and conformity assessment.
Vulnerability handling process: Organisational procedures for receiving, triaging, fixing, and disclosing software vulnerabilities, including cooperation with users and authorities.
Software Bill of Materials (SBOM): A detailed inventory of all software components in a product, including open‑source and third‑party libraries, used to manage vulnerabilities and support transparency.
End-of-life (EoL) / End-of-support: The point at which a manufacturer or supplier stops providing updates and security patches for a product. Under the CRA, this must be planned and communicated clearly to users.
Secure Development Lifecycle (SDL): A structured approach integrating security activities into each phase of software development, such as threat modelling, secure coding, code review, and security testing.