Cyber Resilience Act (CRA) readiness for digital products

The Cyber Resilience Act (CRA) is not finished when a requirement is added to a spreadsheet. A product team needs to know which product the requirement applies to, who owns the work, when it is due, why a decision was made and where the evidence can be found.

CRA reporting obligations have applied since 11 September 2026. The main body of the Regulation will apply from 11 December 2027. Some of the operating model therefore has to work now, while the rest should be built early enough that technical documentation does not have to be reconstructed at the end.

Key CRA dates

Date	What changes
11 September 2026	Article 14 reporting obligations apply
11 December 2027	the main CRA obligations apply

For reportable events, the clock starts when the manufacturer becomes aware. The Commission describes an early warning within 24 hours and a full notification within 72 hours. The final-report deadline differs between an actively exploited vulnerability and a severe incident.

See the practical CRA 24/72-hour reporting workflow

CRA is about a product, not an abstract company-wide compliance score

The first useful question is: which specific product with digital elements are we assessing?

The Regulation covers software and hardware products and, under defined conditions, their remote data processing solutions. The role of the organisation also matters: manufacturer, authorised representative, importer, distributor or an actor making a substantial modification.

Start with a record for one product:

product name and unique identifier;
version or release family;
manufacturer and the brand under which the product is made available;
how it is made available on the EU market;
intended purpose and main functions;
components and dependencies;
remote services required for product functions;
support period;
people responsible for product security, vulnerabilities and releases.

Check how to assess CRA scope for a product

Seven areas that need to connect

1. Scope

Determine whether the product and the organisation’s role fall within the CRA. A label such as “SaaS”, “IoT” or “software” is not a scope assessment.

2. Product risk

CRA requirements are linked to a cybersecurity risk assessment for the product. That assessment should stay tied to a product version and be reviewed when architecture, intended purpose or risk changes.

3. Security by design and by default

A requirement needs to become engineering work: a design decision, action, owner, test, review and evidence.

Go to security by design under the CRA

4. Vulnerabilities and SBOM

The CRA requires manufacturers to identify and document vulnerabilities and product components, including by drawing up a Software Bill of Materials (SBOM) in a commonly used, machine-readable format covering at least top-level dependencies.

See why an SBOM is a process input, not the end result

5. Reporting

The CRA Single Reporting Platform (SRP) has been operational since 11 September 2026. In practice, a manufacturer needs more than portal access: a clear T0, escalation criteria, an accountable owner, backup coverage and the information required to submit a notification.

6. Technical documentation

Technical documentation should not be an archive of disconnected files. It needs to make the product, version, architecture, risk assessment, vulnerability handling, tests, decisions and support-period basis traceable.

See a practical CRA technical-documentation structure

7. Support period

The manufacturer determines a support period based on expected use and the criteria set out in the CRA. As a general rule it is at least five years, unless the product is expected to be used for a shorter period.

See how to document the support period

Where smaller organisations struggle

ENISA’s 2026 SME CRA survey illustrates the gap between awareness and execution. In a voluntary sample of 194 responses, 66% were aware of the CRA, while 54% reported limited or no knowledge of conformity assessment and 42% reported limited or no knowledge of required documentation. Technical-documentation support was selected by 73% of respondents.

The survey should not be treated as a representative estimate of the whole EU market: it is a small, voluntary sample. It is still useful as a signal that the problem is not simply “knowing that CRA exists”. Teams need repeatable operating processes.

Where Pulsar GRC fits

Pulsar GRC connects work that is often spread across documents, spreadsheets, tickets and email:

requirement → risk → control or action → owner → due date → document or evidence → review → decision history.

The current product repository confirms areas including audits, controls, risks, documents, evidence, reports and exports, CAPA, vendors, tasks and notifications, and analysis history. That is useful for operating and evidencing a process without pretending the software makes the legal determination for the customer.

Pulsar does not certify CRA compliance, replace legal assessment or autonomously decide whether an event must be reported. Scope decisions, regulatory classification and the decision to submit remain with accountable people.

Start with one product

Do not begin with a programme called “implement CRA across the entire company”. Pick one real product. Define its scope, owners, current risks, vulnerability workflow, documentation and support period. That is where the actionable gaps become visible.

See Pulsar GRC on one operating workflow

Sources

Sources checked: 12 September 2026.