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 the Classify, Context and risk, Evidence and Conformity tabs. The Requirements, Keep compliant and Secure by design tabs, and all editing, require the workspace Admin role.

Each product page is organised in seven tabs: Classify, Context and risk, Requirements, Evidence, Conformity, Keep compliant and Secure by design. The first six tabs have the same names as the stages in the stage bar, and each stage opens its tab. The Secure by design tab carries a Beta label. The tab strip is a single stop when tabbing through the page, and the left and right arrow keys move between the tabs from there, with Home and End jumping to the first and last. A header shows the product's class, its Article 32 conformity route and the stage bar with the next step. Below the stage bar, "Export checks and progress" is closed by default. Its summary line counts the export checks met and names the first open check. That check can belong to a later stage than the one the stage bar shows, because the export checks and the stages measure different things. Open it to see the readiness summary, the progress bars for the work completed and the remaining work.

The readiness summary, under "Export checks and progress", answers whether the technical file may leave the company yet, by running the same eight checks that gate the Annex VII export: a recorded classification, a notified body with its procedure where the route needs one, a drafted product context, the asset, threat and risk registers filled, at least one assessment criterion passed, at least one Annex I requirement signed off, at least one carrying evidence, and a software bill of materials. The checks are shown as an ordered path, so the product asks for one thing at a time and the current step names the action and links to its tab. A tick means that check is met. It is a floor rather than a finished section, which is why a step can carry a tick while work in that area is still outstanding. The path skips the notified body step for a product that self-assesses under Module A.

Below the path, the panel also reports items that do not block the export. Each item carries the label "Does not block export" and has no step number. It does not change the count of checks met, the stage bar or the export. At this time there are two items. "Manufacturer not confirmed" shows until an admin states who the manufacturer is, in the Manufacturer section of the Classify tab. "Support period not set" is the second item. It shows when the product has no declared support period in months and no support end date (Article 13(8)). The summary line names it too, so you see it while the panel is closed. Admins get a "Set the support period" link that opens the User information (Annex II) section on the Conformity tab. The item goes away when you save a support period there. The MCP tool get_conformity_gaps and GET /api/v1/compliance/gaps do not list it, because each entry in those lists counts as a gap.

The progress bars answer a different question, how much has been produced, and the two can disagree sharply. A product can sit at 100 percent of its technical file artifacts while every check that gates an export is still outstanding, because artifacts accumulate as they are drafted whereas the checks ask whether the file demonstrates anything. The opposite also happens: every check can be met while dozens of items of work remain, because the checks are minimum thresholds. The page reports the next action once, in the readiness card. When every check is met and nothing is left in artifacts, criteria or evidence, and no validation issue is open, the page says the assessment is complete and to keep monitoring for review triggers.

Beside the summary the header carries short signals, each of which explains itself on mouse-over. Violations are contradictions inside the saved assessment, such as a risk with no owning asset, and are fixed on the Context and risk tab. Open triggers are recorded events asking for a re-review, which do not block progress and close with a documentation review on the Keep compliant tab. Pending assignments are evidence requests a colleague has not answered. A documentation review chip appears when the periodic review under Article 31(2) and 13(3) is due or overdue, which is separate from the export sign-off.

Conformity path preview

A conformity path layout is in preview for enabled accounts. The page follows the order of Regulation (EU) 2024/2847 in five phases: 17 pre-declaration steps and 4 post-market steps.

• Overview. One next action, the pre-declaration step count, the conformity blockers, the reported items, the five phases and the key dates.
• Scope and identity. The scope decision, the manufacturer and its confirmation, the importer and distributor, the classification and the conformity route. Facts detected from an uploaded document show "Proposed from document" with the source quote until you confirm each value.
• Risk assessment. The product context with user types, interfaces and remote data processing, the support period, the assets and threats, and one row per risk with its threat. A support period below five years needs a written basis under Article 13(8), and an unsupported short period opens a conformity blocker. The assets and threats step is done when each register holds one confirmed row. A confirmed threat with no risk shows as "Not estimated", and bulk treatment applies only to estimated risks. In the side panel of a risk, an AI-proposed cause shows "Proposed by AI" with the button "Accept cause".
• Requirements and evidence. One applicability decision for each Annex I Part I(2) letter, with the security objectives of that letter inside it. An objective can keep its own answer. A letter whose objectives disagree with it shows "Mixed, review". "Applies" is the default for a letter with no decision, and "Confirm Applies" records it for those letters. Choose "Does not apply", with the reason, for each letter that does not apply before you confirm. Then the Annex I register, vulnerability handling, third-party components and evidence.
• Technical file and declaration. The documents under the 8 points of Annex VII, the user information and CE marking, every conformity check, and the declaration with its signed versions.
• Operate. The Article 14 stages of each report with their due dates, fixes and advisories, review triggers and the documentation review, and the records you keep. When a resolved vulnerability has no published advisory, select the warning to see the Annex I Part II(4) text, the reports it counts and the cases where it can be wrong.

Each step shows its article, a member sees the same pages read-only, and old tab links redirect to the phase page that holds the same work.

Newer path features

CVD Portal turns these features on for one account at a time. The account admin cannot turn them on. Until they are on for your account, the path works as described above.

Step status and progress

• Each step before the declaration has one of five states: Not started, In progress, Needs sign-off, Done, or Waiting on an earlier step. A step whose own work is complete is Done, even when an earlier step is still open.
• A step with open work shows "Still needed". It lists each missing input or sign-off with a link to it. The "Next" button in the header names the first missing item.
• Step B1 needs a confirmed list of user types. Step D2 is Done only when the Annex II sheet has no open point and its sign-off is recorded.
• "N of 17 steps" is the same number in the product header, on the product list and on the dashboard. The product list has five columns: Product, Class, Steps, Blockers and Next action. A product reads "Assessment complete" only when all 17 steps are Done and no export check is open.
• Other counts stay on the step that owns them: criteria on C1, controls on C4 and documents on D1. Each has a help disclosure that says what it counts. On the dashboard, the December 2027 deadline strip shows the steps done across your in-scope products.

Saving and moving between phases

• Free-text fields save 1 second after you stop typing, and when you leave the field. "Saved" with the time shows beside the group.
• A decision has one confirm button that names it, for example "Confirm scope", "Confirm manufacturer", "Confirm classification", "Confirm notified body", "Confirm support period", "Confirm applicability" or "Confirm sign-off as" followed by the signer. The page asks before you leave with a decision that is not confirmed.
• Each phase page ends with "Back to overview" and "Continue to" the next phase. Step B5, the applicability decisions, is at the end of the Risk assessment page.

Creating a product

• Select "This is a test product" when you add a product to try the workspace. A test product shows a "Test" badge and stays out of the dashboard totals. It cannot capture a signed version, issue a declaration, publish a public page, share on the trust portal or link to an Article 14 report. It counts toward your plan's product limit, and you cannot change it into a live product later. An admin can delete it at any time after typing its name.
• "From a web page" reads one public http or https page into the same import as a document. It follows at most three redirects and stops at 2 MB or 10 seconds. It does not read pages on private or local addresses.
• The import can find nine facts and quotes the words it found them in: manufacturer legal name, manufacturer address, contact address in the Union, contact email, website, GTIN, model or part number, declared update period in months, and target market. "Detected facts" shows one checkbox for each. A fact you keep stays a proposal, marked "Proposed from a document" on steps A2, B2 and D4, until you confirm it. A quote shows only when its words are in the document.
• When the import found a network interface, step A1 proposes "In scope of the CRA". Nothing is recorded until you confirm or change it.
• After you create a product, a short screen shows the five phases one time.

Risk assessment

• Step B1 opens the remote data processing form on the page, with its fields, its verdicts and the network assets proposed from your asset list. Step B3 runs threat generation on the page, with an option for MITRE EMB3D, progress for each STRIDE category, and a Stop button that keeps the threats generated so far. Step B4 lets you write and change acceptance rules on the page.
• Step B3 warns when the asset list has no update mechanism, or no keys or credentials, and offers "Add this asset".
• On step B4, select risks and use "Accept suggested treatment for" a number of risks. A dialog lists each risk with its suggested mitigation and residual score. You can clear a row before you confirm. Risks with no likelihood or impact, and risks that already have a treatment, are not included. Each treated risk gets its own audit record.
• The risk drawer shows how many risks are treated, moves to the next untreated risk after you accept one, and shows the one-sentence reason for each generated likelihood and impact. Under the acceptance verdict, the table and the drawer name the acceptance rule that matched, or show "No rule matched". An Undecided or Not estimated risk shows no rule, because the rules could not be checked.
• When more than half of the risks have the highest impact, step B4 shows "Check the scores." with the count.
• A support period below the Article 13(8) minimum, or one with no written basis, saves with the warning "Not conformant". It opens the gap "Support period below the required minimum" and the export check "Set a conformant support period" on step D3. The Annex II draft prints the period with "Not conformant, see open gap". A later conformant period closes the gap.

Dates

• A date field accepts a typed date in your local format and shows the format under the field, for example "Format: DD/MM/YYYY". A date outside the accepted range gets a message that names the range.

Product compliance stages

The stage bar guides product conformity work through six stages.

1. Classify. You record the CRA product category and class decision. The Manufacturer section of the same tab records who the manufacturer is.
2. Context and risk. You document product context, complete the Clause 6 risk assessment artifacts, and pass the Clause 6 criteria. A risk criterion passes only when its register is complete: every threat has a scored risk, every risk has a residual position, and every treatment has a written justification.
3. Requirements. You satisfy the Clause 7 essential requirements and verify the criteria pass.
4. Evidence. You gather verified technical evidence across the controls.
5. Conformity. You close export gaps and create the assessment snapshot for the declaration file.
6. Keep compliant. You resolve open review triggers and maintain documentation currency over time.

Adding the product is not a stage. A new product starts with Classify as the current stage.

The top line of the bar names the current stage, for example "Stage 4 of 6, Evidence", and holds the Next step button. A stage never shows as finished while an export check on its tab is open. For example, Requirements stays open while a drafted artifact on that tab cites the wrong CRA article. A check mark shows a finished stage, and the line after it turns green. The current stage shows its number in a bold outline. A grey lock shows a stage that waits for an earlier stage, with the reason below its name. Stages that an agent drafts for your approval say so below the name. Classify shows "Suggested, you decide" when the portal has a class suggestion, because a keyword match makes that suggestion and no AI model.

Creating a product

Under CRA Portal → Products, select "Add product". The panel gives three ways to start. They are "From a document", "From an industry template" and "Blank product". When the workspace has no product, the panel is already open. A link from a public template page, the free classification tool or a vulnerability report opens the panel on the matching path, with the template or the product name already filled in. The number of products you can manage depends on your plan tier. At the plan limit, the page shows the limit in place of the button.

The description is not frozen at creation. On the Classify tab, "Product description" holds the same text and saves it back, so a description written in a hurry can be corrected later. Only an admin can change it. In the product header the description starts closed under a "Description" toggle, because it runs to 2000 characters and a long one pushed the class, the route and the readiness summary off a phone screen. Open the toggle to read it, and follow "Edit description" to the field that changes it.

Product names must be unique within your workspace, ignoring capitalisation. This is not housekeeping. When a researcher files a vulnerability report through your portal, intake matches the product name they typed against your workspace and links the report to that product automatically, which is what fills SRP fields 9 and 10 on an Article 14 report from the CRA classification instead of someone re-typing the tier under a 24-hour clock. A name matching two products is ambiguous, so nothing links, and the effect is invisible until a report actually arrives. Names that merely resemble each other are fine, so a product line can carry "Gateway 3000" and "Gateway 3000 v2" side by side. Different companies are independent of each other.

