Electronics Guide

What Coordinated Disclosure Is, and What It Is Not

Coordinated vulnerability disclosure is an agreement about sequence. The finder gives the vendor information and time; the vendor uses that time to build and ship a remedy; both parties then release information publicly at a moment that maximizes the number of protected users. Nothing in the arrangement requires the finder to stay silent forever, and nothing entitles the vendor to unlimited delay. The word "coordinated" describes a negotiated schedule between independent parties, not a chain of command.

The older term "responsible disclosure" has largely fallen out of professional use. It framed the finder as the party with a responsibility to discharge and implied that publication before the vendor was ready was irresponsible by definition, which gave vendors an incentive to stall. The shift to "coordinated" put responsibilities on both sides: the finder to report privately and wait a reasonable interval, the vendor to respond, remediate, and publish. The CERT Coordination Center at Carnegie Mellon University's Software Engineering Institute adopted the neutral term, and the industry followed.

Two adjacent practices are frequently confused with CVD. A bug bounty is a payment mechanism rather than a process: an organization can pay a researcher promptly and still fail to fix the defect, notify customers, or trace the same flaw through the rest of its product line. Penetration testing is contracted work on the organization's own schedule with a report delivered to the client. Neither replaces the ability to accept an unsolicited report from a stranger who has no contract, no non-disclosure agreement, and no obligation to be patient.

ISO/IEC 29147: The Receiving Interface

ISO/IEC 29147, Information technology — Security techniques — Vulnerability disclosure, is the international standard for the outward-facing half of the process, and its second edition was published in 2018. It describes what a vendor owes the outside world: a way to be reached, a predictable response, and a published advisory that lets affected parties act. It deliberately says little about internal engineering, which is the subject of its companion standard.

A Channel That Is Published, Monitored, and Authenticated

The first requirement is the most commonly failed. The vendor must publish a way to send a vulnerability report, and that channel must actually be watched. A generic sales address, a support portal demanding a serial number and proof of purchase, or a contact form with a two-hundred-character limit are failures in practice even when a human eventually reads them, because reports arrive from people who own none of the vendor's products and hold no support contract.

The conventional implementation is a dedicated address reserved for security correspondence, advertised on a security page reachable from the main site in one or two clicks. RFC 9116, published in 2022, standardizes a machine-readable pointer for the same purpose: a plain-text file at a well-known path naming the contact address, the disclosure policy, a public encryption key, and an expiry date. Confidential transport matters because the content is, by definition, an unfixed attack; publishing an OpenPGP key lets the finder send proof-of-concept material without exposing it. For hardware the artifacts are often bulky — oscilloscope captures, firmware images, sometimes a physical board — and the policy should state how to send large files and whether the vendor accepts shipped hardware.

Acknowledgment and Status

The standard's expectations for responsiveness are modest and almost entirely about predictability. The vendor should acknowledge receipt quickly, so the finder knows the report did not vanish; most published policies commit to an acknowledgment within one to three business days. The vendor should then state whether the report is in scope, whether it has been reproduced, and what happens next, and should provide status updates at a stated interval — commonly every one to two weeks — until the matter closes.

The disciplinary value of a status cadence is internal rather than external: a commitment to update the finder every fourteen days forces the product security team to ask an engineering manager every fourteen days whether the fix has moved. Without that pull, security defects lose to feature work. Programs rarely fail at triage; they fail in month three, when the report is real, the fix is understood, and nobody has scheduled it.

The Advisory

The published advisory is the deliverable, and its purpose is operational: it must let someone who owns the product decide whether they are affected and what to do. ISO/IEC 29147 addresses advisory content, and mature practice converges on a consistent set of elements. An advisory carries a stable identifier and revision date; states precisely which products, versions, hardware revisions, and configurations are affected and which are not; describes what an attacker gains and what access the attacker needs to begin, whether network reachability, physical possession, an existing local account, or a user action; names the fixed version or hardware revision; gives a workaround for anyone who cannot update immediately; and credits the finder unless the finder asks otherwise.

