NIS2 Art. 21(3) points a regulated buyer's vendor security due diligence at its suppliers' 'cybersecurity practices', ENISA has published the list hospitals are told to ask for, and the bare badge on a trust page answers none of it: a position on what a page may assert and what has to sit next to each claim.
NIS2 Art. 21(3) points a regulated buyer's vendor security due diligence at its suppliers' "cybersecurity practices", ENISA has published the list hospitals are told to ask for, and the bare badge on a trust page answers none of it: a position on what a page may assert and what has to sit next to each claim.
Open a vendor's trust page and the first thing you usually meet is a badge: a framework name, a logo, sometimes a tick. It's the least informative element on the page, because it can stand for three different statements. An accredited body may have audited the company and issued a certificate, the company may have graded itself against the standard, or the badge may be a logo file and nothing else, and all three render identically. The reader on the other side now has a list: on 22 July 2026 ENISA published its procurement guidelines for the cybersecurity of hospitals and healthcare providers, which set out what a hospital is told to require from a supplier. Have you read your own trust page the way that hospital will?
NIS2 binds the essential and important entities it covers, and Article 21 is their list of minimum risk-management measures. Point (d) of Art. 21(2) puts "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers" on that list, and Art. 21(3) says what the entity weighs when deciding which of those measures are appropriate:
"Member States shall ensure that, when considering which measures referred to in paragraph 2, point (d), of this Article are appropriate, entities take into account the vulnerabilities specific to each direct supplier and service provider and the overall quality of products and cybersecurity practices of their suppliers and service providers, including their secure development procedures."
The sentence names the supplier's specific vulnerabilities, the overall quality of its products, and its cybersecurity practices, down to its secure development procedures. The words "certificate", "certification" and "certified" appear nowhere in Article 21. What 21(3) asks the buyer to form a view on is how the supplier works.
The duty is the buyer's: ENISA's scope section notes that NIS2 "does not directly impose requirements on information and communications technology (ICT) suppliers", so it reaches you as your regulated customers' diligence. That diligence starts with whatever you chose to publish: the questionnaire is the inbound half of the chain; the trust page is what the buyer reads before sending one. The Directive's verb is "take into account" rather than "verify", so what a page owes that reader is my position, and I'll defend it as one.
ENISA's guideline for hospitals makes that reading concrete. Its scope section (1.2, pp. 5–6) says the recommendations "specify the required security documentation and evidence suppliers must provide for their network and information systems and services", and its legal notice calls the document ENISA's "views and interpretations", so its "must" is guidance for the hospital.
PLAN-02 (p. 16) asks for "verifying adherence to mandated standards, certifications and regulations such as ISO 27001, the EHDS Regulation and the MDR/IVDR". SOURCE-01 (p. 21), the supplier-selection measure, opens:
"When feasible, healthcare providers must prioritise the selection of ICT product and service suppliers who demonstrate certified compliance with relevant security standards and regulations, including MDR/IVDR requirements and the EHDS Regulation."
Its checklist row for clinical information systems asks the hospital to check that supplier selection "includes evaluation of their product certifications and security audit reports" (SOURCE-01.03). Every item on that list is a document. A badge isn't one.
Nowhere in its 69 pages does the guideline contrast a certification with a supplier's own declaration; it only ever names the external kind, "certified or independently assessed". So the distinction below rests on Art. 21(3)'s "practices" wording and on what a diligence reader can do with each claim. NIST defines that job. SP 1326, its July 2026 quick-start guide, defines due diligence (p. 4) as "the investigative process of researching and verifying all available, pertinent information about a given supplier or product so that informed decisions can be made on new acquisitions or existing systems", and files desktop research on publicly available information, as opposed to asking the supplier, under basic due diligence. Your trust page is that information, and the job includes verifying it.
Here's the sort I'd apply to every claim on a trust page. Three kinds of statement wear the same badge; only the first can be checked from outside.
Now put the Art. 21(3) reader, whose job NIST says is "researching and verifying", in front of each. A self-assessment that names its control set answers the practices question directly: this is the standard, this is how far along, this is when it was measured. A certification with its document beside it answers a stronger question and can be verified. The bare badge answers neither, because the reader can't tell which of the three it is, and has to discount it. I think that's the part vendors get backwards: a labelled self-assessment looks weaker than a badge and is worth more to the person doing the diligence, because it can be used.
So here's the rule I hold a trust page to, and it needs no particular software: a trust page may only assert what it can show next to the claim. A certification names its body and date and carries or links the certificate. A self-assessed status says what it's measured against and when. A claim with nothing behind it isn't made. The page that results is shorter, and everything left on it survives a reader who's allowed to check.
We built one implementation of that rule. The register itself was covered in July's post: off by default, three item kinds (framework, subprocessor, certificate), unpublish deletes, a rotatable handle, your own site renders the data.
A published framework appears in one of three modes: a status badge computed from control coverage, an exact percentage, or a "certified" assertion; in the first two modes anything under 50 % coverage is never published. A certificate is a file with issued and expiry dates; expired ones drop out on their own and downloads are off by default.
Now the cost: the product cannot verify a certification. In certified mode the publisher types a certifying body and a date, both optional, and may link a certificate published on the same Trust Center; a link to anything else is refused. Nothing checks the body or the date, and the assertion saves without any of the three. That's weaker than my principle: the product refuses a dangling link and nothing more, so a false "certified" claim is the publisher's to answer for. The floor hides rather than verifies; a buyer can't tell a framework never published from one that fell under 50 %. There's no access-gated document flow: "available on request" is a label with no request mechanism behind it. The public data carries no contact details and no branding. There is still no hosted page: devguard serves the data and you render it on your own site.
www.devguard.ch/trust is rendered from the same public endpoint every customer gets, and shows what the rule costs. Its frameworks band says coverage is "measured against our own control set in devguard, not a third-party audit". Its subprocessor timestamp is labelled "Last updated", deliberately: it says when the data was produced, which is a different claim from someone having checked it. Its certificates band renders nothing because, as the FAQ puts it, "We hold no formal certification yet". The page shows less than a logo wall would.
The rule needs your page, read from the other side. Take every claim on it and sort it: a certified fact with its body, date and document beside it; a self-assessed status that names what it's measured against and when; or decoration. Whatever fails the sort was never telling the buyer anything they could use, and that buyer, under Art. 21(3), has to take your practices into account regardless. Start with the biggest badge.
The assertion rules above are how devguard's Trust Center behaves today.
Angelo runs strategy and the relationships behind devguard. He spends his time with the teams who live with compliance day to day, and keeps what we build tied to what they actually need.
Start free, bring your frameworks, and keep the evidence attached as the work ships — no setup friction, no audit-week fire drill.
Start free, bring your frameworks, and keep the evidence attached as the work ships — no setup friction, no audit-week fire drill.