Vendor Security Requirements: What 7 Buyers Ask Suppliers For

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

If you sell software, an SDK or a component to big customers, some of them now publish their vendor security requirements. These say what they want from you, in writing. The 7 buyers we quote are manufacturers, telecoms operators and NHS England. Banks and insurers come in a different way, through an EU law, explained below. The shortest notice deadline in the lines we quote is 24 hours. That means telling a customer about a security problem within a day of learning of it.

This page is for software, SDK and component suppliers who want to know what those customers ask for before the questionnaire arrives. It quotes what 7 buyers publish and gives a checklist of what to have ready.

What we found

On 21 October 2026 we read 11 documents that 7 buyers publish for their suppliers.

• Six of the seven ask for at least one of these.
  • A software bill of materials (SBOM). This is a list of the software parts in your product.
  • Notice of vulnerabilities (security flaws) or incidents.
  • A stated support period. This is how long you will keep fixing security problems.
• Four of those six name the EU Cyber Resilience Act (CRA), an EU law on the security of software and connected products. For Siemens, that is in its marketplace seller baseline.
• NHS England asks digital health suppliers for something different. It wants a Cyber Essentials certificate and, for internet-facing products, an external penetration test from the last 12 months. A penetration test is a security test where testers try to break in. Suppliers who have signed the Cyber Security Charter for Suppliers to the NHS skip the rest of that section of the form. That includes the penetration-test question.

What to do now: 3 steps

1. Find your customers’ terms. Look in your purchase conditions, contract annexes and each customer’s supplier pages.
2. Check what you have against the checklist further down. It covers a parts list (SBOM), a contact for flaw reports, fast notice and a support end date.
3. Read your own signed agreement before you rely on any line here. A buyer’s published terms can change, and a published expectation is not the same as a clause in your signed contract.

Words used on this page

• SBOM (software bill of materials): a list of the software parts in a product, like an ingredients list.
• Actively exploited vulnerability: a security flaw that attackers have been shown to use.
• Support period: how long a supplier keeps fixing security flaws in a product.
• CVSS (Common Vulnerability Scoring System): a score from 0 to 10 for how serious a flaw is. Deutsche Telekom and NHS England both use 7.0 as a threshold.
• EU Declaration of Conformity and CE marking: the maker’s formal statement that a product meets the CRA’s security requirements, and the mark that goes on it (CRA Articles 28 to 30).
• DORA (Digital Operational Resilience Act): an EU law on IT risk at banks, insurers and other financial firms.
• DTAC (Digital Technology Assessment Criteria): NHS England’s assessment framework for digital health products.

This guide quotes the buyers’ documents word for word, says which law sits behind each kind of request, and gives the checklist. Each quote links to the buyer’s own page or document, as read on 21 October 2026. Requirements change; check the document itself before you rely on any line here.

Why are customers asking now?

The CRA makes a product’s manufacturer responsible for the parts it buys in. It must take care that those parts don’t weaken the product’s security. The European Commission’s guidance says the evidence for this may include documents from the supplier. In our reading, that is usually where a customer’s request for your SBOM, your vulnerability process or your support period comes from.

Most of the CRA applies from 11 December 2027. Its duty to report exploited flaws and severe incidents has applied since 11 September 2026. The exact wording and article numbers are in “For engineers” below. Every CRA date is in our Cyber Resilience Act timeline.

Some of the requests below come from other rules: the EU’s Digital Operational Resilience Act (DORA) for banks and insurers, and NHS England’s assessment criteria for digital health products. They are not CRA requirements, and the sections below say which is which.

Which buyers publish requirements, and what do they cover?

What each organisation’s quoted text covers. The dates differ in kind: Honeywell’s are a CRA schedule, Deutsche Telekom’s are twice-yearly end-of-life reporting dates, and NHS England’s is the date its old assessment form stopped being used. Anything not listed for an organisation isn’t in the lines we quote below; the full document may cover it.