Two failure modes recur. The first is the advisory written to minimize alarm, which describes a remote unauthenticated code execution as a "potential stability issue" and buries the fix in a routine maintenance release; researchers who read the original report notice the gap immediately. The second omits affected-version detail because the vendor never tracked which firmware shipped on which hardware revision — a configuration management defect surfacing as a communication defect, and one that cannot be fixed during an embargo.

ISO/IEC 30111: The Handling Process Behind the Interface

ISO/IEC 30111, Information technology — Security techniques — Vulnerability handling processes, whose second edition was published in 2019, covers what happens inside the organization once a report arrives. The two standards are designed as a pair, and reading one without the other produces a characteristic failure: a polished security page in front of an organization with no agreed route from a confirmed report to a released fix.

Triage and Verification

Triage answers three questions in order. Is the report about a product this organization is responsible for? Is the described behavior real? Is it a security defect rather than an intended function, a documentation gap, or an ordinary bug? None is trivial in electronics. Ownership is genuinely ambiguous when the affected code is a third-party network stack, the affected block is licensed intellectual property inside a system on chip, or the product carries the vendor's brand but was designed by a contract manufacturer. A program needs a rule for these cases in advance, because the reflex to answer "that is not our code" is both frequently accurate and almost always the wrong first response to the finder.

Verification demands a reproduction environment, and this is where hardware programs diverge sharply from software programs. Reproducing a fault-injection attack requires the specific board revision, a glitch generator, and sometimes decapsulated parts. Keeping representative units of every shipping hardware revision, with debug access still fitted, is an unglamorous investment that determines whether triage takes two days or two months. The techniques a finder is likely to have used are surveyed under vulnerability assessment for hardware.

Investigation Beyond the Reported Instance

ISO/IEC 30111 places the investigation of related instances squarely inside the handling process, and it is the step most often skipped under deadline pressure. A finder reports one exploitable path; the vendor's job is to find the class. If the report describes a missing bounds check in one command handler, the same author almost certainly wrote the neighboring handlers the same way, and the pattern probably exists in the other products sharing that code base. Hunting variants prevents the sequence in which a researcher publishes five nearly identical advisories over eighteen months because the vendor patched each instance in isolation. The mechanism is a mandatory question at triage close: which other products, versions, and code paths share the root cause, and who checked?

The Feedback Loop into Development

The standard's most valuable requirement is the least visible externally: findings must feed back into development so the same weakness does not recur. Each confirmed vulnerability is evidence about a specific gap. A stack overflow in a parser argues for fuzzing that interface in continuous integration; a hardcoded credential argues for a build-time secret scan; a debug interface left enabled in production argues for a manufacturing test that checks the lock state of every unit rather than a checklist item an operator initials.

This loop is what the secure-development standards expect. IEC 62443-4-1 defines a secure product development lifecycle for industrial products and includes practices covering the management of security-related issues and the management of security updates, which means a vendor claiming conformance must be able to show the disclosure process, not merely describe it. The wider family of development-side requirements is treated under firmware security standards.

The PSIRT: Who Actually Does the Work

A process without an owner decays into a mailbox nobody reads. The organizational answer is the Product Security Incident Response Team, universally abbreviated PSIRT: the function accountable for vulnerabilities in what the company sells.

PSIRT and CSIRT Are Different Jobs

The distinction from a Computer Security Incident Response Team is not bureaucratic. A CSIRT defends the organization's own infrastructure — its networks, its laptops, its cloud accounts — and its authority runs to systems the organization controls; when a CSIRT decides to isolate a subnet, it can do so within the hour. A PSIRT is accountable for defects in products other people own and operate, often in places the vendor cannot reach and sometimes in installations the vendor does not know exist. It has no ability to act on the affected systems at all. Its output is not containment; it is a fix, an advisory, and a route by which owners can apply the fix themselves. The FIRST PSIRT Services Framework states the difference directly: the focus on products is the key differentiator between a PSIRT and other incident response teams.

The FIRST PSIRT Services Framework

