Module 8: Technical Documentation, SBOM, and Transparency Duties

Module 8 Overview: Why Documentation and Transparency Matter under the CRA

In the EU Cyber Resilience Act (CRA), technical documentation, SBOMs, and user-facing transparency are not optional paperwork – they are core compliance duties.

In this module you will learn:

• What technical documentation manufacturers must keep for CRA compliance (aligned with the final CRA text as politically agreed in 2024).
• How to document security-by-design, risk assessment, and testing.
• How to structure a Software Bill of Materials (SBOM) in a CRA-friendly way.
• What security information must be given to users, including end-of-support and update information.
• How this links back to vulnerability management (Module 6) and incident/vulnerability reporting (Module 7).

Think of this module as answering two big questions:

1. What must we document and keep on file for authorities?
2. What must we clearly tell users about the product’s security and lifecycle?

We will move step-by-step from internal documentation → SBOM → user-facing information.

Step 1 – CRA Technical Documentation: The Big Picture

Under the CRA, manufacturers must create and keep technical documentation that:

1. Demonstrates conformity with CRA essential cybersecurity requirements.
2. Is kept up to date throughout the product’s lifecycle (including updates and patches).
3. Is available to market surveillance authorities on request (e.g., national competent authorities, not ENISA directly).

At a high level, your CRA technical documentation should cover:

• Product description
• Intended purpose and use cases
• Target users (e.g., consumer, enterprise, industrial)
• Network and data environment (cloud, on‑prem, hybrid)

• Design and architecture
• System architecture diagrams
• Data flows (what data is collected, processed, transmitted, stored)
• Trust boundaries (e.g., between client and server, internal microservices)

• Security-by-design and by-default measures
• Access control model, authentication, encryption, logging
• Secure update mechanism
• Default configurations and why they are secure

• Risk assessment and mitigation (we detail this in Step 3)

• Testing and validation evidence
• Security testing strategy and results (Step 4)

• Vulnerability handling and update processes
• How you monitor and fix vulnerabilities (ties to Module 6)
• Links to your incident and vulnerability reporting process (Module 7)

This documentation is not usually given to end users; it is an internal compliance file that proves you meet the CRA.

Step 2 – Map Your Product: Quick Thought Exercise

Imagine you are documenting a cloud-connected password manager app for CRA compliance.

Task: In your notes, list at least 3 items you would include under each heading below:

1. Product Description

• Example prompts: What platforms does it run on? Who uses it? What data does it handle?

1. Architecture & Data Flows

• Example prompts: Where is data stored? How does the app talk to the cloud? Any third‑party services?

1. Security-by-Design Measures

• Example prompts: How is data encrypted? How are users authenticated? What are the secure defaults?

After you draft your list, check yourself:

• Did you clearly identify what the product does and who it’s for?
• Did you mention at least one data store and one communication channel?
• Did you specify at least two concrete security measures (e.g., `TLS 1.3`, `PBKDF2 password hashing`, `MFA`)?

This is exactly the kind of information that will populate the technical file for CRA.

Step 3 – Risk Assessment and Mitigation Documentation

The CRA requires manufacturers to identify, assess, and treat risks related to cybersecurity and to keep documentation of this process.

Your risk documentation should include:

1. Threat and asset identification

• What needs protection? (e.g., credentials, personal data, control commands)
• What are plausible threats? (e.g., credential theft, remote code execution, data exfiltration)

1. Risk analysis

• For each threat, estimate likelihood and impact.
• Note dependencies on third‑party components and open‑source libraries.

1. Risk evaluation and prioritization

• Decide which risks are unacceptable and must be mitigated.
• Document the reasoning (e.g., high impact on safety, legal obligations like GDPR).

1. Risk treatment / mitigation measures

• Technical controls (e.g., input validation, sandboxing, rate limiting).
• Organizational controls (e.g., secure coding guidelines, code review policies).
• Residual risks that cannot be fully removed and must be communicated to users.

1. Link to lifecycle updates

• How new vulnerabilities (e.g., in a library) trigger a risk reassessment.
• How you update the risk file when architectural changes are made.

Retention: CRA expects that this documentation is retained for a defined period after the product is placed on the market (the final CRA text aligns this with typical EU product legislation practice – often 10 years as a baseline reference). Always check the final adopted CRA text and any delegated acts for the exact retention period.

In practice, this looks like a living document (or set of documents) that evolves with new versions, patches, and discovered vulnerabilities.

Step 4 – Quick Check: Risk Documentation

Test your understanding of CRA risk documentation duties.

Step 5 – Security Testing and Validation Evidence

To prove conformity with CRA security requirements, manufacturers must document how they verified security properties.

