Threat and attack scenario records turn a broad risk assessment into traceable engineering evidence. Rather than listing generic threats such as unauthorised access or denial-of-service, describe how a realistic attacker or technical event could interact with the actual product architecture, what conditions are required, what asset is affected and which controls prevent, detect or contain the scenario.
Threat Scenarios Are a Practical Risk-Assessment Method
Article 13 requires manufacturers to undertake, document and maintain a cybersecurity risk assessment. It does not prescribe one named threat-modelling framework or one mandatory attack-scenario template. Threat and attack scenario documentation is therefore best understood as a practical engineering method for satisfying the broader need to identify and analyse product-specific cybersecurity risks. The method is useful because it creates a traceable connection between product architecture, threats, consequences, Annex I requirements, controls and security verification.
- Do not present one threat-model method as CRA-mandated.
- Use scenarios to support Article 13 analysis.
- Connect scenarios to actual product architecture.
- Connect scenarios to Annex I outcomes.
- Preserve evidence for technical documentation.
Distinguish Threats From Vulnerabilities
A threat describes a potential cause of an unwanted cybersecurity event. A vulnerability is a weakness that can enable or contribute to the event. An attacker attempting to gain administrative access is a threat scenario. A missing authorisation check can be the vulnerability that enables it. The same vulnerability can support several threat scenarios, and the same threat can exploit different vulnerabilities. Keeping these concepts separate makes risk treatment clearer and prevents vulnerability scanning from being mistaken for the complete cybersecurity risk assessment.
- Threat: potential adverse action or event.
- Vulnerability: exploitable weakness.
- Scenario: how the threat reaches an asset.
- Risk: consequence and likelihood or feasibility in product context.
Start With Assets and Security Outcomes
A scenario should identify what matters if the attack succeeds. Assets can include data, credentials, cryptographic keys, configuration, software integrity, administrative privileges, essential functions, update infrastructure or connected systems. Security outcomes can involve confidentiality, integrity, availability, unauthorised access or broader incident impact. Starting from assets prevents teams from generating long lists of attack techniques without explaining why they matter to the product.
- Identify the target asset.
- Identify required security property.
- Identify potential cybersecurity consequence.
- Connect the asset to intended product use.
Identify Threat Sources
Threat sources can include remote unauthenticated attackers, authenticated low-privilege users, malicious administrators, compromised connected devices, malicious software on the same platform, supply-chain compromise or technical failure conditions that create a security consequence. The CRA does not require one universal attacker taxonomy. Product teams should select threat sources that are credible for the intended and reasonably foreseeable operating conditions of the product.
- Remote attacker.
- Local attacker.
- Authenticated low-privilege actor.
- Privileged insider.
- Compromised connected system.
- Compromised dependency or supplier.
- Security-relevant technical failure.
Document the Entry Point
The entry point identifies where the scenario begins. It can be a network service, API, management interface, file parser, wireless protocol, update mechanism, local process boundary, hardware port, plugin interface or external dependency. Entry-point documentation connects the scenario to the product's attack-surface analysis. It also helps security testing identify which interfaces should receive negative testing, fuzzing, authentication testing or other verification.
- Network interface.
- API.
- Administrative interface.
- File or data parser.
- Update channel.
- Hardware interface.
- Third-party integration.
Record Preconditions
Preconditions explain what must already be true before the scenario can occur. They can include network reachability, possession of an account, physical access, installation of a malicious file, presence of a vulnerable component or use of a particular configuration. Preconditions are important because they influence risk and help distinguish a remotely reachable issue from one requiring several layers of prior access. They should be factual rather than used to dismiss risk automatically.
- Required access level.
- Required network position.
- Required product configuration.
- Required component or version.
- Required user action.
- Required prior compromise.
Describe the Attack Path
The attack path should describe the important sequence from entry point to security consequence. It does not need to become an exploit tutorial. The purpose is to explain enough technical progression that architects and reviewers can understand which controls interrupt the scenario. For example, an attacker may reach an exposed management endpoint, obtain an authenticated low-privilege session, exploit an authorisation weakness and modify security configuration. Each stage can map to a different preventative or mitigating control.
- Initial interaction.
- Authentication or access stage.
- Privilege transition where relevant.
- Affected component.
- Target asset.
- Resulting security consequence.
Document Existing Controls
Record controls that already prevent, detect or limit the scenario. Examples can include authentication, authorisation, input validation, secure defaults, interface restrictions, cryptographic protection, least privilege, process isolation, rate limiting, security logging and monitoring. The scenario should not assume a control works simply because it exists in the design. Later verification should show whether the control actually interrupts the relevant attack path under the tested conditions.
- Preventative controls.
- Detection controls.
- Containment controls.
- Recovery controls.
- User or environmental controls.
Connect the Scenario to Annex I
The same attack scenario can affect several Annex I requirements. Unauthorised administrative access can relate to access control, confidentiality, integrity and attack-surface limitation. Denial-of-service can relate to resilience and the availability of essential functions. A scenario involving malicious update substitution can relate to integrity and secure update distribution. Mapping the scenario to relevant requirements makes it easier to identify whether the product's control set addresses the required security outcomes.
- Identify relevant Annex I Part I requirements.
- Identify relevant Part II processes where applicable.
- Avoid generic one-control-fits-all conclusions.
- Link each requirement to appropriate evidence.
Assess Scenario Risk Separately From Scenario Description
The attack scenario describes what could happen. Risk evaluation determines how important the scenario is for the specific product. Keep those steps separate so that changes in exploitability, deployment or impact do not require rewriting the basic scenario unnecessarily. Risk fields can record attack feasibility, likelihood where used by the chosen method, consequence, existing controls, overall rating and rationale. The CRA does not prescribe one universal risk-scoring formula.
- Describe scenario first.
- Evaluate feasibility or likelihood.
- Evaluate impact.
- Record existing controls.
- Record risk rationale.
- Assess residual risk after treatment.
Use Scenarios to Drive Security Testing
A well-written scenario gives security testing a clear objective. Authentication scenarios can drive access-control testing. Untrusted file scenarios can drive parser testing or fuzzing. Update substitution scenarios can drive package-signature and integrity tests. Denial-of-service scenarios can drive resource-exhaustion testing. Test reports can then reference the scenario identifier, creating traceability from cybersecurity risk through control to evidence.
- Map scenarios to test cases.
- Test control failure paths.
- Test representative preconditions.
- Record the product version.
- Link results back to the risk record.
Keep Scenarios at the Right Level of Detail
An attack scenario should contain enough detail to explain cybersecurity risk without becoming an unnecessary step-by-step offensive playbook. Internal engineering records can contain deeper technical detail where required for testing and remediation, while the compliance-oriented scenario record can focus on entry point, preconditions, affected assets, consequence and controls. The appropriate depth depends on the product and risk. The key is that reviewers can understand why the manufacturer reached its risk and control conclusions.
- Describe the security-relevant path.
- Avoid irrelevant exploit detail.
- Reference deeper engineering records when needed.
- Preserve enough information for reproducible assessment.
Maintain Scenarios After Product Changes
New interfaces, dependencies, privileges and deployment models can create new attack scenarios or change existing ones. Product-change review should therefore identify affected threat records. A new cloud integration can change trust boundaries. A new administrative API can create a new entry point. Removal of a service can eliminate an older scenario. Version control should preserve the relationship between product releases and the scenario set used for their cybersecurity risk assessment.
- Review new interfaces.
- Review architecture changes.
- Review dependency changes.
- Review changed privileges.
- Retire obsolete scenarios deliberately.
A Practical Attack-Scenario Record
A practical record can include scenario identifier, product version, threat source, entry point, preconditions, affected components, attack path, target assets, cybersecurity consequence, related vulnerabilities, existing controls, Annex I references, risk rating, treatment decision, verification evidence and review status. The CRA does not prescribe this exact structure. Its value is traceability: a reviewer can follow the path from product architecture to risk and then to the controls and tests used to address it.
- Scenario identifier.
- Threat source.
- Entry point.
- Preconditions.
- Attack path.
- Target asset.
- Security consequence.
- Related vulnerability.
- Mapped Annex I requirements.
- Existing controls.
- Risk rating.
- Verification evidence.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.