Article 13(6) requires a manufacturer that identifies a vulnerability in an integrated component, including an open-source component, to report it to the component manufacturer or maintainer and to address and remediate it under the CRA vulnerability-handling requirements.

If the manufacturer develops a software or hardware modification for that vulnerability, the same provision requires relevant code or documentation to be shared upstream where appropriate, in a machine-readable format.

Send a reproducible finding

Prepare the handoff so the maintainer can reproduce and triage the issue. Include the component and version, affected function, observed behaviour, environment, proof or test steps, impact, discovery source, and a protected contact route. Separate facts about the component from effects caused only by the final-product integration.

Before sending, check the maintainer’s published security channel and disclosure instructions. Record the actual destination, time, payload, and acknowledgement. Avoid a public issue when the details would expose users before a correction is available.

Bound what leaves the organisation

Review the packet for credentials, personal data, customer identifiers, unrelated proprietary code, and exploit detail that is not needed for reproduction. Remove or protect unrelated material while preserving enough technical evidence for the maintainer to understand and test the finding.

State the requested handling, disclosure contact, proposed coordination point, and urgency basis. Do not promise a publication date or embargo on another party’s behalf. Record what the maintainer actually acknowledges.

If the published security route is unavailable, preserve the failed attempt and escalate through a verified organisational contact. Do not move sensitive details to an unverified address merely to close the handoff task.

Keep downstream remediation owned

An upstream handoff does not transfer responsibility for the integrated product. Assign an internal owner for containment, product-version analysis, testing, release, and user communication. Track the upstream response as an input, not as the only plan.

If a local patch or workaround is developed, record what differs from upstream, how it was validated, and which products received it. Prepare the code or documentation that may need to be shared, removing unrelated confidential material without stripping the information needed to understand the correction.

Keep two linked trackers. The upstream tracker covers disclosure, acknowledgement, questions, shared code or documentation, and maintainer response. The product tracker covers containment, version impact, correction, user communication, and any Article 14 decision. Closing one must not close the other automatically.

The Article 13 component handoff and an Article 14 authority report answer different questions. Link both to one vulnerability record, then give each its own trigger, owner, deadline, recipient, and evidence of completion.

Record which legal provision each task serves, and have counsel confirm when it applies to the product and event. Do not present a readiness control as proof that a legal obligation is already in force.

Continue this workflow with the component-trigger assessment and the product-version map.