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 Assess, Evidence and Conformity tabs. The Requirements, Monitoring and Secure by design tabs, and all editing, require the workspace Admin role.

Each product page is organised in six tabs: Assess, Requirements, Evidence, Conformity, Monitoring and Secure by design. 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, a technical file readiness summary and, below it, progress bars for the work completed.

Read the readiness summary first. It 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 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.

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 Assess tab. Open triggers are recorded events asking for a re-review, which do not block progress and close with a documentation review on the Monitoring 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.

Product compliance stages

The stage bar guides product conformity work through seven stages.

1. Register. You create the product record in the workspace.
2. Classify. You record the CRA product category and class decision.
3. Context and risk. You document product context and complete the Clause 6 risk assessment artifacts.
4. Requirements. You satisfy the Clause 7 essential requirements and verify the criteria pass.
5. Evidence. You gather verified technical evidence across the controls.
6. Conformity. You close export gaps and create the assessment snapshot for the declaration file.
7. Keep compliant. You resolve open review triggers and maintain documentation currency over time.

Creating a product

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

The description is not frozen at creation. On the Assess 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. The "Create from a document" panel above the create form 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

Under the create form, "Use an industry template" opens a list of pre-built assessment starters for common product archetypes: 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" stays available 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 analysis 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 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 Assess 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 (Assess 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.

Risk assessment (Assess tab)

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

• Map the product's assets manually, or 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 counts confirmed assets only, so a register nobody has reviewed does not pass it on its own. 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.
• Generate a STRIDE threat model grounded in the CRA threat catalogue, 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. 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.
• 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.
• 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 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.

Product context (Clause 6.2)

The Assess tab has 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.

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 Assess panel ("Provide it in Assess"); 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.

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.

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 in Assess. 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.

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.

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 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.

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 Assess 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, for example "Article 11" for the reporting of actively exploited vulnerabilities, which is Article 14. Article 11 is the numbering of the 2022 proposal.
• 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. An artifact holds an open placeholder or says that a fact is not recorded.

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.

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 Assess tab, 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 (Assess tab)

At the top of the Assess 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. 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. 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 Assess 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 every control, including the two conformity documents (the Declaration of Conformity and the technical documentation index). That is why the "Evidence recorded, all controls" bar on the product page has a larger total than the "Clause 6 and 7 artifacts" bar beside it. Both are correct, and they count different populations. 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.

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 Assess 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. Point 8 of Annex V, the signature, is always yours, because a person 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), so the panel shows which legal entity that is before you generate anything. 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, as a consultant, reseller or partner does, press "Use a different manufacturer" and record their entity: their name then appears 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. 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.

Where a product manual has been analysed on the Assess 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.

All generated documents are drafts. The workspace structures your assessment and evidence; it does not by itself 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. The snapshot comparison lists gaps that opened or closed between two versions.

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 four places.

• The technical file gate, for example an undecided classification or a missing SBOM.
• 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.

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. The technical-file export (JSON and HTML) only unlocks while an approval is current; any change to the assessment, classification or support period makes the sign-off stale and locks the export again until a new review is approved. Every request and decision is recorded in the audit log.

Executive readiness briefing

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

CE marking (Conformity tab)

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

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. Point 9 is optional. Annex II asks for the SBOM address only if you choose to share the SBOM with users. A "point by point" list under the sheet explains each of the 15 points and names every point that still holds a placeholder.

Monitoring, review and snapshots (Monitoring tab)

Record events that oblige a re-review of the assessment (threat-landscape change, substantial modification, and similar) and resolve them once handled. When placing the product on the market or after a substantial modification, capture an immutable snapshot. The reason has no default, and a confirmation states that the snapshot records today as a 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(18) and Article 23).

Compare versions

The "Compare versions" panel on the Monitoring 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 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 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. 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 a product (Monitoring tab)

Account admins can archive a product with Archive product in the Actions card. The product leaves the product list and its controls become not applicable. Its assessment data and snapshots are kept.

You cannot unarchive a product. Capture a snapshot before you archive if you need a record of the product as it was.

Periodic documentation review (Monitoring tab)

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

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

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