Module 12: Building a CRA Compliance Roadmap for Software Organizations

Step 1 – Where Are We in the CRA Timeline?

Before building a roadmap, you need to understand what you are planning for and by when.

Current CRA status (as of late 2024)

• The EU Cyber Resilience Act (CRA) has been politically agreed and is in the final stages of formal adoption.
• It will be an EU Regulation (directly applicable in all Member States), not a directive.
• There will be two key time horizons (exact dates will depend on the final publication date in the Official Journal):

1. Early vulnerability and incident reporting obligations – expected to apply earlier (around 2026; many drafts refer to ~36 months for full application but an earlier start for reporting duties). Your roadmap must ensure you can receive, triage, and report vulnerabilities by this date.
2. Full CRA applicability – most other obligations (design, development, documentation, conformity assessment, CE marking) will apply later (around 2027).

In this module, we will assume:

• Early reporting readiness target: September 2026 (for planning purposes).
• Full CRA compliance target: 2027 (for planning purposes).

Your roadmap should:

• Work backwards from these dates.
• Prioritize vulnerability and incident reporting capabilities first.
• Then expand to full product and process alignment with the CRA.

> Throughout, remember that the CRA interacts with other EU laws like the NIS2 Directive, the General Product Safety Regulation, and sectoral rules. Your roadmap should avoid creating conflicting processes.

Step 2 – Define Your CRA Scope: Products, Roles, and Risk

A roadmap only makes sense if you know what it covers. Under the CRA, your obligations depend on:

1. Which products are in scope

• CRA applies to products with digital elements (PDEs), including software-only products and software embedded in hardware.
• Some products may fall into higher-risk classes (e.g., products with critical security functions, components used in critical infrastructure). These can trigger stricter conformity assessment routes.

1. What role your organization plays (from previous modules):

• Manufacturer (main focus of this module): entity that develops or has a product designed or manufactured and markets it under its name or trademark.
• Importer / Distributor: additional obligations when you place third‑country products on the EU market or distribute them.
• Authorized representative (if used).

1. Where products are in their lifecycle

• Newly developed products (still in design or development).
• Existing products currently on the market.
• Legacy products close to end-of-support.

Mini-framework: CRA Scope Inventory

Create a simple table or spreadsheet with columns such as:

| Product | Type (SaaS, on‑prem, embedded) | CRA Risk Class | Role (M/I/D) | Market (EU? Global?) | Lifecycle Stage | Critical Dependencies |

|--------|---------------------------------|----------------|--------------|----------------------|-----------------|-----------------------|

| SecureCloud X | SaaS | Higher risk (handles credentials) | Manufacturer | EU + global | In operation | Open-source auth lib, cloud provider Y |

This scope inventory will drive priorities and phasing in your roadmap.

Step 3 – Quick Scope Exercise

Imagine you work at a mid-sized software company with this portfolio:

1. A mobile banking app used by EU banks.
2. A developer tool plugin for popular IDEs, used worldwide.
3. An IoT gateway firmware sold to EU energy utilities.

Task:

1. For each product, jot down:

• Whether it is clearly in scope of the CRA.
• Whether it is likely higher risk (due to handling sensitive data, critical infrastructure, or security functions).

1. Decide which product you would prioritize for CRA alignment in 2025–2026 and why.

Reflect:

• How do critical infrastructure customers or security functionality affect your prioritization?
• How might your answer change if the plugin is widely used in safety‑critical development?

(You do not need to submit anything; this is to train your reasoning about scope and prioritization.)

Step 4 – Gap Analysis Against CRA Requirements

Now that you know what is in scope, you need to see how far you are from CRA expectations. This is called a gap analysis.

4.1. Build a CRA control checklist

Use the CRA’s requirements (especially the essential cybersecurity requirements and vulnerability handling obligations) and group them into practical domains, for example:

1. Secure design & development

• Threat modelling, secure coding practices, code review, dependency management.

1. Vulnerability handling & incident reporting

• Processes to receive reports, coordinate disclosure, patch, and notify authorities/users.

1. Post-market monitoring & updates

• Monitoring for new vulnerabilities, providing security updates over the product’s expected lifetime.

1. Documentation & transparency

• Technical documentation, user-facing security information, SBOM or equivalent component transparency (where applicable).

1. Governance & responsibilities

• Named person or team responsible for CRA compliance, decision-making, records.

1. Supply chain management

