Skip to main content

Trust portal for approved viewers

The trust portal lets a company share its Cyber Resilience Act compliance records with specific external people it has approved, such as customers, auditors, and distributors. It is included in the Enterprise plan. On a paid Reporting or Compliance plan you can add it for €1,490 per year.

Add the trust portal to Reporting or Compliance​

  1. Go to Settings → Trust Portal. Only an admin sees the offer.
  2. Read the price, then select Add for €1,490 per year. The add-on goes on your current subscription and bills on the same interval. On an annual subscription it costs €1,490 per year, and on a monthly one €149 per month. Stripe charges the payment method on file at once. The charge is prorated for the rest of the current billing period, plus VAT where it applies.
  3. The portal opens when the payment succeeds, usually within a minute. If your bank asks you to confirm the payment, open Billing, select Manage billing and pay the open invoice.

To stop, select Remove the add-on on the same page and confirm. The portal closes for every viewer. Your viewers, settings and published records are kept, so adding the add-on again restores the portal as it was.

The add-on is not sold to partner-billed companies or during a free trial. If your base plan ends, the trust portal closes with it.

What viewers see​

Approved viewers sign in at your-company.cvdportal.com/trust and see:

  • Compliance documents: EU digital identity verification status (eIDAS 2.0), published security advisories (CSAF/VEX), the Coordinated Vulnerability Disclosure policy (security.txt), a statement that the audit trail is tamper-evident, and a note on where to find the vulnerability check.
  • Products: For each shared product: its CRA classification and conformity route, the security update period, the issued EU Declaration of Conformity once you issue one, the draft EU Declaration of Conformity, the Annex VII technical-documentation index, and the vulnerability check of its SBOM.

Only the latest frozen snapshot of a product is shared, never live in-progress drafts. The vulnerability check is the exception. It shows the SBOM check as it is when the viewer opens the page. Every conformity record carries a notice that it does not by itself constitute a presumption of conformity or a guarantee of compliance.

Page layout​

  • Trust portal list. Products show as a register with four columns: the product, its status, the security support end date and the number of part numbers. On a phone each product is one block. Your access, the compliance documents and the notice about the records are in a column on the right, or under the list on a phone.
  • Product page. The banner names the product. A column on the right holds three blocks. At a glance gives the CRA scope, the placing on the EU market, the class, the support end date, the evidence count, the number of part numbers and VEX statements, and the result of the vulnerability check. Downloads lists every file of the product: the evidence pack (JSON), the signed evidence pack (JWS), the product VEX (CSAF 2.0), the SBOM and the HBOM. On this page links to each section. On a phone, At a glance and Downloads come first and the section list is not shown.
  • Evidence count. "3 of 3 provided" counts three supplier security evidence items, the support end date, the CVD policy and contact, and the SBOM. An SBOM that is available on request counts as provided. The software content statement, the HBOM, the CSAF feed and the remediation SLA are voluntary and leave the count. An SBOM that is not applicable, because the product contains no software, also leaves the count.
  • Status marks. Each evidence item has an icon: a check for provided, a dashed circle for not provided and a circle with a line for not applicable. Screen readers read the status as text.
  • Remediation SLA. Times show in days when they are whole days, for example "Critical, resolved within 30 days".
  • Conformity record. The issued EU Declaration of Conformity, the draft and the Annex VII index are closed by default. Select a title to open it. The issued declaration shows its version, its issue date and the SHA-256 of its text, so a viewer can check a saved copy. A declaration issued as a signed PDF lists the Union acts that it covers. Each PDF of the current version, one for each language, has a download link and its SHA-256. A download writes an audit row, as other downloads do.

Vulnerability check​

The vulnerability check shows what the last check of the product SBOM proves. The check asks OSV.dev about each component with a version and a package ecosystem. It asks NVD about a component that has only a CPE with a version. The page reads the result of the last check each time a viewer opens it.

LabelWhen it shows
Not checkedThere is no SBOM for the product, no component can be checked, or the last check covered an earlier version of the SBOM.
Partly checkedSome components were checked and no finding is open, but other components have no version or package ecosystem.
2 open findingsThe check found vulnerabilities that have no VEX status. The icon is red when one of them is critical or high.
2 open findings, 1 known exploitedOne or more open findings are on the list of known exploited vulnerabilities. The icon is always red.
No open findingsEvery component of the current SBOM was checked and no finding is open. Only this label has a green check.

