Your first step towards CRA compliance

CRA gap analysis

CRA gap analysis: where do your products stand under the Cyber Resilience Act?

The initial assessment is a clearly bounded first engagement. It records your products, gives a technical assessment of which fall under the CRA and in which role you act, and measures how far each product is from the requirements. It ends with a prioritised action plan you can base budget and deadlines on.

Request a gap analysis Check scope first

What the gap analysis (CRA readiness assessment) looks into

Which products and variants have digital elements and are made available on the EU market? Are you the manufacturer, importer or distributor, and what applies to software you supply to other companies? Which products are listed in Annex III or IV, and which conformity assessment route follows from that? On scope, role and product class we provide the technical assessment; the legal decision rests with your legal department or counsel.

For the products in scope we assess what is already met and evidenced of the Annex I requirements, the Article 14 reporting obligation and the other manufacturer obligations. The reporting obligation has applied since 11 September 2026 and is therefore rated separately; the other obligations apply from 11 December 2027.

What we look at

Four blocks, worked through with your teams in a workshop and then checked against code, documents and tools.

Block 1: products, roles, classes

Product inventory with variants, role per product, suppliers and integrated components, product class under Annex III and IV, exemptions and the boundary to other legislation.

Block 2: security requirements

Annex I Part I: the general principle and the individual requirements, such as secure default configuration, protection against unauthorised access and security updates. Plus the risk assessment that everything else builds on.

Block 3: vulnerabilities and reporting

Annex I Part II with the software bill of materials, vulnerability handling and coordinated disclosure, due diligence for third-party components under Article 13(5) and (6), and the Article 14 reporting chain with thresholds, deadlines and recipients.

Block 4: documentation and conformity

Technical documentation under Annex VII, user information under Annex II, support period, conformity assessment, EU declaration of conformity and CE marking.

What you receive

Five results you can use directly for budget, planning and conversations with your customers.

01
Product register
Draft with technical assessment: which products, which role, in scope or not, with the facts it is based on.
02
Class and route
Technical assessment of the product class and the conformity assessment route per product, for confirmation by your legal department or counsel.
03
Gap report per product
Against Annex I and the other manufacturer obligations, every finding rated in a traceable way.
04
Action plan
Prioritised, with effort and date per action and open questions.
05
Reporting process review
Your readiness under Article 14, shown separately because this obligation already applies.

What an entry in the gap report looks like

For illustration, three rows for a fictitious connected device. Each finding names the requirement, the observation, the rating and the action.

Requirement	Finding	Rating	Action	Priority
Art. 14 reporting obligation	Vulnerabilities are fixed, but no reporting path with deadlines and deputies is defined.	Gap	Runbook, roles with deputies, decision aid "actively exploited?"	Immediate
Annex I Part II(1): software bill of materials	SBOM is created manually on request, not per release.	Partial	SBOM generation in the build pipeline, stored per release	High
Art. 13(2) and (3): risk assessment	Security reviews take place, but no product-specific risk assessment is documented.	Evidence missing	Create threat model and risk assessment for Annex VII	High

Fictitious example to illustrate the format, not a client result.

How the assessment runs

Five steps from kick-off to the closing meeting.

1
Kick-off
Scope, reference products, access and contacts. Goal of the session: draft product list and roles as a working hypothesis.
2
Review
Code, build, architecture and existing documents, preferably on your infrastructure with read access.
3
Interviews
Focused sessions with development and operations on the points the documents do not settle.
4
Gap report
Rating per product on one consistent scale, with evidence and actions.
5
Close
Joint walk-through of the action plan. You then decide what comes next.

The duration depends on the number of products and variants. We plan it with fixed dates at the kick-off.

How we rate

One scale for all products, separated into obligations that apply today and those that apply later.

Met and evidenced

Evidence exists, is current and has been checked by sampling.

Evidence missing

Technically in place but not auditable. Counts as a gap.

Partial

Implemented for some releases or variants only.

Gap

Not implemented; action with effort and date.

Open

Not yet clarified; with owner and date.

Not applicable

Only with a documented basis.

Priority: acute risks and the Article 14 reporting obligation first, then lead time for third-party assessments, then customer requirements.

What we need from you

Contacts

One person from development per product.

Read access

Code, build and architecture, preferably on your infrastructure.

Tools

Read access to your vulnerability tools.

Existing evidence

Certificates, policies, customer requirements.

Decision path

Who settles legal questions and approves results.

Feedback

Prompt responses to drafts so the plan holds.

What the gap analysis is not

The assessment is a first, reliable baseline. Deliberately not included:

No legal services: questions that need a legal decision are flagged, with the technical basis, for review by your legal department or counsel.
No notified body, no declaration of conformity, no certificate.
No comprehensive technical product testing and no penetration tests.
No notifications on your behalf and no changes to your code.

What follows the gap analysis is your decision. We can support the implementation, but it is not part of this engagement.

Frequently asked questions

How is this different from the free scope check?+

The check gives you a first, schematic orientation for products like yours in a few minutes. The gap analysis examines your actual products, documents and processes and delivers a gap report with an action plan.

Who should attend the workshop?+

One person from development per product, plus someone from product management or quality and, where they exist, the people responsible for information security and for vulnerability reporting.

Which documents do you need?+

A product list if one exists, architecture documents, read access to code and build, existing certificates and policies, and your customers' CRA requirements. Anything missing is captured at the kick-off.

How long does the gap analysis take?+

It depends on the number of products and variants. We recommend starting with two or three reference products; the method then carries over to the others. We fix the schedule with dates at the kick-off.

What does the gap analysis cost?+

After a free initial call you receive a proposal with a clearly defined scope. The effort depends on the number of products and the state of your evidence.

How does the gap analysis relate to ISO/IEC 27001 and IEC 62443?+

Existing certifications and processes are taken into account. We map the CRA requirements onto your existing practices and only assess what is missing at product level.

Request a gap analysis

Tell us about your products and deadlines. The initial call is free and without obligation; we usually reply within one to two working days with a proposal for the kick-off.

Request a gap analysis All services