The Forum of Incident Response and Security Teams publishes the PSIRT Services Framework, whose version 1.1 was released in spring 2020, as a description of what such a team does. It organizes the work into six service areas, each decomposed into services, functions, and sub-functions, which makes it useful both as a design template for a new team and as a gap analysis for an existing one.

The six areas are Stakeholder Ecosystem Management, covering relationships with internal groups, the finder community, downstream customers, and coordinators; Vulnerability Discovery, covering report intake and the monitoring of third-party components for vulnerabilities the vendor inherits; Vulnerability Triage and Analysis; Remediation, covering the remedy release plan, the fix, and incident handling; Vulnerability Disclosure, covering notification, coordination, and publication; and Training and Education. The framework also separates strategic foundations such as executive sponsorship, a written charter, and an organizational model from tactical resources such as budget, staff, and tooling.

The organizational models it describes are worth naming. A centralized PSIRT holds the expertise in one team, which works when product lines are similar and fails when they are not, while a distributed model places responsibility in each business unit, which scales technically but produces incompatible advisories and inconsistent timelines. The hybrid model — a small central team owning intake, policy, identifiers, publication, and external coordination, with named product security engineers embedded in each engineering group — matches how most hardware companies are structured and fails least often.

Staffing a Hardware Program

A hardware PSIRT needs skills a software PSIRT can do without: someone able to read a side-channel analysis and judge whether the claimed key recovery is real, someone who understands what a microcode or firmware mitigation costs in performance and whether the silicon can accept one at all, someone who can find out how many units of an affected part are in the field, and someone who can speak to the legal and regulatory functions in their own language, because the reporting duties described later carry deadlines measured in hours.

The team is smaller than outsiders expect: two or three full-time people plus a documented network of engineering contacts runs a competent program for a mid-sized manufacturer. What cannot be reduced is the authority to compel a scheduling decision from a product manager who would rather ship the feature, which is why the framework lists executive sponsorship as a strategic foundation rather than an optional nicety.

Identifiers and Scoring: CVE, CVSS, and CWE

Three related systems give the industry a shared vocabulary: a naming scheme for individual vulnerabilities, a scoring scheme for severity, and a taxonomy for the underlying weaknesses. They are frequently confused, and each is misused in a characteristic way.

The CVE Program and the CNA Model

Common Vulnerabilities and Exposures assigns a unique identifier to a publicly disclosed vulnerability so that a vendor advisory, a scanner signature, a customer's ticket, and a news article can be shown to refer to the same defect. The program is operated by MITRE and sponsored by the Cybersecurity and Infrastructure Security Agency of the United States Department of Homeland Security. Identifiers take the form of the prefix, the year of assignment, and a sequence number.

Assignment is federated. A CVE Numbering Authority, or CNA, is an organization authorized to assign identifiers within a defined scope, and the population has grown to more than four hundred organizations across roughly forty countries, arranged in a hierarchy under top-level roots; in November 2025 the European Union Agency for Cybersecurity became a Root serving European entities. Most vendor CNAs hold a scope limited to their own products, while coordinators such as the CERT Coordination Center and CISA hold broader scopes and assign identifiers for vendors that are not CNAs or that will not engage.

Becoming a CNA is a commitment rather than a badge. The authority obliges a vendor to assign an identifier to every qualifying vulnerability in its scope, to publish a record with the required content when the vulnerability becomes public, to maintain a public disclosure policy and a working contact point, and to follow the program's rules on scope and disputes. The benefit is control: a vendor that assigns its own identifiers writes its own descriptions and affected-version lists and coordinates publication with its own release. The cost is that the obligation applies to inconvenient cases too, and a vendor that becomes a CNA and then declines to assign identifiers for its own defects has advertised a problem rather than concealed one.

What a CVE Record Contains