The text under the label gives the counts and the date of the last check. A finding with a VEX status, for example a published "not affected" statement, does not count as open.

The check also shows on a product that has no conformity snapshot. It does not show on a product whose software statement is "Contains no software", unless that product has its own SBOM.

Known exploited vulnerabilities​

When findings are open, the page compares them with a list of known exploited vulnerabilities. The list comes from the GCVE known exploited vulnerability feed (BCP-07), which is updated each day. On a day when GCVE gives no data, the list comes from the CISA catalogue. The text names the source that the last update used, and the date of that update.

A finding matches when its advisory ID or one of its other IDs, for example its CVE, is on the list. A scan of the SBOM records the other IDs of each advisory from OSV.dev.

The page shows no count when the comparison cannot be trusted. The text then says that the findings were not compared, and gives the reason:

  • The last update of the list failed, did not finish, or was not complete.
  • The last update is more than 36 hours old.
  • No scan has recorded the CVE IDs of the open findings yet. This applies to findings that a scan recorded before November 2026, until the next scan of the SBOM. A push of the SBOM through the API or Scan SBOM now on the Supply chain page starts a scan. Enterprise accounts also get a scan each day.

When only some findings were compared, the text gives the count for those findings and says how many were not compared.

Enabling and customizing published records​

Under Settings → Trust Portal:

  1. Enable the Trust Portal: Master toggle activates the portal at your-company.cvdportal.com/trust. When enabled, all publication options show as enabled by default so viewers receive full transparency immediately.
  2. Select Global Published Sections: Administrators can uncheck/toggle off any section:
    • EU Digital Identity Verification: Proves corporate legal identity under eIDAS 2.0.
    • Published Security Advisories: Links to your public CSAF/VEX advisories. Annex I Part II point 8 requires advisory messages with each security update. CSAF is one machine-readable format for them.
    • Coordinated Vulnerability Disclosure Policy: Displays RFC 9116 security contact and policy details.
    • Tamper-Evident Audit Log Notice: Confirms all compliance actions are hash-chained.
    • Vulnerability Check Note: Tells viewers that product pages show the last check of the product SBOM against OSV.dev.

Product-level publication settings​

On any product page under the Conformity tab, in the Public page and trust portal card, or in Settings → Trust Portal under Products on the trust portal. The Settings list is the place to use on a Reporting plan, where the product page is not available:

  1. Use "Share on trust portal" to include the product in the trust portal index.
  2. Set the level of each artifact. Approved viewers shows it on the trust portal only. Public also shows it on the public product page, see Publish the public page. Hidden shows it to your team only. The artifacts:
    • EU Declaration of Conformity (issued): Shows the current issued declaration once you issue one. See Issue the declaration. Enabled by default.
    • EU Declaration of Conformity (draft): Shows the draft declaration of the latest snapshot.
    • Annex VII Technical Documentation Index: Displays file index for technical files.
    • Security Update Support Period: Displays committed end-of-support dates.
    • Vulnerability Check: Shows the result of the last check of the product SBOM. See Vulnerability check. Enabled by default.
    • CycloneDX SBOM Download: Permits viewers to download the software BOM. At Public, anyone can also download it from the public product page. Hidden by default.
    • SBOM available on request: With the download off, the SBOM row reads "Available on request" and names your security contact. Approved viewers then ask you for the file. It needs an uploaded SBOM, and it counts as provided. CRA Annex II point 9 makes sharing the SBOM your choice. Disabled by default.
    • CycloneDX HBOM Download: Permits viewers to download the hardware BOM. At Public, anyone can also download it from the public product page. Hidden by default.
    • CSAF 2.0 Feed and VEX: Displays machine-readable advisory and VEX links. Enabled by default.
    • Remediation SLAs: Displays committed resolution timelines by severity. Enabled by default.

Supplier security evidence​