• Honeywell: names the CRA; SBOM; vulnerability or incident notice; support period; dates stated.
• GEA: names the CRA; SBOM; vulnerability or incident notice; support period.
• Bosch Energy and Building Solutions B.V. (NL): names the CRA; SBOM; support period.
• Siemens: names the CRA (in its marketplace seller baseline); SBOM; vulnerability or incident notice; support period.
• Deutsche Telekom: SBOM; vulnerability or incident notice; support period; dates stated.
• BT Group: vulnerability or incident notice; support period.
• NHS England: a date stated (its assessment criteria cover other things, below).

What do they ask for?

An SBOM

• Honeywell (EU Cyber Resilience Act (CRA) – Supplier Information, as read on 21 October 2026): “A machine-readable SBOM for each product or component supplied to Honeywell, covering at minimum all top-level dependencies and known vulnerabilities at the time of delivery.”
• GEA (CRA – Amendments to the Standard Terms and Conditions of Purchase, as read on 21 October 2026): suppliers “upon request provide GEA with the EU declaration of conformity, the technical documentation (Art. 31, Annex VII CRA), and an up-to-date machine-readable Software Bill of Materials (SBOM) covering at least all top-level dependencies.”
• Bosch Energy and Building Solutions B.V., Netherlands (Terms and Conditions Cybersecurity for Suppliers, form ref. BTFR-09041-004, 2026-03-17): “Manufacturer shall identify and document Vulnerabilities and Components contained in Contract Products with Digital Elements, including by drawing up a Software Bill of Materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products.”
• Siemens (Conditions of Purchase, status October 01, 2025, section 16): “Supplier shall provide to Customer a software bill of materials in a commonly used and machine-readable format (e.g., CycloneDX version ≥ 1.4 or equivalent)”.
• Deutsche Telekom (Information Security Annex V4.0, as read on 21 October 2026): “the Software Bill of Materials in machine readable format (including vendor name when applicable, software and/or open source name and version) and keep such inventory up-to-date.”

BT Group doesn’t use the term SBOM in the lines we quote, but asks for a component list. In its Supplier Security Requirements V5.3, in the controls that apply “Where the 3rd Party is providing network equipment”: “3rd Party will provide details for all major 3rd party components and dependencies, including but not restricted to, product and version, open-source components and level of support and period.”

Notice of vulnerabilities and incidents, often within 24 hours

• Honeywell: “Agreement to notify Honeywell promptly (and in no case later than 24 hours after becoming aware) of any actively exploited vulnerability or severe security incident affecting products or components supplied to Honeywell, in addition to any mandatory reporting to ENISA and national CSIRTs.” In the CRA’s own terms (Regulation (EU) 2024/2847), ENISA is the “European Union Agency for Cybersecurity” and a CSIRT is a “computer security incident response team”.
• GEA sets three steps: “within twenty-four (24) hours as an early warning”, “within seventy-two (72) hours with an initial assessment including severity, impact, and indicators of compromise” and “within fourteen (14) days with a final report including root cause analysis, applied remediation measures, and affected components as identified in the SBOM.”
• Deutsche Telekom sorts vulnerabilities by their Common Vulnerability Scoring System (CVSS) score: “The Supplier shall promptly provide information to the Purchaser about each Vulnerability (with CVSS score greater or equal than 7.0) including Zero-Day impacting the Deliverables and its consequences”. For vulnerabilities rated “From High to Critical 7.0-10.0”, the annex asks suppliers to “make all efforts to provide a Temporary Fix” within “5 (five) calendar days” and to make the official fix available within “30 (thirty) calendar days”. “The time counter starts when the Vulnerability is detected, except for a Vulnerability located on Third Party components where the time counter starts when a fix is available.”
• BT Group: notice of an incident affecting the service to BT “no later than twenty four (24) hours from the time the Incident comes to 3rd Party’s attention”, and “timely (i.e., as soon as practicable to allow remediation before publicly publishing) information in relation to any vulnerabilities in the Service(s)”.
• Siemens (Conditions of Purchase, clause 16.5; its marketplace seller baseline has the same sentence): “The notification shall be made before any public disclosure of fixed vulnerabilities, allowing Customer reasonable time to implement security updates or remediation measures.”

A stated support period

