CRA Cybersecurity Risk Assessment: Guide and Template

Every manufacturer of a product with digital elements in the CRA's scope must run a cybersecurity risk assessment and keep it in writing. It is the document that decides which CRA security requirements bind your specific product, and how you meet them. Market surveillance authorities can ask for it. Without it, your technical file is incomplete and your conformity claim has no foundation.

This guide explains how to perform the assessment, how to record it, and how to keep it current. It includes a full mapping of the security requirements, a worked example and a copyable document skeleton.

What is the CRA cybersecurity risk assessment?

The cybersecurity risk assessment is a documented analysis of the risks your product faces, based on its intended purpose and the ways people can reasonably be expected to use it. It covers the conditions of use, such as the operational environment and the assets the product must protect, and it takes into account how long the product is expected to be in use.

The assessment has one output that everything else depends on. It states, for each product security requirement in the CRA, whether that requirement applies to your product, and if so, how your design and processes implement it. It also records how you meet the secure-design baseline and how your vulnerability handling processes cover the product.

Three properties make it different from a generic corporate risk register:

• It is product-specific. Grounded in that product's architecture, interfaces and users. A company-wide ISMS risk register does not satisfy it. Our ISO 27001 comparison covers that gap in detail.
• It is a lifecycle document. You use it during planning and design, not only at release. And you update it during the whole support period.
• It is evidence. The documented assessment goes into your technical file, where authorities can request it.

Who needs one, and when

Every manufacturer placing a product with digital elements on the EU market needs one, unless the product sits outside the CRA entirely. In scope: hardware with firmware, standalone software, and products whose remote data processing is part of the offering. It applies to a one-person software company the same way it applies to a multinational. Products the CRA excludes, such as covered medical devices, certain vehicles and certified aviation equipment, follow their own sector rules instead. If you are unsure the CRA covers your product at all, start with the scope guide.

Timing matters more than most teams expect:

• Start during planning. The assessment is meant to steer design decisions. Run a first pass when the architecture is still cheap to change.
• Complete and document it before market placement. The written assessment must be in the technical file when the product ships.
• Maintain it through the support period. The assessment is never final. It tracks the product for as long as you owe security updates.

One narrow simplification exists. It covers only the products the CRA treats as high-risk AI systems and that are also subject to other EU laws requiring a risk assessment. For those, the cybersecurity assessment may become a part of that other risk assessment rather than a separate document. The content obligations stay the same. See the AI Act overlap guide for how that works in practice.

What the assessment must contain

The CRA sets a minimum content baseline. Your assessment must cover three things:

• The product in context. What the product is for, how people can reasonably be expected to use it, the environment it operates in, the assets it must protect, and how long it is expected to stay in use.
• Applicability decisions. For each of the 13 product security requirements: does it apply to this product, and how is it implemented. Where one does not apply, a clear written justification.
• Process coverage. How the secure-design baseline is met and how your vulnerability handling processes cover the product.

The justification duty deserves emphasis. "Not applicable" without a reason is a defect. Name the product facts that remove the requirement, and write them down. The written justification goes into the technical file with the rest of the assessment.

Beyond that legal minimum, add the controls that make the document defensible: treatment decisions with their residual risk, acceptance criteria, a named approval with a date, and a revision history. The CRA does not prescribe any of them. They are how you show the assessment stayed current, and that someone accountable accepted the remaining risk.

Choose a method

The CRA does not mandate any assessment methodology, scoring scale or template. What it requires is a documented result that supports the applicability decisions. Pick a method your team can repeat, and describe it inside the assessment so a reviewer can follow your reasoning.

One rule holds regardless of choice. Express each risk as a combination of its likelihood and the magnitude of the loss or disruption it could cause. The CRA frames cybersecurity risk in exactly those two dimensions, so a threat list that rates neither is not yet an assessment.

Common workable choices:

Method	What it gives you	Fits best
Likelihood x impact matrix	Simple numeric risk ratings and a ranked register	Small teams, first assessments
STRIDE-style threat modelling	Systematic threat identification per component and data flow	Software-heavy products with clear architecture diagrams
ISO/IEC 27005 style process	A full risk management cycle with context, analysis, treatment	Organisations that already run an ISMS
IEC 62443 threat-risk approach	Zone and conduit analysis for industrial contexts	Industrial and OT products, see the industrial automation guide