Approved viewers see a dedicated Supplier security evidence section on the product page. This section consolidates the security verification rows that OT buyers commonly request:

  1. Security support end date (month and year) under CRA Article 13(8), 13(19), and Annex II(7).
  2. Coordinated Vulnerability Disclosure (CVD) policy and security contact under CRA Annex I Part II(5), (6).
  3. Machine-readable advisories and VEX statements via CSAF 2.0. Voluntary. The CRA names no advisory format, and Article 14(8) asks for a machine-readable format only where appropriate.
  4. Software Bill of Materials (SBOM) in CycloneDX 1.6 JSON format under CRA Annex I Part II(1). Annex II point 9 makes sharing it your choice, so the row can show a download or "Available on request".
  5. Software content, a manufacturer statement about the software in the product. Voluntary.
  6. Hardware Bill of Materials (HBOM) in CycloneDX 1.6 JSON format for physical components. Voluntary.
  7. Remediation SLAs by severity detailing manufacturer resolution commitments. Voluntary. The CRA sets no remediation time.

The evidence count leaves out the voluntary rows, so a manufacturer that shares every required row reads "3 of 3 provided".

The evidence pack (schema 1.3) gives the SBOM item the status on_request and a requestContact when the SBOM is available on request.

NIST SP 800-82r4 (initial public draft, September 2026) describes supplier requirements for OT operators in section 3.3. Viewers can download the complete machine-readable evidence package as JSON through the Evidence pack link in Downloads.

Supplier statements​

In Settings → Trust Portal, each product under Products on the trust portal has two statements that you make as the manufacturer. Viewers see them on the product page and in the evidence pack. Each one says that it is your own statement, not a legal opinion and not a presumption of conformity.

  • CRA scope statement. Choose "In scope of the CRA", "Outside the scope of the CRA" or "Scope under review". For "Outside the scope", choose the provision you rely on and write the basis, at least 40 characters. Article 3(1) of the CRA includes hardware components placed on the market separately, so the basis must explain why the product is outside Article 2, for example why its intended or reasonably foreseeable use has no data connection. An out-of-scope product does not show the EU Declaration of Conformity or the Annex VII index.
  • Units placed on the EU market. For "In scope of the CRA", you can also say when the units of the product are placed on the EU market. Choose "All before 11 December 2027", "Before and from 11 December 2027" or "All from 11 December 2027". Viewers see the full sentence, for example "Every unit placed on the EU market before 11 December 2027". The Commission FAQs on the CRA read the dates per unit, so choose the first answer only when no unit will be placed on the EU market from that date.
    • For the first two answers, the product page quotes Article 69(2) and 69(3) of the CRA. Article 69(3) keeps the Article 14 reporting obligations for units placed before 11 December 2027.
    • For the first answer, the product page does not show the EU Declaration of Conformity or the Annex VII index, the trust portal list shows "Placed before 11 Dec 2027" in place of "Assessment in progress", and the integrator security guide shows as voluntary.
    • The evidence pack gives the answer in the marketPlacement field of the cra_scope item, from schema version 1.2.
  • Software content. Choose "Contains no software", "Contains firmware that cannot be updated in the field", "Contains firmware that can be updated" or "Contains software". "Contains no software" needs a short attestation, and the SBOM row then shows "Not applicable". Firmware is still code, so for firmware the SBOM row stays "Not provided" until you publish an SBOM.

The supplier security evidence shows on the product page even when the product has no published conformity record yet, as on a Reporting plan.

Part numbers​

A component supplier can list the part numbers of each shared product. Approved viewers search for a part number on the trust portal index, and see the part numbers on the product page. The evidence JSON pack lists them in the part_numbers item.

To add part numbers:

  1. Go to Settings → Trust Portal. Only an admin can change part numbers.
  2. Under Products on the trust portal, select Manage part numbers for the product.
  3. Paste a CSV or choose a CSV file, then select Import part numbers.

The first row of the CSV is the header.