• Honeywell asks for “your defined support period (end-of-support date) for each product”, as part of “Evidence of an established vulnerability handling process, including your coordinated vulnerability disclosure policy, a designated contact point for vulnerability reports”.
• GEA: “The Supplier warrants that all Deliveries comply with the essential cybersecurity requirements of Annex I Part I CRA and that vulnerabilities are handled in accordance with Annex I Part II CRA throughout the term of the Contract or, for products with digital elements, for no less than ten (10) years from delivery of the product.”
• Bosch Energy and Building Solutions B.V.: “The Support Period shall be at least five years. Where the Contract Products with Digital Elements are expected to be in use for less than five years, the Support Period may correspond to the expected use time, but only to the extent explicitly agreed upon by the Parties in writing.” The supplier also “shall inform Bosch of the end-date of the Support Period for each Contract Product with Digital Elements prior to the conclusion of a contract and/ or binding order regarding that product.”
• Siemens: “Supplier shall continue to support and provide services to repair, update, upgrade and maintain Digital Products including the provision of patches to Customer remedying vulnerabilities and other cybersecurity risks for the expected use time of the Digital Products;”
• Deutsche Telekom (End-of-Life appendix, last revision 07.12.2020, which is older than the CRA): “The EoX information must be provided by the supplier every six months on February 1 and August 1 in final form.” One of the dates it asks for is “The last date on which the supplier publishes fixes for vulnerabilities or security issues in the operating system software.”
• BT Group, for network equipment: “3rd Party will support all equipment and all software and hardware subcomponents for the length of the contract.”

The CRA itself also sets a minimum support period for manufacturers: at least five years, or the expected use time if the product is expected to be in use for less. Its exact wording is in “For engineers” below.

CRA attestations and dates

• Honeywell asks for “A written declaration confirming that your products meet the essential cybersecurity requirements of Annex I, accompanied by a copy of your EU Declaration of Conformity and evidence of CE marking, or (before December 2027) a documented plan and timeline for achieving compliance.” Its page says “Honeywell expects suppliers to progress toward full CRA readiness on the following schedule” (the first date has already passed):
  • “By September 11, 2026”: “Have vulnerability and incident reporting processes operational, including registration on the ENISA Single Reporting Platform, to meet the Article 14 reporting obligations that take effect on that date”.
  • “By Q4 2026”: “Provide Honeywell with CRA compliance attestations (or detailed compliance roadmaps) for all products and components supplied for integration into Honeywell products destined for the EU market”.
  • “By December 11, 2027”: “Achieve full CRA compliance, including completed conformity assessments, CE marking, EU Declarations of Conformity, and all required technical documentation”.
• GEA (supplier page) sets no supplier deadline: “Compliance with these CRA requirements is mandatory when establishing new agreements or renewing existing agreements with suppliers that provide products or components containing digital elements.” Its amendment says “The Supplier shall comply with all applicable requirements of the CRA.”
• Bosch Energy and Building Solutions B.V.: “If the EU Cyber Resilience Act (EU Regulation 2024/2847) stipulates further obligations for the Supplier, such obligations shall apply in addition to these T&C CS for Suppliers.”
• Siemens names the CRA in its Cybersecurity Baseline for Marketplace Sellers and Digital Products (version 2.0, May 2026), for sellers on the Siemens Xcelerator Marketplace: “These measures shall be consistent with applicable laws and regulations, such as EU Cyber Resilience Act (CRA) or Network and Information Security Directive 2 (NIS2), as well as good industry practice”. The section 16 lines quoted above don’t name the CRA.

Note the wording: Honeywell “expects”; GEA, Bosch, Siemens and Deutsche Telekom write their terms into purchase conditions or contract annexes. A schedule a buyer expects you to meet is not the same as a clause in your signed contract, so read your own agreement first.

What do banks, insurers and the NHS ask for?

Banks and insurers: DORA

If you sell IT services to banks, insurers or other EU financial firms, then in our reading DORA usually reaches you through your customer’s contract. The law says what those contracts must contain. One item is help from you when an incident hits the service you provide, either at no extra cost or at a price agreed in advance. DORA has applied since 17 January 2025. This is not a CRA requirement, but it is why a bank’s contract may already ask how you will help in an incident, and at what price. The article-by-article detail is in “For engineers” below.

