Products — CRA compliance workspace

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

Each product page is organised in five tabs: Assess, Requirements, Evidence, Conformity and Monitoring. 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 five checks that gate the Annex VII export, and it lists whichever ones are outstanding with a link to the tab that resolves each. 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: a recorded classification, a drafted product context, at least one assessment criterion passed, at least one Annex I requirement signed off, and at least one carrying evidence.

Creating a product

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

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 a product 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, "Start from 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 class badge keeps its "unconfirmed" marker 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 class badge carries an "unconfirmed" marker and the "What to do next" hint links straight to the classification panel. 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, extract asset candidates from a pasted product manual, or add the assets detected by the document analyzer (each uploaded or pasted document proposes detected assets you can add to the risk assessment in one click).
• 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. 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. 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.
• 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).
• 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.
• Decide which of the 33 SECURE 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, and each panel now says which applies to it. The Clause 6.2 context boxes and the remote data processing section save on their own as you leave a field. Everything else on the Assess tab waits for "Save assessment" at the bottom, and an "Unsaved changes on this tab" marker sits beside that button 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.

• 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. 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 paste a product manual into "Extract from a manual" 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 an extraction finishes it lists what it found as candidate chips, in two groups. "Candidate assets" are the things the product is made of and handles, and "Add all" imports those. 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.

The product header's "What to do next" hint always points at the next missing item and links straight to 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.

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, type your name once, and each ticked row records that name with its own timestamp. 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.

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. 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 "Analyze 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. Each draft is generated and recorded automatically as it completes. A progress bar tracks the run, and you can stop at any time and keep what is done. The panel lists every artifact the run touched, with its outcome and what each one received. The list fills in as the run goes rather than naming one draft at a time. 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 run autofill again to retry it. 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.

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 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, "Analyze a document" 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. When a document also names security-relevant assets, the review card offers "Add N assets to risk assessment", which appends them (AI-detected and unconfirmed) to the assets list without disturbing the assets you already have. Assets that duplicate one already in the register are left out: 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 paste the same document a second time into "Extract from a manual". 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.

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.

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.

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.

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

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

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

Export approval, four-eyes review (Conformity tab)

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

Executive readiness briefing

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

CE marking (Conformity tab)

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

User information sheet, Annex II (Conformity tab)

Set the product's support period or support end-date (Article 13(8)), then generate the draft Annex II information and instructions sheet that must accompany the product. The 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.

Monitoring, review and snapshots (Monitoring tab)

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

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

Periodic documentation review (Monitoring tab)

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

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

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