A record moves through defined states. An identifier is first reserved, which lets a vendor and a finder refer to the issue during an embargo before any details exist publicly; it becomes published when the CNA supplies the content, and it can be rejected when the entry turns out to be a duplicate or a mistake. The published record carries a description, affected products and versions, and references to the vendor advisory. A JSON schema, the CVE Record Format, defines the structure and permits a container from the assigning CNA together with additional containers from authorized data publishers, which is how enrichment such as severity scoring is added by parties other than the vendor.

Two fields deserve care from hardware vendors. Affected-version data expressed only as a product name is nearly useless to an asset owner running four hardware revisions, and the description should state the attack precondition, because remote-unauthenticated and physical-access-required defects demand entirely different responses. Record volume has risen steeply, with independent analyses counting more than forty-eight thousand records published during 2025, so inbound monitoring of third-party components requires a component inventory — in practice a software bill of materials maintained per firmware release — matched automatically against the identifier stream. That inventory also supports the outbound answer: a Vulnerability Exploitability eXchange statement, carried in the OASIS Common Security Advisory Framework, lets a vendor assert machine-readably that a vulnerable component is present but not reachable in the shipped configuration.

CVSS and the Limits of a Base Score

The Common Vulnerability Scoring System, also stewarded by FIRST, produces a numeric severity rating from a structured description of a vulnerability's characteristics. Version 3.1 remains widely deployed, and version 4.0 was published in November 2023 with the metrics organized into four groups. Base metrics capture intrinsic characteristics that do not change over time: how the attack is delivered, what complexity and privileges it requires, whether user interaction is needed, and the effect on confidentiality, integrity, and availability. Threat metrics — renamed from the Temporal group of earlier versions — capture what is known about exploitation in the wild. Environmental metrics let an operator adjust the score for a particular deployment. Supplemental metrics, new in version 4.0, convey context such as automatable exploitation or safety impact without altering the computed score.

The honest caveat is that a base score is not a risk assessment, and the specification says so: a numeric score is an input to a vulnerability management process that must also weigh regulatory obligations, customer impact, and financial consequence. Vendors that publish only the base score let customers infer urgency from a number that deliberately ignores whether anyone is exploiting the flaw, and customers who patch strictly in descending numeric order leave moderate-scored defects unpatched while they are under active attack. Better practice pairs the score with exploitation information: CISA's Known Exploited Vulnerabilities catalog, established in late 2021, the estimates of the Exploit Prediction Scoring System, and decision-tree methods such as Stakeholder-Specific Vulnerability Categorization, developed by the CERT Coordination Center and used by CISA to reach an explicit act-or-defer decision rather than a number.

Scoring is genuinely awkward for hardware. A fault-injection attack requiring physical possession, decapsulation, and a laboratory scores low on attack vector and high on complexity, yielding a modest number that badly understates the consequence for a payment terminal or a hardware security module whose threat model assumes a hostile holder. Vendors in those markets should say so in the advisory rather than let the number speak alone.

CWE and the Weakness Underneath

Common Weakness Enumeration, maintained by MITRE, classifies the underlying flaw types rather than their instances. A CVE identifier names one vulnerability in one product; a CWE identifier names the kind of mistake — an out-of-bounds write, a use of hardcoded credentials, an improper certificate validation. Tagging advisories with weakness classes converts a pile of individual defects into evidence about engineering practice, and the annual Top 25 Most Dangerous Software Weaknesses list published by MITRE with CISA gives a reference point. CWE also covers hardware: a dedicated hardware design view spans debug and test interfaces left accessible, privilege separation errors in on-chip peripherals, weaknesses in power and clock domains that enable fault injection, and information exposure through microarchitectural side channels. Tagging findings against it is the fastest route to noticing that three unrelated reports describe one design-review omission.

Timelines, Embargoes, and the Ninety-Day Convention

The single most contested element of any disclosure is the date. The embargo is the interval during which the finder, the vendor, and any coordinators hold the information privately while a fix is prepared.

Where the Conventional Deadline Came From

No standard sets a universal number, and the two most influential published policies do not agree. The CERT Coordination Center applies a default of forty-five days from its first attempt to contact the vendor, disclosing at that point regardless of whether a patch exists, and adjusts the date earlier or later for active exploitation, unusually severe or unusually trivial issues, or cases requiring a change to a published standard.