If your workspace already contains two products with the same name, reports naming it will say so on the submission page and offer both as candidates so you can pick one during triage. Renaming one of them stops it recurring.

You can also start from a document. "From a document" lets you upload or paste existing documentation (a datasheet, manual or security document) before the product exists. The assistant detects the product name and a short description, pre-fills the create form with them, and maps the document to the CRA controls it evidences for you to review. Confirming creates the product with those fields filled in and the evidence already attached, so you land in the product with a head start instead of a blank form. The same analysis also detects the product's security-relevant assets and lists them as a "Detected assets" checklist, so the risk assessment starts pre-populated instead of empty; seeded assets are marked AI-detected and stay unconfirmed until you review them, so they never count toward CRA coverage on their own. Untick any control or asset the document does not really evidence before creating; you can add more evidence inside the product afterwards. This is the same analysis as the in-product document analyzer described below, run one step earlier.

Starting from an industry template

"From an industry template" shows a list of pre-built assessment starters for common product archetypes. They are agricultural IoT gateway, carrier router or CPE, smart home security hub, network management system, firewall or IDS/IPS appliance, network camera or NVR, industrial controller (PLC), mobile robot controller, vehicle telematics backend and smart meter gateway. Each card shows the industry and how many assets and threats it seeds. "Blank product" is the choice for an empty assessment.

Picking a template and creating the product seeds three parts of the risk assessment:

• A starter asset inventory for that archetype, covering the firmware, network paths, data stores, functions and user-related assets a product of that kind normally has. Assets arrive unconfirmed, so you tick the ones your product actually has. Unconfirmed assets never count toward CRA coverage on their own.
• A STRIDE threat list drawn from the CRA threat catalogue. Each threat is tied to one of the seeded assets and to the Annex I Part I requirements it evidences, with a proposed likelihood, impact and mitigation. The threats arrive as "Catalogue baseline", because their text is the catalogue text and not an analysis of your product. A baseline threat does not count toward the threat register, the export checks or the threat model verdict. It counts when you rewrite its description for your product. A threat that you add or generate for the product also counts.
• The default likelihood and impact scales, so risk scoring has documented criteria from the first day.

The template also proposes an Annex III or Annex IV classification with the standards to apply and the justification for both, and pre-fills them on the product. That is a suggestion, and the product's classification stays unconfirmed until an admin reviews it and saves it in the classification panel on the Classify tab. The header shows "Not yet classified" until then, and placing the product on the market still requires that confirmation.

Treat a template as a first draft to challenge. Delete the assets your product does not have, add the ones that make it different, and re-score likelihood and impact against your own deployment and threat exposure. A seeded threat model that nobody argued with is not a documented risk assessment under Article 13.

Each archetype also has a public companion page under Templates (/templates/risk-assessment-starter-<archetype>), which sets out the same content as a document you can read or copy out. Starting a workspace from one of those pages carries the archetype through signup, so the Products page opens with that template already selected.

Classification and conformity route (Classify tab)

Classify the product against the CRA Annex III and Annex IV categories. When a product is created, a category is suggested automatically from its name and description, but the classification is not decided until an admin reviews the category, records the classification basis and saves. Until then the header shows "Not yet classified" and "Route follows the classification", and the "Technical file readiness" card links to the classification step. 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. Hovering the route chip in the header shows the full Article 32 reasoning. For Class I products, recording the harmonised standards or EUCC certification applied affects the available route. Those are recorded as a tick list grouped by the question each standard answers rather than by its number, behind a "have you applied any?" gate, so the panel does not ask an SME to recognise "IEC 62443-4-1" before it can answer. The stored value stays visible and editable underneath the list, and where it names a standard inside a sentence rather than as its own entry, the panel says so and names which, because that wording ticks no box and the route does not count it.

Where the derived route is not Module A, the classification panel and the conformity route card both state that CVD Portal prepares the technical file and the evidence behind it and does not replace the notified body or the certification scheme. The panel also highlights the applicable vertical standard (such as ETSI EN 304 6xx or CENELEC prEN 50765/prEN 50770) being drafted for the selected category. The statement is driven by the derived route rather than by the class, so it appears while you are still choosing a category and clears on its own for a Class I product once a harmonised standard is cited and recorded as fully applied.

Notified body status

When the newer path features are on for your account, step A4 records the notified body with a status: Not selected, Selected, In assessment or Certificate issued. Step A4 is complete from Selected, with the body's name, its 4-digit number and the procedure it performs.

You can export the technical file and approve it for export before the certificate exists. The notified body needs that file for its assessment (Annex VIII). The exported file lists the missing certificate as an open gap, and point 7 of the declaration keeps a placeholder.

Three actions wait for Certificate issued and the certificate number: issuing the declaration, recording the product as placed on the market, and step D3.

Risk assessment (Context and risk tab)

The Context and risk tab holds the product context, the threat model and risk assessment, and the risk register. A row of numbered links at the top of the tab follows the working order: product context, remote data processing, assets, data flows, threat model, security objectives, essential requirements and risk register. Each link goes to its section. The tab is blocked in the stage bar until the product is classified. Links saved before this tab existed, such as ?tab=assess#threats, open the Context and risk tab.

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

• Map the product's assets manually, or let a document fill them. In "Start from a document", press "Fill the assessment" beside a confirmed document. The assistant reads it again and shows its suggestions at the top of the Assets section, next to the list they add to.
• Confirm each asset that did not come from you. An asset seeded by an industry template, an extraction or the document analyzer arrives marked unconfirmed and carries a Confirm button on its row, and the asset list says how many are still waiting. Each asset displays its document citation basis, or a No source badge when no quote exists. The asset-inventory assessment criterion passes only when every asset of the product is confirmed and has its properties recorded. One unconfirmed asset keeps it outstanding. An asset you typed in yourself is confirmed already. Unconfirmed rows also carry a checkbox, with "Select all unconfirmed" above the list and "Confirm N assets" below it, so a 25-asset register does not mean 25 separate clicks. Selecting is not confirming; the button is.
• Record the properties each asset has to keep. Each asset row has three checkboxes: Confidentiality, Integrity and Availability. The asset table of the risk step has the same checkboxes under each asset name. A user who cannot edit sees the properties as text. FprEN 40000-1-2 clause 6.4.2 asks for these properties. A new asset starts with the properties that its category suggests. For example, a data asset starts with confidentiality and integrity, and a network asset starts with all three. Change them when they do not fit the asset. An asset saved before this field existed shows "Not recorded". The asset list counts these assets, and "Fill N from their category" sets the suggested properties on all of them in one step. The asset-inventory assessment criterion stays outstanding until every asset has at least one property. The technical file prints the properties in its asset table. Threat generation reads the properties you record. It aims each STRIDE category at the assets that keep the property the category attacks, so an asset with Availability set gets Denial of Service threats. Generate the threats again after you change a property.
• Generate a STRIDE threat model grounded in the CRA threat catalogue and in the seven update life-cycle threats of the ENISA Technical Advisory on Secure Update Mechanisms (version 1.0, 4 November 2026), then confirm or discard each AI-suggested threat. Threat generation asks for 2 to 6 threats per category, one for each two assets, so a large product gets at most 36. When the same catalogue threat against the same asset comes back in two categories, the generator keeps the one with the higher score, but it never removes the last threat of a category. Each threat displays its basis citation or an Assumed badge. The Assumed basis only toggle filters threats with assumed basis. Generated threats arrive with a proposed likelihood and impact, so their risk scores are pre-filled for you to adjust rather than blank. The generator rates on low, medium and high, and on critical for impact. Each word takes the highest level in its range, so a rating is never lower than the generator meant. Low is Unlikely or Minor, medium is Possible or Moderate, high is Almost Certain or Catastrophic, and critical impact is Catastrophic. The same reading applies to the score, the acceptance verdict, "Mitigate N risks above acceptable score" and the MCP server. If the model cannot be reached, the panel says so and tells you that what you are looking at is the CRA catalogue baseline rather than an analysis of your product, so a provider outage is never mistaken for a threat model. "Confirm remaining threats" opens a dialog that counts the AI threats, the threats scored 9 or above, and the threats with an assumed basis. The last two groups are left out by default, so you review them one by one. Tick a group to include it. Each confirmation records who confirmed the threat and when.
• Choose the asset each threat targets from the asset register. The Asset field of a threat lists the recorded assets, and "Product-wide" for a threat that has no single asset. The threat keeps its link when you rename the asset. When you remove an asset, its threats show the old name with "(not in the asset register)", so you can choose a different asset. A threat saved before this change names its asset in text. It links to the asset that has the same name, when exactly one asset has that name. Threat generation links each threat to the asset it names in the same way. FprEN 40000-1-2 Annex C traces each threat to an asset, and the technical file prints the linked asset beside each threat and risk.
• Score each risk by likelihood and impact and record a treatment (avoid, mitigate, accept or transfer). The field has no default value. Each option explains its meaning and its standard mechanism. Accepting or transferring a risk requires a written justification. A "Risk scoring criteria" reference in the threat model panel defines every likelihood and impact level and the score bands (low, medium, high, critical). "Mitigate N risks above acceptable score" sets the treatment to mitigate on each risk with no treatment that is not acceptable or scores 9 or above. A risk with no score counts as above acceptable, but its score stays blank. Where a risk carries a treatment proposal, its residual likelihood and impact are applied, capped at the inherent values. A notice then counts the risks that still have no residual score, so you can record them one by one.
• Record what remains after the treatment, as its own likelihood and impact under "After treatment". The residual fields stay disabled until you record a treatment. This position is not pre-filled from the inherent score. Recording a residual position equal to the inherent position is a recorded judgement. The Clause 6.4 and Clause 6.5 evidence only counts a risk as evaluated once you record it. The risk detail page reads that recorded position rather than the inherent score, so a risk with no residual recorded shows a dash and no reduction figure.
• A summary above the Save button counts what is still open across the register: risks that are scored but carry no treatment, risks treated with no residual position recorded, and risks accepted or transferred without a written justification. Saving is not blocked on any of them, because refusing the save would strand a threat model you have just waited for. The count is there because generated threats arrive scored but untreated, and the Clause 6.5 artifact and the Annex II sheet are built from exactly those fields, so anything left blank is missing from the technical file rather than defaulted.
• Tick the interfaces each threat is reached through ("Reached through"). Threat generation proposes them from the recorded interfaces. The acceptance rules then judge each threat by its own interfaces, so a threat that needs the device opened is not caught by a network rule. With no interface ticked, a threat is judged by every interface of the product.
• Read the acceptance verdict beside each risk. An "Undecided" verdict has a line that names the data it needs and links to it. The acceptance rules read the interface list in the Product context panel. When that list is empty and the asset register holds confirmed network assets, press "Add N interfaces from the asset register", then choose the restriction of each interface. The new interfaces have no restriction until you choose one, and the risk stays undecided until then. See Clause 6.3.
• Say whether the control behind a residual score is shown to exist. A mitigated risk with a residual reads "control assumed" and "provisional" until you choose "control evidenced" and name the evidence, for example a test report. The technical file prints the same note beside the residual. A residual you pick by hand can never be higher than the inherent value. An AI treatment proposal lowers the impact only when it names a damage-limiting reason: containment, segmentation, encryption or recovery. Otherwise the proposal keeps the inherent impact.
• Check the coverage notes. When the product records at least one interface, the Assets section lists the classes that no asset mentions: the firmware, the update mechanism, keys and credentials, and the product's own function. The Threats section asks for a threat about the update path when none mentions updates. These are prompts to look, not verdicts, and nothing is added for you.
• Decide which of the 33 security objectives apply. The section carries its own heading and a count of how many have been assessed, and expands to the full list. The export gate does not check them, so nothing stops you leaving them undecided; they are simply absent from the technical file if you do.
• Record the Annex I Part I(2) applicability of each essential requirement. Do these before the Requirements tab: until they are decided and saved, every requirement over there reads "review required" and cannot be signed off, and the Requirements tab now says so and links back. Each requirement starts "Not yet decided" and stays that way until you choose applicable, under review, or not applicable. Marking a requirement not applicable requires a justification. An undecided requirement is recorded as nothing at all rather than as a decision you did not make, so it prints as "Review required" in the exported Part I(2) table and shows as "review required" on the Annex I checklist. It still asks for a sign-off, because under Article 13(3) and 13(4) the two lawful answers are that a requirement applies or that it does not and here is why.

