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 Vulnerabilities (Submissions, Readiness, Pipeline Findings), CRA compliance (Controls, Policies, Products, Supply Chain Partners, Exposure Search, Supply Chain Intel) and Account. In the new interface the sidebar runs the full height of the window. The workspace menu is at the top. A star in a circle next to a page shows that your plan does not include that page. Pipeline Findings, Policies, Exposure Search and Supply Chain Intel can show it. Four icons at the bottom open Team, Integrations, Settings and Sign out. The top bar has a Search field that opens the same page search as Ctrl K (⌘ K on a Mac). On a phone, the menu button at the top left opens the sidebar.
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/
In the new interface, a toolbar is at the top of Submissions. New report opens a form to log a report that reached you outside your portal, for example by email. The report is not published to your portal. Import adds up to 50 reports from a JSON file. The file holds an array of reports, or an object with a reports array. Each report needs a description of 10 characters or more and can have productName, vulnerabilityType, stepsToReproduce, impact and contactEmail. Actions opens a menu to report a security incident, copy your portal link, open your portal and open portal settings. Export CSAF lists your 10 most recent reports and downloads the CSAF advisory of the report you select. On a plan without CSAF export, it shows a star and opens Billing. Filters shows the reports with one status. The two buttons at the right show the reports as a table or as a grid of cards. When you have no reports, the page shows your portal address, a New report button and an Open your portal link. The old interface does not change.
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. The page keeps a scan result for 10 minutes and shows when the scan ran. A change to any SBOM starts a new scan on the next page load.
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. These are public signals that a reporting channel exists. They do not show CRA conformity. 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.
Each result names the standard it reads. A domain with both reads "RFC 9116 file and policy found". A domain with one reads "No CVD policy found" or "No RFC 9116 security.txt". A domain with neither reads "No reporting channel found". The CRA does not require a security.txt, so the result for a missing file names RFC 9116. From 11 December 2027 the CRA requires a CVD policy (Annex I Part II point 5). In the TR-03183-3 checklist, a MUST row that is not met is red and a SHOULD row that is not met is grey advice. TR-03183-3 is a voluntary BSI guideline.
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 Search through Google Cloud Vertex AI in the EU. 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. The page follows the light or dark theme.
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 bot challenge, a 401, a 403, a 429 or a server error at a security.txt address counts as a refusal. 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). Manifest names are matched without regard to case, and a requirements file can have a suffix, such as requirements-dev.txt. XML SBOMs are not supported. A CycloneDX or SPDX XML file is refused with a message to upload the JSON form. A version range in package.json, such as ^4.17.0, is checked at the lowest version that it allows, and the version shows as 4.17.0 (from range ^4.17.0) wherever it appears. The same applies to a Cargo.toml requirement such as "1.2", which Cargo reads as ^1.2. It shows as 1.2.0 (from range ^1.2). Only =1.2.3 pins a version in a Cargo.toml. In both files, a requirement with no lower bound, such as "*" or "<2.0.0", is stored with no version, and so is a package.json tag such as latest. A Cargo.toml is read in all its dependency tables, including [build-dependencies] and platform tables such as [target.'cfg(unix)'.dependencies], and [workspace.dependencies] in a workspace root. A member crate line such as serde.workspace = true takes its version from the workspace root, so a member Cargo.toml uploaded alone lists that line as unread. A renamed dependency, such as rand_old = { package = "rand" }, is checked as the crate rand. A package.json is read in dependencies, optionalDependencies and devDependencies. A requirements.txt line without an exact == version is stored with no version, so the scan lists its advisories for review and reports no finding for it. After a manifest upload, the page lists the dependencies that have no exact version and the lines that it could not read, such as an -r include, a Git URL or a package.json dependency from a file path. 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. A renamed Cargo.toml dependency counts under its package name. 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. The public validator also lists four practices from the ENISA Technical Advisory for Software Bill of Materials (October 2026): an embedded signature, a hash that binds the SBOM to the artifact it describes, declared known unknowns, and the SBOM type (lifecycle phase). Each practice shows as observed, not observed, or not assessable from the format. These checks have no score, and they do not change the CRA, BSI or CISA results. The advisory is non-mandatory. The validator checks only that a signature or a hash is present. It does not verify the signature or compare the hash with the artifact. A detached signature, for example from Cosign, is not in the file, so check it separately. SPDX has no field for an embedded signature, and SPDX 2 has no field for the SBOM type.
Free SBOM tools
Three SBOM tools on cvdportal.com need no account. The SBOM checker (https://cvdportal.com/tools/sbom-checker) takes a pasted component list, one component per line as a purl, CPE, npm, Go, pip or Maven line, and checks each component against OSV.dev and CVE records. A plain name@version line is read as npm. A line with no ecosystem, such as busybox 1.36.1, cannot be matched by version, so the checker marks it as not scanned and the result counts it apart from the clean components. The option Search links only keeps the list in the browser and gives an NVD and an OSV search link for each line. The SBOM exposure snapshot (https://cvdportal.com/tools/sbom-exposure-snapshot) runs the same scan on an uploaded SBOM or manifest. The scan stores nothing. The SBOM validator runs in the browser and is described above.
When you start a trial from the result of one of these tools, the first dashboard page shows the counts from that check, for example the number of components and known vulnerabilities, or the validator's verdict on the CRA SBOM minimum. It links to Settings → SBOM. The SBOM file itself is not carried over, so upload it there.
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.
An administrator can change the last line of the badge, the footer. Enter the text in the Badge footer field and click Save footer. Leave the field empty to use the default. The default is "Powered by" and the name of your partner when an active partner onboarded you, and "Powered by CVD Portal" for all other companies. The footer can have 48 characters at most, and it must fit the width of the badge. The badge cannot carry words that state a claim the badge does not prove, such as "certified", "compliant", "approved" or "CE". The other lines of the badge do not change. A badge on another website can show the old footer for up to one hour, because the image is cached.
The badge contains its own copy of the Inter font, so it looks the same on all devices.
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). Each authenticator code and each backup code works once. If a code is refused, wait for the next code in your app. Turning 2FA off requires your password. Two-factor applies to password login. When 2FA is on, sign-in with Google, GitHub or Microsoft is refused, and the login page asks you to sign in with your password and code. SAML SSO accounts rely on the identity provider's own MFA. For account safety, repeated failed sign-ins temporarily lock an account for 15 minutes.
Passkeys
Sign in with your fingerprint, your face or a security key instead of your password. Add a passkey at Settings → Account (https://cvdportal.com/settings/account), then select Sign in with a passkey on the sign-in page, or pick the passkey from the suggestions of the email field. A passkey sign-in skips the authentication code, because the passkey checks you with your fingerprint, face or PIN. Removing a passkey signs you out of every session. Accounts created through SAML SSO cannot add a passkey. See Passkeys.
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) covers the CRA reporting obligations of Article 14, which apply from 11 September 2026. They are the early warning within 24 hours, the notification within 72 hours, and the final report, for actively exploited vulnerabilities and for severe incidents. 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 page has one tab for each task.
- Overview shows the September 2026 percentage and the item it counts, the Vulnerability Handling Procedure. The reporting channel on your own website shows under Advice, and the percentage leaves it out. A phase that you prioritise for September also counts. At 100% you have done the work that is legally required for September 2026. The overview also gives one line for each groundwork list, and folds away the three clause groups that the portal mostly supplies.
- Procedure holds the Vulnerability Handling Procedure form and the Article 14 guide.
- Reporting channel holds the steps to publish and verify your security.txt or badge.
- Groundwork holds the process artifacts due 11 December 2027, in two lists. Preparation and intake has the Applicability, Preparedness, Reception and Verification phases. Remediation and release has the Remediation, Release and Post-Release phases.
- Roadmap holds the OpenChain implementation roadmap.
The procedure counts only when it is complete. When you link an existing policy, give a link or a document ID with a version, for example ISMS-SEC-07 v2.1. A single word such as "There" is refused, because a reviewer cannot find the document from it. When you generate the procedure, give the function and email of the triage lead, an email for the early warning owner, the escalation path for a suspected malicious act, where the reporting address appears in your product documentation, and a storage location with a retention period of 10 years or more. The save is refused and nothing is stored until every item is there. A procedure saved before this check, which does not meet it, shows as not complete. It does not count toward the percentage, and your public verification page, badge and attestation letter do not show it.
The Groundwork tab splits the outstanding work into three kinds. Some artifacts are supplied by the portal. A portal artifact counts when the portal holds its data, for example an uploaded SBOM. A portal row with no data says what is missing. Some artifacts can be drafted for you in the portal. The rest are existing engineering documents which you attach as evidence.
Two rows carry an Advice tag. The standard only recommends them, so they leave every count and never show as a next step:
- Assigned coordinator role (RCP-5). RCP-5-RC-01 says a coordinator should be assigned where appropriate. Assign one when a report needs outside coordination, for example with a CSIRT.
- Documentation on the secure communication mechanism used (PRE-5). The one PRE-5 shall is a risk-based enhancement, and the HTTPS reporting form already meets it. Write the document when your risk assessment asks for more than HTTPS.
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.
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.
CRA Requirements Map
The new interface shows the CRA Requirements Map on the Requirements map tab of the Readiness page (https://cvdportal.com/readiness/requirements). The map lists each requirement of Regulation (EU) 2024/2847 with its live status.
Each requirement has the date from which it applies, under Article 71(2):
- The eight Article 14 rows apply from 11 September 2026. Three cover an actively exploited vulnerability, Article 14(2)(a) to (c). Three cover a severe incident, Article 14(3) and 14(4)(a) to (c). One covers the Single Reporting Platform, Article 14(7), and one covers informing the impacted users, Article 14(8).
- The other requirements on the map apply from 11 December 2027. This includes Annex I Part I and Part II, the user information in Annex II and Article 13(18), the technical documentation in Annex VII, the EU Declaration of Conformity and CE marking under Annex V and Articles 28 to 30, and document retention under Article 13(13).
- The rules on notified bodies in Chapter IV, Articles 35 to 51, apply from 11 June 2026. They are not on the map, because they apply to conformity assessment bodies, not to the manufacturer.
An Article 14 row shows the readiness items it needs now, for example a complete procedure and a named final report owner. Its status comes from these items only. When an item is missing, the hint names the next step, for example "Next, name the final report owner". The row also shows the December 2027 groundwork behind it as a separate count, which does not change the status.
Annex I Part I, the technical documentation, the Declaration of Conformity and retention are assessed for each product, in the Products workspace. The map shows them as "Per Product" and never as satisfied.
The requirements that apply now come first. The other requirements follow, each group in the order of the Regulation. The header shows two groups of counts. "Applies now" shows how many of the requirements that apply today are satisfied, in progress, need action, or are assessed per product. "From 11 Dec 2027" shows how many requirements that apply later are upcoming, already satisfied, or assessed per product.
Select a count to list exactly those requirements. Select it again to show all requirements.
Below the category tabs, the list filters by date first and status second. When has the values All dates, Applies now and Applies later. Status has the values Action Required, In Progress, Satisfied, Upcoming and Per Product. The status counts follow the category and the date that you select. Every requirement has one status, so the counts add up to the requirements in the list. A status with no requirements is hidden.
A requirement that does not apply yet has the status "Upcoming" and shows the grey badge "Applies 11 Dec 2027" when its work is not complete. Its hint still shows how many related artifacts are ready. A company requirement with all artifacts complete shows "Satisfied", whatever its date.
The link on a company requirement that is not satisfied opens the groundwork row of its next open artifact, where you record it. A satisfied requirement keeps its usual link, for example to the SBOM registry or to your reports.
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.