CRA topic guide

Secure software development under the CRA

Last updated · 8 Jun 2026

The CRA expects security to run through your whole software development lifecycle - from design and coding to testing, release and ongoing maintenance. It combines the Annex I product requirements with continuous vulnerability handling, so a secure product stays secure across its support period.

TL;DR

  • A secure software development lifecycle (SDLC) is implied throughout the CRA's essential requirements.
  • You must handle vulnerabilities continuously - not just ship and forget.
  • Free security updates are required during the support period (presumed at least five years).
  • The whole process must be documented in the technical documentation.
Get the CRA ChecklistCheck if you are in scope

Overview

What it is

Secure software development means embedding security activities into every phase of building software: threat modelling and a risk assessment up front; secure coding and dependency management during development; security testing before release; and vulnerability monitoring, patching and disclosure after release. The CRA turns this from best practice into a legal expectation by pairing the Annex I, Part I product properties with the Annex I, Part II vulnerability-handling duties that continue for the life of the product.

The regulation

What the CRA requires

  • Manufacturers must perform a cybersecurity risk assessment and apply its results across design, development, production, delivery and maintenance (Art. 13).
  • Annex I, Part II requires ongoing vulnerability handling: identify and document vulnerabilities (incl. an SBOM), remediate without delay, and provide free security updates during the support period.
  • A coordinated vulnerability disclosure policy and a reporting contact point are mandatory.
  • Manufacturers must provide security updates separately from functionality updates where feasible, so users can patch without changing behaviour.

How to comply

How to comply

  1. Adopt a documented secure SDLC (e.g. aligned to recognised secure-development frameworks).
  2. Threat-model and risk-assess before you build; feed results into requirements and tests.
  3. Manage dependencies actively: maintain an SBOM and monitor it for new vulnerabilities.
  4. Run security testing (SAST/DAST, dependency and secret scanning) in your pipeline.
  5. Stand up a vulnerability-handling process with SLAs and a CVD policy before release.
  6. Commit to free security updates across a clearly stated support period.

Watch out

Common mistakes

  • Bolting security testing on at the very end instead of throughout the pipeline.
  • Having no process to receive and triage externally reported vulnerabilities.
  • Bundling security fixes inside large feature releases users may delay or skip.
  • Failing to define and honour a support period for security updates.

FAQ

Common questions

Does the CRA mandate a specific SDLC standard?
No single standard is named, but harmonised standards are being developed that will confer a presumption of conformity. Aligning to recognised secure-development frameworks now is the safest path.
How long must I provide security updates?
For the support period, which should reflect how long the product is reasonably used and is presumed to be at least five years unless shorter use is expected.
Do reporting duties start before full compliance?
Yes. The vulnerability and incident reporting obligations apply from 11 September 2026 - over a year before the rest of the CRA - so your handling process must be ready first.

Related guides

More CRA topic guides

SBOM

SBOM (Software Bill of Materials) under the CRA

An SBOM is an "ingredients label" for your software: a machine-readable inventory of components and dependencies.

Security by design

Security by design under the CRA

Security by design means building in security from the first design decision, proportionate to the product's risk.

Secure by default

Secure by default under the CRA

Secure by default means the out-of-the-box configuration is the safe configuration.

Back to the CRA overview or see all guides.

This is guidance, not legal advice

This guide explains how the Cyber Resilience Act approaches secure software development, but it is not legal advice. For decisions specific to your business or product, confirm with the official sources we link or a qualified adviser.

Sources

  1. [1]European Commission - CRA legislative summaryretrieved 8 Jun 2026
  2. [2]European Commission - CRA reporting obligationsretrieved 8 Jun 2026
  3. [3]Regulation (EU) 2024/2847 - full text (EUR-Lex)retrieved 8 Jun 2026

The CRA Brief

Stay current on CRA guidance

We watch Brussels so you don't. Plain-English CRA updates, free.

No spam. Unsubscribe anytime.