Cyber Resilience Act (CRA): Product & Software Engineering

Purpose

This document explains how Thinkwerke interprets and implements the EU Cyber Resilience Act (CRA) for software products and vendor-hosted digital services.

The focus is on engineering secure-by-design products, establishing defensible vulnerability handling, and producing continuous, audit-ready evidence.

—

What the CRA Actually Targets

The CRA applies to products with digital elements, including:

  • Software products

  • Cloud-hosted platforms and services

  • Embedded and connected systems

  • Products distributed to EU markets

Its intent is to ensure that security is built into products throughout their lifecycle, not added post-release.

—

Core CRA Expectations

CRA introduces explicit expectations around:

  • Secure development practices

  • Vulnerability management

  • Software supply-chain transparency

  • Timely remediation and disclosure

  • Accountability of manufacturers and vendors

These expectations directly affect engineering teams.

—

Common Failure Patterns

CRA initiatives often stall because:

  • Security is treated as a legal requirement only

  • SBOMs are generated but not governed

  • Vulnerability handling lacks ownership and SLAs

  • CI/CD pipelines are excluded from compliance scope

  • Evidence cannot be produced consistently

Thinkwerke addresses CRA at system-design level.

—

Thinkwerke Implementation Model

CRA compliance is implemented across four layers:

  1. Secure software lifecycle (SSLM)

  2. Vulnerability intake, triage, and remediation

  3. Supply-chain governance (SBOM & OSS)

  4. Continuous evidence and reporting

Each layer is traceable and auditable.

—

Secure Software Lifecycle (SSLM)

CRA-aligned SSLM includes:

  • Secure CI/CD pipelines

  • Static, dynamic, and dependency analysis

  • Artifact integrity and provenance

  • Policy enforcement before release

Security controls are embedded where code is built and shipped.

—

Vulnerability Handling

CRA-compliant vulnerability management includes:

  • Centralised intake of vulnerabilities

  • Ownership and severity-based SLAs

  • Engineering workflows (e.g. issue tracking)

  • Verification of remediation

  • Evidence of timelines and actions

This applies to both internally found and externally reported issues.

—

Software Supply-Chain Governance

CRA requires visibility and control over dependencies.

Thinkwerke implementations include:

  • SBOM generation and versioning

  • OSS license identification and tracking

  • Risk classification of components

  • Change impact visibility across releases

SBOMs are treated as living artefacts, not static exports.

—

Vendor-Hosted Responsibility

For cloud-hosted products, CRA responsibilities extend beyond code:

  • Platform security configurations

  • Runtime monitoring

  • Incident handling

  • Patch and update processes

Shared responsibility models are documented and evidenced.

—

Evidence and Audit Readiness

CRA evidence is generated continuously via:

  • CI/CD execution logs

  • Vulnerability workflow records

  • SBOM history and approvals

  • Release and change records

This supports regulatory review, customer assurance, and market access.

—

Relationship to Other Frameworks

CRA overlaps with:

  • ISO 27001 technical controls

  • NIS2 operational resilience requirements

  • Customer security assessments

See also:

—

Key Takeaway

CRA compliance is achieved by engineering discipline, not paperwork.

When secure development, vulnerability handling, and supply-chain governance are built into delivery, CRA becomes sustainable and provable.