Three different save behaviours sit on this one tab. The Product context and Remote data processing sections save on their own as you leave a field, and their headers say "Saves automatically". Everything else in the risk assessment waits for "Save assessment". That button sits in a bar that stays at the bottom of the screen while you work through the risk assessment, with an "Unsaved changes on this tab" marker beside it while there is work to lose. On the Requirements tab, "Save checklist" saves evidence, owners, dates and remaining risk, while sign-off is recorded on its own the moment you make it.

Longer help text sits behind a small (i) icon next to the question it explains. Select the icon, or press Enter or Space on it, to open the text in place. Requirement text, warnings and status stay visible.

• Editing a threat's description drops the CRA catalogue identifier it arrived with. The exported Part I(2) table cites that identifier as the evidence for a requirement, and once you have rewritten the threat in your own words the catalogue is no longer what the evidence rests on. The threat itself, and which Annex I requirement it bears on, are unaffected.

The workspace also draws three data-flow diagrams from what you have recorded: a Level 0 context diagram, a Level 1 trust-boundary view and a Level 2 process-and-port view. Open the "Data-flow diagrams" section to see them. They render on the page rather than printing diagram source for you to paste elsewhere, and the source stays available under each one because that is what the Annex VII technical file carries.

The diagrams are drawn from the asset register, the user types and the remote systems. There is no diagram editor. To change a diagram, change those entries, and the diagram is drawn again. The Mermaid source under each diagram is read only. Copy it to edit it in a Mermaid editor.

If you already have a data-flow or architecture diagram, upload it with "Start from a document". With the new product path off, that is at the top of the Classify tab. With it on, it is in the evidence register on the Requirements and evidence page. The panel under "Show the data-flow diagrams" links to the right place. Upload the diagram as a PDF or an image (PNG, JPG, WEBP or GIF). The analyzer reads it. When you confirm the document, the analyzer drafts "Architecture and interfaces" (C6.2-IN-04) from the boundaries, interfaces and remote services that the diagram shows. It does not replace text that a person wrote in that box, and it does not change the generated diagrams.

The diagrams are built from three things, not just the asset list. Level 0 names the product and draws one actor per user type recorded in the C6.2-IN-02 product-context input, falling back to a single generic operator when none has been recorded. The Level 1 external zone is populated from the remote services in the RDPS assessment, with the operator named where you recorded one; if you have not recorded any, it says so and points at the RDPS panel rather than asserting that nothing outside the product exists. Assets you classified "public" are drawn with a dashed outline, since who can read something without authenticating is the question a trust-boundary diagram is drawn to answer.

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, and within a panel a problem in one section no longer discards the rest: the sections that validate cleanly are saved, and the message names the ones that were held back so you know what to go back to.

Some rules only apply when you commit the product to record. An incomplete remote-data-processing dependency map, for instance, does not block an ordinary work-in-progress save, but does block taking a snapshot or placing the product on the market. Validation messages name fields by the labels on the form rather than by their internal names.

Saving sends only the rows you changed, and a row you deleted is deleted explicitly. Two people working on different threats or different risks at the same time therefore both keep their work, the same way the Annex I checklist already behaved.

The browser warns you before closing or reloading a tab that holds unsaved assessment work. It cannot warn you about a link to another page inside the app, so the panels say what is unsaved instead.

After a successful save, a "Continue to Requirements" action moves you to the Annex I sign-off and clause artifacts.

Risk across products (Risk page)

