Independent information resource Product security · EU CRA
User information and security communications / 09

Communicating Known Security Risks

Learn how CRA manufacturers should communicate known or foreseeable circumstances that may lead to significant cybersecurity risks, including intended use, foreseeable misuse, deployment assumptions, insecure configurations and actionable user precautions.

IN BRIEF

Known security risk communication should tell users which real-world conditions can make a CRA product materially less secure and what they can do about them. The best guidance connects the risk to the product's intended environment, configuration and operating assumptions.

01 / 08

Annex II Point 5 Creates a User-Facing Risk Communication Duty

Annex II point 5 requires information about known or foreseeable circumstances related to use in accordance with the intended purpose or under conditions of reasonably foreseeable misuse that may lead to significant cybersecurity risks. This is user-facing information. It should translate relevant product-risk knowledge into practical warnings users can understand.

  • Identify material risk-producing circumstances.
  • Cover intended use and foreseeable misuse.
  • Focus on significant cybersecurity risks.
  • Make the information actionable.
02 / 08

Start With the Intended Security Environment

Many cybersecurity risks arise when a product is deployed outside the security environment assumed by its design. Risk communication should explain material assumptions about network exposure, identity systems, physical access, administrative control, supported integrations or other environmental conditions that affect secure operation.

  • Network trust assumptions.
  • Administrative access assumptions.
  • Physical protection where relevant.
  • Supported integrations and dependencies.
03 / 08

Describe Reasonably Foreseeable Misuse

Foreseeable misuse is not limited to deliberate abuse. Users can predictably expose management interfaces, disable authentication for convenience, reuse credentials, operate unsupported configurations or deploy a product in an unsuitable environment. Where such behaviour may lead to significant cybersecurity risk, the manufacturer should communicate the risk and safer operating approach.

  • Predictable insecure deployment.
  • Disabled or weakened security controls.
  • Unsupported configuration combinations.
  • Security-sensitive convenience workarounds.
04 / 08

Prioritise Significant Cybersecurity Risks

Annex II point 5 focuses on circumstances that may lead to significant cybersecurity risks. Manufacturers should therefore prioritise risks that materially affect confidentiality, integrity, availability or control of the product. Flooding users with low-value warnings can make genuinely important security information harder to find.

  • Prioritise material security consequences.
  • Avoid warning fatigue.
  • Use clear severity or importance cues where helpful.
  • Keep the guidance tied to realistic product use.
05 / 08

Explain the Consequence and the Safer Alternative

A warning is more useful when it explains both what can go wrong and what the user should do instead. For example, rather than stating that public exposure is insecure, the guidance can explain that an administrative service should be restricted to trusted networks and identify the supported secure access method.

  • Describe the risky condition.
  • Explain the cybersecurity consequence.
  • Provide a safer configuration or behaviour.
  • Point to detailed instructions where needed.
06 / 08

Keep Vulnerability Advisories Separate From General Risk Information

Annex II point 5 risk information and fixed-vulnerability advisories serve different purposes. A general risk statement can describe unsafe deployment conditions that exist even without a specific vulnerability. A security advisory addresses a particular fixed vulnerability, affected versions and remediation. The two should be consistent but should not be merged into one confusing document.

  • Use general risk guidance for operating conditions.
  • Use advisories for specific fixed vulnerabilities.
  • Cross-reference when a vulnerability changes the risk picture.
  • Keep affected-version information precise.
07 / 08

Review Risk Communication After Product Changes

A software release, new integration or architecture change can alter known risk-producing circumstances. Product teams should review Annex II point 5 information when security-relevant changes modify deployment assumptions, supported environments or the consequences of foreseeable misuse.

  • Review after security-relevant releases.
  • Update deployment assumptions.
  • Remove obsolete warnings.
  • Add newly material user precautions.
08 / 08

Keep Risk Communication Consistent With the Cybersecurity Risk Assessment

The internal cybersecurity risk assessment and the user-facing risk information are not the same document, but they should not contradict each other. Material user-dependent risks identified during product assessment should be considered for Annex II communication where users need the information to operate the product securely.

  • Connect internal risk findings to user guidance.
  • Avoid contradictory assumptions.
  • Do not expose unnecessary sensitive threat detail.
  • Document why important user-facing warnings exist.
REFERENCE DESK

Official sources

Read the full legal text and Commission material for precise wording, qualifications and updates.

Editorial review: 26 September 2026. Regulatory material can change; follow the official sources for current guidance.