Module 5: Risk Assessment and Lifecycle Security Management

1. Where Risk Assessment Fits in the Cyber Resilience Act (CRA)

Under the EU Cyber Resilience Act (CRA), manufacturers must perform and maintain cybersecurity risk assessments for each in‑scope product throughout its lifecycle.

> Note: As of 2024–2025, the CRA has been politically agreed and is in the final stages of the legislative process. The obligations described here reflect the current, agreed text and latest EU guidance.

How this links to earlier modules:

• From Module 3 you know: products are classified as standard, important, or critical.
• From Module 4 you know: manufacturers must meet essential cybersecurity requirements (security‑by‑design and by default).

Now in Module 5 you focus on how to:

1. Identify and assess risks for each product.
2. Integrate risk assessment into design, development, deployment, and maintenance.
3. Maintain lifecycle security, including updates and end‑of‑support.
4. Document risks and mitigations to demonstrate CRA compliance.

Think of risk assessment as the engine that keeps your secure development lifecycle aligned with the CRA: if it stops or is incomplete, the whole compliance effort breaks down.

2. Core Risk Assessment Obligations for Manufacturers

Under the CRA, manufacturers have several concrete duties related to risk assessment:

1. Perform a documented cybersecurity risk assessment for each product before placing it on the EU market.
2. Cover the full lifecycle in the assessment:

• Design and development
• Production and initial configuration
• Deployment and normal use
• Maintenance and updates
• End‑of‑support / decommissioning

1. Consider the product’s classification (standard / important / critical):

• Important and critical products need deeper, more formalized risk analysis and testing.

1. Identify reasonably foreseeable misuse and threat scenarios

(e.g., default passwords left unchanged, exposed debug interfaces, common social engineering vectors).

1. Update the risk assessment:

• When new vulnerabilities are found
• When the product is significantly updated (major releases, new features)
• When threats or operating environments change

1. Keep evidence (documentation, test reports, threat models) to show conformity to the CRA.

In practice, this means risk assessment is not a one‑off PDF; it is a living document that evolves with the product.

3. Example: Risk Assessment for a Smart Lock App

Imagine you are the manufacturer of a smart lock system:

• A mobile app that controls the lock
• A cloud backend for user accounts and logs
• The lock firmware itself

Step 1 – Identify assets and functions

• Assets: user credentials, access logs, door unlock commands, firmware.
• Functions: remote unlock, temporary guest access, log viewing.

Step 2 – Identify threats (simplified)

• Attacker intercepts network traffic and replays unlock commands.
• Attacker guesses weak passwords and takes over accounts.
• Insider at the company abuses admin tools to unlock doors.
• Vulnerable firmware allows remote code execution on the lock.

Step 3 – Assess risks

• For each threat, estimate likelihood and impact:
• Password guessing: High likelihood, High impact → High risk.
• Insider abuse: Low likelihood, Very high impact → High risk.

Step 4 – Define mitigations (linking to Module 4 requirements)

• Enforce strong authentication (MFA, password policies).
• Use end‑to‑end encryption and replay protection for commands.
• Implement role‑based access control and logging for admin tools.
• Secure firmware update mechanism with code signing.

Step 5 – Document and maintain

• Store the risk assessment in your CRA technical documentation.
• Update it after:
• A new vulnerability in your crypto library is disclosed.
• You add a new feature: "Share one‑time access link".

This is the kind of end‑to‑end view the CRA expects manufacturers to maintain.

4. Thought Exercise: Quick Risk Brainstorm

Consider a desktop password manager sold in the EU.

Task (2–3 minutes):

1. List 3 key assets that must be protected.
2. For each asset, think of 1 realistic threat (how could it be attacked?).
3. For one of those threats, suggest 1 mitigation that could be built into the product.

Use this structure in your notes:

• Asset: ``
• Threat: ``
• Mitigation: ``

When you are done, compare your ideas with these prompts:

• Did you consider local device compromise (malware)?
• Did you think about cloud sync or backup features?
• Did you include user mistakes (e.g., weak master password)?

This mirrors the early design‑stage risk analysis that manufacturers must perform under the CRA.

5. Integrating Risk Assessment into the Secure Development Lifecycle (SDLC)

The CRA expects risk management to be embedded in your secure development lifecycle, not added at the end.

A practical way to do this is to align with a security‑aware SDLC such as Microsoft SDL, OWASP SAMM, or ISO/IEC 27034, but adapted to CRA requirements.