Google's Project Zero publishes a stricter and more elaborate policy that has done more than any other to fix expectations. A vendor has ninety days to make a patch available; details are published thirty days after the patch reaches users, or at day ninety if no patch has arrived. A vendor that requests it may receive a fourteen-day grace period, extending the deadline to one hundred four days. Vulnerabilities already under active exploitation compress the schedule sharply, with a seven-day policy replacing the ninety-day one and a three-day grace period.

Ninety days became the industry's default reference point because it is long enough to design, test, and release a software fix through a normal quality process, and short enough that it cannot absorb an entire product planning cycle. It is a norm rather than a rule, and its authority rests on the fact that large finders enforce it. For hardware vendors the number is often uncomfortable, and the correct response is to negotiate explicitly rather than let it pass in silence.

Negotiating an Extension

Extensions are routinely granted to vendors who ask well and rarely to vendors who ask late. A credible request explains the specific obstacle — a fix requiring a silicon respin, a safety-critical requalification, a certification body that must re-examine the product before an update may ship, or a coordination effort across a dozen downstream integrators — and offers a concrete date with interim milestones. A request that says only "we need more time" invites the finder to conclude that nothing is happening, which is usually correct. The FIRST multi-party guidelines, whose version 1.1 was also released in spring 2020, capture the principle: a published, actionable policy with clear timelines is a precondition for good coordination, and stated timeframes are best treated as the opening position in a negotiation rather than a hard boundary. A vendor with no published policy has no opening position, and defaults to whatever the finder chose.

When the Fix Will Never Be Ready

Sometimes the correct answer is that there will be no patch. The product is out of support, the defect is in mask-programmed silicon, or the remedy would break a safety certification that cannot be renewed. Disclosure still has to happen, because the owners of those devices are exposed whether or not they are told. The advisory then documents compensating controls instead of a fix: network segmentation, disabling an affected service, physical access restrictions, monitoring signatures that reveal exploitation attempts, or a recommendation to replace the equipment on a stated timeline. That is unwelcome, and far better than the alternative in which the owners learn of the exposure from an intrusion.

Multi-Party Coordination in the Electronics Supply Chain

A single-vendor disclosure has two parties and one clock. Real electronics disclosures frequently have twenty parties and a clock every one of them wants to move. This is the case the general literature handles least well and the case electronics manufacturers meet most often.

Why Hardware Is the Hard Case

Consider a defect in a network stack embedded in a real-time operating system. The operating system vendor licenses it to chip vendors, who ship it in their software development kits; module makers build the kits into certified radio modules; original design manufacturers build the modules into products sold under other brands; and systems integrators install those products in hospitals, substations, and factories. When the flaw is found at the top of that chain, every layer must receive the information, rebuild, requalify, and release before the owner at the bottom can act — and many intermediate parties do not know who is below them, because distribution obscures the customer list.

The pattern is not hypothetical. The Urgent/11 findings disclosed in 2019 concerned a network stack used in a widely deployed real-time operating system, and the Ripple20 findings disclosed in 2020 concerned a commercial embedded TCP/IP stack licensed and re-licensed for decades; in both cases the affected population had to be reconstructed by investigation, because no supplier held a complete list of who had incorporated the code. Hardware adds constraints software coordination does not face: some downstream parties must re-run regulatory or safety testing before shipping an update, which takes months and cannot be compressed by adding engineers, some cannot update in the field at all, and the logistics of a recall run on an entirely different timescale from a software release.

Running a Coordination

The reference material is the CERT Coordination Center's guide to coordinated vulnerability disclosure, which describes the process in phases — discovery, reporting, validation, prioritization, remediation, public awareness, and deployment — together with the FIRST guidelines for multi-party coordination. The roles those documents define are worth using precisely, because arguments in a multi-party coordination are frequently arguments about who is playing which one: the finder discovers the issue, the reporter conveys it, the vendor produces the remedy, the coordinator brokers among parties who may not trust one another, the deployer applies the result, and upstream and downstream vendors occupy the supply chain positions between.

