When a manufacturer finds a vulnerability in a third-party component integrated into a product with digital elements, the Cyber Resilience Act (CRA) requires more than an internal remediation ticket. Article 13(6) requires the manufacturer to report the vulnerability to the person or entity manufacturing or maintaining the component, address and remediate it under the CRA vulnerability-handling requirements, and, when the manufacturer has developed a software or hardware modification for the component, share the relevant code or documentation with that upstream party.
For product-security teams, this creates a coordination workflow across organizational boundaries. The manufacturer remains responsible for the security of its own product, but it must also ensure that relevant component-level information can reach the party best placed to maintain the affected component.
What Article 13(6) requires
Article 13(6) applies when a manufacturer identifies a vulnerability in a component integrated into its product with digital elements. The provision explicitly includes open-source components.
The legal workflow has three connected parts:
- Report the vulnerability upstream. The manufacturer must report the identified vulnerability to the person or entity manufacturing or maintaining the component.
- Address and remediate the vulnerability in the product. Upstream notification does not transfer the manufacturer's own vulnerability-handling responsibility. The manufacturer must address and remediate the vulnerability in accordance with Annex I Part II.
- Share a modification when the manufacturer developed one. If the manufacturer developed a software or hardware modification to address the component vulnerability, it must share the relevant code or documentation with the component manufacturer or maintainer, where appropriate in a machine-readable format.
This is different from the CRA's Article 14 reporting regime for actively exploited vulnerabilities and severe incidents. Article 13(6) is a component-coordination obligation. Whether a vulnerability also triggers Article 14 reporting is a separate assessment based on the Article 14 criteria.
The obligation covers open-source and proprietary components
A common process mistake is to treat open-source dependencies as a special case that falls outside supplier coordination. Article 13(6) expressly includes vulnerabilities in open-source components.
The practical contact path may differ. A proprietary component may have a vendor security contact or contractual escalation route. An open-source project may use a security policy, private vulnerability-reporting feature, maintainer email, foundation process, or another coordinated-disclosure channel. The CRA does not prescribe one universal communication mechanism in Article 13(6); the important operational point is to identify the person or entity manufacturing or maintaining the component and establish a defensible reporting route.
Teams should therefore record component ownership and security-contact information before an urgent vulnerability appears. Waiting until triage to discover who maintains a dependency can turn a straightforward notification duty into a time-consuming investigation.
Upstream notification does not replace product remediation
The manufacturer integrating the component cannot simply forward a vulnerability report and wait for the upstream party to act. Article 13(6) connects upstream reporting to the manufacturer's obligation to address and remediate the vulnerability under Annex I Part II.
Annex I Part II requires manufacturers to identify and document vulnerabilities and components, address and remediate vulnerabilities without delay in relation to the risks posed to the product, and apply effective and regular security tests and reviews. It also contains requirements concerning information about fixed vulnerabilities once a security update has been made available.
For an integrating manufacturer, this means the product-level response may need to proceed even while upstream coordination is still open. Depending on the product and risk, engineering options can include updating the component, applying an upstream patch, carrying a temporary downstream patch, disabling an affected function, adding a compensating control, or changing product configuration. Those are engineering choices, not outcomes prescribed by Article 13(6), and they should follow the product's cybersecurity risk assessment.
When fix sharing becomes relevant
Article 13(6) adds a specific requirement when the manufacturer itself develops a software or hardware modification to address the vulnerability in the component. In that case, the manufacturer must share the relevant code or documentation with the person or entity manufacturing or maintaining the component, where appropriate in a machine-readable format.
The wording matters. The obligation is tied to a modification developed to address the vulnerability in that component. It is not a general requirement to disclose unrelated product source code, proprietary implementation details, or complete product binaries.
A practical handoff package can be narrowly scoped to what the upstream maintainer needs to understand and evaluate the fix. Depending on the component and change, that may include a patch or commit, a concise technical description, affected versions, reproduction conditions, test evidence, build or configuration context, and any limitations known to the manufacturer.
The CRA does not prescribe one mandatory patch format in Article 13(6). The phrase "where appropriate in a machine-readable format" supports using a form that can be consumed efficiently by the recipient when the material lends itself to that treatment.
Build a component-vulnerability coordination record
Article 13(7) separately requires manufacturers to systematically document relevant cybersecurity aspects concerning their products, including vulnerabilities of which they become aware and relevant information provided by third parties. That makes retained coordination evidence useful beyond the immediate exchange with a maintainer.
For each component vulnerability, a practical record should capture:
- the affected product, variant and release context;
- the component identity and affected version or range;
- how and when the vulnerability became known to the manufacturer;
- the upstream manufacturer or maintainer and the contact route used;
- the date and substance of the upstream notification;
- the product-level risk and remediation decision;
- any downstream software or hardware modification developed by the manufacturer;
- what code or documentation was shared upstream and when;
- responses, acknowledgements or upstream fixes received;
- validation evidence for the remediation used in the product; and
- links to any separate Article 14 assessment or report, if that regime is relevant.
This record separates facts that are easy to blur during an incident: discovering the vulnerability, notifying upstream, deciding how the product is affected, implementing a remediation, sharing a downstream fix, and deciding whether another CRA reporting obligation applies.
A practical workflow for engineering teams
A repeatable process can keep component coordination from becoming an ad hoc email exercise.
1. Resolve the component identity
Confirm the exact component, version, origin and affected product context. Use the product's component inventory or SBOM to avoid contacting the wrong upstream project or applying information from a similarly named package.
2. Validate the vulnerability and product impact
Record the source of the vulnerability information, affected versions, exploit conditions and the product-specific exposure. Distinguish a vulnerability in the component from evidence that the vulnerability is reachable or exploitable in the manufacturer's product.
3. Identify the upstream security channel
Use the component's documented security-reporting mechanism where one exists. Preserve the contact details and the route used. For sensitive, non-public vulnerabilities, avoid defaulting to a public issue tracker if the project provides a private disclosure channel.
4. Notify the manufacturer or maintainer
Provide enough technical information for the recipient to identify and investigate the issue. Keep a timestamped record of what was sent. If the vulnerability came from a third party, handle disclosure restrictions and sensitive details carefully while still meeting applicable legal obligations.
5. Run product remediation in parallel
Assign the product-level remediation owner and decide how the vulnerability will be addressed in the affected release or supported product line. Do not make closure of the internal remediation dependent on receiving an upstream response when the product risk requires action sooner.
6. Share a downstream modification when applicable
If your team developed a software or hardware modification for the vulnerable component, prepare the relevant code or documentation for the upstream manufacturer or maintainer. Record the material shared, the recipient and the date.
7. Validate and close with evidence
Test the product-level remediation, preserve the result, update vulnerability and release records, and capture any upstream acknowledgement or subsequent fix. If the upstream project later releases a canonical fix, assess whether the temporary downstream change should be replaced.
Keep Article 13(6) separate from Article 14 reporting
The two workflows can concern the same vulnerability, but they answer different questions.
Article 13(6) asks whether the manufacturer identified a vulnerability in an integrated component and therefore needs to coordinate with the component manufacturer or maintainer while remediating its own product. Article 14 concerns notification of actively exploited vulnerabilities and severe incidents through the CRA reporting process.
A component vulnerability may require Article 13(6) coordination without meeting the Article 14 reporting threshold. Conversely, if evidence shows active exploitation affecting the manufacturer's product, the team should assess the Article 14 obligations independently rather than assuming that an upstream notification satisfies them.
This distinction is particularly important since the CRA's Article 14 reporting obligations apply from 11 September 2026, while the main CRA obligations, including the broader manufacturer obligations discussed here, apply from 11 December 2027. Teams can still implement the component-coordination workflow earlier so that product, SBOM and vulnerability records already support the later lifecycle requirements.
Connect component decisions to lifecycle evidence
Component vulnerability coordination becomes difficult when the SBOM, vulnerability decision, release impact, upstream communication and remediation evidence live in unrelated systems. The operational objective is not to centralize every engineering artifact, but to preserve traceability between the component issue and the product decision it caused.
AA-sec is designed around connecting SBOM, vulnerability management, security evidence and exact product or lifecycle context. For teams implementing this workflow, that model can keep the upstream notification, remediation decision and supporting evidence linked to the affected product and release while complementing existing engineering and delivery systems rather than replacing them. Learn more about AA-sec.
What to implement now
Before this obligation becomes operationally urgent, manufacturers can establish a small set of controls:
- maintain component identity and upstream security-contact information alongside the SBOM or component inventory;
- define who owns Article 13(6) notification and who owns product remediation;
- create a private communication path for sensitive component vulnerabilities;
- define the minimum evidence retained for each upstream notification;
- add a decision point for sharing manufacturer-developed component modifications;
- keep Article 13(6) coordination distinct from Article 14 reporting assessment; and
- test the workflow with a real or simulated third-party component vulnerability.
The key design principle is simple: component vulnerability handling is both an internal product-security process and an upstream coordination process. A manufacturer should be able to show what it discovered, whom it notified, how it remediated its own product, what fix material it shared when applicable, and which evidence supports those decisions.
Official sources
- Regulation (EU) 2024/2847 - Cyber Resilience Act — EUR-Lex
- Commission publishes new guidance to support timely Cyber Resilience Act implementation — European Commission
- Cyber Resilience Act — European Commission