Will Your Chip Maker’s PSIRT Warn You About a Flaw? We Checked 40

Last reviewed: 26 October 2026. General information, not legal advice.

When your chip’s firmware or SDK has an exploited flaw, the EU’s 24-hour reporting clock runs from when you become aware of it, which in our view is often when the chip maker tells you. So how it tells you matters. On 25 October 2026, none of the 33 chip-maker websites we could check offered machine-readable CSAF advisories where the CSAF standard tells tools to look. At least 6 of the 40 chip makers we checked publish a list of security advisories on a web page anyone can read. The 40 are the chip makers whose microcontrollers, system-on-chips (SoCs) or FPGAs have a port in the open-source Zephyr real-time operating system (RTOS).

A PSIRT, or product security incident response team, is “a team within a commercial entity (typically a vendor) that manages the receipt, investigation, and internal or public reporting of security vulnerability information related to products or services commercialized by the organization” (FIRST PSIRT Services Framework). The channels below are the public outputs of that work. If a flaw in your chip maker’s firmware or SDK is exploited, how quickly you hear about it depends on which of these channels your supplier uses.

This finding is also listed on SDL Research.

Why does this matter to a device maker?

In our view, the number to watch is the time from a supplier’s fix or warning to a ready Cyber Resilience Act (CRA) report. Since 11 September 2026, a manufacturer must send the CSIRT designated as coordinator and ENISA an early warning of an actively exploited vulnerability in its product “without undue delay and in any event within 24 hours of the manufacturer becoming aware of it” (Article 14(1) and 14(2)(a) of Regulation (EU) 2024/2847; Article 71(2) sets the date). The clock runs from when you become aware. In our view, for a flaw in a chip maker’s firmware or SDK, that is often when the chip maker tells you.

Three more CRA points matter here:

• You have to report flaws you find to the chip maker. A manufacturer that finds a vulnerability in a component must “report the vulnerability to the person or entity manufacturing or maintaining the component” (Article 13(6)). That needs a contact you can find. This applies from 11 December 2027 (Article 71(2)).
• Chip makers can be manufacturers too. The CRA’s definition of a product with digital elements includes “software or hardware components being placed on the market separately” (Article 3(1)). Annex III lists “Microprocessors with security-related functionalities” and “Microcontrollers with security-related functionalities” as important products (Class I, points 13 and 14). Whether a given chip falls in scope depends on the product.
• Manufacturers must publish fixed vulnerabilities. From 11 December 2027, once a security update is available, they must “share and publicly disclose information about fixed vulnerabilities” (Annex I, Part II, point 4). In duly justified cases, the same point lets them delay publication until users have had the chance to patch. Since 11 September 2026, Article 14(8) has also required manufacturers to inform impacted users of an actively exploited vulnerability, “where appropriate in a structured, machine-readable format that is easily automatically processable”. In our view, CSAF is one such format. The CRA doesn’t name a format.

What did we find?

Source: SecureByDesignLabs analysis, 25 October 2026, of the websites of the 40 chip makers with a SoC port in Zephyr’s main tree, and the CVE Program’s partner data (CNAsList.json). Denominators differ because some sites blocked us: 6 for every file check, and 1 more for the CSAF location only.

Which makers publish a web page listing their advisories?

• Ambiq: newest entry 17 February 2026.
• Espressif: newest entry in its Security category is AR2026-006 (28 July 2026). The newest entry on the page is AR2026-008 (15 September 2026), categorised End-of-Life. The table loads with JavaScript.
• Intel: newest release date in its list 11 August 2026 (later dates in its “Updated” column are revisions).
• MediaTek: monthly bulletin, newest published 5 October 2026.
• Nuvoton: advisories SA-001 to SA-007, newest publish date 11 August 2026.
• Renesas: a list of advisory PDFs on its PSIRT page, newest entry 23 July 2026 (ID 202600001, on FreeRTOS in the SmartBond DA14697). The list loads with JavaScript, so it shows only in a browser.

This is a floor. We count only makers whose web page lists advisories with an entry dated 2026. Our dataset records 3 more makers that publish advisories, which we don’t count here: one list whose newest entry is from 2018, and two makers that publish PDF documents without a list page.

Who publishes machine-readable advisories?

• CSAF files: Intel’s security centre says “Public Intel® CSAF advisories can be found here”. They are in Intel’s security-center repository on GitHub. The files there declare "csaf_version": "2.0", for example INTEL-SA-01499, released 11 August 2026.
• Where tools look: the CSAF 2.0 standard says tools should check /.well-known/csaf/, the CSAF: field of security.txt, and a csaf.data.security host name (section 7.3.1). It also notes that the security.txt CSAF: field was “in the process of being officially added” when it was written (section 7.1.8). We found nothing at any of these locations for the 33 sites we could check. Intel’s CSAF files are in its GitHub repository instead.

