Skip to main content

CRA compliance features

CRA compliance in CVD Portal guides manufacturers through Cyber Resilience Act requirements as a single ordered path.

Ordered compliance workflow​

Each product follows an ordered sequence of readiness checks:

  1. Classify the product: Determine the Annex III/IV category and Article 32 conformity route.
  2. Record the notified body: Required when self-assessment under Module A is unavailable.
  3. Describe the product: Provide Clause 6.2 context inputs.
  4. Record the risk registers: Confirm at least one asset, record at least one threat of your own, and record at least one risk. Required once the risk assessment documents carry content.
  5. Assess the risk: Score the risks and determine treatment.
  6. Sign off the requirements: Complete the Annex I essential requirements checklist.
  7. Attach the evidence: Attach audit-ready evidence to applicable controls.
  8. Upload the SBOM: Provide the Software Bill of Materials (Annex VII point 8).

Risk treatment proposals​

Each scored threat on the Assess tab shows a treatment proposal. A proposal has three parts: a mitigation, the residual likelihood and impact after that mitigation, and the residual score. The first proposal is generic guidance for the threat's STRIDE category. Click "Propose with AI" to get a proposal written for this threat and product. The residual likelihood and impact are never higher than the inherent values. The generic guidance keeps the inherent impact unless its mitigation limits the damage. If you change the likelihood or impact, an AI proposal made for the old values is dropped, and you can ask for a new one.

Click "Accept treatment and residual risk" to record the proposal. One click sets the treatment to mitigate, writes the mitigation on the threat, and records the residual likelihood and impact. You can change any of these values after you accept. An accepted proposal stays on the threat after you reload the page. Nothing is recorded until you click Accept, and you must still save the assessment.

The product header displays the current step as the primary action. Subsequent steps remain available through progressive disclosure sections that show their current status.

Below the current step, the Work completed strip reports three counts: Clause 6 and 7 artifacts, criteria passed, and evidence recorded across all controls. A bar is green at 100 per cent and amber below it, so an incomplete dimension is visible without comparing the numbers. Each label and count is a link, and the page scrolls to what it opens. The artifact count opens the first artifact still to be drafted, on the Requirements tab or, for a Clause 6.2 input, on Assess. The evidence count opens the first control that is not audit-ready, on the Evidence tab. The criteria count opens the Assess tab, because a criterion has no row of its own. On the Evidence tab, use the "Show only the N not ready" button to hide the controls that are already audit-ready.

Under the strip, a row of status chips appears when the product has open items. Each chip is a link and each explains itself on mouse-over. "N violations" opens the Assess tab and counts contradictions inside the saved assessment, such as a risk with no owning asset. "N open triggers" opens the trigger list on the Monitoring tab and counts recorded events that oblige a re-review of the risk assessment (CRA 6.7.3 / 7.9): a change in the threat landscape, a cybersecurity issue, or a change in risk exposure. Some triggers are recorded by hand and others come from a KEV listing, a match in the software bill of materials, or a vulnerability report. A trigger does not block the export, and a documentation review closes it. "Documentation review due" opens that review panel, and "N pending assignments" opens the Evidence tab, where evidence requests sent to a colleague are tracked. The Monitoring tab is admin-only, so a member sees those two chips as plain text.

September 2026 readiness and December 2027 readiness​

The readiness page shows two separate measures.

September 2026 Article 14 readiness is the work legally required on 11 September 2026. Under Article 71(2) of Regulation (EU) 2024/2847, only Article 14 binds that date. Article 14 is the duty to report an actively exploited vulnerability or a severe incident. The work that meets it is two documents, your Vulnerability Handling Procedure and your externally published reporting channel. When both are in place, this measure reads 100%, and a board or auditor can see that your September 2026 obligation is complete.

December 2027 readiness is the full CRA groundwork, every process artifact across all seven phases. This is Article 13 and Annex I work, legally due 11 December 2027. It prepares your Article 14 report but is not itself due in September 2026.

The two measures stay separate on purpose. A completed September figure is Article 14 readiness alone. It never reads as full CRA compliance.

Pulling a phase into your September target​

Each September phase carries an explanation of this framing and a link to the regulation. You can record a stance for each phase, either "Prioritise for September 2026", "Plan for December 2027", or "Undecided", with an optional note. A phase you mark "Prioritise for September 2026" folds its artifacts into your September 2026 required set, so you define the target you report against. Phases left "Plan for December 2027" or "Undecided" stay in the December 2027 groundwork. Your stance and note travel in the exported evidence package, alongside both scoped readiness statements.

Workspace components​

  • Products workspace: Product classification, risk assessment, Annex I checklist, technical file artifacts, and conformity documentation.
  • Article 14 reporting: 24-hour early warning, 72-hour notification, and final incident reporting.
  • SBOM registry: Software Bill of Materials tracking and vulnerability monitoring.
  • Upstream reporting: Third-party and open-source component duties.
  • Feature guide: Platform-wide capabilities overview.