CVD Portal — feature guide
Navigation
The dashboard sidebar is split by product. The narrow rail on the far left switches between the two workspaces: CVD Portal (coordinated vulnerability disclosure: Dashboard, Submissions, CVD Readiness, Pipeline Findings, Analytics) and CRA Portal (EU Cyber Resilience Act compliance: Overview, Controls, Policies, Products, Supply Chain Partners, Supply Chain Intel). Selecting CRA Portal lands on its Overview. Account pages (Settings, Billing, Feedback & Support) appear in both. In the old interface the sidebar is an icon-only strip. Hover over it to see the labels. The new interface shows a fixed sidebar with three groups. They are Vulnerability disclosure (Submissions, Readiness, Pipeline Findings), CRA compliance (Controls, Policies, Products, Supply Chain Partners, Exposure Search, Supply Chain Intel) and Account.
Each product opens on an Overview dashboard (CVD Portal at https://cvdportal.com/dashboard, CRA Portal at https://cvdportal.com/cra-dashboard). The Overview leads with a headline readiness figure and a row of key numbers, then groups the detail into collapsible sections. Every section shows its status (Ready, In progress, or Action required) in its header, and that status stays visible when the section is collapsed, so you can fold away the detail and still read where each area stands. Every card, tile, product row and status panel on both Overviews is a link to the page that acts on it. The CRA Portal Overview covers product conformity readiness (per-product technical file, essential requirements and evidence), the September 2026 and December 2027 reporting obligations, and supply-chain and monitoring posture (partners, published CVD contacts, known-vulnerable component matches and open review triggers).
Every user can choose between the old interface and the new interface. Use the New interface switch in the top bar, next to the theme button. Switch it on for the new interface and off for the old one. The page reloads in the interface you chose. Your choice is saved in this browser, so another browser or device starts from your company's default. Some companies get the new interface as their default. If you made no choice, you see that default. The first time you sign in after the new interface is released, a banner asks you to try it and to send feedback. Try the new interface switches you to it. Give feedback opens the feedback form for the new interface. OK closes the banner. Each of the three buttons closes the banner for good, on every browser. While you use the new interface, the Feedback link next to the switch opens the same form. On the redesigned Overview each part of the page is a widget, and each graph opens the list of the things it counts. Select a segment of the Report status graph or a month in the Reports per month graph to open the submissions list for that status or that month. Select Customize to change the page. You can remove a widget, add it back from the Hidden widgets list, and move a widget up or down. Needs attention now always stays on the page. It groups open work under three headings, Vulnerability reports, Products and Account setup, and each heading shows how many items it holds. The group with the most urgent item comes first. Each group shows 10 items, and Show all opens the rest of that group. Reset to default restores the standard layout. The layout is saved to your own account, so it follows you to every browser, and other users in your company keep their own layout. A read-only view shows no Customize button.
Submissions inbox
All vulnerability reports submitted through your public portal land in Submissions (https://cvdportal.com/submissions). Each submission tracks reporter contact details, affected product, description, severity, and status through the disclosure lifecycle. The full timeline is recorded so you can evidence compliant handling under the CRA vulnerability handling requirements (Annex I Part II).
When a researcher submits a report, they are shown a reference number (for example CVD-4XUTU3MU) and a private link to track its status. If they provided a contact email, that confirmation and link are also emailed to them. The status page (at your portal, /status/
Researchers can also report anonymously by leaving the contact email empty. Anonymous reports are stored without the reporter's IP address (metadata minimisation per BSI TR-03183-3), and the form tells the researcher that anonymous reports can only be processed to a limited extent if follow-up questions are impossible.
CSAF advisories (PRO)
Export advisories in CSAF (Common Security Advisory Framework) format from a submission at https://cvdportal.com/submissions. CSAF is the machine-readable advisory format used by EU CSIRTs and required in modern advisory pipelines. Fixed-vulnerability disclosure is a CRA obligation (Annex I Part II point 4).
Researcher acknowledgment
An advisory can credit the reporting researcher by name or alias. In the advisory editor (Public Advisory panel on a submission), enter the researcher's name or alias and tick the consent checkbox confirming the researcher has given permission to be credited. The credit then appears in an Acknowledgments section on the public advisory page and in the CSAF export's document.acknowledgments array. Without the consent checkbox the name is stored but never shown publicly. This follows the joint CISA/NSA/JPCERT/NCSC CVD guidance on recognising researchers, and the disclosure policy template's promise to credit reporters who want it.
CSAF provider hosting (PRO)
Your public portal also acts as a CSAF provider. It serves a provider-metadata.json at https://
AI triage (Enterprise, opt-in)
When enabled under Settings → AI triage (https://cvdportal.com/settings/ai-triage), AI triage pre-assesses new submissions: suggested severity, CVSS score, vulnerability type, a summary, and whether the issue looks reportable under CRA Article 14. Suggestions never overwrite human decisions.
Threat intelligence (PRO)
Supply Chain Intel (https://cvdportal.com/threat-intel) has two feeds. The vendor watchlist shows advisories for the manufacturers you follow, matched by CPE vendor. Each advisory shows the EPSS probability, sightings and KEV entries from GCVE. SBOM Exposure matches the components in your uploaded SBOM against OSV.dev by exact version.
CRA Exposure Scanner (Compliance)
The Scanner (Settings → CRA Scanner, https://cvdportal.com/settings/scanner) scans your domains for the presence and validity of security.txt (RFC 9116) and a reachable CVD policy, the externally visible signals of CRA CVD compliance. Each scan also produces a BSI TR-03183-3 conformance checklist covering every MUST and SHOULD requirement for the security.txt (canonical URI, contact addresses, OpenPGP encryption key, preferred languages, policy link, CSAF provider metadata, expiry window, and the OpenPGP signature), so you can see exactly how far beyond the baseline your public channel goes.
A CVD policy counts as found only when the page reads as a policy. The scanner rejects a page that says it was not found, and a page that does not mention vulnerabilities in its main content, such as a homepage served at the policy address. A page that is a PDF or that needs JavaScript is shown as found, with a note that its content was not checked.
If a domain sits behind a bot-protection service such as Cloudflare, the scanner can be served an interstitial challenge instead of your page. It retries the request once, and if the challenge persists the checked-URL table marks that row "blocked by bot protection challenge" so you can tell an obstructed check apart from a genuinely missing page. To get an accurate result, allow the scanner's user agent (CVDPortal-CRAScanner/1.0) through your bot-protection rules.
The scanner looks for a CVD policy at the Policy: URL in your security.txt, then at eight common paths: /vulnerability-disclosure-policy, /security-policy, /cvd-policy, /security, /disclosure, /psirt, /product-security and /trust. A policy at any other address is not found by these checks. If your policy is on a help-desk article or a product subdomain, add a Policy: field to your security.txt that points at it.
The free scan at https://cvdportal.com/scan has an option to also search the web. When it is on and the checks above find nothing, the scanner searches Google for a policy page on your domain or one of its subdomains. It then reads each page it finds and counts the page only when it reads as a policy. Pages on other domains never count. The result then says that the policy was found through a web search and not at a standard location. The web search sends the domain name to Google through our AI provider, OpenRouter. Clear the checkbox to scan without it. A scan that starts by itself from a link such as /scan?domain=example.com never runs the web search. Select "Scan now" to run it.
A Zendesk Help Center article behind bot protection is read through the public Zendesk article API.
The Scanner in Settings has the same web search option. It is a checkbox above the domain list, on by default, and it applies to "Scan" and "Scan All". Each company can run 100 web searches a day. The weekly automatic scan (Enterprise plan) never searches, because nobody confirms it at run time. When the policy was found through a web search, the domain details say so and suggest a Policy: field in your security.txt. A domain whose result is not proven shows "Not confirmed" instead of "Non-Compliant".
A web search does not return the same pages every time. If a scan misses a policy that you know exists, scan the domain again, or add a Policy: field to your security.txt so that no search is needed.
When a page refuses the scanner and no channel is found, the free scan shows "Not confirmed" instead of "Exposed", and lists the pages that refused it. A "no channel found" result means that the scanner found none at the places it checked. It does not prove that the company has no channel.
A scan takes at most 75 seconds. The scanner checks the common paths at the same time, so a slow site does not make each check wait for the one before it. A page that the scanner had no time left to check also gives "Not confirmed", not "Exposed".
SBOM and hardware registry (PRO)
Store software bills of materials at Settings → SBOM (https://cvdportal.com/settings/sbom) and hardware product records at Settings → Hardware (https://cvdportal.com/settings/hardware), supporting the CRA SBOM requirement (Annex I Part II point 1). An SBOM covers a product: leave the scope on "All products" and every product uses it, or upload one for a specific product to override that for that product alone. Either way the upload is written into the technical file of every product it covers, which is what satisfies Annex VII point 8, and a product with no SBOM cannot pass the Annex VII export gate. You can upload a CycloneDX or SPDX JSON file (SPDX 2.x and SPDX 3.x JSON-LD are both accepted), or a native dependency manifest (package.json, requirements.txt, go.mod, Cargo.toml, pom.xml, Gemfile.lock). From a CycloneDX file, every component is stored, including components nested inside other components and inside the product entry in the file metadata, so a firmware image that lists its libraries inside its own entry is monitored in full. An SBOM can hold up to 10,000 unique components.
Every CycloneDX or SPDX upload also produces a BSI TR-03183-2 conformance report: whether the file meets the minimum specification version (CycloneDX 1.6 or SPDX 3.0.1) and which of the TR's required data fields (SBOM creator and timestamp, and per component the creator, name, version, filename, dependencies, licences, hash and file properties) are present. The SBOM creator must be a person or an organisation. A generation tool alone does not count. The hash must be SHA-512. Components nested inside other CycloneDX components are counted. For SPDX 3, the per-component fields are not assessed yet, so the report shows them as "not assessed" and leaves them out of the count. Older versions and missing fields never block ingestion; they are reported so you can improve your SBOM pipeline. A free public version of this validator is at https://cvdportal.com/tools/sbom-validator and runs entirely in the browser. The public validator also checks the CRA's own minimum in Annex I Part II(1): a commonly used machine-readable format, the product's components, and at least the top-level dependencies. A document that links no dependency from the product cannot show which components are top-level, so the validator reports "cannot tell" instead of a failure. Add your dependency manifest (package.json, requirements.txt, pyproject.toml, go.mod, Cargo.toml or composer.json) and the validator names every direct dependency the SBOM leaves out. Development-only and indirect entries are excluded and counted. Meeting this minimum is one part of Annex I and not a statement of CRA conformity.
SBOM connectivity from CI/CD (Enterprise)
Instead of uploading by hand, Enterprise plans can push an SBOM automatically from a build pipeline so the supply-chain view never goes stale. Send it to the public API with POST /api/v1/sbom, a Bearer API key, and a JSON body of { "filename": "sbom.cdx.json", "content": "
Products — CRA compliance workspace (Compliance)
The Products workspace (CRA Portal → Products, https://cvdportal.com/products) runs the CRA conformity work per product: Annex III/IV classification and the Article 32 route, the documented Article 13 risk assessment with STRIDE threat modelling and risk scoring, the 22-requirement Annex I checklist with per-requirement owners, due dates and deadline reminders, the 22 ENISA Secure by Design and Default playbooks tracked per product with a signed release gate, Clause 6 and 7 artifact drafting, the draft EU Declaration of Conformity (Annex V) with its simplified Annex VI form and the Annex VII technical-documentation index with export (optionally behind a four-eyes export approval), CE marking guidance, the Annex II user-information sheet with support-period management, and monitoring with assessment snapshots. A company-wide executive readiness briefing (print / PDF) summarises portfolio progress, deadline posture and approval state for leadership. See the dedicated Products workspace guide for details.
In the Evidence tab of a product, attached documentation evidences CRA controls. When the AI analyzes a document and finds a partial match, that partial evidence does not make the control ready on its own. An administrator can review the finding and choose Accept as complete. When a control is ready because the assessment engine verified it from draft documents that nobody has reviewed yet, the row shows the Ready, draft basis badge instead of Ready.
Monitoring sources and obligations (PRO)
Monitoring sources (Settings → Monitoring sources, https://cvdportal.com/settings/monitoring-sources) let you register feeds to watch for vulnerabilities relevant to your products. The obligations tracker (Settings → Obligations, https://cvdportal.com/settings/obligations) helps prepare CRA-mandated notifications and track the December 2027 obligations. The Article 14 reporting flow that applies from 11 September 2026 is driven from each submission.
Email notifications
Configure alert recipients and toggles at Settings → Notifications (https://cvdportal.com/settings/notifications). When "New Vulnerability Reports" is on, every new portal submission is emailed to your alert recipients (or, if none are configured, to your dashboard users). Researchers who left a contact email receive an automatic acknowledgment email when you acknowledge their report. Reporting, Compliance and Enterprise plans also receive Article 14 deadline emails from the hourly deadline monitor: an approaching warning before each stage (24-hour early warning, 72-hour notification, final report) and an alert if a stage deadline is missed. These emails are sent in addition to any webhooks you have configured. A welcome email with your portal URL arrives after your email address is verified.
The Compliance Deadlines section on the same page controls the Annex I checklist reminders (Compliance plan and higher): a daily job emails each requirement owner when an owned item comes due (7 days before) and again once it is overdue, and escalates items that stay overdue past the configurable threshold (default 7 days) to the escalation contact you set there. Without an escalation contact, escalations go to the alert recipients.
Team, API, integrations
- Team members (PRO). Invite colleagues with roles at Settings → Team (https://cvdportal.com/settings/team). Three roles are available: Admin (full control), Member (read and triage, without Article 14 decisions or dismissal), and Auditor — a read-only account for an external assessor or notified body that can optionally expire on a set date, does not consume a team seat (up to 5 per company), and never receives operational alert emails. Auditor sessions cannot change anything; login stops working after the expiry date.
- Public API (Enterprise). Bearer-token API under /api/v1 for automating submissions, data access, SARIF pipeline findings, and SBOM pushes (POST /api/v1/sbom). Create and manage API keys at Settings → API Keys (https://cvdportal.com/settings/api-keys). Each key can be scoped to only what it needs (for example push SBOMs but not export data), given an expiry (30 days, 90 days, 1 year, or never), and restricted to specific source IPs or CIDR ranges. Keys are shown once at creation, and can be rotated (issue a new secret, old one stops working immediately) or revoked at any time.
- Integrations. Webhooks for submission, SLA, Article 14, threat-intel, and SBOM-ingested events at Settings → Integrations (https://cvdportal.com/settings/integrations).
Compliance badge
Every plan can embed a compliance badge on its own website or repository. Settings → Compliance Badge (https://cvdportal.com/settings) gives copy-paste HTML and Markdown snippets plus a live preview. The badge image is served from https://cvdportal.com/api/badge/<your-slug> and links to your public verification page at https://cvdportal.com/verify/<your-slug>, so it doubles as a trust signal and a link back for researchers.
Portal attribution on the free plan
Free portals carry a small "Vulnerability disclosure powered by CVD Portal" line in the footer of the public researcher pages. Paid plans (Reporting, Compliance and Enterprise) do not show it.
Password
Change your password at Settings → Account (https://cvdportal.com/settings/account). Enter your current password and the new one, which must be at least 8 characters. A change ends every session on the account and writes an audit entry. Accounts that sign in through Google, GitHub, or SAML SSO have no password here and manage sign-in with that provider.
Two-factor authentication
Add a second step to password sign-in at Settings → Account (https://cvdportal.com/settings/account). Scan the QR code with any authenticator app (Google Authenticator, 1Password, Authy), confirm a 6-digit code, and save the one-time backup codes shown once at enrolment. After that, signing in with your password also asks for the current authenticator code (or a backup code). Turning 2FA off requires your password. Two-factor applies to password login only. Accounts that sign in through Google, GitHub, or SAML SSO rely on that provider's own MFA. For account safety, repeated failed sign-ins temporarily lock an account for 15 minutes.
Audit log
Every significant action is recorded in an append-only audit log at Settings → Audit log (https://cvdportal.com/settings/audit-log): actor, timestamp, IP, country, and action type. This is your paper trail for CRA evidence.
September 2026 Article 14 readiness
CVD Readiness (https://cvdportal.com/readiness), and Settings → September 2026 (https://cvdportal.com/settings/september-2026), includes a dedicated September 2026 view for the CRA reporting obligations (Article 14) that apply from 11 September 2026: early warning within 24 hours, notification within 72 hours, and final reports for actively exploited vulnerabilities and severe incidents. It also tracks three artifact groups, the Vulnerability Handling Procedure, and your externally published reporting channel. Article 71(2) of Regulation (EU) 2024/2847 applies only Article 14 and Chapter IV from 2026, and leaves every other obligation to 11 December 2027. The process artifacts in the September section prepare the Article 14 report, and none of them falls due on 11 September 2026.
The September section carries two separate counters. Read them as two different measures.
- The percentage at the top measures how ready you are to file an Article 14 report. It counts the process artifacts of the four September phases, which are Applicability, Preparedness, Reception and Verification. Every one of these artifacts is listed lower down in the same September section, grouped by phase, where you tick it and attach evidence. Ticking an artifact is free on every plan.
- The three artifact groups are a separate set. They cover the two documents you supply directly, the Vulnerability Handling Procedure and your externally published reporting channel. These two documents are not members of the process-artifact set, so completing all three groups does not move the percentage.
The summary above the groups splits the outstanding work into three kinds. Some artifacts are supplied by the portal and already count. Some can be drafted for you in the portal. The rest are existing engineering documents which you attach as evidence.
Every artifact row is company level. It carries one tick and one evidence link. 30 of the rows name a document that is written once per product, for example the risk assessment, or once per vulnerability report, for example the remediation plan. Those rows say so, and they ask for the method you apply rather than every copy of the document. Name the products or the reports it covers in the note.
Where a per product row has a matching document in the Products workspace, the row also counts them. It reads "3 of 5 products hold this document in the portal" and links the products still missing it. The count never ticks the row for you, because the row records your company-level method and the count records your per-product work.
The Remediation, Release and Post-Release phases belong to the 11 December 2027 set. They are listed in the December 2027 section of the same page. Settings → Compliance & Obligations (https://cvdportal.com/settings/obligations) shows all seven phases together, and each phase there carries a badge with its deadline.
The generated security.txt follows the BSI TR-03183-3 layout: Canonical, Contact (email plus your portal's submission form), Encryption (your PGP key, served from your portal at /pgp-key.asc when one is saved under Settings → Policy & Security), Acknowledgments (when you save an acknowledgments page URL there), Preferred-Languages, Policy, CSAF (on plans with CSAF export) and Expires. After you verify a domain, CVD Portal remembers it and emails your admins when the published security.txt is missing, expired or expiring within 30 days, plus a quarterly reminder to review the file's contents, matching the TR's quarterly-check requirement.
CVD policy template and customisation
Your public policy page (at your portal, /policy) uses a built-in template aligned with BSI TR-03183-3 section 4.4: confidential handling, no disclosure of reporter personal data without consent, no criminal charges for good-faith research, no NDA requirement, an anonymous-reporting statement, response times, a 90-day coordinated disclosure window, a visible last-updated date and a yearly review commitment. You can override the text under Settings → Policy & Security (English and German), and a "Reset to latest template" button removes your override so future template improvements apply automatically.
Feedback and support
Use the Feedback page (https://cvdportal.com/feedback) to send a message to the team. The floating chat assistant answers questions about the CRA and about using CVD Portal, with citations to the official documentation, and points you to the exact page for what you want to do. Answers appear word by word as they are generated, so you can start reading immediately. Your conversation stays with you as you move between dashboard pages and survives a page refresh; it is kept for the duration of your browser session. It also tracks your setup and per-product compliance progress, recommends your next step, accepts document attachments, and (on the Compliance plan, after your explicit confirmation) can analyze documents, create a product from them, or draft a technical-file artifact for you. See the compliance assistant guide for details.
If something breaks, you do not have to leave the page. Every error message and the error page itself carry a "Report this failure" button. It captures the error details and the page you were on, lets you add an optional note about what you were doing, and sends the report straight to the team. Reports from signed-in users are logged as a bug on your account so we can follow up.