The Risk page (https://cvdportal.com/risk) shows the risk position of every product in one table. Open it from Risk in the sidebar, from the Risk card on the dashboard, or from Risk across products on the products list. It requires the Compliance plan or higher.

The top of the page counts the classified products, and the risks that are not acceptable, undecided and untreated. A verdict judges a risk before its treatment, so a mitigated risk still counts as not acceptable. Register counts the risk controls of your control register. It is the same figure as the ring on the dashboard Risk card.

The Acceptance criteria section lists how many products use the BSI baseline, their own rules, the old BSI rules or no rules. When the products with rules use different rule sets, the section says so, because the same risk can then get a different verdict on two products. The section also says what the BSI baseline is. The rules come from section 5.14.3 of BSI TR-03183-1, which the German Federal Office for Information Security (BSI) publishes.

An admin can load the BSI baseline on many products at once. Under the section, Load the BSI baseline on N products opens a review panel, and nothing is saved until you press Load on N products. The panel puts each product in one of these groups:

• Gets the baseline: products with no rules yet. They get the six baseline rules.
• Old BSI rules replaced: products that hold only the earlier BSI rules. The baseline replaces them.
• Reviewed technical file: products whose technical file has a current review. New rules change the assessment, so that review goes stale and the file shows as not reviewed until it is reviewed again. These products change only when you tick Include this product (or Include these products).
• Keeps own rules: products with rules that a person wrote or changed. The rollout never changes them. Each name links to the product, where you can load the baseline yourself.

The panel also counts the products that already hold the baseline. Each product is checked again when you confirm, so a product that changed after you opened the panel is not changed, and the result names it with the reason. Each changed product gets an entry in the audit log. The verdicts on the page change at once. The button is shown to admins on the Compliance plan or higher.

The table has one row for each active product.

• Criteria: BSI baseline (the six TR rules, unedited), Own rules (any other rule set, an edited baseline included), Old BSI rules, or None.
• Risks, Not acceptable, Undecided and Untreated: the counts for the product.
• Controls: the product's share of the register's risk controls. The footer adds the controls that belong to no product. The total equals the ring on the dashboard Risk card.
• Next action: the first open step, in this order. Confirm the classification, build the threat model, set the acceptance criteria, replace the old BSI rules, review risks accepted against the criteria, record the data that undecided risks need, treat the untreated risks, record the residual risk of each treated risk, then justify each treatment other than mitigate. Picking a treatment does not close the work, because Clause 6.5 needs the residual position and an accepted or transferred risk needs its reason in writing.

The products with the earliest open step come first. The threat model and risk assessment are open to Admins only, so a Member who follows a next action goes to the product page instead.

Product context (Clause 6.2)

The Context and risk tab opens with a "Product context (Clause 6.2)" panel where you provide the six Clause 6.2 inputs (functional use cases, user types, market segments, product architecture, existing functions and any remote-data-processing dependency map). Type each one directly in its box, or use "Fill the assessment" on a document in "Start from a document" and let the assistant fill them for you. If the model cannot be reached, the extraction is refused outright and nothing is written to the inputs, rather than filling them with placeholders that would then sit in your technical file as though a model had read the manual. Each box saves on its own when you leave it, and says so; if a save fails it tells you and offers Retry. Products migrated from the standalone CRA app may have had these boxes render empty even though the content was recorded; they now show what is stored, and editing one updates that record rather than writing a second copy beside it. Saved inputs are recorded against the product, count toward the technical-file artifact total, and feed the Clause 6 and 7 artifacts you draft in the Requirements tab.

"Suggest" on a box writes only the text for that box, with no title or artifact header. A note that says where the text came from, for example the document analyzer or Suggest, shows under the box and does not go into the technical file. When you replace the text yourself, the note goes away.

When a document describes several products, names a different product, or its scope is unclear, a warning names the products found. In the document analyzer, the confirm button stays disabled until you tick "I confirm this document applies to" the product. With "Fill the assessment", nothing is applied until you press "Apply anyway", and "Cancel" discards the result. When "Fill the assessment" finishes, the Assets section shows "Suggestions from" the document as candidate chips, in two groups. Dismiss hides them. "Candidate assets" are the things the product is made of and handles, and "Add all" imports those. Each candidate carries its citation quote from the document. Underneath, "Claimed controls and specifications" holds what the manual says the product does or how it is built, such as "TLS 1.3 with certificate pinning", "IP67 enclosure" or "10-year declared support period". Those are kept out of "Add all" on purpose. Everything you import becomes a threat-model target, a node in the data-flow diagrams and technical-file content, and a claimed control belongs on the Evidence tab, where something has to substantiate it. The split is a best guess, so nothing is discarded and any chip can still be imported with one press. A chip you have already imported is ticked and greyed, and removing that asset from the register makes it addable again.

The extraction also records the manufacturer it found on the product, the first time, so the Declaration of Conformity names the right company. See "Which company the declaration names" below.

Where an Annex I checklist row or a playbook needs a clause artifact, its link opens the place to supply it. Clause 6.2 inputs open in this panel on the Context and risk tab ("Provide it in Context and risk"); every other clause artifact opens on its own row in the Requirements clause-artifact list ("Draft it in Requirements").

Annex I checklist (Requirements tab)

A 22-requirement self-assessment covering the overarching Annex I Part I(1) requirement, the 13 Part I(2) product security requirements and the 8 Part II vulnerability-handling requirements. 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 where risk remains, what it is and how the product addresses it. The checklist can be downloaded as Markdown or as ReqIF.

The ReqIF download is a ReqIF 1.2 file for requirements management tools such as Jama Connect, Siemens Polarion, PTC Codebeamer, IBM DOORS Next, Visure and ReqView. It holds one requirement for each of the 22 checklist rows, under the headings Part I(1), Part I(2) and Part II. Each requirement carries the regulation text, the Annex I reference, the EN 40000 clauses that evidence it, the applicability and its justification, the sign-off, the evidence, the owner, the due date and the remaining risk. A requirement that is not yet decided exports as "Review required". The identifier of each requirement contains the product id and the requirement key, and it does not change between exports. Import the file again after a change and the tool can update the requirements it already holds. Check this in your tool on a test project first, because each tool maps ReqIF attributes in its own way.

Each requirement has a "How to evidence this" panel under its text. It says what the requirement asks in plain words, the evidence that shows it, how to test it on the real product, where manufacturers usually fall short, and when "not applicable" can be defended. Part I(1) and all of Part II are always applicable, and the panel says so. A Part I(2) requirement marked not applicable shows the condition its justification must meet directly under the requirement text, because Article 13(4) requires that justification in the technical documentation. The panel cites the regulation, Commission guidance C(2026) 5252 by point number and the Commission CRA FAQ by question. The guidance and the FAQ are interpretive and not binding. The panel is help text only and never prints into the technical file.

Manufacturer duties (Article 13)

Below the checklist, the Requirements tab lists the 23 manufacturer duties in Article 13(1) to (23). Annex I says what the product must be. Article 13 says what you must do: assess risk, check components, set a support period, label the product, keep the technical file, act on non-conformity, answer authorities and give notice before you cease operations.

Each duty carries a label that says how far CVD Portal records it. "Recorded in CVD Portal" links to the tab where the work happens. "Partly recorded" says which part is outside, for example the label on the physical product. "Outside CVD Portal" means you keep the procedure and its evidence in your own systems, for example upstream reports of component vulnerabilities, update archives, recalls and the notice before ceasing operations. Paragraphs 10 and 11 apply only if you rely on them. Paragraphs 24 and 25 are Commission powers and are not listed. Each duty has the same "How to evidence this" panel as the Annex I rows.

For the 13 duties that CVD Portal does not fully record, you record a status, where the evidence lives and an owner. The statuses are Not started, In progress and In place. "Not relied on" exists only for paragraphs 10 and 11. "In place" needs an evidence reference, because a claim without evidence is what an authority will not accept. The evidence field is a pointer, for example a procedure number or a ticket, not the document itself. "Save duties" saves only the rows you changed, so another reviewer's rows stay as they are. Duties marked "same for every product" are company procedures. Record them on each product, because each technical file must carry them. The records print into section 5 of the technical file under "Manufacturer duties kept outside CVD Portal (Article 13)", with every recordable duty listed, recorded or not.

Remaining risk against a requirement

Where risk remains against a requirement, record what it is and how the product addresses it. That last field is deliberately not called "residual risk" on its own. The term appears nowhere in Regulation (EU) 2024/2847. It comes from the draft Commission guidance on Article 13(2), which is not binding, and that guidance is explicit that residual risk is measured against the essential requirements rather than against your own risk appetite, and cannot be accepted at your discretion. Cost and commercial feasibility are not grounds to leave a risk untreated, and user instructions can inform about a risk but cannot substitute for addressing it in the design. So the field records how a risk is addressed, not a risk booked as accepted, and the generated checklist carries the same caveat for whoever reads your technical file.

One piece of evidence usually answers several requirements. Clause 7.4 evidences 11 of the 22, and clause 7.6 evidences 7, so once you tick a control the checklist names every other requirement the same control evidences and offers to link it to all of them in one action. It names them before it touches them, and each requirement keeps its own owner, due date and sign-off.

The checklist saves requirement by requirement, so two reviewers working through different requirements at the same time, in two tabs or on two machines, no longer overwrite each other. Whoever saves second keeps their own work and the other reviewer's sign-offs.

The counter above the list reports what is saved, and counts anything you have typed since separately, as "+2 unsaved". The single Save button sits below all 22 requirement blocks, so a counter that simply climbed as you worked was the thing that made unsaved sign-offs look recorded.

Sign-off can also be done in bulk, and works differently on purpose. Tick the requirements you are accepting, give your function once, and each ticked row records your name with its own timestamp. The tick prepares a requirement and signs nothing, so a ticked row is marked “prepared for sign-off” until you complete the act. The sign-off panel appears as soon as you tick the first requirement and stays at the foot of the screen while you work down the list, because the panel used to sit below all 22 requirement blocks and a tick near the top changed nothing you could see. Nothing is ever selected for you and nothing outside the list you can see is touched, because Article 13 sign-off is a person accepting that a specific requirement is met. Rows already signed off cannot be selected, so an existing signature is never overwritten. Every control on the checklist carries a mouseover explanation of what it records and where that text ends up.

Changing who signed a row re-dates it. The sign-off records that a named person accepted the requirement and when they accepted it, so replacing the name records a new acceptance and the timestamp moves to the moment you save it. Editing the evidence or the remaining-risk note under an unchanged name leaves the date alone, because the same person accepted the same requirement at the same moment.

A revoke removes the signature and leaves a trace. The requirement reads "Not signed off", and a line under it names who withdrew the sign-off and the date, for example "Sam Admin withdrew the sign-off on 2026-10-30." The downloaded checklist and the technical file print "Withdrawn by" with the same name and date. When the requirement is signed off again, the new signature shows instead. The audit log keeps who signed before.

Evidence you have already attached to the product appears under the requirements it can evidence, so you can tick it instead of describing it again. The link runs through the clause structure: each Annex I requirement maps to the EN 40000 clauses that evidence it, and any evidence attached to an artifact in those clauses is offered on that requirement. Only artifacts that actually carry an attached file are offered, and a requirement with nothing to offer shows no list at all. Each suggested evidence row shows the text the product holds for that control and where it came from. The architecture row links to the data-flow diagrams on the Context and risk tab. Ticking records what the requirement rests on, and the linked control ids print in the downloaded checklist alongside anything you typed. Ticking is not sign-off. Sign-off stays a named person accepting that the requirement is met, which is what Article 13 asks for, and nothing is ever ticked for you.

Occasionally a link you ticked earlier stops being offered, because the evidence file behind it was removed, or because the clause structure changed so that clause no longer evidences that requirement. Those links are shown under the requirement in their own list, saying which of the two happened and what to do about it. They stay visible because they still count as evidence for the export gate and still print into the downloaded checklist, so hiding them would let the readiness summary and the page tell you different things. Untick one to drop it.

The owner is picked from your team members, and each open item can carry a target date to complete it. That date is planning only, and is labelled as such: the date a technical file actually needs is the date of sign-off, which is stamped automatically and shown beside the signatory. Items show a "due soon" badge in the 7 days before the target date 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.

Secure by design and default (Secure by design tab)

The 22 playbooks from the ENISA Secure by Design and Default Playbook, worked per product. Each playbook carries a principle, an objective, an implementation checklist, a minimum-evidence list and a release gate. There are 125 release-gate items across the 22.

The release gate is what the tab tracks. Tick an item when the product meets it, and the playbook shows its progress as "gate 4/6". The implementation checklist sits beside it, read-only, under "Principle, checklist and minimum evidence". That split is deliberate. The checklist is guidance on how to do the work ("draw the system", "list critical assets"), while the release gate is written as assertions about the finished product, so the gate is the part a signature can stand behind.

Signing off a playbook needs every one of its gate items met. The server checks the saved gate, so save the tab before signing if you have just ticked items. Sign-off works like the Annex I checklist: tick the playbooks you are accepting, give your function, and your name is taken from your account rather than typed. It is recorded immediately rather than with the Save button. Unticking a gate item on a playbook that is already signed off is refused until you revoke the sign-off, because the signature asserts that all of those items hold.

A revoke on a playbook leaves a trace, the same as on the Annex I checklist. The playbook reads "Not signed off", and a line names who withdrew the sign-off and the date. The downloaded Markdown prints the same name and date. When the playbook is signed off again, the new signature shows instead. The audit log keeps who signed before.

Evidence you have already attached to the product appears under the playbook bearing on the same Annex I requirement, so you can tick it rather than describe it again. Each playbook shows the Annex I requirement it is filed under, and how many others it supports. The mapping is ENISA's own, from Annex C of the published playbook, not our reading of it. Playbooks also take an owner and a target date, on the same terms as the Annex I checklist. The tab can be downloaded as Markdown.

Twenty-two playbooks is a lot to open cold, so each row carries a phase from ENISA's suggested adoption order (section 4.23): "start here" for threat modelling, "baseline" for the foundational engineering set plus the secure-by-default playbooks that apply given what your product does, and "later" for the rest. Some baseline playbooks name the condition that puts them there, for example secure communication by default applies where the product communicates over a network. The order sequences effort and nothing else. A legal requirement that applies to your product applies from the start, whichever phase its playbook sits in.

Nothing on this tab affects the export readiness gate. The playbooks are ENISA guidance, not a harmonised standard, so completing them does not confer presumption of conformity with Regulation (EU) 2024/2847. They evidence the engineering work behind the Annex I requirements rather than discharging them, and a product with no gate items ticked is not thereby non-compliant. ENISA's Annex C maps the 22 across every Annex I essential requirement, though six of those rest on a single playbook each, which the public standards page sets out.

The playbook text is reproduced from the ENISA Secure by Design and Default Playbook under CC BY 4.0, reformatted but unaltered.

Traceability matrix (Requirements tab)

Below the sign-off lists, the traceability matrix shows the 22 Annex I requirements in one table. Each row shows the matching EN 40000 clauses, the applicability, the linked threats, the evidence, the verification activity, the open gaps and the sign-off. Each row has one status: verified, gap, review required or not applicable. Filter the table by status, or export it as CSV or Markdown. The CSV export protects against formula injection, so a spreadsheet does not run a cell that starts with =, +, - or @.

The same data is at GET /api/products/{id}/traceability-matrix?format=json|csv|md for a signed-in user of the company.

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.

Artifacts are drafted in dependency order, and an artifact cannot be drafted before the artifacts it derives from exist. A row whose sources are still empty shows which ones are missing and its Draft button stays disabled until they are filled. The Declaration of Conformity, for example, derives from the product context and the secure-development output, so it becomes available only once those are recorded. This is what keeps a drafted document an account of work you actually did rather than plausible text with nothing behind it. Filling a source artifact releases everything that was waiting on it.

For the same reason, an artifact built from your assessment data is refused rather than produced as a placeholder when that data is missing. Asking for the Clause 6.5 risk treatment decision before the risk register carries any treatment decisions tells you to complete the register first, instead of recording an empty document that would count toward your progress. The three Clause 6.4 risk documents answer the same way. The list of threats to assets needs a confirmed asset and a recorded threat, and both risk lists need a risk row. Each refusal names the register that is empty and says that an asset counts once you confirm it and a threat counts once you confirm the assistant's proposal.

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. If the model cannot be reached, the self-review is skipped rather than faked. The note says the draft has not been scored, no revision is attempted, and the draft you already have is kept, so an outage never replaces a clean draft with an unreviewed rewrite. 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.

The revision cannot see your product record. It can only turn a gap into an open item. A revision that adds a contact address, a link or a technical term the draft does not use, removes an open item or a "not stated in the recorded product data" statement, changes the status line, or drops a section is discarded, and the draft is kept. The note then shows the completeness of the draft with no revision applied. A higher completeness score is not proof of a better document: a revision can score higher because it fills a gap with a value you never recorded.

The same applies to the standalone Analyze button on a saved artifact. When the model cannot be reached it says so and shows no completeness figure and no gap list, rather than a generic score you could mistake for a reading of your document.

A draft that gets cut off before it finishes is refused rather than recorded. Nothing is saved and the artifact stays as it was, so a half-written document cannot count as completed work, feed the artifacts that derive from it, or sit in an exported technical file. Draft it again if this happens; if it repeats, shorten the Clause 6.2 context inputs the artifact is built from, since everything the draft is grounded in competes for the same room.

What the assistant will and will not write

Every draft is grounded in what you have recorded. Specifications are treated as facts rather than defaults: protocol generations, link speeds, interface versions, part numbers, dates and version numbers appear only where your inputs state them. Where the artifact needs a fact you have not supplied, it says "not stated in the recorded product data" and lists it as an open item instead of filling in a plausible value. This is deliberate. In a technical file a reader cannot tell an assumed default from a measured specification, so the document marks the difference itself, and the open items tell you exactly what to go and confirm.

An empty register is stated as empty. Every draft is told which of your asset, threat and risk registers hold no rows, in words as well as in the data it reads. A draft that needs a row from an empty register says the register is empty and lists filling it as an open item, rather than naming a record you never entered.

A draft that invents a register row is thrown away. Telling the assistant a register is empty is not enough on its own, because a model can read that as a gap to close rather than as a fact about your product. So a finished draft is checked before it is recorded, and one that names an asset, a threat, a risk or a component identifier while the matching register holds no rows is refused with the identifiers it invented. Nothing is stored, and the artifact stays as it was. Record the rows first, then draft it again.

A control is written as applied only when you have shown it exists. A mitigation on a threat and a treatment you accepted on a risk record a decision. Until you link evidence to the control or confirm it on the risk, the draft describes the control as a planned measure and lists its verification as an open item. This matches the exported technical file, which marks the residual risk of such a row as provisional.

Drafts state the Article 14 deadlines as the regulation sets them. The final report on an actively exploited vulnerability is due 14 days after a fix or mitigation is available. The final report on a severe incident is due one month after the incident notification.

Drafts are dated the day they are generated, never with a date copied from the input artifacts they were built from.

Each artifact stays inside its own scope. The Annex I Part I(2) applicability determination in particular belongs to C6.4-OUT-03 and the Annex I checklist, so other artifacts reference it rather than restating it, and there is only ever one applicability answer for a product.

Review every draft before relying on it. The assistant works from what you recorded, and an assertion in your inputs that has not been verified is still an unverified assertion after it has been written into a document.

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. Analyze and confirm your manuals and policies with "Start from a document" at the top of the Classify tab before drafting to get product-specific drafts instead of generic text.

Before a run starts, the panel lists what it will not reach. Each line names one root cause, counts the artifacts it blocks, and links to the section that fixes it. Three causes cover almost every stop. An empty asset register, an empty threat model, or an empty risk register blocks the Clause 6.4 chain and everything derived from it. A risk register carrying no treatment decision blocks the Clause 6.5 and 6.6 outputs. An artifact that an earlier run deferred stays out until you ask for it. The count covers the whole blocked set, direct and derived, so one line stands for what would otherwise appear as dozens of separate messages. The button states how many artifacts the run will draft.

"Autofill all remaining" drafts every missing artifact in one run. Several drafts run in parallel. A progress bar tracks the run, and you can stop at any time. The interface displays distinct status phases during warm-up, execution, stopping and completion. Stopping a run cancels open network requests at once, and counts cancelled drafts as not started. The final summary displays counts for drafted, failed, skipped and not started documents. A Retry failed button lets you retry only the failed artifacts. A drafted artifact reports the documents its draft was built from. An artifact drafted with no confirmed document says so. An artifact refused for want of a risk register entry names that register. 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.

The run works through the dependency order, so each artifact is drafted after the ones it derives from. A draft that fails is retried once before the run moves on. The closing summary groups what it could not record by the action each group needs from you. The outcome list names the artifacts, so each grouped remedy states the action and the list states which artifacts need it. An artifact that refused needs its required input supplied. An artifact that failed without a reason failed as a request, so use Retry failed to run it again. An artifact still waiting on a source artifact needs the artifacts above it filled first. An artifact that named a reason stays out of the next run while the registers behind that reason are unchanged, and it returns on its own once you record the missing rows. The next run retries an artifact that failed without a reason and an artifact whose inputs have arrived. Running autofill again after filling those inputs picks up the rest.

Facts every draft states

Each draft receives the support period and the vulnerability reporting channel as recorded facts. The support period gives the months, the placing-on-the-market date and the end date, or says that the period is not recorded. The reporting channel gives the address for reports, the policy address and the published response times. Drafts quote these and do not invent other figures or addresses.

By default the channel is this account's portal, with the response targets from the account settings. When the product's manufacturer runs its own programme, for example a bug bounty programme, record it under "Vulnerability reports go to" on the Conformity tab. Enter the reporting address, the policy address and the response times as the policy states them. Addresses must start with https:// or mailto:. The Annex II sheet (point 2) then gives that channel instead of the portal. When a product names a different manufacturer and records no channel, the panel asks you to check the portal is the right one.

"Autofill all remaining" first shows the facts every draft in the run will state: the manufacturer, the interfaces, the support period, the reporting address and the response times. It also lists what is missing. Correct a wrong fact before the run, because each draft repeats it.

Checks on drafted artifacts

CVD Portal checks the text of every drafted artifact against the recorded product facts. The checks are rules, not AI, and they never change the text. An artifact with findings shows "N to check". Open it to see each finding with the sentence that caused it. The list updates while you edit.

• Errors block the export. An artifact names the account as the manufacturer when the product records a different manufacturer. An artifact cites the wrong article of Regulation (EU) 2024/2847. A frequent error is a number from the 2022 proposal, for example "Article 11" for the reporting of actively exploited vulnerabilities, which is Article 14. The check reads lists such as "Articles 10 and 11". It covers reporting, the obligations of manufacturers and vulnerability handling (Article 13), the technical documentation (Article 31), the EU declaration of conformity (Article 28) and the support period (Article 13(8)).
• Checks ask you to look. An artifact describes an interface the product does not record, for example Wi-Fi on a product with Thread and Bluetooth LE. An artifact promises a time, for example "within 24 hours", that no recorded fact states. The deadlines of Article 14, the final report included, are not flagged. An artifact holds an open placeholder or says that a fact is not recorded.
• Checks also ask you to look when an artifact states the law wrongly. It presents a support period other than five years as a CRA requirement. Article 13(8) sets at least five years, unless the product is expected to be in use for less. It gives a one-month final report for an actively exploited vulnerability. That report is due 14 days after a fix is available, and one month applies to severe incidents. It puts "malicious" or similar indicators in the early warning on a vulnerability. Those belong to the early warning on a severe incident.

The support assistant and the MCP tool ask_expert run the article and law checks on their answers too. There the citation check flags only the article numbers of the 2022 proposal, because an answer quotes the regulation and cites more articles than a draft does.

While an error remains, the path shows the step "Correct the flagged artifacts" after "Assess the risk", and the export is refused. The step disappears when no error remains.

Each draft records the product facts it was written against: the manufacturer, the classification, the product name and description, the interfaces, the intended purpose and the user capability. When one of these changes, the drafts written before the change show "out of date", and "Redraft N out of date" drafts them again. That replaces their text, including your edits, so the button asks first. Saving an artifact yourself marks it as checked against the current facts. Drafts saved before this check existed show no freshness.

An open artifact with no unsaved changes offers "Mark reviewed". It records your name and the time against the exact text you read. Any later edit or redraft voids the review. "Mark reviewed" is refused while the text holds an error the checks block on. "Withdraw" removes the review. A reviewed artifact shows "reviewed" in the list. The review is recorded per artifact. It does not change the criteria and evidence counts in the product header. It closes the "Review the ... draft" gap of the artifact in the status of the technical file.

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.

Remaining work

The product header shows a "Remaining work" 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. The panel opens by saying what it counts, and that meeting every export check still leaves this list, because those checks are minimum thresholds. The panel opens with a "Start here" row carrying the same next action as the header hint, each artifact links straight to the row where it is provided or drafted, and each section links to the tab where its items are completed.

How assessment criteria pass

There is nothing to tick. Each of the twenty assessment criteria asks whether a clause reached its conclusion, so each one passes on its own once the clause artifacts it rests on are recorded under "Clause artifacts" on the Requirements tab. Draft those and the criterion follows.

Which artifacts a criterion waits on is specific to the question it asks, not to the clause as a whole. Clause 6.4 carries four criteria and each tracks a different deliverable: the asset question is answered by the asset list on the Context and risk tab, once every asset is confirmed and has its properties, the threat question by the threat list, the risk-estimate question by the scored risk register, and the evaluation question by the treatment decisions. So one 6.4 criterion can pass while the other three are still outstanding. A criterion only ever reads the artifacts recorded against that product.

A criterion that has not passed is reported as outstanding rather than failed. An artifact you have not written yet means the question is unanswered, which is not the same as answering it "no", so the counter says so plainly and the criterion sits in the remaining-work list until the artifact exists.

Document analysis (Classify tab)

At the top of the Classify tab, "Start from a document" is the one place to bring in a document. It turns your existing documentation into pre-mapped CRA evidence and is the fastest way to start an assessment. Upload up to 5 files at once (PDF, images such as PNG/JPG/WEBP for architecture diagrams or settings screenshots, TXT, MD, CSV, JSON, XML, HTML or YAML, 15 MB each and 25 MB per batch), or switch to "Paste text" to analyze a document too large to upload by pasting its text. Sizes are checked the moment you pick the files, and an oversized selection offers the paste route instead of just naming the limit. A line under the picker shows how many of the 5 files you selected and the batch size against the 25 MB limit, for example "2 of 5 files · 12.3 of 25 MB". It turns red when a file or the batch is over its limit. Each file is one AI analysis, so fewer, more relevant files give a faster result. 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. After you confirm a document, the summary offers "Fill the assessment from" that document. Confirmed documents also appear under "Documents on file" with the same button. To delete a document you uploaded by mistake, or a duplicate, press "Remove" beside it and confirm the prompt. Remove deletes the stored file and every evidence record made from that document, and it cannot be undone. Only administrators can remove a document. It reads the document for the product context, the remote systems and candidate assets, and adds them to the risk assessment below as unconfirmed suggestions. Assets that duplicate one already in the register are marked: matching is by meaning rather than exact text, so "GPS" is recognised as the "GPS antenna" you already have. Discarding a review deletes that document.

Confirming a document also drafts the Clause 6.2 context boxes it found material for. Where the assistant wrote a rationale for a Clause 6.2 input, that text is saved into the matching box on the Context and risk tab as an editable draft, so you do not have to run the same document through "Fill the assessment" only for those boxes. Drafts are marked as generated rather than verified, and a box you have already written in is never overwritten; the confirmation summary says which boxes were filled and which were left alone.

The same confirmation fills the Structured Context Data form in the "Product context (Clause 6.2)" panel. The analysis reads the document for the intended purpose, the reasonably foreseeable use, the reasonably foreseeable misuse, the product boundaries, the operational environment, the expected user capability and the product interfaces, and writes each value the document states. Only empty fields are filled. A value you supplied is a statement your company has made, so the import never replaces it, and the confirmation summary names the fields it added. A document that states none of this fills nothing.

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.

AI-extracted remote data processing proposals

Extracted remote services arrive as proposals that require approval. They do not expand statutory scope or alter the Declaration of Conformity until approved.

Every extracted service displays its source document name and a verbatim quotation. Extracted entries without a quotation display a missing source warning badge.

Suggested answers for hosting model, function prevention, manufacturer responsibility, and operator arrive with citations. You can review each field individually, accept the suggested value and quotation, or edit the value. Editing a field marks it as changed by user review.

The parent product scope cannot be set to no remote services while unreviewed AI proposals exist.

Threat generation (STRIDE)

Generating threats runs across the six STRIDE categories. The categories are spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege.

Progress streams live to the browser. The interface displays completed categories and an elapsed time counter updated every second.

If generation takes longer than 60 seconds, a warning states that generation takes longer than usual.

A Stop button aborts the request cleanly. Stopping does not add partial threats to the product register.

If generation fails, the interface displays the failure message and provides a Try again button.

Evidence and audit readiness (Evidence tab)

The Evidence tab tracks audit readiness per CRA control. A control is audit-ready when the assessment engine has verified it, or when accepted evidence is attached and still inside its validity window. The evidence count reports what is recorded rather than what an auditor has accepted. The panel names how many controls rest on documents nobody has reviewed. Its total counts the Clause 6 and 7 controls. The two conformity documents, the Declaration of Conformity (C-DOC-01) and the technical documentation index (C-TDOC-01), are not counted. The app generates them from the assessment on the Conformity tab, which comes after the Evidence stage, so they need no evidence. They show at the end of the list as "Generated", with any file already attached to them, and offer no form to add evidence. Evidence confirmed from the document analyzer appears here against the controls it was mapped to. When a control has a recorded draft, expanding its row shows a read-only "View generated draft" reveal, so reviewers can read the drafted document without leaving the Evidence tab.

Every evidence file records its SHA-256 when it is stored. The Evidence tab shows the first characters of the hash under the file name, and the full hash on hover. "Verify" hashes the stored file again and compares the two. A match means the file is unchanged since the hash was recorded. A mismatch means the stored file changed. The technical file prints an "Evidence register (SHA-256)" in section 5 with the full hash of every file, and each snapshot freezes it. Anyone who holds a copy of a document can compute its SHA-256 and compare it with the register. The snapshot comparison flags evidence whose file changed between two versions.

Files stored before hashing have no hash recorded at upload. A one-off backfill adds one and marks it "(backfilled)". A backfilled hash proves the file is unchanged since the backfill, not since upload.

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.

Validity windows

Accepting a document is a judgement made on a date. A penetration test report or a supplier attestation is true when it is filed and means much less two years later, so each accepted attachment can carry a validity window: 6 months, 1 year, 2 years, 3 years, or no expiry. The window runs from the moment of acceptance.

Three things follow once a window lapses.

• The attachment stops counting towards audit readiness, so the percentage on this tab falls on its own without anyone logging in. The control's reason line says which attachment lapsed.
• The "No evidence past its validity date" check on the control register fails for the product, against the Annex VII technical documentation index.
• A reminder goes to the workspace admins, both 30 days before the date and once it has passed. These follow the same Settings → Notifications toggle as the other deadline reminders.

Evidence with no window set is treated as not expiring, which is what every attachment accepted before this feature existed carries. Nothing changed status on its own. Set a window on an existing attachment from the dropdown beside it, which does not re-open the acceptance.

Choose "No expiry" deliberately rather than by default. A document with no window is one nobody will be reminded about.

Component due diligence (Article 13(5))

Below the software bill of materials, the "Component due diligence" panel lists every component in the product's SBOM. The SBOM scan answers the vulnerability question. Article 13(5) also expects a record of the non-vulnerability attributes for each integrated third-party component. For each component, an admin records whether it carries a CE marking (present, not required, absent, or not yet checked), its upstream maintenance and security-update status (actively maintained, maintained, end of life, unmaintained, or not yet checked), and a fit-for-purpose determination (fit, fit with mitigations, unfit, or not yet determined), with an optional note for the basis. Saving stamps who attested it and when, and writes an audit entry.

Two more fields record what the supplier gives you. "Supplier support ends" is the last day the supplier gives security updates for that component version. "Supplier evidence link" points to the supplier's evidence, such as a security statement, an SBOM or a support policy. The link must start with https:// and must not contain a user name or password. The Commission CRA FAQ lists both checks as due diligence actions.

Your vulnerability handling covers the whole product, the components included. When a supplier stops security updates before your product's support period ends, you must patch, replace or disable that component yourself. The panel compares each supplier support end date with the product support end date from the Annex II information. When a component's support ends first, the component shows a warning with the number of days, and the panel header gives the count of such components. Set the product support period first, or the panel has nothing to compare against.

Published support dates

For some upstream projects the panel can fill in the support end date for you. It knows the release lines of OpenSSL, the Linux longterm kernels, Python, Node.js, PostgreSQL, Next.js, Spring Boot and Mbed TLS. Each date comes from the project's own release policy or from endoflife.date. Each suggestion links to the page that states the date. A project that does not publish a date for each version gets no suggestion. Examples are BusyBox, curl and React.

A component matches only when its package URL type fits the project. The PyPI redis client therefore never takes a Redis date, and an npm package called node never takes a Node.js date. Next.js and Spring Boot need a package URL, because their bare names are too common.

An admin can use one suggestion with "Use published date", or fill every open row with "Prefill published support dates". A prefill never changes an attested row or a field that you already filled. A prefilled row stays "Not attested" until an admin saves it, and the admin who saves it is the one who signs for the date.

The panel header shows how many components are attested. A component counts as attested once it carries a fit-for-purpose determination. The coverage figure travels into the Annex VII technical documentation index, which states the count under the design and development processes item and flags any component still without a record. When the product inherits the account-wide SBOM, the panel says so and lists that SBOM's components.

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 Classify tab gains an "Import from Jira & Confluence" section under "Start from a document". 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 the product's manufacturer and its 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.

Under the declaration and under the index, a "point by point" list explains every point of Annex V and Annex VII: what it asks, the evidence that shows it, how to check it, where manufacturers usually fall short, and how far the draft fills it. Under the declaration, each point that still holds a bracketed placeholder says so and quotes it. Under the index, each item the index marks missing says so. Points 1, 4 and 8 of Annex V take facts only you can state. Record them under "Declaration of conformity facts" below. A person still signs the issued declaration.

Log of cybersecurity issues (C7.8-OUT-01)

The log of cybersecurity issues is built from the vulnerability reports recorded for the product, not drafted by the assistant. It gives the open, resolved and dismissed counts, the median days to acknowledge and to resolve, the reports with an Article 14 decision, and one table row per report with its dates, severity, status, remediation decision and deadline, the Article 14 stages sent, and the advisory. A section lists open reports past their remediation deadline. The table shows the newest 200 reports.

The log carries metadata only. It never contains the report description, steps to reproduce, impact, reporter contact or internal notes. With no report for the product, the log says so and gives the date of the check. Draft its input (C7.8-IN-01, the sources of cybersecurity issue information) first. Auto-enrichment then keeps the log current, and a log you edited by hand is never replaced.

Evidence of monitoring (C7.9-OUT-01)

The evidence of product cybersecurity monitoring is built from the platform's records, not drafted by the assistant. It lists each monitoring source from Settings, Monitoring sources, with its schedule, last check and state, then the last complete OSV.dev check of the product's SBOM, then the exploitation signals that match open findings in the product's components.

A scheduled source is "Fresh" when it was checked within twice its interval (one day, one week or one month), and "Stale" otherwise or when never checked. An ad hoc source has no schedule and is never "Fresh", because it does not show regular monitoring. With no source and no current SBOM check, the record says that the platform holds no monitoring record for the product. Monitoring sources are recorded for the account, and the record says so. Auto-enrichment keeps the record current once its inputs (C7.9-IN-01 to C7.9-IN-04) exist, and never replaces a record you edited by hand.

Item 1, general description of the product

Annex VII item 1 has four sub-points: (a) the intended purpose, (b) the versions of software that affect compliance, (c) for a hardware product, photographs or illustrations of the external features, marking and internal layout, and (d) the user information and instructions of Annex II.

Item 1 shows "Present" only when all four hold.

• (a) The product context (C6.2-OUT-01) exists.
• (b) The software versions affecting compliance are listed on the product page, for example "app 4.2.0, firmware 1.8.3". The index quotes the list. The platform cannot tell whether the list is complete, so the reviewer checks it.
• (c) The product page says the product is software only, or it says the product has hardware and a photograph or illustration is attached to C6.2-IN-05 as an image file. A PDF about existing functions does not count.
• (d) The technical documentation and user instructions artifact (C7.5-OUT-04) exists.

Record the versions and the hardware decision on the product page. Once set, both are part of the content that an export approval signs, so a change after approval makes the approval stale. The box is above the vulnerability reporting channel. When the hardware decision is not made, the gap list says "Decide whether the product has hardware". The generated Annex II sheet does not count for (d), because it always keeps placeholders for facts that only you can state. Before this change, the product context or the user instructions alone were enough, so most products that showed item 1 as present now show it as missing until you record the version and the hardware decision.

Item 2(b), vulnerability handling evidence

Annex VII item 2(b) asks for the SBOM, the coordinated vulnerability disclosure policy, evidence of a contact address for vulnerability reports, and the technical solutions for the secure distribution of updates. The index adds a section "Item 2(b), vulnerability handling evidence" with one row for each.

Part	Source in CVD Portal
Software bill of materials	The SBOM that reaches the product, with its last OSV.dev check
Coordinated vulnerability disclosure policy	The public CVD portal, a verified portal redirect, or a policy the exposure scanner found on your contact domain
Contact address for vulnerability reports	The exposure scanner's latest result for each scanned domain
Secure distribution of updates	The C7.7-OUT-02 and C7.8-OUT-02 artifacts
Approved policies	Policies with status approved or published, with version, approval date, review date and acceptance of the current version. Recorded for the account

The contact address is "Recorded" only when a valid security.txt that has not expired was found, in the last 35 days, on the domain of the product's manufacturer email or of your security contact email (Settings). A subdomain of those domains also counts. The result of one scanned domain never stands for another. A passing domain that is not your contact domain shows "Partial", and so does a failing contact domain when another domain passes. The row lists every scanned domain with its own result.

The policies row is "Recorded" when the vulnerability handling policy is approved and no policy is past its review date. It does not decide whether item 2 is present.

Item 2 now shows "Present" only when the architecture (C7.4-OUT-01) exists, an SBOM reaches the product, and the contact address row is at least "Partial". Before, the architecture and an SBOM artifact were enough. Some products that showed item 2 as present now show it as missing, with the missing part named in the gap list. To close it, add your domain under Settings, CRA Scanner, scan it, and record your security contact email.

Item 6, test reports

Annex VII item 6 asks for the reports of the tests that verify the product (Annex I Part I) and the vulnerability handling process (Annex I Part II). The index adds a section "Item 6, test reports" that shows what the platform already holds for the product and what is still to provide. It has six rows.

Annex I	Test activity	Source in CVD Portal
Part I	Known-vulnerability check of components	The SBOM that reaches the product, checked against OSV.dev, and against the NVD for components that have only a versioned CPE. The row counts the components the check cannot use, because they have no version and no package ecosystem or CPE.
Part I	Static code analysis	SARIF results sent to /api/v1/scan/sarif, for the product when the upload names it (productId), else for the account.
Part I	Security testing (penetration test, fuzzing, interface tests)	Report files attached as evidence on C7.6-OUT-01 or C7.6-OUT-02.
Part II	Security test and review plan	Settings, Security test and review plan. Each item can name a product, or cover all products.
Part II	Vulnerability handling exercise	Completed tabletop exercises. A run can be recorded for one product, or for all products.
Part II	Reports handled through the disclosure process	Vulnerability reports received for the product. Supporting evidence, not a test.

Each row is "Recorded", "Partial" or "Not recorded", and gives the next step. A product reads the rows recorded for it and the rows recorded for all products, never the rows of another product, and the row says which. Item 6 shows "Present" when the verification artifact exists or when a test report file is attached. When the artifact exists with no attached file, the section says so, because a drafted summary or a test plan is not a test result. The CRA does not require a specific test method or an accredited laboratory for internal control (Module A). Your own laboratory or an external one is acceptable.

Which company the declaration names

The declaration is issued under the sole responsibility of the manufacturer (Article 28). Every drafted document names the manufacturer too, so you decide it first, in the Manufacturer section of the Classify tab, below the product description. By default it is your own company, which is correct when you make the product yourself. If you prepare the file on behalf of a client or for another brand, as a consultant, reseller or partner does, press "Use a different manufacturer" and record their entity. Their name then appears in every draft, in Annex V field 2 and the signature block, in the Annex VI simplified declaration, and in section 1 of the Annex II user-information sheet. The Conformity tab shows the manufacturer read-only above the declaration, with a link back to the Classify tab. Your account still supplies the vulnerability-reporting portal and disclosure-policy links, because those really are your portal. Clearing the name returns the product to your own company.

The Manufacturer section shows "Not confirmed" until an admin answers the question. When your own company is the manufacturer, press "Confirm" next to its name. Saving a different manufacturer, or clearing it, also counts as the answer. The section then shows the date of the confirmation. Until then, "Export checks and progress" reports "Manufacturer not confirmed". The item does not block the export.

Where a product manual has been analysed on the Classify tab and named its manufacturer, that name is recorded on the product automatically the first time, and the suggestions panel in the Assets section says so. It never overwrites a manufacturer you set yourself.

The "Established in the Union" answer has three states, and "Not yet stated" is one of them. An unstated answer prints a placeholder rather than declaring establishment on the manufacturer's behalf, because that answer decides whether an EU authorised representative must be appointed under Article 18. Record it before issuance.

Importer and distributor

Below the manufacturer, record the named importer and distributor in this product's supply chain (Articles 19 and 20). Each takes a legal name, a registered address, a contact email and a country of establishment. When either is recorded, an "Economic operators" block is printed in the Declaration of Conformity. Leave both blank for a product you sell directly. These are the specific legal entities, which is separate from the importer and distributor applicability roles under Settings, which decide which obligations apply rather than which company.

Declaration of conformity facts

Below the importer and distributor, record the six facts Annex V asks for that only the manufacturer can state.

Field	Annex V point
Type, model, batch or serial identifier	1
Traceability of the object, for example a build number or a photograph reference	4
Place of issue	8
Date of issue	8
Signatory name	8
Signatory function	8

Each empty field prints as a bracketed placeholder in the declaration, and each point with a placeholder is an open gap in the technical file. A point stays open until all of its fields are recorded. Press "Save declaration facts", then generate the conformity documents again. The facts bind the export review, so a change after approval makes the approval stale.

For a route that needs a notified body, point 7 keeps a placeholder for the procedure that was performed. The route can allow more than one module, so the declaration cannot choose one for you.

Issue the declaration

The issue act makes the declaration of a signed version official. Only an account admin can issue it, on the Compliance and Enterprise plans. The "Issued declaration" panel is under the signed versions in the conformity path, and under the conformity documents on the classic product page.

You issue the newest signed version, in one of two forms.

• The generated text. The declaration that the workspace generates, for a product under the CRA only.
• Your own signed PDF. Use it for a route that needs a notified body, or for one declaration under several Union acts, for example the CRA and the Machinery Regulation (Article 28(3)). You choose the language of the PDF and list the Union acts that it covers, each with its Official Journal reference. The list always holds Regulation (EU) 2024/2847. The form offers the common acts with their references. The PDF can be up to 25 MB.

The issue needs all of these.

• The version records a placing on the market or a substantial modification.
• For the generated text, the declaration of the version has no bracketed field, so all six declaration facts are recorded. For your own PDF, the list of Union acts takes the place of this check.
• The technical file has an approved review, and the product is unchanged since the approval.
• The declaration that the product generates today is the same as the declaration of the version. If you changed the product after you captured the version, capture a new version.
• The CRA scope statement shows conformity records. A product that is out of scope, or whose units are all placed before 11 December 2027, needs no declaration yet.
• You say how the declaration goes with the product. A full copy goes with it, or the simplified declaration of Annex VI goes with it (Article 13(20)).
• You confirm that the text, or the PDF, is the declaration that the named signatory signed.

The issued text is the declaration of the version without the draft title, the draft banner and the signature line. It names the signatory and their function. The text, or the PDF, is frozen when you issue it. To correct it, capture a new version and issue that one. The newer version becomes the current version, and the older version shows "Superseded by version n".

Each issue writes the SHA-256 of the text or the PDF into the audit trail. The audit trail is a hash chain, so a later change to the record breaks the chain. The panel shows the full hash. Anyone with a copy can compute its SHA-256 and compare the two.

Add a language

A Member State can require the declaration in its own language (Article 28(2)). To add one, select "Add a language" on an issued version, choose the language and the PDF, and select "Add the file". Each version holds one file for each language. The languages are the official languages of the EU, and Icelandic and Norwegian. Each file writes its own audit row with its SHA-256. A file cannot change, and you cannot remove it. A withdrawn version takes no new file.

Each issued version has a simplified declaration in the Annex VI wording. It names the exact internet address of that version, for example https://your-company.cvdportal.com/products/7KQ2M9XW4D/declaration/2. The address uses your verified custom domain when you have one. The address answers once you publish the public page and the issued declaration is Public. See Publish the public page. Open the address once before you print it.

To withdraw a version, select "Withdraw version n" and give a reason. Only your team sees the reason. The version stays in the list with its withdrawal date.

Report the effort

After you issue a declaration, the current version asks two optional questions. Only an account admin sees them.

• How many person-days did your team spend on this product's conformity work? Give a whole number from 1 to 2000.
• Did a notified body take part?

Under the questions, a box asks for consent to use the answers in combined figures only. Each figure needs reports from at least 40 companies. No figure identifies your company. Without the tick, the answers stay out of every figure. Select "Save the answers" to keep them, or "Skip" to close the questions. The questions show once for each issued version. After a skip they do not show again for that version.

You can change saved answers later with "Change the answers". A withdrawn version takes no answers. Each save and each skip writes an audit row. The answers never show on the public page, on the trust portal or in the export.

Publish the public page

The public page shows a product at a stable address on your portal host, with no sign-in. A user, a buyer or a market surveillance authority who scans the code on a box opens it. Only an account admin can publish it, on the Compliance and Enterprise plans. The "Public page" panel is under the issued declaration.

The address is https://<your host>/products/<ref>. The reference has 10 characters and never changes, so a product rename breaks no printed address. The current declaration is at /products/<ref>/declaration, and each version is at /products/<ref>/declaration/<version>.

The page always shows the product name and model identifier, the manufacturer name, address and contact, the link to report a vulnerability, the disclosure policy and the published advisories for the product (Annex II points 1 to 3). Each other item shows only at the level Public. Set the level of each item in the panel.

Level	Public page	Trust portal
Public	Yes	Yes
Approved viewers	No	Yes
Hidden	No	No

Approved viewers needs the trust portal. Without it, the panel offers Public and Hidden. The issued declaration, the support period end date, the remediation SLA, the SBOM download and the HBOM download can be Public. The draft declaration, the Annex VII index, the vulnerability check and the VEX feed are never Public.

The SBOM and the HBOM are Hidden by default, because Annex II point 9 makes their publication your choice. At Public, the page links each one as CycloneDX 1.6 JSON, with a rate limit, and each download writes PRODUCT_PUBLIC_BOM_DOWNLOADED with no IP address.

Select "Publish the page". The panel lists each item that becomes public and the address, then you confirm. Each publish and each unpublish writes an audit row. An unpublished page answers Not found, also for a printed code.

A partner client needs a verified custom domain of its own before it can publish. A printed code stays in use for years, and a partner domain goes when the partner leaves.

The declaration page shows the generated text, or the PDF files of an uploaded declaration with the browser's language first. Each file and text shows its SHA-256. A generated version has "Download this version as HTML", so a manufacturer, an importer or a distributor keeps its own copy. The page lists every version with its date and status, and prints without the portal header and footer. A withdrawn version shows its withdrawal date and no text. The page is not indexed by search engines. A product that is out of scope, or whose every unit is placed on the market before 11 December 2027, shows no declaration, as on the trust portal.

QR code

On a published page, the panel gives the QR code of /products/<ref>/declaration. A scan opens the current declaration with no further click, and one printed code also serves later versions. Download it as SVG for print or as PNG at 1024 px. The image holds the code only, so print the address from the panel next to it. Each download writes PRODUCT_PUBLIC_QR_DOWNLOADED with the host.

The panel gives no code when the code would open a page with no declaration. That is when your portal is not public, when no declaration is issued, when the current one is withdrawn, when the issued declaration is not Public, or when the product shows no conformity records.

A printed code stays on a machine for 10 years or more. On a host that is not your own domain, the panel says so. When the host of your portal changes, the product panel and the Custom Domain card in Settings name the count of codes downloaded with the old host. Codes printed with that host work only while it serves your portal.

Static export

"Download the export" gives a ZIP of the declaration pages, every issued version at its own path, with the PDF files and a README. Each page is one HTML file with its style inline, so it also opens from disk. Copy the products folder to the root of your own domain, and printed codes keep working after you leave. The export shows each status at the time of export, so export again after each issue or withdrawal. Any member can download it once a version is issued.

A route that needs a notified body keeps the point 7 placeholder, so its generated declaration cannot be issued. Issue your own signed PDF for it.

Generated documents are drafts until you issue them. The workspace structures your assessment and evidence. By itself, it does not establish or guarantee conformity.

Status of the technical file

The exported technical file opens with "Status of this file". The export gate is a floor, so a file can leave the company with one Annex I requirement signed off out of 22. The status says how far past the floor the file goes.

The status is one of two, never a percentage.

• Incomplete. The file lists every open gap with its provisions. The conformity assessment cannot be concluded on the file as it stands.
• Complete as recorded. Every applicable Annex I requirement is signed off with evidence, every Article 13 duty the file records is in place, and the declaration and the documentation index have no open item.

Both statuses carry the same limits. CVD Portal computes the status from the records in the file. It does not assess, test or certify the product. The manufacturer alone is responsible for conformity, the EU declaration of conformity and the CE marking.

The open gaps in the status are the same gaps as in "Open gaps as tickets", built from the same records. A threat register that holds only the generic catalogue threats is also a gap, because it is not an analysis of the product.

Unreviewed drafts. The export gate counts an artifact when it holds text, whoever wrote it. So a draft from AI, an import or an agent can let the gate pass before a person reads it. The status lists each such draft as a gap, for example "Review the agent draft of C6.2-IN-03", in the area "Unreviewed draft". The gate does not change.

• Only drafts that a gate needs are listed. These are the six Clause 6.2 inputs and the product context (C6.2-OUT-01), the SBOM section (C7.5-OUT-03), and the artifacts behind an assessment criterion that passes only on drafts. If the gate passes without the drafts, they are not listed.
• The SBOM section that an SBOM upload writes is not a draft, because it describes the uploaded file. The same applies to the remote data processing declaration, which repeats your answers.
• To close the gap, open the artifact under "Clause artifacts" on the Requirements tab, read it, correct it if necessary, and select "Mark reviewed". Text that you write in an empty box is yours and gets no gap. An edit after the review opens the gap again. The snapshot comparison lists gaps that opened or closed between two versions.
• Text from "Suggest" on a Clause 6.2 box (Context and risk tab) is an AI draft.
• An edit does not close the gap. When you save over a draft from AI, an import, the document analyzer or an agent, CVD Portal keeps the name of the writer of the draft. The gap then reads "Review the edited agent draft of C6.2-IN-03", for example. Only "Mark reviewed" closes it. Your edit still belongs to you, so a later import or analysis does not replace it.

Annex I evidence from an agent. An agent can record the evidence of an Annex I requirement over MCP. The evidence counts for the export gate at once, also on a requirement that is already signed off. The status lists each such requirement as a gap, for example "Review the agent evidence for Part II(1)", in the area "Unreviewed draft".

• To close the gap, open the requirement on the Requirements tab, read the evidence, and correct it if necessary. Then sign the requirement off. If it is signed off already, revoke the sign-off and sign it again.
• An edit does not close the gap. When you edit the evidence text or the linked evidence, the gap reads "Review the edited agent evidence for Part II(1)", for example. Only a sign-off closes it.
• If you delete all the evidence text and links of the requirement, the mark goes. Evidence that you record after that is yours and gets no gap.
• A sign-off through MCP also closes the gap. The signatory owns the OAuth token, and the agent must sign only after the signatory has read the evidence.
• A sign-off from before the agent recorded the evidence does not close the gap.
• Evidence that an agent recorded before the platform began to mark it is not listed.

Open gaps as tickets (Conformity tab)

"Open gaps as tickets" lists every open CRA gap for the product, one ticket each, most urgent first. The gaps come from five places.

• The technical file gate, for example an undecided classification or a missing SBOM.
• The machine drafts that the gate counts and that no person has reviewed, and the Annex I evidence that an agent recorded and no person has reviewed. See "Unreviewed drafts" above.
• The Annex I checklist. A requirement that is undecided, not signed off, signed off without evidence, or not applicable without a written reason is a gap. A requirement past its due date is "highest".
• The Article 13 duties that are not started or in progress.
• The drafted declaration of conformity (Annex V) where a placeholder is still open, and the technical documentation index (Annex VII) where an item is marked missing.

Each ticket names the provisions, what is missing, what to do, and what CVD Portal checks before it treats the gap as closed. A ticket never contains evidence content. For Annex VII point 1, "what is missing" names each open sub-point, for example the photographs of a hardware product.

Download. Any user can download the list as a CSV for the Jira importer or as Markdown.

Send to Jira or GitHub. An admin can send the list to the Jira or GitHub connection under Settings, Integrations. "Check first" shows what would happen and creates nothing. "Create tickets" creates one ticket for each gap that has none, at most 50 per run.

• In Jira, enter the project key and the issue type. Each issue gets the labels cra-gap, one label for the product and one label for the gap.
• In GitHub, enter the repository as owner/name. The token needs the Issues permission set to read and write. The SBOM connector needs read only, so you may have to add the permission.

Sending again is safe. A gap that already has a ticket, open or closed, is not sent again. The result lists those tickets. A closed ticket for a gap that is still open is not reopened, so check it. The result also lists open tickets whose gap CVD Portal no longer reports, so you can close them.

A closed ticket does not close a gap. The gap closes when CVD Portal sees the fix, for example a sign-off with evidence.

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. An approval also waits for every export check to pass. Until then Approve is off, the panel lists the open checks, and the API refuses an approval with status 409. 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.

Signing a decision

The decider can add a signature to an approval or a rejection. The signature states what the decision means: technical file approval, conformity review or release sign-off. A signature needs a fresh proof of identity, either the account password or an authenticator or backup code. The approval card then shows the meaning and how the signer was verified. A decision with no signature shows neither.

Five wrong passwords or codes within 15 minutes block more attempts for 15 minutes. Each wrong attempt is written to the audit log. The meaning and the verification method are stored in their own fields. Text that you type in the decision note cannot create a signature.

Account archive

The account archive puts the assessment of every active product into one HTML file. You can download it on the Compliance or Enterprise plan, during a trial, and after a trial ends.

The archive never blocks a product. A product that the technical-file export would refuse gets the stamp "DRAFT" and a list of its open issues. The open issues are the validation errors, the open export checks, and a missing or stale export review. Do not send a product with the DRAFT stamp to an authority as its technical file.

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.

Under Article 30(4), the notified body's identification number follows the CE marking only when the conformity assessment is based on full quality assurance (Module H). EU-type examination plus conformity to type (Module B + C), a European cybersecurity certification scheme and internal control (Module A) add no number. For an important or critical product, the product record does not store which module you choose, so the panel states the number as conditional on Module H.

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 support period runs from the placing-on-the-market date. When you do not record that date and no "Placed on market" snapshot exists, the start and the derived end date stay empty and a warning asks for the date. The save date is never used as the start. When you change the months or the start, the end date is derived again, unless you typed an end date yourself. The placing-on-the-market date is checked for a plausible year, so a stray keystroke cannot quietly put your support period a few centuries out and publish it on the sheet. 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.

Point 8 of the sheet lists items (a) to (f) of Annex II point 8 separately, including (e), how to turn off automatic security updates, and (f), information for integrators. A "point by point" list under the sheet explains each of the 15 points and names every point that still holds a placeholder.

Annex II answers

No record holds some of the facts that Annex II asks for, so an admin writes them under Annex II answers, above the sheet. Select Edit the answers. Each field shows what its Annex II point asks for.

Field	Source
Website, optional	Annex II point 1
Intended purpose, security environment, functions and security properties	Annex II point 4
Circumstances that may lead to significant cybersecurity risks	Annex II point 5
Type of security support	Annex II point 7. The sheet takes the end date from the support period
Secure use, data security, updates, decommissioning, turning off automatic updates	Annex II point 8(a) to 8(e)
Information for integrators	Annex II point 8(f)

Select Save draft to keep your work. The sheet does not use a draft. Tick the sign-off box and select Sign off. A sign-off needs every field except the website. When you change an answer later, the sheet keeps the signed-off text until you sign off again. Withdraw the sign-off puts the placeholders back and keeps your draft.

The answers are one record with the integrator security guide of the trust portal. On the trust portal, approved viewers see points 4, 5, 8(d) and 8(f) only. The Compliance plan and the trust portal both open the answers.

Foreseeable circumstances (point 5)

When the newer path features are on for your account, point 5 prints a short list of circumstances of use, or of reasonably foreseeable misuse, that can lead to significant cybersecurity risks. It prints only the text an admin confirms.

The editor proposes the list from the confirmed risks with an inherent score of 15 or more. Each risk gives one statement, chosen from what the risk description and its asset say. The threat category alone never chooses a statement. "Where the proposed statements come from" lists the risks behind each statement, so you can check every statement before you confirm it. Edit the text for your users. It holds at most eight statements and no scores, likelihood or impact words.

Points the sheet fills itself

• Point 3 gives the type, model, batch or serial identifier that you record for the declaration.
• Point 6 gives the address of the public declaration page when that address opens the current issued declaration. That is when the page is published, the portal is public, the issued declaration is Public, and the product shows conformity records, the same conditions as the QR code. When the declaration is issued but the address does not open, point 6 says that the declaration is available on request from the contact in point 1. Before the first issue, point 6 keeps a placeholder.
• Point 9 gives the address of the public SBOM download when the SBOM is Public and the page is live. Annex II asks for point 9 only when you make the SBOM available to users, so in every other case the sheet has no point 9.

With every answer signed off, the sheet has no placeholder, and its first line asks you to review it before distribution.

Place on the market (Conformity tab)

The last card on the Conformity tab captures the snapshot that records the placing on the market. Only an account admin sees it. The Conformity stage is done only when this snapshot exists, so the step sits on the stage it completes. A confirmation states that the snapshot records today as a placing on the market. The card shows the version and date of the latest "Placed on market" snapshot.

The snapshot uses the export checks and one more rule. Every applicable Annex I requirement must have a sign-off and evidence. The export passes a file with one requirement signed off and one evidenced, because a technical file is put together step by step. A placing on the market states that the product meets every essential requirement that applies, so the snapshot asks for all of them. A requirement you mark not applicable, with a written reason, does not count.

Monitoring, review and snapshots (Keep compliant tab)

Record events that oblige a re-review of the assessment (threat-landscape change, substantial modification, and similar) and resolve them once handled. After a substantial modification, capture a new snapshot with Capture snapshot in the Actions card. The button stays disabled until the four-factor test records a substantial verdict, and a confirmation states that the snapshot records today as a new placing on the market. If no support-period start is recorded, a "Placed on market" snapshot sets it to the snapshot date. The snapshot stores the full assessment together with the generated conformity documents, versioned per product and retained for the technical file. The snapshot confirmation shows the exact date the technical file must be retained until. That date is ten years after the product was placed on the market, or the end of the declared support period where that is later, whichever is longer (Article 13(13)).

Compare versions

The "Compare versions" panel on the Keep compliant tab shows what changed between two snapshots, or between a snapshot and the current assessment. The technical documentation has to describe the changes between versions of the product, and a change since the last placing on the market may be a substantial modification, so the panel answers both questions.

The comparison covers the classification and conformity route, the product context, the support period, assets, threats, risks, Part I(2) applicability, security objectives, the Annex I checklist and sign-off, the Article 13 duty records, the assessment criteria and the clause artifacts. Rows are matched on their own identifier, so a reordered list is not reported as a change. A threat shows the interfaces it is reached through by name, and no name means every interface of the product. A renamed interface shows once, in the product context, and not again on each threat. A drafted artifact is reported as changed with its length before and after, not word by word.

Changes that need a decision come first, under "Needs attention":

• a removed sign-off, or a requirement that lost all its evidence
• a Part I(2) requirement newly marked not applicable, which needs an Article 13(4) justification
• a risk score that rose, or a threat, risk or artifact that left the file
• a changed intended purpose, which alone can make the change a substantial modification under Article 3(30)
• a new or removed interface, which the four-factor test treats as a possible new threat vector
• a changed threat cause, or a change in the interfaces a threat is reached through, because the acceptance verdict of its risk reads both
• a changed product class or conformity route
• an Article 13 duty that is no longer in place, or a criterion that no longer passes

"Download change record (Markdown)" saves the same comparison for the technical file. A snapshot taken before a section existed says so. It does not report that section as added or removed. The current assessment is assembled the same way as a snapshot, so product facts that did not change never appear as changes.

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.

Close each open trigger with an outcome, so the file shows what the review decided. "Add as threat" adds a threat to the threat model with the category "tampering" and the asset "Product-wide", the same defaults as a threat you add by hand, and links it back to the input (for example sbom:GHSA-...:lodash@4.17.20 or submission:<id>). Set the category, the asset and the rating afterwards. A second click for the same input adds no second threat. "No change needed" asks why the risk assessment does not change, in at least 10 characters, and keeps the reason on the trigger. Under the box, the page counts the characters still needed, and "Close trigger" stays unavailable until the reason is long enough. "Record trigger" refuses a second open trigger with the same event and the same text, so describe what changed or close the open one first. The Clause 6 updates artifact (C6.7-OUT-03) lists every closed trigger with its outcome, and the exported technical file carries the link on each threat (schema cra-risk-assessment/1.8).

Archiving or deleting a product (Classify tab)

Account admins archive or delete a product in the Archive or delete card at the bottom of the Classify tab. On the conformity path, the same card is in step E4.

Archive product removes the product from the product list and keeps its records. Its controls become not applicable. Its assessment data, evidence and snapshots stay stored. Use archive for a product that was placed on the market. You cannot unarchive a product. Capture a snapshot before you archive if you need a record of the product as it was.

Delete product removes the product with its assessment, evidence, artifacts, controls and uploaded files. It also removes the pipeline findings, security review items and tabletop exercises of the product. You cannot undo a delete. To confirm, type the product name exactly as it is shown. The audit log keeps a record of the delete.

You cannot delete a product in these cases. Archive it instead.

• The product has a snapshot. A snapshot records a placing on the market, so you must keep the technical file for ten years or for the support period, whichever is longer (Article 13(13)).
• The "Placed on the market" date of the product is today or earlier. The same retention period applies. A date in the future does not stop a delete.
• A vulnerability report is linked to the product.

Archived and deleted products do not count against the products in your plan.

Periodic documentation review (Keep compliant 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, with a link to the comparison against that snapshot.