The coming harmonised standards will not change the free choice of method. The draft European framework standard for CRA risk management is itself method-neutral, building on the ISO 31000 risk process without prescribing a scoring model. Our harmonised standards status page tracks its progress. And standards never replace the assessment: even a product that applies harmonised standards in full needs its own documented assessment, and you must check that the standards cover the risks you actually identified.

Whatever you choose, keep two rules:

1. The method must produce applicability answers. A pile of rated risks is not enough. The output must map to the 13 security requirements below.
2. Write the method down. Scale definitions, formula, acceptance thresholds. A rating of "12 (High)" means nothing if the scale is undocumented. The record should let a market surveillance authority verify how each risk was identified, evaluated and treated.

The assessment, step by step

A workable process in seven steps. Adjust depth to your product's complexity and risk.

Step 1: Define scope and context

Record the product name and version, its intended purpose, the environments it will run in, and its users. State what is in scope, including companion apps, cloud backends that are part of the offering, and bundled components. State what is out of scope and why.

Step 2: Identify assets

List what the product must protect. Typical assets are user data, credentials and keys, firmware and configuration integrity, availability of the product's function, and the surrounding network. Note where each asset lives and how it moves.

Step 3: Identify threats

Work through your architecture surface by surface. External interfaces first, since attackers start there. For each interface and data flow, ask what an attacker could do: intercept, spoof, tamper, flood, extract. Include foreseeable misuse of the product, not only deliberate attack. Record each credible threat with the vulnerability it would exploit.

Step 4: Rate the risks

Rate likelihood and impact for each threat using your documented scale. Where an incident could cause physical harm, include the effect on users' health and safety in the impact rating. Rank the results. The point of rating is prioritisation, not precision. A defensible ranking that drives design decisions beats a precise-looking table nobody uses.

Step 5: Decide applicability of the security requirements

Take the 13 product security requirements one by one. For each, state whether it applies to this product, which of your identified risks it addresses, and how you implement it. Where one genuinely does not apply, write the justification. The full mapping table below is your worksheet.

Step 6: Treat the risks and record residuals

For each material risk, record the control you chose, where it is implemented, and the residual risk after the control. Define acceptance criteria and record who accepted the remaining risk. Risks without a control need an explicit, owned acceptance decision.

Step 7: Approve and set maintenance triggers

Have a named owner approve the assessment, with a date. Then define the events that reopen it: new vulnerability information, new features, component or supplier changes, incident findings. Add a revision history table so authorities can see the document has lived.

Mapping the 13 security requirements

This is the centre of the assessment. The CRA lists 13 product security requirements, and your document must answer two questions for each: does it apply, and how do you implement it. The table below translates each requirement into review questions and typical evidence.

The requirement column stays close to the legal wording. The controls column is not part of the law: it lists the measures and evidence teams typically use to show the requirement is met.

Two practical notes on using the table:

• "Where applicable" is a per-product decision, and yours to defend. The requirements apply on the basis of your risk assessment. A standalone software tool that holds no data and no settings can justify excluding the data-removal requirement. No product can exclude update capability just because updates are inconvenient.
• The mapping doubles as your conformity evidence index. Each row's controls column tells you what belongs in the technical file, and it is the material a conformity assessment will examine.

Covering the vulnerability handling processes

The assessment must also state how your ongoing processes cover the product. The CRA's process requirements are the operational side of the same coin. Your assessment should confirm, briefly and with pointers to the owning documents, that for this product you:

• identify and document vulnerabilities and components, including an SBOM covering at least top-level dependencies
• address and remediate vulnerabilities without delay, with security updates delivered separately from feature updates where technically feasible
• apply effective and regular tests and reviews of the product's security
• once an update is out, publicly disclose the fixed vulnerability with a description, affected products, impacts, severity and remediation help. A justified delay is allowed where the security risks of publication outweigh the benefits, and only until users have had the possibility to apply the patch
• run a coordinated vulnerability disclosure policy
• provide a contact address for vulnerability reports and help information about potential vulnerabilities flow, including for third-party components
• distribute updates through secure mechanisms so fixes arrive in a timely manner, automatically where that applies to security updates
• disseminate security updates without delay and free of charge, with advisory messages telling users what to do. For a tailor-made product, a business customer can agree otherwise on the free-of-charge point only

