Article 13(6) covers a flaw found in a part built into a product. The part may be open source. The maker must tell the maker or keeper of that part. It must also address and fix the flaw under the CRA rules.

The product maker may build a software or hardware change for the flaw. If so, the same rule may require it to share useful code or notes with the source project. When apt, it must use a form that a machine can read.

Send a reproducible finding

Help the keeper repeat and assess the flaw. Name the part, version, weak task, seen result, and test setting. Give proof or steps, harm, source, and a safe contact route. Keep facts about the part apart from harm caused only by the final product.

Before you send, check the keeper’s public security route and rules. Record the real address, time, data sent, and reply. Do not open a public issue if it could put users at risk before a fix exists.

Bound what leaves the organisation

Check the pack for passwords, personal data, customer IDs, and private code not tied to the flaw. Remove attack detail that is not needed for the test. Protect other secret facts. Leave enough proof for the keeper to understand and repeat the issue.

State how the keeper should handle the facts. Give the public contact, proposed lead, and reason for speed. Do not promise a date or news hold for the other party. Record what the keeper agrees to do.

If the public route fails, save proof of the try. Raise the issue through a contact you have checked. Do not send secret facts to an unknown address just to close the task.

Keep downstream remediation owned

The handoff does not move the duty for the final product. Name in-house owners for limits, version checks, tests, release, and user notes. Treat the keeper’s reply as one input, not the whole plan.

If your team builds a patch or short-term fix, record how it differs from the source. State how it was tested and which products got it. Prepare any code or notes that may need to go back. Remove unrelated secrets, but keep the facts needed to grasp the fix.

Keep two linked task lists. The source list tracks the alert, reply, questions, shared code or notes, and keeper response. The product list tracks limits, versions, fixes, user notes, and any Article 14 choice. Closing one list must not close the other.

The Article 13 handoff and Article 14 report answer two questions. Link both to one flaw record. Give each its own trigger, owner, due time, reader, and proof of completion.

State which legal rule each task serves. Have legal staff confirm when it applies to the product and event. A readiness step does not prove that a legal duty is in force now.

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