Your testing documentation should include:

1. Testing strategy

• Types of tests: unit, integration, system, security-specific tests (e.g., fuzzing, penetration testing, SAST/DAST).
• Scope: what components and interfaces were tested.

1. Test procedures and tools

• How tests were run (manual vs automated).
• Tools used (e.g., `OWASP ZAP`, `Burp Suite`, `Snyk`, `GitHub Dependabot`).

1. Results and follow-up

• Summary of findings, their severity, and how they were fixed.
• Justification for any issues not fully fixed (residual risks).

1. Regression and update testing

• How you test security after updates or patches.
• Links to your continuous monitoring process (Module 6).

In CRA terms, this documentation shows that you did not just design secure features, but also verified that they work in practice.

Step 6 – SBOM under the CRA: Purpose and Core Elements

A Software Bill of Materials (SBOM) is a structured list of all software components in your product, including open-source and third‑party parts. The CRA pushes for SBOMs because authorities and users need visibility into what is inside a product to assess vulnerabilities.

While the CRA does not hard-code one global SBOM format, it aligns with international practice (e.g., SPDX, CycloneDX) and expects SBOMs to be:

• Machine-readable and structured.
• Up to date with each significant release.
• Linked to your vulnerability management process.

A CRA-aligned SBOM typically includes for each component:

• Component name (e.g., `OpenSSL`)
• Version (e.g., `3.0.13`)
• Supplier/author (e.g., `OpenSSL Software Foundation`)
• License information (e.g., `Apache-2.0`)
• Component type (library, framework, OS package, container image, etc.)
• Unique identifiers (e.g., Package URL `purl`, or identifiers from NVD/CPE if available)
• Dependency relationships (e.g., component A depends on B)

CRA-relevant uses of SBOM:

• Faster identification of affected products when a new vulnerability appears.
• Evidence that you know your supply chain and manage third‑party risks.
• Basis for user-facing security communication, when appropriate.

Historically, SBOMs were voluntary or sector-specific. Under the CRA, they become a mainstream expectation for digital products in the EU.

Step 7 – Example SBOM Snippet (CycloneDX-style JSON)

Below is a simplified CycloneDX-style SBOM snippet for a web application. This illustrates how to structure SBOM data that would support CRA transparency.

Step 8 – SBOM Structure Check

Review the SBOM snippet from the previous step, then answer:

Step 9 – User-Facing Information: Instructions, Security, and End-of-Support

The CRA requires manufacturers to provide clear, understandable information to users, not just to authorities. This includes:

1. User instructions and security configuration guidance

• How to install and configure the product securely.
• Default settings, and which settings users should not weaken (e.g., disabling encryption).
• How to manage user accounts, roles, and permissions.

1. Update and vulnerability information

• How security updates are delivered (automatic vs manual).
• Expected timeframe for providing security updates (minimum support period).
• How users will be notified about critical vulnerabilities and patches.

1. End-of-support (EoS) / End-of-life (EoL) information

• The date or conditions when security support will end.
• What risks arise after EoS (e.g., no more patches).
• Recommended actions (e.g., upgrade path, migration options).

1. Residual risk disclosure

• Any known limitations that cannot be fully mitigated (e.g., product not designed for highly classified data).
• Clear explanations in non-technical language.

These transparency duties link directly to your technical documentation:

• Risk assessment → explains what residual risks must be shared.
• SBOM and vulnerability management → explain why updates matter and when users are affected.
• Incident reporting (Module 7) → serious incidents may trigger user notifications about new risks.

Always check the final CRA text and any guidance from the European Commission or ENISA for specific wording and presentation expectations, especially regarding consumer-facing products.

Step 10 – Draft a CRA-Compliant End-of-Support Notice

Imagine you are the manufacturer of a home Wi‑Fi router covered by the CRA.

Task: Draft a short end-of-support (EoS) notice (3–5 sentences) that you would show to users in the admin interface.

Your notice should:

1. Clearly state when security updates will stop.
2. Explain what this means for the user’s security.
3. Recommend what the user should do.

Use this structure as a guide:

• Sentence 1: Product and EoS date (e.g., Security support for [Product] will end on [date].)
• Sentence 2–3: Impact (e.g., After this date, we will no longer provide security patches, which may increase your risk…)
• Sentence 4–5: Recommendation (e.g., We recommend upgrading to… or replacing the device by…)

When you are done, check:

• Is the language understandable for a non‑expert home user?
• Is the date/condition of support ending explicit?
• Does it clearly link EoS to cybersecurity risk, not just feature updates?

Step 11 – Key Term Review

Flip the cards (mentally) to review key CRA documentation and transparency concepts.