These bullets are working summaries, not the full legal wording. Keep this section short in your assessment, link to the owning process documents, and check the complete requirements in our vulnerability handling guide.

Worked example

The excerpts below show the level of detail that works in practice. The product is a fictional connected environmental sensor with a companion app and cloud dashboard.

Risk register excerpt

CYBERSECURITY RISK ASSESSMENT

Product: SmartSense Pro (SSP-3000)
Version: 2.4.1
Assessment date: January 2027
Owner: [Name, Security Team]

METHOD:
Likelihood x impact, scales defined in section 1.
Risk = Likelihood (1-5) x Impact (1-5)
Bands: Low (1-4), Medium (5-9), High (10-16), Critical (17-25)

-------------------------------------------------------------
RISK ID: R-001
THREAT: Unauthorised firmware modification
VULNERABILITY: Unsigned firmware could be installed
IMPACT: 5 - Device compromise, data breach
LIKELIHOOD: 3 - Requires physical or local network access
INHERENT RISK: 15 (High)

CONTROL: Firmware signature verification
IMPLEMENTATION: ECDSA P-256 signature checked before install
RESIDUAL RISK: 3 (Low) - Cryptographic attack unlikely
STATUS: Mitigated
-------------------------------------------------------------
RISK ID: R-002
THREAT: Interception of cloud communication
VULNERABILITY: Network traffic readable in transit
IMPACT: 4 - Data exposure, command injection
LIKELIHOOD: 3 - Shared and public networks expected
INHERENT RISK: 12 (High)

CONTROL: TLS 1.3 with certificate pinning
IMPLEMENTATION: Pinned CA certificate, no fallback
RESIDUAL RISK: 2 (Low) - Certificate compromise unlikely
STATUS: Mitigated
-------------------------------------------------------------
[Continue for all identified risks...]

RISK SUMMARY:
Total risks identified: 23
Critical: 0
High: 3 (all mitigated to Low or Medium)
Medium: 8 (all mitigated to Low)
Low: 12 (accepted or mitigated)

RESIDUAL RISK ACCEPTANCE:
All residual risks within tolerance defined in section 1.
Accepted by: [Security Lead], [Date]

Applicability record excerpt

SECURITY REQUIREMENTS APPLICABILITY

REQ 3 - SECURITY UPDATES
Applies: YES
Risks addressed: R-004, R-011
Implementation: Signed OTA updates. Automatic security updates
enabled by default, opt-out and postponement in app settings.
Users notified in app and by email.
Evidence: Update mechanism design UMD-002

REQ 12 - LOGGING AND MONITORING
Applies: YES
Risks addressed: R-009
Implementation: Security events (auth failures, config changes,
update events) recorded on device and forwarded to cloud.
Logging opt-out available in privacy settings.
Evidence: Logging design LD-001, event catalogue

REQ 13 - SECURE DATA REMOVAL
Applies: YES
Risks addressed: R-015
Implementation: Factory reset permanently clears all stored
data and settings, including network credentials. The device
holds no transferable user data, so no transfer path exists.
Evidence: Reset and wipe design RD-001

[Continue for all 13 requirements...]

Note the data-removal entry: the requirement covers all data and settings, and stored network credentials count. Where a requirement genuinely does not apply, the entry keeps the same shape but names the product facts that remove it. A standalone software tool with no stored data and no settings could record: "Not applicable. The product holds no data and no settings. There is nothing to remove." That factual sentence is what an authority can assess.

Document skeleton

A structure you can copy for the written assessment:

CYBERSECURITY RISK ASSESSMENT - [Product, version]

1. METHOD
   Scales, formula, risk bands, acceptance thresholds