Who publishes a security contact or assigns CVEs?

• security.txt (RFC 9116): Analog Devices, Infineon, Intel, Raspberry Pi, Rockchip and Texas Instruments.
• CNAs: Analog Devices, AMD, ELAN, Intel, MediaTek, Microchip, Silicon Labs and Synaptics are listed in CNAsList.json.
• CVEs from other CNAs: for makers that aren’t CNAs, another CNA assigns the ID. That might be MITRE, which CNAsList.json lists with the role “CNA-LR”, or a researcher’s or coordinator’s CNA. The assignerShortName field in a CVE record shows which: the CVE record format describes it as “The short name for the organization to which the CVE ID was originally assigned.”
• Customer-only advisories: for 4 makers, the security page says advisories go to affected customers or need a login, or the advisory link redirects to a login page. We don’t name them here.

Related SDL research

This is one step up the supply chain from our earlier finding. On 21 October 2026, for 306 of the 438 connected-device companion apps whose result we could determine (69.9%), we found no published way to report a security flaw on the maker’s website (Most of the 550 Connected-Device Apps We Checked Have No Published Way to Report a Security Flaw That We Could Find). The two studies cover different populations, app makers and chip makers, but ask a broadly similar question: can the next party in the chain find where to send, or get, word of a flaw? Device makers need a route from their users. They also need one to and from their chip makers.

What can you check yourself?

• List every chip and module in your bill of materials. Include the radio module, and note whether the module maker and the chip maker differ. Each may publish its own advisories.
• For each one, write down where advisories appear: a public page, PDFs, CSAF files or a customer portal. If they go to customers only, check that your company is registered with the maker. That matters most if you buy through a distributor.
• Write down the security contact you would use for an Article 13(6) report: a security.txt, a PSIRT email or a reporting form.
• Keep it dated in your technical file. The CRA’s recitals give “checking its security updates history” as one example of due diligence on a third-party component (recital 34; Article 13(5) sets the duty).
• If you are the chip maker, each item above is a question your customers are likely to ask. A public answer can save repeating it per customer.

Method and limits

• Population: all 61 directories under soc/ in Zephyr’s main branch at commit bc5d59d, as fetched on 25 October 2026. We excluded 19 that aren’t a chip maker’s own silicon: emulators and hypervisor targets, shared code, open-source and academic projects, processor-IP licensors and a board maker. We merged Atmel into Microchip and Xilinx into AMD (2 more directories). That leaves 40 chip makers. The population leans towards makers that support Zephyr, so it isn’t every chip maker.
• security.txt and CSAF: fetched on 25 October 2026 from each maker’s main domain, with and without www. We counted security.txt only with a Contact: line, and CSAF only where a valid provider file parsed. A check counts as not done when both an HTTP client and a headless browser were blocked or couldn’t reach the host. Those sites are left out of that denominator: 6 for security.txt, and 7 for CSAF.
• Controls: the same CSAF check found provider files for all 6 known publishers we ran alongside: Siemens, Schneider Electric, SICK, Huawei, Cisco and Nozomi Networks. Qualcomm, Siemens and Arm appear in the CNA list as expected.
• Advisories are a floor, not a rate: we read each maker’s security pages by hand and searched the web. Our first automated pass missed security pages for 5 makers that a web search later found. So “not found by us” isn’t evidence that a maker publishes nothing. That’s why the advisory figure is “at least 6”, with no rate for the rest.
• CNA list: the CVE Program’s partner list as fetched on 25 October 2026 (559 entries), matched by name and domain. Broadcom’s four CNAs are its software divisions, so we didn’t count them for its chips.
• What this doesn’t say: these are channels on websites, not the quality of any maker’s vulnerability handling. A maker may notify customers in ways we can’t see. Naming a maker here doesn’t say anything about its products’ security.
• Captures: captures of each cited page as read on 25 October 2026 are kept on file. Advisory pages were read in a Chromium browser, so lists that load with JavaScript are in the capture, and advisory PDFs were saved as text. Renesas’s list is one of these: the text of the list as the browser showed it on 25 October 2026, including the 23 July 2026 entry, is in our source copy renesas-psirt-advisory-list-2026-10-25.txt.
• General method: how we measure, and how to ask for a correction, is on How we measure.

Last reviewed 26 October 2026. Legal quotations are from Regulation (EU) 2024/2847. This is engineering research, not legal advice, and not a conformity assessment.