AA-sec logo AA-sec
Cyber Resilience Act

Cyber Resilience Act Readiness: A Practical Starting Point for Product Teams

A practical starting point for Cyber Resilience Act readiness, covering product scope, risk assessment, vulnerability handling, evidence, and reporting preparation.

AA-sec5 August 2026
  • Cyber Resilience Act readiness
  • CRA readiness checklist
  • CRA product security requirements
  • CRA reporting obligations
  • secure product lifecycle
AA-sec cover graphic for a practical Cyber Resilience Act readiness guide

Cyber Resilience Act readiness should begin with a controlled product-security operating model, not with a last-minute documentation exercise. Product teams need to know which products are in scope, who owns each obligation, how security risks are assessed, how vulnerabilities are handled, and which evidence proves that these activities occurred throughout the product lifecycle.

Why product teams should start before the main application date

The Cyber Resilience Act applies broadly to hardware and software products with digital elements made available on the EU market. Its main obligations apply from 11 December 2027, while the reporting obligations in Article 14 apply from 11 September 2026. The provisions concerning notification of conformity assessment bodies have applied since 11 June 2026.

These dates create two different preparation horizons. Reporting processes must be operational first. Product design, development, documentation, conformity assessment, and post-market support capabilities must then mature before the full set of obligations applies.

For Austrian manufacturers and software companies, the practical challenge is usually not a single missing document. It is the absence of a connected system linking engineering decisions, product releases, vulnerability records, supplier information, and management accountability. A useful readiness programme therefore treats the regulation as a lifecycle requirement and builds repeatable controls into existing product processes.

1. Establish the product and role boundary

The first task is to determine what is being placed on the EU market and which economic-operator role the organisation performs for that product. The answer affects the applicable responsibilities and the evidence that must be retained.

Create an inventory that records at least:

  • the commercial product name and version family;
  • the hardware, firmware, software, cloud, and mobile components that form the product;
  • separately distributed components and libraries;
  • the legal entity placing the product on the market;
  • the manufacturer, importer, distributor, or open-source software steward role;
  • intended purpose, reasonably foreseeable use, and supported deployment environments;
  • markets in which the product is made available;
  • the planned support period and end-of-support conditions.

The product boundary must be specific enough for engineering teams to identify which repositories, build pipelines, binaries, services, and supplier components belong to a release. A marketing-level product description is not sufficient for vulnerability analysis or technical documentation.

Teams should also define how they will recognise a substantial modification. The Commission guidance published on 27 July 2026 provides practical clarification on scope, substantial modification, support periods, reporting, and risk assessment. Product governance should use that guidance as an input when defining change-control criteria.

2. Make the cybersecurity risk assessment operational

The regulation requires manufacturers to perform and document a cybersecurity risk assessment for a product with digital elements. This assessment should not be a one-time spreadsheet completed shortly before release. It needs to influence requirements, architecture, implementation, verification, vulnerability handling, and support planning.

A practical assessment process should connect:

  1. product assets and security objectives;
  2. threat scenarios and misuse cases;
  3. exposed interfaces and trust boundaries;
  4. third-party and open-source dependencies;
  5. identified risks and treatment decisions;
  6. security requirements and verification evidence;
  7. accepted residual risks and accountable approval;
  8. changes that require reassessment.

Map the resulting controls to the applicable essential cybersecurity requirements in Annex I of the regulation. This creates traceability between a legal requirement, the engineering control that addresses it, and the evidence generated by implementation and testing.

The risk assessment should be versioned with the product. When architecture, intended purpose, dependencies, connectivity, or deployment assumptions change, teams need a defined trigger for review. This prevents the assessment from becoming disconnected from the product that is actually released.

3. Build a vulnerability-handling operating model

Vulnerability handling is one of the most time-sensitive parts of Cyber Resilience Act readiness. It requires more than a security mailbox. The organisation needs an end-to-end process that can receive a report, establish whether a product is affected, assess severity and exploitation status, coordinate remediation, make reporting decisions, communicate with affected parties, and retain evidence.

Define the following capabilities before they are needed during an incident:

  • a monitored vulnerability intake channel;
  • ownership and escalation paths for each product;
  • a consistent triage and severity method;
  • access to product versions, SBOMs, and deployment information;
  • criteria for actively exploited vulnerabilities and severe incidents;
  • legal, security, engineering, communications, and management decision roles;
  • remediation, verification, release, and customer-notification workflows;
  • coordinated vulnerability disclosure procedures;
  • records of facts, timestamps, decisions, approvals, and submitted notifications.

From 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements. ENISA is establishing the Single Reporting Platform as the central electronic system for these notifications. A team should not wait for a reportable event to decide who can submit, who approves the information, or how the necessary facts are collected.

Run a tabletop exercise using a realistic scenario. For example, assume that a critical library in a supported product is being actively exploited. Measure how long it takes to identify affected versions, confirm exposure, contact responsible decision-makers, prepare a notification, produce a fix, and preserve the complete event record. The gaps found in this exercise are concrete backlog items.