Typical integration points:

1. Concept / Requirements phase

• Identify intended use and reasonably foreseeable misuse.
• Classify the product: standard / important / critical.
• Start a high‑level threat model.

1. Design phase

• Perform detailed threat modeling (e.g., using STRIDE or similar).
• Decide on security controls (encryption, authentication, logging, update mechanisms) that address identified risks.

1. Implementation phase

• Apply secure coding practices.
• Link each security requirement to one or more risks in your risk register.

1. Testing and pre‑release phase

• Conduct security testing (SAST, DAST, fuzzing, penetration tests).
• Update risk levels based on test results.
• Confirm that high and critical risks are mitigated or justified.

1. Post‑release / Maintenance

• Monitor for new vulnerabilities (e.g., in third‑party components).
• Re‑assess risk when issuing security updates or feature releases.

The key idea: every SDLC gate (design review, release review, etc.) should include a risk assessment checkpoint.

6. Simple Risk Register Template (Developer‑Friendly View)

Here is a minimal risk register format you can adapt in a development team. This is not mandated by the CRA, but it helps prove that you manage risks systematically.

```yaml

risk-register.yaml

product: Smart Lock App

version: 1.3.0

last_review: 2025-03-10

risks:

• id: R-001

description: Brute-force attacks against user passwords

asset: User accounts

likelihood: High

impact: High

level: High

mitigations:

• Enforce password complexity & length
• Rate limiting & account lockout after failed attempts
• Optional multi-factor authentication (MFA)

status: Mitigated

last_updated: 2025-02-20

• id: R-002

description: Replay of captured unlock commands

asset: Unlock control channel

likelihood: Medium

impact: High

level: High

mitigations:

• TLS 1.3 for all communication
• Nonces / sequence numbers to prevent replay
• Server-side detection of anomalies

status: In progress

last_updated: 2025-03-01

• id: R-003

description: Vulnerable third-party crypto library

asset: All encrypted data

likelihood: Unknown

impact: Critical

level: Critical

mitigations:

• SBOM maintained for all components
• Subscribe to vendor security advisories
• Patch within 30 days of critical disclosure

status: Open

last_updated: 2025-03-10

```

In a real CRA context, this file would be part of your technical documentation and updated regularly.

7. Lifecycle Security: From Design to End‑of‑Support

The CRA explicitly requires manufacturers to manage cybersecurity throughout the product lifecycle, not just until first release.

Key lifecycle stages and CRA‑relevant actions:

1. Design & Development

• Perform initial risk assessment and threat modeling.
• Choose architectures that support updates, logging, and secure defaults.

1. Production & Deployment

• Ensure secure default configurations (no default passwords, minimal exposed services).
• Provide installation and configuration guidance that reflects your risk assessment.

1. Operational Use

• Monitor for vulnerabilities and incidents (own product and third‑party components).
• Provide security updates and communicate their importance to users.
• Update the risk assessment when new threats appear.

1. End‑of‑Support (EoS)

• Define a support period that is reasonable for the expected lifetime and risk level of the product.
• Before EoS, inform users about:
• The date after which security updates stop.
• Residual risks if they continue using the product.
• Possible mitigation steps (e.g., disconnecting from the internet).
• Reflect EoS in your risk assessment (e.g., risk transfer to user, decommissioning guidance).

Lifecycle security is about planning for change: new features, new threats, and the eventual retirement of the product.

8. Quiz: When Must the Risk Assessment Be Updated?

Test your understanding of continuous risk assessment under the CRA.

9. Activity: Mapping Risks to CRA Requirements

Using the Smart Lock App example, try to connect risks to CRA essential requirements (from Module 4).

Task: For each risk below, decide which type of CRA requirement it mainly relates to:

1. Risk: Brute‑force attacks against user passwords

• Possible requirement types: secure authentication, security‑by‑default configuration, protection of confidential data.

1. Risk: Replay of captured unlock commands

• Possible requirement types: secure communication, protection against known attack patterns, integrity of commands.

1. Risk: Vulnerable third‑party crypto library

• Possible requirement types: vulnerability handling process, secure update mechanism, use of up‑to‑date components.

In your notes:

• Map each risk to one or more requirement types.
• Write one sentence explaining why you chose that mapping.

This mirrors how manufacturers must show that identified risks are addressed by specific technical and organizational measures required by the CRA.

10. Review Terms

Flip the cards to review key concepts from this module.