Skip to main content

PortaRegulus CRA app — feature guide

Risk assessment workflow (sidebar clauses 6.2 to 6.4)​

The risk workflow follows a structured method aligned with the CRA's requirement for a documented cybersecurity risk assessment (Article 13(2) and 13(3)).

  • 6.2 Product Context. Describe the product, its intended purpose, and its operational environment. You can also upload an architecture diagram and let the app extract interfaces, components, and data flows from the image automatically.
  • 6.2 Assets. List the assets to protect (data, functions, interfaces).
  • 6.3 Risk Criteria. Define your likelihood and impact scales and acceptance thresholds.
  • 6.4 Threat Model. Model threats per asset using the STRIDE editor (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege).
  • 6.4 Risk Assessment. Rate likelihood and impact per threat, decide treatments, and track residual risk.

Classification & conformity route (sidebar Classification & Route)​

The Classification section on the Compliance & Conformity page determines the CRA product class and the Article 32 conformity assessment procedure. This is the pivotal CRA decision, because it sets how you are allowed to demonstrate conformity.

  • Pick the Annex III or Annex IV category that matches the product. The app suggests a category from the product name and description, which you confirm or change.
  • The app derives the product class (default, important Class I, important Class II, or critical) and the conformity route:
    • Default products can self-assess using the internal control procedure (Module A), Article 32(1).
    • Important Class I products need a third-party route (EU-type examination Module B plus Module C, or full quality assurance Module H) until a harmonised standard for the CRA is cited in the Official Journal, Article 32(2).
    • Important Class II products always need Module B+C, Module H, or a European cybersecurity certification scheme at assurance level at least substantial, Article 32(3).
    • Critical products (Annex IV) are demonstrated through a European cybersecurity certification scheme under Article 8, Article 32(4).
  • Record a classification justification (required for important and critical products) and any harmonised standards or certification schemes applied.
  • Confirm the classification. Placing a product on the market (a snapshot) is blocked until the class is determined.

Conformity documents​

From the Classification section you can generate four formal documents:

  • EU Declaration of Conformity (draft) — the Annex V fields (1 to 8) prefilled from your classification and product data, with placeholders for the manufacturer, notified body (when the route requires one), and signature. It carries the non-presumption caveat while no harmonised standard is yet published in the Official Journal (Article 28, Annex V).
  • Simplified EU Declaration of Conformity — the Annex VI short form that references the full declaration by internet address, for inclusion with the product (Article 28(3), Annex VI).
  • Annex VII technical documentation index — a present/missing checklist mapping the eight Annex VII items to the artifacts in your workspace, so you can see what still needs to be produced for the technical file (Article 31, Annex VII).
  • Annex II user information (draft) — the nine Annex II items (manufacturer identification, vulnerability reporting contact, product identification, intended purpose, foreseeable risks, DoC address, support period, secure-use instructions, SBOM access) prefilled from your workspace with placeholders for the rest (Article 13(18), Annex II).

All documents, plus the classification and route, appear in the Conformity Export pack and in the exported report.

Artifacts and documentation​

  • Artifacts (6.4) and All Documents (the Artifact Registry). Generate compliance documents from your assessment data. Generation uses AI grounded in your own product context and previously generated documents. Generated artifacts are versioned and stored in the registry.
  • Export & Declaration (Conformity Export). Bundle documentation for a conformity assessment, in line with the technical documentation requirements of CRA Article 31 and Annex VII.
  • Executive Report. A summary report suitable for management.

SBOM Manager​

Manage software bills of materials for your products. The CRA requires manufacturers to draw up an SBOM in a commonly used, machine-readable format covering at least top-level dependencies (Annex I Part II point 1).

Incident Reporting (ENISA)​

Track security issues that may be reportable under CRA Article 14 (actively exploited vulnerabilities and severe incidents). From 11 September 2026 manufacturers must submit an early warning within 24 hours, a notification within 72 hours, and a final report. The tracker computes all three deadlines per issue. The final report is due 14 days after a corrective or mitigating measure becomes available for vulnerabilities (record this with the "Fix available" action), or one calendar month after the 72-hour notification for incidents. An issue carrying both duties takes the earlier date. Each issue can record its Article 14 track (vulnerability, incident, or both) and the designated national CSIRT coordinator for your Member State, which is included in the notification packet draft together with a per-stage checklist of the information the ENISA Single Reporting Platform expects.

Vulnerability Disclosure (CVD Portal integration)​

The Vulnerability Disclosure page (https://app.cra.portaregulus.com/cvd) connects your workspace to CVD Portal (https://cvdportal.com), the companion product for coordinated vulnerability disclosure. You can register your products with CVD Portal, see the reports researchers filed against them, and open CVD Portal without a separate password. A CVD policy is mandatory under CRA Annex I Part II point 5. See the dedicated "CVD Portal integration" guide for how registration, sign-in, and the shared workspace behave.

Third-Party Management​

Track third-party and open-source components and the due-diligence obligations for integrating them (CRA Article 13(5) and 13(6)).

Collaboration, Knowledge Graph, Audit Trail​

  • Collaboration. Invite team members to work on the same workspace.
  • Knowledge Graph. An interactive graph linking CRA requirements, your products, risks, and evidence.
  • Audit Trail. Immutable log of significant actions for accountability.

Feedback & Support​

Use Feedback & Support in the sidebar to send a bug report, feature request, or support question to the team. The floating chat assistant answers questions about the CRA and about using the app, citing the official documentation it draws from.