Several practices separate coordinations that work from ones that collapse. Identify the full affected population early, accepting that this takes weeks and the first list is wrong. Agree a single disclosure date and hold it, because a staggered release means the first advisory tells attackers where to look for the rest. Designate one party to hold the master timeline, usually the upstream vendor or a neutral coordinator, since a group with no coordinator drifts. Reserve identifiers early, share the advisory text in draft so that a downstream integrator does not publish a contradictory description on the same morning, and give downstream parties several days of advance notice of the patch itself so they can stage their own releases rather than scramble in public.

A neutral coordinator earns its role where the parties are competitors. A silicon vendor, two operating system suppliers, and four device makers will not readily share unpatched defect details with one another, but all of them will share with a national coordination center, which is why bodies such as the CERT Coordination Center and national CSIRTs remain central despite every large vendor now running its own program. For industrial control and medical equipment, CISA operates a coordination process for cases in which a vendor is unresponsive or multiple vendors are affected. The wider institutional context is described under cybersecurity regulations.

When the Embargo Breaks

Embargoes leak, and the probability rises with the number of parties and the length of the hold. The disclosure of the Spectre and Meltdown microarchitectural attacks illustrates both. The issues were reported to processor vendors in mid-2017, and coordination across processor designers, operating system vendors, hypervisor developers, and cloud operators extended over months. Coordinated publication had been scheduled for 9 January 2018, but public reporting and observable patch activity forced disclosure on 3 January, before several parties had finished.

A program should therefore hold a contingency plan rather than a hope: a draft advisory kept current from the day the embargo begins, so publication is a decision rather than a writing project; a named person authorized to publish out of hours; a watch for the signals of a leak, including sudden commits to related open-source projects and questions from journalists; and a rule that once information is meaningfully public, withholding the advisory protects nobody but the vendor's schedule.

Safe Harbor and the Legal Posture of a Program

The fastest way to destroy a disclosure program is to send a legal threat to someone who reported a defect. It works exactly once. The researcher publishes the letter, the security community concludes that reporting to this vendor is dangerous, and every subsequent finding goes to a conference, a broker, or nowhere — while the defect remains in the product, because a threatening letter fixes nothing.

The countermeasure is explicit safe harbor language in the published policy. Effective language commits the vendor not to pursue civil action or support criminal prosecution against a finder acting in good faith within the stated scope, and states that the vendor will not treat such research as a violation of the terms of service or the license agreement — which matters because those documents typically prohibit reverse engineering in terms broad enough to cover any security research. Community templates, notably those maintained by the disclose.io project, provide tested wording, and recognizable language reassures a finder more than bespoke drafting.

Scope must be stated with equal clarity, because safe harbor without boundaries is unusable in both directions. A workable policy names the products in scope, sets out what is out of bounds — denial-of-service testing against production services, social engineering of employees, accessing other customers' data, physical intrusion — and asks finders to test against their own equipment. Vague boundaries cause careful researchers to stop and careless ones to proceed anyway. Positive incentives belong in the same document: credit in the advisory, in the form the finder prefers, costs nothing and is what most researchers want.

The legal environment has moved in the researcher's favor in several jurisdictions. In the United States, the Department of Justice revised its charging policy under the Computer Fraud and Abuse Act in 2022 to state that good-faith security research should not be charged, and the Copyright Office has repeatedly granted an exemption for good-faith security research under the anti-circumvention provisions of the Digital Millennium Copyright Act. Neither binds a private vendor's contract terms, which is exactly why the vendor's own safe harbor statement still carries weight.

Hardware Problems That Software Programs Do Not Have

Everything above applies to any vendor. The following applies specifically to organizations that ship physical devices, and it is where hardware disclosure programs actually strain.

The Defect That Cannot Be Patched

