CVD Portal — Product Manual

Overview

CVD Portal is a SaaS platform for EU Cyber Resilience Act (CRA) compliant coordinated vulnerability disclosure. It gives manufacturers and importers of products with digital elements a structured inbox for receiving, triaging, coordinating, and publicly disclosing security vulnerabilities — with CRA Art. 13/14 obligations tracked automatically.

Steps 1–3 are included on every plan. Steps 4–6 are optional enhancements available on PRO and above.

Quick Start

From sign-up to receiving your first real vulnerability report takes under ten minutes.

1. 1

   Create your account. Register at cvdportal.com with your work email address. A company workspace is provisioned automatically. OAuth sign-in (Google, GitHub) is also available.

2. 2

   Complete your portal profile. Go to Settings → Portal and fill in your company name, security contact, and scope statement. This text appears on your public submission page.

3. 3

   Share your portal URL. Your public portal is live immediately at cvdportal.com/<your-slug>. Link to it from your security.txt file, product documentation, and vulnerability disclosure policy page.

4. 4

   Invite your team. Under Settings → Team, invite colleagues who should receive and action reports. Roles: ADMIN (full access) and MEMBER (view and action submissions).

5. 5

   Configure notifications. Set an email address or webhook URL for new submission alerts under Settings → Notifications.

Portal Setup

Portal URL & slug

Your portal slug is set during account registration and forms the path on the shared domain: cvdportal.com/acme-corp. The slug cannot be changed after creation — contact support if you need a correction.

Scope statement

The scope statement tells reporters which products and versions are covered. Be specific: list product families, firmware versions, or component names. Out-of-scope items should be explicitly excluded to reduce noise.

Custom domain Enterprise

Enterprise accounts can serve the portal from their own domain via a CNAME record. Configure this under Settings → Portal → Custom Domain.

security.txt

CVD Portal can serve a standards-compliant /.well-known/security.txt file from your portal domain. Enable this under Settings → Portal → security.txt.

Step 1 — Submit

Anyone — a security researcher, a customer, an employee, or an automated scanner — can submit a vulnerability report through three channels:

What the reporter sees

On submission the reporter immediately receives a confirmation email with a tracking reference number, a summary of what was submitted, and an estimated response timeline.

What lands in the dashboard

• Timestamp and reporter contact (anonymous submissions accepted)
• Affected product / component
• Description and reproduction steps
• Any attached files
• Auto-detected severity estimate (editable in Step 2)
• CRA SLA countdown timer, started from time of receipt

Step 2 — Triage

Triage validates the submission and assigns a severity tag. CVD Portal runs automated checks first, then allows your team to review and override.

Automated checks

• Duplicate detection — compares against existing open and closed submissions.
• CVE lookup — if the reporter supplies a CVE ID, it is cross-referenced with the NVD and CIRCL databases.
• CVSS estimate — a baseline CVSS v3.1 score is computed from structured fields in the form.
• CRA scope check — the affected product is checked against your configured product registry.

Severity tags

SLA defaults can be overridden per severity in Settings → SLA.

Disposition statuses

Step 3 — Coordinate

Once a submission is confirmed, CVD Portal manages the coordination window: keeping the reporter informed, enforcing the embargo, and tracking remediation progress.

Notification recipients

• Your security team — all ADMIN and MEMBER users with notification enabled receive an alert.
• Reporter — an automated status update confirms the vulnerability has been accepted.
• Upstream vendor (optional) — if your organisation acts as a coordinator, you can forward the report to the upstream vendor from within the submission detail view.

Embargo & disclosure date

CVD Portal sets a default disclosure date 90 days from confirmation. This is configurable per submission. If remediation completes early, disclosure can be brought forward. If more time is needed, the embargo can be extended with a reason noted in the record.

Messaging the reporter

All communications with the reporter are threaded within the submission record. Use the Send Update action to compose a message — it is delivered by email and logged permanently in the audit trail. Reporters cannot see internal comments.

Step 4 — Remediation

Remediation itself happens in your own development and release workflow. CVD Portal tracks the status, not the fix.

Remediation status lifecycle

1. Confirmed — fix not yet started
2. Fix in progress — engineering work underway
3. Fix ready — patch developed and internally verified
4. Patch released — fix shipped to users
5. Disclosed — security advisory published

Step 5 — CSAF Export PRO

When a fix is ready, CVD Portal can generate a machine-readable CSAF 2.0 security advisory from the submission record.

What is CSAF?

The Common Security Advisory Framework (CSAF) 2.0 is an OASIS standard for structured vulnerability advisories. Downstream tools — vulnerability scanners, SBOMs, dependency trackers — can ingest CSAF documents automatically to update their records without manual intervention.

Generating a CSAF document

1. 1

   Open the submission and click Generate CSAF Advisory.

2. 2

   Review the pre-filled fields. CVD Portal maps submission data to CSAF fields automatically. Edit the product tree, fixed versions, and remediation instructions as needed.