• Controls over open-source components, third-party libraries, cloud services, and suppliers.

4.2. Rate current maturity

For each domain, ask:

• Do we already have a process or control? (Yes/No/Partial)
• Is it documented and repeatable?
• Would it stand up to regulator or auditor scrutiny?

Use a simple scale, for example:

• 0 = No control
• 1 = Ad hoc / informal
• 2 = Defined but inconsistently applied
• 3 = Defined and usually followed
• 4 = Measured and improved

This gap analysis becomes the backbone of your roadmap: the bigger the gap and the higher the risk, the earlier you should address it.

Step 5 – Example Gap Analysis for a SaaS Product

Consider a SaaS CRM platform sold to EU customers.

Simplified gap analysis snapshot:

| CRA Domain | Current Practice | Maturity (0–4) | Gap vs. CRA | Priority (High/Med/Low) |

|-----------|------------------|----------------|-------------|-------------------------|

| Secure design & development | Basic code review, no formal threat modelling | 1 | No documented secure SDLC, no formal risk assessment | High |

| Vulnerability handling & reporting | Security@ email monitored by IT; no formal SLA or link to authorities | 1 | CRA requires structured vulnerability handling, timelines, and reporting to CSIRTs/ENISA where applicable | Very High (due to 2026 reporting) |

| Post-market monitoring & updates | Ad hoc monitoring of major CVEs; no formal process | 1 | CRA expects continuous monitoring and timely security updates | High |

| Documentation & transparency | Internal architecture docs; minimal end-user security info | 2 | Need CRA-aligned technical file and user security instructions | Medium |

| Governance & responsibilities | CISO part-time, no CRA owner | 1 | Need clear assignment of manufacturer responsibilities and decision-making | High |

| Supply chain management | Uses open-source libraries; no SBOM; occasional license checks | 1 | CRA expects control over components and their vulnerabilities | High |

From this table, the top early actions are:

• Establish a formal vulnerability handling and reporting process.
• Assign clear CRA governance roles.
• Begin secure SDLC improvements (especially for new releases).

Step 6 – Phase 1 (Now–Mid 2025): Foundations and Governance

Phase 1 focuses on organizational foundations that enable everything else.

6.1. Assign CRA ownership and governance

• Appoint a CRA Program Owner (could be in Security, Product, or Compliance).
• Set up a cross-functional CRA working group with:
• Engineering / DevOps
• Product management
• Legal / Compliance
• Security / CISO team
• Customer support / incident response

6.2. Map CRA into your SDLC and DevSecOps

• Identify where CRA requirements fit into your existing lifecycle:
• Requirements and design (threat modelling, risk classification).
• Implementation (secure coding, dependency management, SAST/DAST tools).
• Testing & release (security gates, pen testing, security sign-off).
• Operations (monitoring, incident response, updates).
• Document a CRA-aware SDLC policy that references these touchpoints.

6.3. Start updating contracts and supply chain controls

(Connecting to Module 10)

• Update supplier and open-source policies to ensure:
• You can obtain security information and timely patches.
• You have rights to distribute updates and provide security support to customers.
• Begin integrating CRA obligations into new contracts with key suppliers.

Deliverables by end of Phase 1:

• Named CRA owner and working group.
• Initial gap analysis and prioritized backlog.
• Draft CRA-aware SDLC policy.
• Plan to update key supplier contracts.

Step 7 – Phase 2 (Mid 2025–Sept 2026): Early Reporting Readiness

Phase 2 aims to ensure you are ready for early vulnerability and incident reporting obligations by September 2026.

7.1. Build a formal vulnerability handling process

• Define how you:

1. Receive vulnerability reports (e.g., security.txt, web form, security email, bug bounty platforms).
2. Acknowledge and triage them (severity scoring, ownership, SLAs).
3. Remediate and release patches.
4. Notify affected customers and, where required, notify authorities/CSIRTs/ENISA within the specified timelines.

• Align this with coordinated vulnerability disclosure (CVD) practices.

7.2. Integrate tooling into DevSecOps

• Add or improve tools that support CRA compliance:
• SCA (Software Composition Analysis) for third‑party and open-source components.
• SAST/DAST/IAST tools for code and application security.
• Issue tracking that tags CRA-relevant vulnerabilities and deadlines.
• Ensure security findings can be traced to products and versions, which is essential for incident reporting.

7.3. Incident response alignment