A logic error fixed in mask-programmed read-only memory, a flaw in a hardware state machine, or a physical characteristic permitting key extraction cannot be corrected in a shipped part. The vendor may be able to fix it in the next stepping, which reaches customers over quarters, and the installed base remains vulnerable for the product's entire service life — which in industrial and infrastructure electronics routinely exceeds fifteen years. The advisory should therefore say plainly that no fix is possible for affected revisions, identify the first corrected revision and its availability date, and set out what the owner can do instead. Characterizing an unfixable defect as a low-severity curiosity has a short half-life, since the finder understands its severity precisely and will say so publicly.

Mitigation Through Firmware and Microcode

Between "patched" and "unfixable" lies the middle ground where a silicon defect can be contained by software. Microcode updates alter processor behavior after manufacture; firmware updates can disable an affected peripheral, add a check the hardware omits, or change key handling to avoid a vulnerable path; and compiler and operating system mitigations can make an exploitable primitive unreachable.

These remedies carry costs the advisory must state. Mitigations for microarchitectural side channels have measurably reduced performance on affected workloads, and a customer running a capacity-planned system needs that number before deploying rather than after. Some depend on the operating system or hypervisor as well as the firmware, so the vendor must state the complete set of updates required, including those from other suppliers. And the delivery mechanism must itself be trustworthy, because a mitigation shipped through an unauthenticated update path creates a larger problem than it solves; the requirements for that path are covered under firmware update security.

End of Support and the Final Advisory

Every product security program needs a published end-of-support policy, for a reason peculiar to security: a customer who cannot tell whether a device is still supported cannot tell whether the absence of an advisory means the device is unaffected or merely abandoned. A usable policy states the security support period at the time of sale, publishes the end date well in advance, and commits to a final notice telling owners the product will receive no further fixes. The interaction with the wider withdrawal process is treated under software obsolescence management.

The hard case is a serious vulnerability in a product just past end of support that is still in heavy use, which describes a great deal of industrial and medical equipment. Many vendors issue an out-of-cycle fix anyway when safety is implicated and state clearly that the exception does not extend the support period. That is defensible; saying nothing at all is not.

Coordinating Down a Long Supply Chain

A component vendor cannot notify end users, because it does not know them; a brand owner cannot fix a defect in licensed silicon, because it does not have the design. Effective coordination therefore requires contractual plumbing established long before an incident: supply agreements obliging each party to notify the other of security defects within a stated period, naming a security contact who is not the account manager, and permitting the sharing of embargoed information under confidentiality. Without those clauses, a coordination begins with a legal review of whether the parties may talk to each other at all.

The artifact that makes the chain traceable is the bill of materials, hardware and software both. A vendor that can answer "which shipping products contain this component, at which versions" in an hour can scope an inbound third-party vulnerability in a day, while one that must poll each engineering team will still be scoping when the ninety days expire — the same inventory discipline that supply chain compliance requires for other purposes.

From Voluntary Practice to Legal Duty

The regulatory turn is the most consequential change in this field in a decade. Disclosure and vulnerability handling have moved from best practice to statutory obligation across several major markets, with deadlines, penalties, and audit expectations attached.

The European Union Cyber Resilience Act

Regulation (EU) 2024/2847, the Cyber Resilience Act, entered into force on 10 December 2024 and applies to products with digital elements generally rather than to any single sector. Its obligations arrive in stages: the reporting duties apply from 11 September 2026, and the main requirements covering secure design, vulnerability handling, technical documentation, conformity assessment, and CE marking apply from 11 December 2027. Penalties for the core obligations reach 15 million euros or 2.5 percent of worldwide annual turnover, whichever is higher.

Three elements bear directly on a disclosure program. First, manufacturers must have a coordinated vulnerability disclosure policy, which makes the practice described here an auditable requirement rather than a discretionary one. Second, manufacturers must report actively exploited vulnerabilities and severe security incidents through a tiered timeline submitted via the single reporting platform operated by the European Union Agency for Cybersecurity: an early warning within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report within 14 days of a corrective or mitigating measure becoming available. Third, vulnerability handling and security updates must continue through a support period of at least five years unless the expected product lifetime is shorter, with the end date communicated to the buyer at the time of purchase.