3. 3

   Attach an SBOM (optional). Upload a CycloneDX or SPDX SBOM and it will be linked to the advisory.

4. 4

   Export or publish. Download the JSON document for local distribution, or click Publish to global feed to push it to the CVD Portal crowd-sourced CSAF index.

Step 6 — Compliance Artifacts PRO

CVD Portal turns each closed vulnerability into a signed CRA obligations record — the documentation a notified body would expect to see during a conformity assessment.

What is generated

• CRA obligations checklist — timestamped record of every Art. 13 and Art. 14 action taken against its deadline.
• Audit trail export — signed PDF of the full submission history with timestamps and acting user.
• Policy documentation stub — pre-filled CVD policy document meeting minimum requirements of CRA Annex I, point 2(c).

Navigate to the closed submission and click Export Compliance Record. A ZIP package is generated and also stored in Dashboard → Compliance Records, retained for seven years per CRA record-keeping requirements.

Submissions Inbox

The inbox is the primary view for your security team. It lists all submissions with their current status, severity, and SLA countdown.

• Filter by status, severity tag, custom tag, date range, or reporter
• Full-text search across title and description fields
• Sort by received date, SLA deadline, or severity
• Bulk actions: assign tag, change status, archive

The submission detail view has four tabs:

• Overview — reporter details, affected product, description, attachments
• Timeline — chronological log of all actions and communications
• SLA — CRA deadline tracker with status per obligation
• CSAF / Compliance — advisory generation and compliance record export (PRO)

Tags & Rules

Tags

• Severity tags — system-assigned from CVSS score. Can be overridden manually. Drive SLA timers.
• Custom tags — free-form labels you define. Applied manually or via rules. For organisation only.

Rules

Rules are automatic actions triggered when a submission matches specified conditions. Rules run immediately on receipt.

SLA Tracking

Every submission has a live SLA panel showing CRA-mandated deadlines, calculated from the submission receipt timestamp.

Overdue deadlines are highlighted in red in both the inbox list and the submission detail view. A daily digest email lists all submissions with deadlines approaching in the next 48 hours.

Analytics PRO

• Submission volume — submissions per week/month, by severity and source
• MTTA — mean time to acknowledge, by severity
• MTTR — mean time to remediate
• SLA compliance rate — percentage of submissions where each CRA deadline was met
• Researcher leaderboard — reporters ranked by submission count and confirmed rate

All reports can be exported as CSV. Date range and severity filters apply across all views.

Webhooks

Webhooks push real-time events from CVD Portal to your own systems — SIEM, ticketing, Slack, PagerDuty, or any HTTP endpoint.

Webhook requests include an X-CVD-Signature header (HMAC-SHA256) for verification. Rotate the secret under Settings → Webhooks.

REST API v1 PRO

The CVD Portal REST API allows programmatic access to your submissions and settings.

All requests require a Bearer token:

Authorization: Bearer cvdp_live_xxxxxxxxxxxxxxxxxxxx

Generate API keys under Settings → API Keys. Keys are stored as SHA-256 hashes — store them securely.

Team Members

Free plans include one seat. PRO plans include up to five seats. Enterprise plans are unlimited.

Settings Reference

Plans & Trials

Free trial

New accounts receive a time-limited PRO trial automatically. All PRO features are active during the trial. All data and compliance records generated during the trial are retained if you convert to a paid plan.

CRA Compliance Reference

A practical reference for manufacturers preparing for the 11 September 2026 reporting deadline under the EU Cyber Resilience Act (Regulation (EU) 2024/2847). Covers what the regulation requires, how the obligations work in practice, and how CVD Portal addresses each piece.

What is the security.txt file?

security.txt is a plain-text file published at https://<yourdomain>/.well-known/security.txt. Defined by RFC 9116 (May 2022), it provides a standardised, machine-readable location for a manufacturer’s vulnerability disclosure contact details.

The minimum CRA-relevant fields:

• Contact: — email address or URL where researchers submit reports (multiple allowed in priority order)
• Policy: — link to the human-readable CVD policy
• Expires: — mandatory under RFC 9116; once past this date the file must not be trusted. Set 12 months ahead and renew annually
• Encryption: — URL of the PGP key for encrypted reports (recommended)
• Canonical: — the authoritative URL of this file

The CRA does not name security.txt specifically, but Article 13(1) requires manufacturers to provide an accessible single point of contact for vulnerability reporting. security.txt is the de facto standard for satisfying that obligation. ENISA endorses it in its CVD Good Practice Guide. An expired file weakens compliance posture.

What does scan.cvdportal.com check?

scan.cvdportal.comperforms an unauthenticated check of a domain’s public surface:

1. Presence and validity of security.txt at /.well-known/security.txt (and the legacy fallback /security.txt).
2. Whether the Expires field is current. An expired file is treated as effectively absent.
3. Whether the Policy URL resolves to an accessible CVD policy page.
4. Whether the policy page contains the elements a regulator would expect: a contact channel, a coordinated disclosure timeline, safe-harbour language, and scope.