NHS suppliers: the DTAC

NHS England’s Digital Technology Assessment Criteria (DTAC) page says “The NHS Digital Technology Assessment Criteria (DTAC) is an assessment framework for care commissioners and providers to use when assuring digital health technology (DHT) products”, and “The previous version of the DTAC form should not be used from 6 April 2026 onwards.”

The DTAC form 2.0 (February 2026), section C3, says: “To pass, the manufacturer must have a valid Cyber Essentials certificate.” The next question, C3.2, asks whether the supplier has signed the Cyber Security Charter for Suppliers to the NHS: “If you have responded ‘Yes’ please skip remaining questions within the C3 section.”

For suppliers who answer “No”, question C3.3 applies “If the product is internet based (e.g., website) or is provided as a service accessible from the internet (e.g., Mobile App, server-side software)” and asks for “the summary report of an external penetration test of the product that included Open Web Application Security Project (OWASP) Top 10 vulnerabilities from within the previous 12-month period”. The form adds: “The penetration testing / summary report must demonstrate there are no vulnerabilities that score 7.0 or above using the Common Vulnerability Scoring System (CVSS).”

Question C3.4 asks suppliers to “confirm that software has been produced in adherence to the Department for Science, Innovation and Technology (DSIT) / National Cyber Security Centre (NCSC) Software Security Code of Practice”. None of this is a CRA requirement.

Do component makers already publish their security advisories?

The notice clauses above ask suppliers to tell their customers about flaws, some within 24 hours. Our own research looked at one group of component suppliers: chip makers. A security advisory is a notice from a vendor about a flaw and its fix.

On 25 October 2026 we checked the 40 chip makers whose microcontrollers, system-on-chips or FPGAs have a port in the open-source Zephyr real-time operating system. At least 6 of the 40 publish a list of security advisories on a web page anyone can read. None of the 33 websites we could check offered machine-readable CSAF advisories where the CSAF standard tells tools to look. CSAF is a standard format for security advisories that tools can collect automatically. For 4 of the 40, advisories go directly to customers or sit behind a login.

The study, its method and its limits are in our study of chip makers’ security advisories. In our view, a public advisory list doesn’t replace the direct notice the buyers above ask for: Siemens, for one, asks for notice before public disclosure. It does give a customer one place to check what you have already fixed.

What should you have ready? A checklist

Built from the quotes above. Each item names the buyers whose quoted text asks for it.

1. An SBOM for each product or component you supply: machine-readable (Honeywell, GEA, Bosch Energy and Building Solutions B.V., Siemens, Deutsche Telekom), covering at least the top-level dependencies (Honeywell, GEA, Bosch Energy and Building Solutions B.V.), and kept up to date (GEA, Deutsche Telekom). Siemens’ conditions give CycloneDX 1.4 or later as an example format. BT Group asks network-equipment suppliers for a list of major components and dependencies.
2. A designated contact point for vulnerability reports and a coordinated vulnerability disclosure policy (Honeywell).
3. A way to notify a customer within 24 hours of an actively exploited vulnerability or a severe security incident (Honeywell), with a 72-hour initial assessment and a 14-day final report where GEA’s terms apply, and of an incident affecting the service to BT (BT Group).
4. A fix timetable by severity, if you sell to telecoms operators: Deutsche Telekom’s annex asks for all efforts towards a temporary fix in 5 calendar days and an official fix in 30, for vulnerabilities scored 7.0 to 10.0.
5. Notice to customers before you publish details of a fixed vulnerability (Siemens), and vulnerability information in time for remediation before anything is published (BT Group).
6. A support end date for each product (Honeywell, Bosch Energy and Building Solutions B.V.; Bosch Energy and Building Solutions B.V. asks for it before the contract or order), and for telecoms customers the last date you will publish vulnerability fixes, reported twice a year (Deutsche Telekom’s 2020 end-of-life appendix). The length each buyer asks for differs: at least five years (Bosch Energy and Building Solutions B.V.), ten years from delivery (GEA), the expected use time (Siemens), or the length of the contract (BT Group, network equipment).
7. A written CRA position for each product: either a declaration against Annex I with the EU declaration of conformity and CE marking, or, before December 2027, a documented plan and timeline (Honeywell).
8. For banks and insurers: a stated price, or no charge, for incident assistance (DORA Article 30).
9. For NHS buyers: a valid Cyber Essentials certificate (DTAC form 2.0, February 2026, section C3).
10. For NHS buyers, unless you have signed the Cyber Security Charter for Suppliers to the NHS: the rest of section C3. For internet-facing products, that includes an external penetration test from the last 12 months with nothing at CVSS 7.0 or above. It also includes a confirmation against the Software Security Code of Practice and a multi-factor authentication plan.