The 24-hour clock is the operational shock. It is shorter than any engineering cycle and shorter than most legal review processes, and it starts when the manufacturer becomes aware of active exploitation — which may be a Friday evening message from a researcher. Meeting it requires a decision path defined in advance, with named people, delegated authority, and a rehearsed template. These duties belong to the wider set of continuing obligations described under post-market compliance.

The United Kingdom Product Security Regime

The United Kingdom's Product Security and Telecommunications Infrastructure regime has been in force since April 2024 and applies to consumer connectable products. Of its three baseline requirements, one is squarely a disclosure obligation: the manufacturer must publish information on how to report security issues, and must state the timescales within which the reporter will receive an acknowledgment and status updates. The other two prohibit universal default passwords and require transparency about the minimum period for which security updates will be provided. The regime draws on ETSI EN 303 645, whose second provision requires a publicly available vulnerability disclosure policy, and conformance with the relevant provisions is a route to demonstrating compliance. The wider consumer-device landscape is surveyed under Internet of Things security.

Medical Devices and Road Vehicles

Medical device regulators reached the same conclusion earlier, because the consequence of an unpatched defect can be physical harm. In the United States, section 524B of the Federal Food, Drug, and Cosmetic Act requires premarket submissions for cyber devices to include a software bill of materials and a plan for monitoring, identifying, and addressing postmarket cybersecurity vulnerabilities, which in practice means a coordinated disclosure process the manufacturer can describe to the agency. In the European Union, the Medical Device Coordination Group's guidance on cybersecurity sets parallel expectations. The clinical dimension, including the interaction between a security update and a device's regulatory clearance, is treated under cybersecurity in medical devices.

Automotive regulation took a structural approach. UN Regulation No. 155 requires a manufacturer seeking type approval to operate a certified Cyber Security Management System covering the vehicle's whole lifecycle, including the monitoring, detection, and response to cybersecurity incidents in the field, and UN Regulation No. 156 imposes a parallel management system for software updates. ISO/SAE 21434, published in 2021, supplies the engineering method beneath the regulation, with explicit activities for cybersecurity monitoring, event triage, vulnerability analysis, and vulnerability management after start of production. The obligation is not merely to publish an advisory but to hold an audited management system, evidenced by records, on which the right to sell the vehicle depends — which is the direction the other sectors are moving.

Conclusion

Coordinated vulnerability disclosure is a negotiation conducted under a clock, and the vendor's job is to make that negotiation routine. ISO/IEC 29147 defines what the outside world sees: a monitored channel, an acknowledgment, a status cadence, and an advisory precise enough to act on. ISO/IEC 30111 defines the machinery behind it: triage, verification, a root-cause investigation that finds the variants, a remedy, and a feedback loop that keeps the weakness from recurring. The PSIRT owns both, and it is distinct from the team defending the corporate network, because its remedies must travel to systems it will never touch. The CVE program supplies the shared name, CVSS a severity estimate that is an input to risk assessment rather than a substitute for one, and CWE the taxonomy that turns individual defects into evidence about engineering practice.

What distinguishes electronics is the chain. Ninety days is a workable default for a software vendor with a weekly release train and an unreasonable one for a defect propagating from silicon through firmware suppliers, module makers, and integrators before it reaches the person who owns the device. Meeting it requires work done long before any report arrives: contracts that name security contacts and permit embargoed sharing, a bill of materials that answers scoping questions in hours, a laboratory that can reproduce a physical attack, and an honest end-of-support policy. Safe harbor language protects the supply of reports that makes the whole system function, and a legal threat to a finder ends it. None of this is discretionary any longer, and the programs that will survive the new obligations are those built deliberately and in the right order — channel, policy, owner, triage, handling loop, and rehearsal — rather than assembled in the hours after the first serious report arrives. The exercise is cheap; the uncontrolled first attempt is not.

Related Topics

Disclosure practice connects the standards that mandate it, the testing that produces reports, and the sectors with their own regimes: