Products — CRA compliance workspace

The Products workspace (https://cvdportal.com/products) is where a manufacturer runs the CRA conformity work for each product with digital elements: classification, risk assessment, the Annex I checklist, clause artifacts, conformity documents, CE marking guidance and ongoing monitoring. It requires the Compliance plan or higher. Members can view; editing requires the workspace Admin role.

Each product page is organised in four tabs: Assess, Requirements, Conformity and Monitoring. A header shows the product's class, its Article 32 conformity route and two progress bars (artifacts completed, criteria passed).

Creating a product

Under Compliance → Products, create a product with a name and description. The number of products you can manage depends on your plan tier.

Classification and conformity route (Assess tab)

Classify the product against the CRA Annex III and Annex IV categories. The class (default, important Class I, important Class II, or critical) determines the Article 32 conformity assessment route, which the page derives automatically: internal control (Module A) where self-assessment is available, or third-party routes (Module B and C, Module H) where it is not. For Class I products, recording the harmonised standards or EUCC certification applied affects the available route.

Risk assessment (Assess tab)

The risk-assessment workspace implements the documented cybersecurity risk assessment required by CRA Article 13:

• Map the product's assets manually, or extract asset candidates from a pasted product manual.
• Generate a STRIDE threat model grounded in the CRA threat catalogue, then confirm or discard each AI-suggested threat.
• Score each risk by likelihood and impact and record a treatment (avoid, mitigate, accept or transfer). Accepting or transferring a risk requires a written justification.
• Record the Annex I Part I(2) applicability of each essential requirement. Marking a requirement not applicable requires a justification.

Saving validates the assessment against the CRA rules and reports any violations inline. Each panel saves only its own data, so working in one panel never overwrites another.

Annex I checklist (Requirements tab)

A 21-requirement self-assessment covering Annex I Part I(1), Part I(2) and Part II. Part I(2) applicability comes from the risk-assessment workspace; for each row you record evidence, an owner, a due date, a sign-off and any residual risk. The checklist can be downloaded as Markdown.

The owner is picked from your team members, and each open item can carry a due date. Items show a "due soon" badge in the 7 days before the deadline and an "overdue" badge once past it; signing an item off closes its deadline. A daily job emails the owner when an item comes due and again once it is overdue. Items that stay overdue past the escalation threshold (default 7 days) are escalated to the escalation contact. Reminders, the escalation contact and the threshold are configured under Settings → Notifications, in the Compliance Deadlines section.

Clause artifacts (Requirements tab)

Draft the Clause 6 (risk management) and Clause 7 (secure engineering) artifacts one by one. Deterministic artifacts such as the risk methodology and the Annex I applicability table are built directly from your assessment data; the rest are drafted by the assistant for your review. Accepting an artifact records it against the product for the Annex VII technical file.

Next to Draft, AI-drafted artifacts also offer "Draft + self-review": the assistant drafts the artifact, scores it for completeness with the gap analyzer, and automatically revises it once when it scores below 70 percent, keeping the better version. The note above the draft shows the resulting completeness and whether a revision was applied. On the Enterprise plan the same self-review runs automatically for every artifact during "Autofill all remaining" (a fired revision counts one extra draft against the daily autofill budget); other plans keep autofill at one draft per artifact.

Drafts are grounded in your own confirmed evidence documents. When a control has confirmed evidence from the document analyzer, the assistant reads excerpts from those documents (the decoded text of text files, or a factual summary captured during analysis for PDFs and images) and bases the draft on those facts, citing the source file name. Controls without direct evidence fall back to documents confirmed for the same clause. Upload and confirm your manuals and policies in the Evidence tab before drafting to get product-specific drafts instead of generic text.

"Autofill all remaining" drafts every missing artifact in one run: several drafts run in parallel, each is generated and recorded automatically as it completes, a progress bar tracks the run, and you can stop at any time keeping what is done. Artifacts that need manual input are skipped and listed at the end for individual attention. Review the generated drafts afterwards; they are recorded as generated, not verified. Shared product context is reused across the run's drafts, which makes long runs faster and keeps every draft grounded in the same classification, manufacturer, and risk-workspace data.

Autofill has a plan-tiered daily budget sized in products (a full product is 88 artifacts): the Compliance plan can autofill one full product per day (90 automated drafts), Enterprise several (300 per day). Free and Reporting plans do not include the drafting workspace. Single manual Draft clicks are not counted against the autofill budget. When the daily budget is reached the run stops, keeps everything drafted so far, and can be continued the next day.

What's left to 100%

The product header shows a "What's left to 100%" button that opens the complete remaining-work list across all three progress dimensions: technical-file artifacts still to draft, assessment criteria not yet passed, and controls without audit-ready evidence, each with a pointer to the tab where it is completed.

Evidence and document analysis (Evidence tab)

The Evidence tab tracks audit readiness per CRA control: a control is audit-ready when the assessment engine has verified it or accepted evidence is attached.

To attach evidence, upload up to 5 compliance documents at once (PDF, images such as PNG/JPG/WEBP for architecture diagrams or settings screenshots, TXT, MD, CSV, JSON, XML, HTML or YAML, max 5 MB each) with "Analyze documents". Each document is dissected by the assistant and mapped to every CRA control it provides evidence for, each match with a confidence score, a satisfied-or-partial coverage verdict and a one-line rationale. Nothing is saved yet: you review the proposed controls per document, untick any that are wrong, and confirm each document separately. On confirmation one evidence record is attached per confirmed control, marked AI-mapped, and a summary shows which controls the batch now covers and how many applicable controls remain gaps. Discarding a review deletes that uploaded document.

When a document clearly identifies the product it describes, the review card shows the detected product name with a "Use as product name" button, so a product created with a placeholder name can be renamed in one click from its own manual.

Attached evidence can be accepted, rejected, re-mapped to a different control or deleted, and evidence can also be added manually as a note against a specific control. Controls can be assigned to a colleague to provide information or upload data.

Importing evidence from Jira and Confluence (Enterprise)

Enterprise workspaces can pull product documentation straight from Atlassian Cloud instead of uploading files. An admin first connects the company's Atlassian site under Settings → Integrations → Jira & Confluence, using the site URL (https://yourcompany.atlassian.net), an account email and an Atlassian API token (created at id.atlassian.com under Security → API tokens; a read-only service account is recommended). The token is verified against the site on save and stored encrypted; it is never displayed again.

Once connected, each product's Evidence tab gains an "Import from Jira & Confluence" section. Enter a Jira JQL query (for example resolved security tickets for the product) and/or a Confluence CQL query (for example the product's documentation space), then run "Import & analyze". Up to 12 items are imported per run; each Jira issue or Confluence page becomes a text document that goes through the same analysis and review flow as an uploaded file, so nothing becomes evidence until you review and confirm the proposed control mappings. Re-running an import skips items that have not changed in Jira or Confluence since the last import.