part_number,description,revision,cpe,purl,lifecycle_status
AX2040QFN,"4 Mb serial memory, 8-pin",B,cpe:2.3:h:example:ax2040:-:*:*:*:*:*:*:*,,ACTIVE
  • Only part_number is necessary. The columns can be in any order.
  • A file has up to 5,000 rows and 1 MB. Put quotes around a value that contains a comma.
  • A part number has 1 to 64 characters. It cannot contain ? or *, because CSAF 2.0 reads these characters as wildcards.
  • cpe is a CPE 2.3 formatted string with the part h (hardware), a (application) or o (operating system).
  • purl starts with pkg: and has a type and a name.
  • lifecycle_status is ACTIVE, NRND (not recommended for new designs), LAST_TIME_BUY or EOL. Empty means ACTIVE.

The import saves the valid rows and shows each rejected row with its line number and the reason. A part number is unique in your company, and case does not matter. A row for a part number that you already have replaces its values, so an empty cell clears that value. If one file has the same part number on two rows, the first row is used. A part number of another product is rejected, not moved. Delete it from that product first.

Viewers search by an exact or a prefix match. For example, AX20 finds AX2040QFN. The search shows only parts of shared, active products.

Integrator security guide​

A component supplier can write an integrator security guide for each shared product. It gives an OEM the information it needs to build the part into its own product. Approved viewers see four sections, one for each point of Annex II of the CRA.

SectionSource
Intended purpose, security environment, functions and security propertiesAnnex II point 4
Circumstances that may lead to significant cybersecurity risksAnnex II point 5
Secure decommissioning and data removalAnnex II point 8(d)
Information for integratorsAnnex II point 8(f)

The guide is part of the Annex II answers of the product. The same record also holds the website and points 7, 8(a), 8(b), 8(c) and 8(e), which complete the Annex II user information sheet. Viewers do not see those answers.

Follow these steps to write the guide.

  1. Go to Settings → Trust Portal. Only an admin can change the guide.
  2. Under Products on the trust portal, select Edit the guide for the product. Each field shows what the Annex II point asks for.
  3. Write the answers and select Save draft. Viewers do not see a draft.
  4. Tick the sign-off box and select Sign off and publish. Every answer must have text. The website is optional.

You can also edit the same answers under Annex II answers on the Conformity tab of the product.

Approved viewers see the signed-off guide on the product page, and the evidence pack has it in the integrator_guide item. When you change the text later, viewers keep the signed-off version until you sign off again. Withdraw the sign-off removes the guide from the trust portal and keeps your draft.

For a product with the scope statement "Outside the scope of the CRA", the guide is voluntary, and the page says so. On the Compliance plan, the signed-off answers also fill the Annex II user information sheet of the product, so you write that text once.

Certificates​

You can show your certificates and qualifications to approved viewers, with their expiry dates. Go to Settings → Trust Portal, section Certificates. Only an admin can change certificates.

For each certificate, give the standard, the category, the scope, the issuer, the issue date and, if it has one, the expiry date and the certificate number. The form suggests ISO/SAE 21434, IEC 62443-4-1, IEC 62443-4-2 and ISO/IEC 27001 as security standards, and AEC-Q100 as a qualification. AEC-Q100 is a reliability qualification, not a security certificate.

A certificate applies to every product or to one product. You can attach a PDF, PNG or JPEG file of 5 MB or less. The portal checks the file content, not only the file name. Approved viewers see the certificates on each product page and can download the files. The evidence pack has them in the certificates item.

A certificate is valid up to and including its expiry date. After that date it stays on the page and shows Expired. It is never hidden. To record a renewal, select Change and set the new dates. To change the product or the file, delete the certificate and add it again.

Signed evidence pack​

Under Downloads on the product page, next to the Evidence pack, approved viewers can download a Signed evidence pack (JWS). It holds the same content as the JSON pack, signed by CVD Portal.

The signature means one thing. Porta Regulus B.V., the operator of CVD Portal, states that your company published this content on its trust portal at the time in the pack. The content stays your own statement, and CVD Portal does not check that it is correct. The pack says this in its signature.meaning field, and the product page says it to viewers.

For a client of a reseller partner, the sentence names Porta Regulus B.V. as the signer without "the operator of CVD Portal". The product page says "the operator of this portal", and the NDA page names the partner as the host.

Each pack also holds these fields.

