Email is not a vulnerability disclosure programme
A late-stage proposal review. The asset owner's security architect asks the manufacturer how vulnerabilities affecting the deployed equipment will be communicated during the operational life of the asset. The manufacturer's response is helpful and concrete. They will maintain a distribution list of customer security contacts. When a vulnerability is identified, the security contacts will be notified by email. The notification will include the affected product, the severity, and the patch when one is available.
The architect notes that this is useful, but does not address the requirement. The Cyber Resilience Act requires a coordinated vulnerability disclosure programme accessible to the public — not only to existing customers. The manufacturer's team is briefly puzzled. Why does the public need access? The vulnerabilities affect the asset owner's equipment. Surely the asset owner is the appropriate audience?
The architect explains. Vulnerability disclosure is not a customer-relationship function. It is a public function, governed by international standards, expected of every serious industrial equipment manufacturer, and required in operational form by EU regulation from September 2026. The asset owner is one beneficiary of the programme. The security research community, downstream asset owners on the second-hand market, parallel deployments at other operators, the national CERT community, sector ISACs, vulnerability scanner vendors, insurance underwriters, regulators — all are beneficiaries. Restricting disclosure to a private distribution list serves none of them.
A vulnerability is information. The asset owner's interest is in receiving it; the wider ecosystem's interest is in being able to act on it; the security research community's interest is in having a channel through which to report what they find. None of these interests is served by private email. Each requires a public, persistent, structured mechanism for vulnerability disclosure — a programme rather than an inbox.
Why disclosure is a public function
The Cyber Resilience Act, in Article 13 (via Annex I Part II point 5), requires manufacturers of products with digital elements to operate a coordinated vulnerability disclosure policy. The phrase "coordinated vulnerability disclosure" carries specific meaning under ISO/IEC 29147 — the international standard that defines what such a policy must contain — and the operational counterpart, ISO/IEC 30111 , which defines what a manufacturer's internal vulnerability handling process must look like. Together these two standards set out the architecture of a credible disclosure programme.
What the standards require, and what the Cyber Resilience Act will enforce from December 2027, is structural rather than discretionary. The manufacturer publishes a clear policy stating how vulnerabilities can be reported, by whom, under what conditions. The manufacturer provides a public channel for receiving reports, accessible to anyone who finds a vulnerability without requiring an existing customer relationship. The manufacturer commits to a process for triaging, investigating, remediating and publishing information about vulnerabilities, with stated timelines. The manufacturer publishes advisories once remediations are available, in a format that downstream parties can monitor and act on.
Three reasons make the public posture non-negotiable.
Security researchers do not have customer relationships. A researcher in Helsinki, a graduate student in Tel Aviv, a security team at an unrelated company, an independent bug bounty hunter — none of them are customers of the manufacturer, and none should need to be. They have found a vulnerability and they need a way to tell the manufacturer about it without going through a sales call. Private email distribution lists serve customers. Researchers reach manufacturers through the public channel or, if no public channel exists, through public disclosure on a fixed timeline. The manufacturer's choice is between operating the channel themselves or having the disclosure happen without them.
Downstream parties depend on advisories. A wind turbine installed at the project in question is one of perhaps several hundred globally of the same model. A vulnerability affecting it affects them all. The other asset owners — whether they bought directly from the manufacturer, inherited the equipment through acquisition, or operate it under second-life arrangements — need access to the same advisory. National CERTs and sector Information Sharing and Analysis Centres feed off published advisories to provide guidance to their constituencies. Insurance underwriters cross-reference advisories against the equipment they cover. Vulnerability scanning tools ingest advisories into their detection databases. A vulnerability not published is not visible to any of this infrastructure.
Equivalence with peers. The major industrial control manufacturers — Siemens, ABB, Schneider Electric, Rockwell, GE Vernova, Hitachi Energy, Mitsubishi, Yokogawa, several others — all operate published vulnerability disclosure programmes with security.txt files, advisory pages, CVE issuance, PGP keys, and acknowledged researcher credits. A manufacturer that lacks these is signalling either that they have not yet reached the operational maturity of peers, or that their internal posture toward vulnerabilities is more defensive than collaborative. Both readings are damaging at proposal evaluation, and both are increasingly difficult to defend at lender due diligence.
What a PSIRT actually does
A Product Security Incident Response Team — PSIRT, to use the common acronym — is the organisational function that handles vulnerabilities affecting the manufacturer's products. The work has six phases.
Intake. A vulnerability arrives through the public channel — a web form, an email address, an encrypted message. The intake process acknowledges receipt within a stated timeline (typically three business days), records the report in a tracking system, and assigns initial triage.
Triage. An analyst confirms the report is genuine, identifies which product or products are affected, estimates initial severity, and decides whether to escalate. In the operational experience reported by established PSIRTs, a substantial fraction of reports turn out to be duplicates, configuration issues or scope mismatches; the residue requiring engineering action varies by product.
Coordination. The PSIRT works with the reporter on a disclosure timeline. Standard practice under ISO/IEC 29147 is 90 days from initial report to public disclosure, with extensions negotiable if remediation is complex. The reporter and the manufacturer agree on what will be published and when; if they cannot agree, the standard provides for the reporter to disclose unilaterally after the standard timeline. A PSIRT that fails to engage substantively within the 90 days finds itself responding to public disclosure rather than coordinating it.
Remediation. Engineering develops the fix. This is the most variable phase — a configuration change might take a day, a firmware update with full regression testing might take months. The PSIRT tracks progress and updates the reporter on timeline, while parallel work prepares the advisory text, the customer notifications and the patch delivery infrastructure.
Disclosure. Once the remediation is available, or once the disclosure deadline passes, the PSIRT publishes the advisory. The advisory contains the affected products, the affected versions, a CVE identifier, a CVSS score, a description of the vulnerability written for the technical audience that needs to act on it, the remediation guidance, and any workarounds for asset owners who cannot patch immediately.
CVE issuance. The Common Vulnerabilities and Exposures programme, operated by MITRE under sponsorship from the US Cybersecurity and Infrastructure Security Agency, assigns unique identifiers to publicly disclosed vulnerabilities. A manufacturer that operates as a CVE Numbering Authority — a CNA — can assign CVE identifiers to their own products' vulnerabilities, which signals operational maturity and integrates the manufacturer into the global vulnerability tracking ecosystem. Applying to become a CNA is a process MITRE manages openly. For industrial equipment manufacturers selling into EU-financed projects, it is the expected end state.
The minimum-viable PSIRT
The full operational programme is well-defined. The minimum-viable initial deployment is achievable in four to six weeks of focused work, most of which is editorial and process design rather than engineering.
A security.txt file at the root of the manufacturer's primary domain — at /.well-known/security.txt under RFC 9116
. The file declares the contact for vulnerability reports, the encryption key for confidential reports, the policy URL, the acknowledgments URL where credited researchers are listed, and the preferred languages for communication. A dozen lines of plain text; one of the simplest deliverables in the entire programme; the file that researchers actively look for as their first signal that a manufacturer takes disclosure seriously.
A /security/advisories page on the manufacturer's website. A clean, navigable list of published advisories, each with a unique identifier, an affected products list, a CVE reference where applicable, a CVSS score, the publication date, the remediation status, and links to firmware downloads or configuration guidance. Static HTML is sufficient; the page does not need to be application-driven. The publication discipline matters more than the technology.
A PGP key, or modern equivalent, for encrypted communication. Researchers reporting sensitive vulnerabilities require a confidential channel. A published PGP key with a known fingerprint, accessible from the security.txt file, and a separate encrypted-mailbox infrastructure for receiving reports, addresses this requirement. Age keys are increasingly accepted as a modern alternative, though PGP remains the default in security research communities.
A coordinated vulnerability disclosure policy document, aligned to ISO/IEC 29147. The policy states the manufacturer's commitments to researchers — that good-faith reports will not result in legal action, that disclosure timelines are stated and adhered to, that credit will be offered for valid reports unless the reporter prefers anonymity. Without these commitments, serious researchers will not engage. With them, the channel becomes productive.
An RSS or Atom feed of advisories. Downstream consumers — CERTs, ISACs, vulnerability scanning vendors, automated procurement tooling, insurance risk engines — ingest advisories through feeds rather than human visits. A manually maintained advisory page that requires browser visits will not reach the infrastructure that needs it.
A CVE Numbering Authority application, in progress or completed. Manufacturers that operate as CNAs can assign their own CVE identifiers, which speeds the disclosure process, demonstrates a degree of maturity that procurement teams notice, and embeds the manufacturer into the wider vulnerability tracking ecosystem.
These six artefacts, taken together, constitute the minimum-viable PSIRT. They are not the full operational programme — that requires staffing, internal procedures, executive ownership, engineering escalation paths, integration with the development lifecycle, and continuous engagement with the security research community. But they are the visible artefacts the asset owner, the lender, and the security researcher will look for. A manufacturer that has them, even if the operational programme behind them is still maturing, has crossed the threshold of credibility. A manufacturer that has none of them has not. The IEC 62443 evidence pack post covers the asset-owner-side artefacts that consume the PSIRT's outputs.
At proposal stage
A manufacturer's bid that includes the URL of an existing security.txt and advisory page, the disclosure policy document, the CNA reference, and a brief description of the PSIRT function, is a bid that meets the Cyber Resilience Act's vulnerability handling provisions at face value. The conversation that follows is about how project-specific advisories will be handled — escalation paths to the asset owner, integration with the project's incident response procedures, contractual notification timelines that may run faster than the public disclosure timeline — not about whether the function exists.
A manufacturer's bid that offers a customer-only email distribution list, or that proposes to set up a disclosure programme after contract signature, signals a gap that procurement and the lender will both flag. The gap is not unbridgeable. The four-to-six-week timeline to a minimum-viable PSIRT is short enough that it can run in parallel with contract negotiation. But the work needs to start before the bid is competitive, not after.
The cultural shift, finally, is the one this piece has been circling. Traditional vendor instinct treats vulnerabilities as private matters — minimise public attention, brief affected customers quietly, work issues outside view. The mature posture, now codified in the Cyber Resilience Act and embedded in the operating practice of every major industrial control manufacturer, is the opposite. Vulnerabilities are inevitable in any complex product. How a manufacturer handles them — promptly, transparently, in dialogue with the security research community, with credit for those who report in good faith — is the signal procurement teams now read. A manufacturer that publishes advisories is a manufacturer that knows what is in their product, that has the engineering capability to fix what they find, and that trusts their organisational maturity to let the information be seen.
The procurement criterion has been quiet about this until recently. It is no longer quiet.
The next article picks up the technical foundation that vulnerability disclosure rests on, and that the Cyber Resilience Act will require independently: the software bill of materials that catalogues what is actually inside the firmware shipping in every product, and why most non-EU industrial manufacturers have never produced one.
This article reflects the regulatory and standards landscape at publication. The Cyber Resilience Act's implementing acts continue to be issued through 2026–2027 and may alter specific disclosure obligations. References to ISO/IEC 29147, ISO/IEC 30111 and RFC 9116 may be superseded by revisions. Named manufacturers and certification bodies are illustrative rather than endorsements. Specific transactions should be reviewed by qualified legal counsel rather than against this article. If a citation has rotted or a clause has moved, LinkedIn is the way to flag it.