4. Use the SBOM as operational product data

A software bill of materials is valuable only when it is accurate, release-specific, and connected to vulnerability response. Generating an SBOM file during a build is a starting point, not the completed control.

An effective SBOM process should answer:

  • which components are included in a specific released version;
  • where each component came from;
  • which version and identifiers can be used for vulnerability matching;
  • whether the component was modified or built from source;
  • which licence and supplier information is available;
  • which products and customers may be affected by a new vulnerability;
  • whether the SBOM can be reproduced from the release pipeline.

Product teams should define a canonical component identity model and validate generated SBOMs for completeness and consistency. Dependency data from package managers alone may omit vendored code, firmware blobs, operating-system packages, generated components, or manually integrated libraries.

Store the SBOM together with the release evidence. When a vulnerability is disclosed, the response team should be able to query the relevant product versions immediately rather than reconstructing dependency information under time pressure.

5. Build evidence into normal engineering work

The strongest compliance evidence is produced as a by-product of controlled engineering processes. Manual evidence collection after the fact is expensive and often incomplete.

For each product release, retain a coherent evidence package containing items such as:

  • approved product and security requirements;
  • the current cybersecurity risk assessment;
  • architecture and threat-modelling outputs;
  • source and dependency provenance;
  • the release-specific SBOM;
  • security test results and resolved findings;
  • vulnerability-treatment decisions;
  • build, signing, and release records;
  • known limitations and user security information;
  • support-period and update commitments;
  • approval of residual risks and release readiness.

Evidence should have an owner, creation source, timestamp, product version, retention rule, and integrity protection. A folder containing screenshots and unrelated documents is difficult to maintain and difficult to defend. Structured links between requirements, controls, findings, decisions, and releases provide much stronger traceability.

Automation can reduce the burden. CI/CD pipelines can capture build metadata, SBOMs, test results, artefact hashes, signatures, and release approvals. Vulnerability-management systems can preserve triage and remediation history. The important point is that evidence remains understandable and attributable after staff, tools, or product versions change.

6. Introduce a CRA-aware release gate

A release gate converts policy into an operational decision. It should identify the minimum security and evidence conditions that must be satisfied before a product version is made available.

A practical gate may verify that:

  • the product scope and intended purpose are current;
  • the risk assessment reflects the release;
  • applicable security requirements have verification evidence;
  • critical vulnerabilities have been resolved or formally assessed;
  • the SBOM has been generated and validated;
  • user-facing security and update information is ready;
  • support and vulnerability-response ownership is assigned;
  • required technical documentation is complete;
  • exceptions and residual risks have accountable approval.

The gate should distinguish between an automated check and a decision requiring human accountability. A missing SBOM can be detected automatically. Acceptance of a residual product risk normally requires an authorised decision with documented reasoning.

7. Execute a focused 90-day readiness plan

A compact first implementation can deliver meaningful progress without attempting to solve every conformity question at once.

Days 1–30: establish control

  • appoint a responsible owner and cross-functional working group;
  • create the product and role inventory;
  • identify products affected by the September 2026 reporting date;
  • document the current vulnerability process and escalation path;
  • map repositories, build pipelines, release artefacts, and dependency sources;
  • select one representative product for the pilot.

Days 31–60: connect engineering and evidence

  • perform or update the pilot product risk assessment;
  • map Annex I requirements to engineering controls;
  • generate and validate a release-specific SBOM;
  • define the evidence package and retention model;
  • establish vulnerability decision records and reporting ownership;
  • add initial automated release checks.

Days 61–90: test the operating model

  • run a vulnerability-reporting tabletop exercise;
  • execute the CRA-aware release gate on a real or rehearsal release;
  • record gaps, owners, priorities, and target dates;
  • extend the model to the next product family;
  • establish management reporting for unresolved readiness risks.

Common implementation mistakes

Several patterns create activity without durable readiness:

  • treating the CRA as a documentation project owned only by legal or compliance teams;
  • creating an SBOM that cannot be linked to released product versions;
  • performing a risk assessment that does not influence engineering work;
  • relying on informal vulnerability decisions made in chat or email;
  • collecting evidence manually shortly before an audit or market launch;
  • assuming the 2027 date means reporting preparation can wait;
  • applying identical controls to every product without considering risk and intended use.

The corrective principle is consistent: connect obligations to product ownership, engineering controls, and verifiable evidence.

What good readiness looks like

A mature product team can identify the applicable product scope, retrieve the evidence for a specific release, explain how cybersecurity risks were treated, locate affected versions when a vulnerability emerges, and execute reporting and remediation workflows within defined timelines. Management can see unresolved risks and accountable owners without requesting a manual reconstruction.

Cyber Resilience Act readiness is therefore best managed as a product-security capability. Starting with one representative product, proving the workflow, and then scaling a common evidence model across the portfolio is usually more effective than producing disconnected documents for every product at once.

Official sources