FieldContent
issuerdid:web:cvdportal.com
issuedAtThe time of the download
tenantYour portal slug and company name
productThe product id and name
snapshotVersionThe version of the latest conformity record snapshot, or null
viewerHashA SHA-256 code that is the same for every pack one viewer downloads

The viewer hash does not show the viewer's identity in the pack. The Download log CSV export has a Viewer hash column, so you can find out which viewer downloaded a pack that leaked under your NDA.

The CVD policy item in the pack now reads the actual state. It gives the security contact address, and the result of the reporting channel check on your own domain when you ran it.

Verify a signed pack​

The pack is a compact JWS, EdDSA over Ed25519. Its header names the key did:web:cvdportal.com#key-2. The public key is in the DID document at https://cvdportal.com/.well-known/did.json.

  1. Download the pack, for example gateway-evidence.jws.
  2. Fetch https://cvdportal.com/.well-known/did.json.
  3. Find the entry in verificationMethod whose id is the kid of the JWS header. Use its publicKeyJwk.
  4. Verify the signature over the first two parts of the JWS, joined by a dot.
  5. Read the payload, the second part, as base64url-encoded JSON.

This Node.js script does the five steps. Save it as verify-pack.mjs and run node verify-pack.mjs gateway-evidence.jws.

import { readFileSync } from "node:fs"
import { createPublicKey, verify } from "node:crypto"

const token = readFileSync(process.argv[2], "utf8").trim()
const [header, payload, signature] = token.split(".")
const h = JSON.parse(Buffer.from(header, "base64url"))
if (h.alg !== "EdDSA" || h.kid !== "did:web:cvdportal.com#key-2") throw new Error("Unexpected key or algorithm")

const did = await (await fetch("https://cvdportal.com/.well-known/did.json")).json()
const method = did.verificationMethod.find((m) => m.id === h.kid)
if (!method) throw new Error("The key is not in the DID document")

const key = createPublicKey({ key: method.publicKeyJwk, format: "jwk" })
const ok = verify(null, Buffer.from(`${header}.${payload}`), key, Buffer.from(signature, "base64url"))
console.log(ok ? "Signature is valid" : "Signature is NOT valid")
if (ok) console.log(JSON.parse(Buffer.from(payload, "base64url")))

A changed character in the payload or in the signature makes the check fail. If CVD Portal ever changes the key, packs signed with the old key fail the check. Download a new pack after a key change.

VEX statements per part number​

A supplier can write a VEX statement by hand for one vulnerability and some or all part numbers of a product. Published statements go into the product VEX file in CSAF 2.0, next to the statements from the SBOM findings, and approved viewers see them on the product page. This is for a vulnerability that no SBOM scan finds, for example a weakness in a chip design, or a published CVE that a customer asks about.

Follow these steps to write a statement.

  1. Go to Settings → Trust Portal. Only an admin can change VEX statements.
  2. Under Products on the trust portal, select Manage VEX statements for the product.
  3. Enter the vulnerability id. Use a CVE, GCVE, EUVD, GHSA or OSV id. For a weakness class with no CVE, use an id of your own and give a title.
  4. Choose the status and write the text that the status needs.
    • Not affected needs an impact statement that says why. The justification label is optional.
    • Affected needs an action statement that tells the customer what to do.
    • Fixed can have an action statement, for example the revision that holds the fix.
    • Under investigation needs no text.
  5. Choose the part numbers. Every part number of this product is selected by default. Clear it to name part numbers, one on each line or separated by commas. Write each part number in full. A part number with ? or * is refused, because CSAF 2.0 reads these characters as wildcards.
  6. Select Save as draft or Save and publish.

The form offers the justification labels component_not_present and inline_mitigations_already_exist first. When the product's software content statement is "Contains no software", only these two labels are accepted. The other three labels describe code, and a part with no software has none.

Nothing writes or publishes a statement for you. A draft stays out of the VEX file until you publish it. To correct a published statement, change it and select Publish the change. To take it out of the VEX file, select Withdraw. A published statement must be withdrawn before you can delete it.

If you delete every part number that a statement names, the statement leaves the VEX file. When you change it, name the part numbers again or select Every part number of this product. The form never widens a statement to every part number on its own.