For engineers: the legal text behind the requests

The CRA’s duty on components

The CRA puts a duty on the manufacturer of a product, and that duty reaches the parts it buys in. Article 13(5) of the regulation (Regulation (EU) 2024/2847) says “manufacturers shall exercise due diligence when integrating components sourced from third parties so that those components do not compromise the cybersecurity of the product with digital elements”. The Commission’s guidance on applying the CRA (annex to C(2026) 5252, dated 27 July 2026, paragraph 171) says “Evidence for this purpose may consist of documentation obtained from the component manufacturer, such as technical specifications, security documentation or relevant conformity or assurance documentation.”

The CRA’s dates

The dates come from Article 71(2): the regulation “shall apply from 11 December 2027”, and “Article 14 shall apply from 11 September 2026”. Article 14 is the manufacturer’s duty to notify actively exploited vulnerabilities and severe incidents (Article 14(1) and (3)). Honeywell’s page ties its 11 September 2026 date to “the Article 14 reporting obligations that take effect on that date”.

The CRA’s support period

The CRA’s own floor is in Article 13(8): “the support period shall be at least five years. Where the product with digital elements is expected to be in use for less than five years, the support period shall correspond to the expected use time.” That duty is the manufacturer’s. In our reading, contract terms like those above are usually how a manufacturer passes it on, though some of them, such as Deutsche Telekom’s 2020 appendix, pre-date the CRA.

DORA Article 30

If you sell ICT services to banks, insurers or other EU financial entities, then in our reading DORA (Regulation (EU) 2022/2554) usually reaches you through your customer’s contract. Article 28(1)(a) says financial entities that use contracted ICT services to run their business operations “shall, at all times, remain fully responsible for compliance with, and the discharge of, all obligations under this Regulation and applicable financial services law”, and Article 30 sets what their contracts with you must contain. The exception is a provider the European Supervisory Authorities (ESAs) designate as critical under Article 31(1)(a): one of the ESAs, as its Lead Overseer, then oversees it directly (Articles 31(1)(b) and 33(1)).

Article 30(2) says: “The contractual arrangements on the use of ICT services shall include at least the following elements:”. Point (f) is “the obligation of the ICT third-party service provider to provide assistance to the financial entity at no additional cost, or at a cost that is determined ex-ante, when an ICT incident that is related to the ICT service provided to the financial entity occurs;”.

Article 64 states: “It shall apply from 17 January 2025.” This is not a CRA requirement, but it is why a bank’s contract may already ask how you will help in an incident, and at what price.

How we compiled this

We read each document on 21 October 2026 and copied the quotes from it. On 27 October 2026 we checked the NHS England quotes again, word for word, against the live DTAC page and the downloaded DTAC form 2.0.

We include only requirements an organisation publishes itself, and we don’t list any buyer’s suppliers. Inclusion says nothing about how any organisation applies its terms in practice. Some terms apply from the next new or renewed contract rather than from a calendar date; GEA says so in as many words.

If a quote here no longer matches its source, tell us at support@securebydesignlabs.com and we will correct it. Our corrections policy, which covers every page on this site, is on How we measure.

This guide reproduces published requirements for reference. It is not legal advice, and it is not affiliated with or endorsed by any organisation listed.