Ticking "Re-check nightly for changed sources" enables a nightly sync for that product: changed or new items matching the saved queries are re-imported automatically and appear as draft documents awaiting your confirmation. The sync never confirms evidence by itself. Disconnecting Atlassian in settings stops all imports and syncs; evidence that was already imported and confirmed is kept.

Conformity documents (Conformity tab)

Generate the draft EU Declaration of Conformity (Annex V), the simplified declaration (Annex VI, the short form that references the full declaration by internet address for inclusion with the product), and the Annex VII technical-documentation index. The DoC is pre-filled from your company identity and the product's classification and route; remaining bracketed fields must be completed before issuance. The Annex VII index maps the eight required documentation items to your recorded artifacts and lists the gaps. The full technical file can be exported as JSON or as a print-ready HTML page. Exports run the CRA conformance checks, and a product with open violations cannot be exported.

All generated documents are drafts. The workspace structures your assessment and evidence; it does not by itself establish or guarantee conformity.

Export approval, four-eyes review (Conformity tab)

Companies that want a second pair of eyes on the technical file before it leaves the company can enable "Require approval before export" on the Conformity tab (admins only). With the gate on, an admin submits the product for review and a different admin approves or rejects it — the requester can never decide their own review. The technical-file export (JSON and HTML) only unlocks while an approval is current; any change to the assessment, classification or support period makes the sign-off stale and locks the export again until a new review is approved. Every request and decision is recorded in the audit log.

Executive readiness briefing

The "Executive briefing (print / PDF)" button on the Products page generates a company-wide, print-ready management report: per-product conformity progress, Annex I sign-off counts, open issues and review triggers, export-approval state and the latest point of record, plus a portfolio-wide deadline table showing every open Annex I item with its owner and due date. Use it for leadership updates and management reviews; it is an internal document, not a conformity claim.

CE marking (Conformity tab)

Route-aware guidance for affixing the CE marking under CRA Articles 29 and 30, including whether a notified-body number must follow the marking, plus an Article 30 checklist.

User information sheet, Annex II (Conformity tab)

Set the product's support period or support end-date (Article 13(8)), then generate the draft Annex II information and instructions sheet that must accompany the product. The sheet pulls the manufacturer identity, the vulnerability-reporting contact from your portal, the support period, and the foreseeable cybersecurity risks recorded in your risk assessment. Active support periods also appear as comment lines in your portal's generated security.txt.

Monitoring, review and snapshots (Monitoring tab)

Record events that oblige a re-review of the assessment (threat-landscape change, substantial modification, and similar) and resolve them once handled. When placing the product on the market or after a substantial modification, capture an immutable snapshot: it stores the full assessment together with the generated conformity documents, versioned per product and retained for the technical file.

Some review triggers are created automatically from monitoring signals and carry an "auto" tag: a supply-chain scan finding a critical, high-severity or actively exploited (KEV) vulnerability in an SBOM component, or a portal vulnerability report being triaged as real. SBOMs are recorded at company level, so a supply-chain trigger appears on each assessed product and asks you to confirm whether that product actually uses the affected component. Triggers left open for two weeks receive one email nudge.

Periodic documentation review (Monitoring tab)

CRA Article 31(2) and Article 13(3) require the technical documentation and the risk assessment to be kept up to date during the support period. The "Periodic documentation review" panel runs that clock. The review cadence (quarterly or semi-annual) is read from the product's own C6.7-OUT-01 artifact, the determined regularity for reviewing risk management, and can be overridden in the panel. The clock starts with the product's first snapshot, since the keep-current duty attaches when the product is placed on the market.

When a review comes due, confirm the risk assessment, technical documentation and Declaration of Conformity still reflect the product, optionally tick the open review triggers the review addressed, and press "Mark review complete". This stamps the review date, moves the next due date, closes the ticked triggers and files an append-only review record (who, when, cadence, note) as exportable evidence that the declared regularity is practised. A daily job emails a reminder 30 days before the due date and again once it is overdue; these reminders share the Compliance Deadlines toggle under Settings → Notifications.

The product header also warns when the declared support period (Article 13(8)) is inside its last 90 or 30 days, with a pointer to the Annex II sheet for the end-of-support user notice, and shows a "possible substantial modification" hint when the assessment content has changed since the last captured snapshot.