How the VEX file changes​

  • A product with part numbers has one CSAF product for each part number. Its product_identification_helper holds the part number in model_numbers, and the CPE and purl when the part has valid ones. The product itself is not listed. A product with no part numbers stays one CSAF product.
  • A statement that names no part lists the product id of every part.
  • A finding from the SBOM applies to every part, because the component is in all of them. When a finding and a statement cover the same vulnerability and part, the stricter status wins, in the order that the SBOM registry page describes. A not affected statement cannot hide an affected finding.
  • An id of your own is listed under your company name as the tracking system.
  • A statement has no discovery date, because CSAF means the original discovery date, which you may not know.
  • Each publish, change of a published statement and withdrawal raises the document version. So does an import that adds a part number or changes its spelling, revision, CPE or purl, and the deletion of a part number. The portal stores each version, so the version never goes down, also when you withdraw or clear a statement. Changes made between two downloads share one version, and its revision entry names each vulnerability that changed.
  • A product with no published statement gets a CSAF informational advisory in place of a VEX document. It has no vulnerabilities list, because CSAF 2.0 requires at least one vulnerability in a VEX document. Its summary note says that no statement is published yet. The first published statement makes it a VEX document again.

Managing viewer access​

  1. Approve Viewers: People can request access directly from the portal, or an administrator can invite an email address.
  2. Single-Use Magic Links: Approved viewers receive a private magic link. Opening the link sets a signed 7-day session cookie on the tenant host and consumes the token.
  3. Revoking Access: Revoke a viewer at any time in Settings → Trust Portal. Access terminates immediately on their next page load.

NDA before access​

You can make each approved viewer accept a non-disclosure agreement (NDA) before they see your records. Only an admin can change this setting.

  1. Go to Settings → Trust Portal, section NDA before access.
  2. Write your NDA text in the text box. You can use Markdown. The limit is 20,000 characters. Select Show preview to see the text as viewers see it.
  3. Select Viewers must accept the NDA, then select Save NDA. You cannot turn on the NDA with an empty text.

When the NDA is on, a viewer who signs in sees only the NDA page. The page shows your text, says that the agreement is between your company and the viewer, and says that CVD Portal is not a party. The viewer selects I accept to continue. Until then, every product page and every download (SBOM, HBOM, VEX and evidence JSON) is closed to that viewer. A download link that a viewer opens directly gets an error that tells them to accept the NDA first.

Each saved text has a version. The version is a SHA-256 hash of the text, so a change to the words makes a new version. Changes to line endings or to spaces at the start or end do not. When you save a new version, every viewer must accept it again before they see the portal. The section shows the current version and the number of viewers who accepted it.

For each acceptance we record the viewer, the version, the time, the IP address and the browser user agent. The NDA page tells the viewer this.

You write the NDA text and you are responsible for it. CVD Portal does not review the text. Have your own counsel check it before you use it. If you turn off the NDA, the text and the acceptances are kept. If you turn it on again with the same text, viewers who accepted that version do not accept again.

Download log​

Settings → Trust Portal, section Download log, shows what your viewers did, newest first. Only an admin sees it, because it shows viewer email addresses. The log shows these events.

  • Sign-in. A viewer opened a magic link.
  • NDA accepted. A viewer accepted the NDA.
  • SBOM download, HBOM download, VEX download, Evidence pack download and Signed evidence pack download. A viewer downloaded a file of a product.
  • Certificate download. A viewer downloaded the file of a certificate.

You can filter by viewer email (part of the address is enough), product, event and date range. Dates are in UTC, and the end date is included. The log shows the latest 500 events that match the filters. Select Export CSV to download the same events as a CSV file. For an evidence pack download, the CSV also gives the viewer hash that is in the pack. Cells that start with =, +, - or @ get a leading apostrophe, so a spreadsheet does not run them as formulas.

The log reads the audit trail, which is append-only. It also shows events from before the log existed.

Delegating a control (assignments)​

Separately from the trust portal, an admin can assign a single CRA control to an outside person to provide information or upload a document. The assignee gets a magic link to a one-off contribution page, and their submission is filed as evidence for that control. See the Evidence tab on a product page.