Article 14 triggers

Article 14 is sometimes summarised as covering “critical or non-exploitable” vulnerabilities. The actual triggers are narrower. The two Article 14 triggers:

1. Active exploitation of a vulnerability (Article 14(1)): credible evidence that the vulnerability is being used in real attacks — customer reports, threat intelligence detections, exploitation code observed in the wild, or CSIRT confirmation. A publicly available proof-of-concept without confirmed exploitation does not automatically trigger Article 14.
2. Severe security incident with significant impact on the security of the product or its users (Article 14(2)).

Internally discovered vulnerabilities that are not actively exploited are handled under Article 13 (CVD policy and routine vulnerability handling), not Article 14. The dashboard distinguishes the two paths.

Article 14 reporting stages

The three-stage timeline once a trigger is met:

The 48-hour acknowledgement to the reporter is ISO/IEC 29147 best practice, not a CRA statutory requirement. Article 13 does not set a specific acknowledgement deadline in primary text.

What each stage requires

Stage 1 — 24-hour early warning (Article 14(2)(a))

A brief notification, not a full technical report. Speed is the priority; root cause analysis is not expected.

• Manufacturer identification and contact
• Product name and affected versions
• Brief description of the vulnerability or incident
• Indication that active exploitation is occurring
• Geographic scope if known
• Initial mitigation actions taken, if any

Stage 2 — 72-hour full notification (Article 14(2)(b))

A full technical report. If a complete analysis is not yet possible, submit what is known and mark the report preliminary. ENISA prefers a timely partial report over a complete late one.

• CVSS 3.1 (or 4.0) score and vector string
• CVE identifier, or a request for one if not yet assigned
• Affected products, versions, configurations
• Known attack vectors and available mitigations
• Supply chain impact assessment

Stage 3 — Final report (Article 14(2)(c))

The 14-day window applies to actively exploited vulnerabilities and runs from the moment a corrective measure becomes available. Severe incidents carry a 1-month window.

• Root cause analysis
• Complete remediation details (patch release, advisory publication)
• CSAF 2.0 advisory if applicable
• Supply chain coordination actions taken
• Steps taken to prevent recurrence

Where notifications go

Notifications are not sent separately to ENISA and multiple national CSIRTs. Manufacturers submit a single notification via the ENISA Single Reporting Platform (Article 29). The platform routes it automatically to the manufacturer’s relevant national CSIRT (the coordinator designated under NIS 2 Article 12(1)) while ENISA receives a copy simultaneously. Until the ENISA SRP is fully operational, notifications go directly to the relevant national CSIRT: BSI in Germany, ANSSI in France, NCSC-NL in the Netherlands.

Standards landscape

The CRA obligations map in the portal covers every obligation a manufacturer carries between now and December 2027, linked to the relevant CRA article, the harmonised standard status, the portal feature that addresses it, and the tenant action required. The two key dates:

• 11 September 2026: Article 14 reporting obligations apply, including to legacy products already on the market within their support lifecycle.
• 11 December 2027: the full CRA regime applies — conformity assessment, technical documentation, CE marking, Annex I essential requirements, and Articles 13 onwards in full.

The mapping is against prEN 40000-1-3 (Vulnerability Handling), the draft European standard developed by CEN-CENELEC JTC 13 / WG 9. prEN 40000-1-3 finished public enquiry in February 2026 and is currently in comment resolution. No harmonised standard under Regulation (EU) 2024/2847 is yet published in the OJEU. Presumption of conformity via EN 40000-1-3 is not yet available.

Data residency

CVD Portal runs on EU-located infrastructure with end-to-end data residency inside the EU, hosted in Frankfurt and Helsinki on EU-headquartered providers. EU data residency is a commercial requirement. Notified Bodies, market surveillance authorities, and EU-headquartered enterprise customers weight it in vendor selection. A CRA compliance vendor that processes vulnerability data outside the EU has a harder conversation with the regulator-facing buyer. Enterprise accounts can request a dedicated data residency confirmation document.

Audit defensibility

The artefacts CVD Portal produces map directly onto the questions an external assessor will ask:

• For Notified Body assessment: a documented, traceable vulnerability handling process aligned with the draft EN 40000-1-3 is concrete technical evidence.
• For market surveillance authority audits: the portal’s immutable audit log, timestamped notifications, and SLA records are precisely the artefacts an MSA inspector will request. The proportionality factors in Article 64(5) explicitly include cooperation and demonstrable good-faith effort.
• For downstream customers’ procurement: enterprise customers increasingly require CVD policies, SBOMs, and CSAF advisories as part of vendor onboarding. The portal produces all three.
• For insurers and M&A due diligence: the same artefacts, used for the same purposes.

FAQ

Glossary