There is a real argument against giving anyone a pre-filled CRA risk assessment. Article 13(2) requires the manufacturer to assess the cybersecurity risks of the product, and Article 13(3) makes that assessment the manufacturer's own determination, documented and kept current through the support period. It is the assessment that decides which of the Annex I Part I(2) requirements apply to your product and which you are justifying away. Hand a team a document with the answers already in it and you have handed them a way to skip the only step that carries any legal weight.
That argument identifies a real risk. It also treats the empty document as neutral, and this is where the reasoning breaks. Both starting points carry a bias. Only one of them shows it to you.
This post covers what an empty page selects for, what a starting draft is legitimately for, and the single property that separates a useful starter from a compliance liability.
What the empty page selects for
Ask a team that has never done this to list the threats to their product. The list arrives quickly, and it holds the threats that team already discusses: the ones tied to incidents they have lived through, the components they personally own, and the attack classes that were in the news recently. It is recall presented as analysis.
The gaps in that list are predictable, because they are structural.
Threats to the parts of the product nobody in the room owns. The firmware team lists firmware threats. The interface between the device and the vendor cloud belongs to two teams and gets assessed by neither.
Threats that arrive through the decommissioning path. Almost nobody writes down what happens to credentials and stored data when the product is resold or scrapped, because that is a stage nobody is measured on. Annex I Part I(2) asks about it anyway, and the requirement to protect the confidentiality of stored data continues to apply after the device leaves the customer.
Threats to availability that are only visible at population scale. One device failing to reach the backend is a support ticket. Every device attempting to reconnect at the same moment is a different failure, and a team that thinks per-device will miss it.
Threats the team has silently assigned to somebody else. The classic is the supplier component with a known unpatchable weakness. It gets left off the list because writing it down felt like inviting work.
These gaps trace back to an assessment whose scope was set by who happened to be in the room. The empty page ratifies that scope, and it yields a document that reads as complete because every line in it is one somebody thought of.
Product archetypes share more attack surface than teams expect
A starting draft can help at all because the attack surface of a product follows from what kind of product it is. Ownership matters far less than shape.
Two industrial controllers from unrelated vendors carry close to the same asset inventory. Firmware with a boot chain. An engineering access path that can download logic. A fieldbus carrying commands to drives. A control program whose integrity determines physical behaviour. A safe state that has to hold when the network drops. The implementations differ enormously. The list of things worth attacking stays almost constant.
The same holds for a smart home hub, where the governing question is always whether an unlock command authenticates to a person or to a position on the network. It holds for a smart meter gateway, where key material in the security module and the aggregate consequence of a fleet-wide command are the two things that matter most. It holds for a mobile robot, where the teleoperation link and the behaviour on link loss carry the physical risk.
This is where archetype content earns its place. It enumerates the questions a product of that shape has to answer, including the four or five that a first-time team reliably skips.
A starter holds claims you have to dispose of
The useful framing is that a starter carries claims for you to dispose of.
Take a threat like tampering with data in transit on a local pairing radio, applied to a smart home hub. Nobody outside your team knows your radio, your pairing flow or your replay protection, so the row settles nothing by itself. Its value is that your team now has to answer it, and there are only three defensible endings. The threat applies, and here is the control that addresses it, which produces an implementation reference the technical documentation needs anyway. Or it does not apply, and here is why, which produces exactly the justification Annex I Part I(2) requires for an inapplicable requirement. Or nobody knows, which is the most valuable of the three, because an unknown that surfaces during assessment costs a conversation and an unknown that surfaces after placing on the market costs an Article 14 notification.
Every one of those endings advances the file. An empty page produces a fourth, where the question goes unasked, never appears in the document, and leaves nothing behind to mark its absence.
The same reasoning applies to shipping default likelihood and impact values in a starter. The defaults will be wrong for your deployment, and that is the point: a wrong number invites an argument while an empty cell invites agreement. A team that sees an interface it knows is unreachable in its architecture rated as medium likelihood will fix the rating. The same team scrolls past an unscored row.
The one property that makes this safe
All of this collapses if seeded content can be inherited without a decision. A starter that quietly counts toward your compliance posture does real damage, because it converts an unexamined assumption into apparent evidence.
So the property that matters is this: nothing a template supplies may count until a human has confirmed it.
In practice that means seeded assets arrive unconfirmed and stay outside your coverage measurement until someone ticks them. It means a proposed classification is recorded as a suggestion with no decision timestamp, so the gate that governs placing the product on the market still requires a person to read the Annex III and Annex IV lists and commit. It means the risk criteria are visibly defaults, present so that scoring has documented scales from the first day, with the scales fixed before the scores.
Classification deserves particular care, because it is the one field where a wrong inherited answer becomes expensive. Under Article 32 the class determines the route. A default-class product can self-assess. An Annex III Class II product needs notified-body involvement. An Annex IV critical product needs a certification scheme or an equivalent route. A team that inherits a suggested class without checking it can spend months on the wrong conformity path and discover the error at the point where correction costs most. No template should be able to make that decision quietly.
There is a reasonable objection here. Unconfirmed content still anchors, and a team that starts from a list of ten threats may stop at ten. That is real, and it is why a starter has to announce itself as an archetype, and why the prompts asking what is missing carry more weight than the rows already filled. The claim worth defending is modest: a starting draft trades an invisible bias for a visible one, and a visible bias can be argued with.
Where this leaves the work
A CRA risk assessment is still yours. Article 13(3) does not move, the determination of which Annex I Part I(2) requirements apply is yours to make and defend, and no starting draft changes what you are accountable for.
What a starting draft changes is the first hour. The team spends it disagreeing with a list that already includes the decommissioning path, the interface nobody owns, and the failure mode that only appears at fleet scale. The output is a shorter list of open questions and a longer list of decisions with reasons attached, and the second list is what the technical documentation under Annex VII eventually has to carry.
We have published archetype starters for ten common product types, covering the classification and the conformity route it implies, a starter asset inventory, a threat analysis tied to the Annex I Part I requirements each threat evidences, and the default scoring scales. They are on the templates page, and each one is built to be argued with. If your product resembles none of them closely, that is useful information about your scope, and the classification tool is the better place to start.
A good first risk assessment is measured by how many things the team discovered it did not know.