Your PSIRT confirms it at 09:00 on a Tuesday: a memory-corruption flaw in the crypto library that ships inside every microcontroller module you sell, and there is traffic in the wild exercising it. Three Tier-1 OEMs have that module soldered into machines already placed on the European market. Each of them now carries a reporting duty with a 24-hour fuse — and that fuse is lit by their awareness, which your phone call is about to create. Your engineering instinct is to say nothing until you have a patch. Their compliance instinct is to demand everything, source included. The contract between you is what decides whether both of you come out of the week intact.
Before drafting a single clause, fix the one fact that governs all of them: the contract cannot move the duty. It can route information and set the tempo. It cannot make your customer's legal obligation yours, or yours theirs.
Whose clock is it, and what actually starts it
The reporting duty lives in Article 14, and it is narrower than the boilerplate makes it sound. It does not fire for every defect in a backlog. It fires for an actively exploited vulnerability, or for a severe incident affecting the security of the product. When one of those exists, the manufacturer of the affected product notifies the coordinating CSIRT and ENISA together, through the single reporting platform (Article 16), on a fixed cadence: an early warning within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report within 14 days of a fix or mitigation being available.
The word doing the heavy lifting is manufacturer of the affected product. You are the manufacturer of your component; your OEM is the manufacturer of the machine it went into. When your exploited flaw is riding inside their integrated product, the reporting duty for that product is theirs — it attaches to the thing they placed on the market. If your module is also sold on its own as a product with digital elements, you carry your own duty for it in parallel. Two clocks, two filings, one root cause. Neither of you can hand your clock to the other by writing a sentence in a supply agreement.
That is precisely why the data-sharing agreement matters. You cannot take the OEM's obligation away, but you decide how much runway they get before their 24 hours is forced, and you decide what leaves your building to give it to them.
The clauses that carry the load
What follows is illustrative scaffolding, not legal advice — the exact wording for your deal is your counsel's work, and jurisdiction-specific. Treat these as the shape of the instrument, not a template to paste.
1 — Notification trigger and timing. The clause that starts everything, written to your tempo rather than the statute's:
Vendor shall notify the affected OEM of any confirmed vulnerability in the supplied Component within [N] hours of Vendor's own confirmation, and without any delay period where Vendor has reason to believe the vulnerability is being actively exploited.
The point is to reach the OEM before an external event — a researcher's tweet, a CVE publication — forces their awareness on someone else's schedule. Give them a running start and their 24-hour early warning is a prepared act, not a scramble.
2 — Tiered disclosure: what crosses the boundary. This is where the IP protection happens. Split the payload in two:
Vendor shall provide an actionable advisory containing affected part and version identifiers, severity assessment, conditions required for exploitation, available mitigations, and patch timing. Vendor shall not be required to disclose source code, proprietary exploit-reproduction material, or internal design documentation.
Read the two lists against what the OEM's filing needs. The early warning and the 72-hour notification call for the general nature of the vulnerability and of the exploit, the products affected, and the corrective or mitigating measures — exactly the first list. Nothing in the reporting duty asks the OEM for your source. The IP you are protecting was never an input to their compliance in the first place; the tiered clause simply writes that fact down so a procurement lawyer cannot drift past it.
3 — Embargo. A coordinated window in which neither side publishes until the agreed release:
The parties shall coordinate public disclosure and withhold public advisories until [the coordinated release date], provided that this embargo terminates immediately upon active exploitation becoming known or upon either party's obligation to make a statutory notification.
The embargo has a real statutory footing: Annex I Part II lets a manufacturer delay public disclosure of a fixed vulnerability where the risk of publishing outweighs the benefit, until users can apply the patch. That is the legitimate basis for a quiet window — and its ceiling. An embargo governs when the world is told. It has no power over a notification to a CSIRT, which is confidential and non-negotiable. Write the carve-out explicitly, or you have drafted a clause that appears to gag a legal duty.
4 — Secure channel and named contact. Annex I Part II already requires you to run a coordinated-disclosure policy and to publish a contact address for reporting. The agreement pins that to this relationship:
Disclosures shall be transmitted only through [named PSIRT contact / authenticated portal] using [specified encryption], and shall not be sent through general commercial or sales channels.
A "secure disclosure portal" is not a product you must buy; it is an authenticated, encrypted, logged path with a named human on the other end. It keeps the exploited-flaw advisory out of a shared sales mailbox where its blast radius is uncontrolled. Generating the component inventory those advisories reference — the machine-readable SBOM the OEM will map your advisory against — is its own discipline, covered in EP_4.02.
5 — Reciprocal reporting. The flow runs both ways, and the statute expects it to. Article 13(6) requires a manufacturer that finds a vulnerability in an integrated component to report it back to whoever makes that component, and to share any fix code or documentation it developed. Mirror it:
Each party shall report to the other any vulnerability it identifies in the Component, and shall share relevant remediation code or documentation, in a machine-readable format where appropriate.
This is the clause that turns a one-way disclosure duct into an actual coordinated relationship: the OEM's field telemetry finds flaws your bench never will, and it is obliged to send them home.
What no contract can buy you
Three limits are worth stating plainly, because deals get signed that pretend otherwise. A contract cannot extend the 24-hour clock — it runs from awareness by operation of law, and no notice period you negotiate slows it. A contract cannot reassign that reporting duty; the OEM's filing for its integrated product stays with the OEM, and your filing for your standalone component stays with you, whatever indemnities you trade. And a confidentiality clause cannot override a statutory notification — an NDA that reads as if it could is not a shield, it is a liability, and it should carry an express carve-out saying nothing in it prevents a required disclosure to an authority.
Strip those illusions away and the agreement does something narrower but genuinely valuable: it makes the disclosure fast, scoped, and secure, so the OEM meets a clock you cannot lift and you keep IP the clock never needed.
Which leaves the one question the contract is silent on — the one that actually decides everything above. Article 14 starts counting when a manufacturer "becomes aware." But aware when? When your PSIRT opens the ticket? When the researcher's email arrives, still unread, in a monitored inbox? When exploitation is suspected, or only when it is confirmed? Your OEM's 24 hours — and your own — hinge on a moment the Regulation names but never fixes. Where, in your intake process, would a market surveillance authority say the clock began?