2. PRODUCT CONTEXT
   Intended purpose / Foreseeable use and misuse
   Operational environment / Users
   Assets to be protected
   Expected time in use
   Scope: included components, exclusions with reasons

3. ARCHITECTURE AND ATTACK SURFACE
   Interfaces, data flows, trust boundaries
   (diagram reference)

4. RISK REGISTER
   One entry per credible threat, rated, with control,
   residual risk and status

5. SECURITY REQUIREMENTS APPLICABILITY
   One entry per requirement (all 13), applies yes/no,
   implementation, evidence pointer, justification where
   not applicable

6. SECURE-DESIGN BASELINE AND PROCESS COVERAGE
   How the product's overall security level matches its
   risks, pointers to vulnerability handling processes

7. RESIDUAL RISK AND ACCEPTANCE
   Summary, acceptance criteria, named acceptance

8. APPROVAL AND MAINTENANCE
   Owner, approval date
   Update triggers
   Revision history table

Keep it current

The assessment is a living document for the whole support period. Reopen it when:

• new vulnerability information arrives for the product or its components, from your own monitoring, researcher reports or supplier advisories
• the product changes, and always when a change is substantial enough to require a new conformity assessment
• components change, including new suppliers and versions of third-party or open-source components
• an incident teaches you something your ratings did not anticipate

Record every revision in the history table, with what changed and why. An assessment dated once, three years ago, tells a market surveillance officer the document is decorative.

One consistency duty is easy to miss. Your assessment considers how long the product is expected to be in use. The support period you declare must reflect that expected use time, weighed against its own statutory factors. So the two records must line up. If your assessment expects eight years in the field and your declared support period is five, revisit the determination against those factors. The usual outcome is a longer support period, not a footnote explaining the gap.

Who owns it, and where it fits your workflow

The CRA makes the manufacturer responsible. It does not assign internal roles or prescribe a risk-assessment methodology or team workflow. But an assessment nobody owns goes stale, so working teams split it roughly like this:

• Product owner. Owns the context: intended purpose, foreseeable use, expected time in use. Decides what the product promises, so they sign off when the promise changes.
• Developers and architects. Own the threat picture: interfaces, data flows, the controls that treat each risk, and the evidence that the controls exist.
• Security lead, or whoever holds that hat. Owns the method, the register, the applicability record and the approval. In a small team this is one person wearing three hats, and that works.

Then wire the update triggers into the moments where work already happens, so the assessment never depends on someone remembering it:

The pipeline evidence comes from the tooling you already run: SBOM generation in CI/CD feeds the component record, and your vulnerability handling process is what reopens entries at step 4. The CRA prescribes the outcome, a documented assessment kept current, not the loop. The loop is what makes that duty survivable next to real delivery pressure.

Third-party components

Your product's risk includes the components inside it. When you integrate third-party components, including open-source components, you must exercise due diligence so they do not compromise the product's security. In the assessment, that means:

• component risks appear in the register where material, with the SBOM as the inventory backbone
• your selection and monitoring approach for components is stated, with pointers to supplier evidence
• update paths for components are part of the update-capability analysis

The practical mechanics, including a supplier questionnaire, live in the supplier due diligence guide.

Where the assessment lives

The written assessment is part of your technical file, next to the design documentation, test evidence and the support period decision record. Keep the approved version, its revision history, and the evidence it points to retrievable for as long as the file must be retained. The technical documentation guide shows the file structure and where each artefact sits.

Common mistakes

• Written after the fact. An assessment produced in the week before shipping cannot have informed design. Reviewers notice.
• No applicability decisions. A risk register alone does not answer the question the CRA asks. Every one of the 13 requirements needs an explicit answer.
• "Not applicable" without justification. Every exclusion needs written reasoning in the file.
• Undocumented method. Ratings without scales, formulas without definitions.
• Corporate instead of product-level. An ISMS risk register covers your organisation. The CRA wants this product.
• Frozen at release. No revision history, no update triggers, no connection to vulnerability monitoring.
• Inconsistent with the support period. Expected-use assumptions that contradict the declared support window.
• No named ownership. Nobody approved it, nobody accepts residual risk, nobody owns updates.