• Update your incident response plan to:
• Include CRA-related reporting triggers and timelines.
• Clarify roles (who decides if an incident is reportable, who communicates externally).
• Coordinate with NIS2 obligations if your organization is an essential or important entity.

Deliverables by Sept 2026:

• Documented vulnerability handling and disclosure policy.
• Operational intake and triage mechanisms (tested in at least one drill).
• Updated incident response plan with CRA reporting steps.
• Evidence of integrated security tooling in the pipeline.

Step 8 – Quick Check: Early Reporting Priorities

Test your understanding of Phase 2 priorities.

Step 9 – Phase 3 (2026–2027): Full CRA Alignment of SDLC and Products

Once early reporting is under control, expand to full CRA compliance for your product portfolio.

9.1. Embed secure-by-design across SDLC

• Design phase:
• Introduce threat modelling for higher-risk products.
• Classify products according to CRA risk and intended use.
• Development phase:
• Enforce secure coding standards and mandatory security reviews.
• Automate security checks in CI/CD (build fails on severe vulnerabilities).
• Testing & release:
• Plan regular penetration tests for higher-risk products.
• Require a security sign-off before releases.

9.2. Documentation and conformity

• Prepare CRA-aligned technical documentation ("technical file") including:
• Architecture and threat models.
• Security controls implemented.
• Vulnerability handling procedures.
• Evidence from testing and audits.
• For products requiring conformity assessment, determine:
• Whether you can use self-assessment or need a notified body.
• How CRA interacts with existing CE marking (e.g., Radio Equipment Regulation, Machinery Regulation).

9.3. Post-market monitoring and updates

• Define and implement:
• Continuous monitoring for new vulnerabilities (e.g., using vulnerability feeds, vendor advisories).
• Policies for providing security updates over the product’s expected lifetime.
• Criteria for end-of-support and how you inform users.

Deliverables by full applicability (2027):

• CRA-aligned SDLC operational across teams.
• Technical documentation for in-scope products.
• Conformity assessment strategy defined and, where needed, executed.
• Post-market monitoring and update policies in place.

Step 10 – Prioritizing Quick Wins vs. Long-Lead Items

Think about a hypothetical software manufacturer with limited resources.

Quick wins (can start within weeks):

• Create a security@company.com mailbox and basic intake procedure.
• Add a security section to product release checklists.
• Draft a simple vulnerability handling policy and run a tabletop exercise.
• Tag existing Jira issues that are clearly security vulnerabilities.

Long-lead initiatives (months to years):

• Rolling out a secure SDLC across all teams.
• Implementing full SBOM generation and SCA integration for all products.
• Negotiating contract changes with major suppliers and customers.
• Preparing technical documentation and going through a notified body (if required).

Your task:

• Pick two quick wins and two long-lead items you would prioritize in 2025.
• For each, explain in 1–2 sentences:
• Why it matters for CRA.
• What risk it reduces (e.g., enforcement risk, operational risk, reputational risk).

This exercise helps you practice building a phased, risk-based roadmap.

Step 11 – Key Terms Review

Flip the cards (mentally) to review core concepts for building a CRA roadmap.

Step 12 – Staying Up to Date and Final Checklist

Because the CRA is still being finalized and will be supported by implementing acts, harmonized standards, and guidance from expert groups, your roadmap must include ongoing monitoring.

12.1. Monitoring sources

• Official EU sources:
• Publications in the Official Journal of the EU (for final text and dates).
• Updates from ENISA and the European Commission on CRA guidance.
• Standards and best practices:
• Evolving harmonized standards under the CRA (e.g., EN/ISO standards for secure development, vulnerability handling).
• Guidance from industry bodies and national cybersecurity agencies.

12.2. CRA roadmap final checklist

Before you finish this module, ensure your hypothetical (or real) organization has:

1. Scope inventory of CRA-relevant products and roles.
2. Gap analysis with prioritized actions.
3. Phase 1 (Foundations): governance and CRA-aware SDLC plan.
4. Phase 2 (Early reporting): documented vulnerability handling and incident reporting process ready by ~Sept 2026.
5. Phase 3 (Full alignment): secure-by-design SDLC, documentation, conformity assessment, and post-market monitoring.
6. Monitoring plan for evolving CRA standards and guidance.

If you can outline these phases and explain which actions are quick wins versus long-lead initiatives, you have achieved this module’s learning objectives.