Eu Cyber Resilience Act Cra Compliance Services

Scope and evidence must be confirmed before any paid tests or filings.

EU Cyber Resilience Act (CRA) compliance is not a single penetration test or a one-off certificate. For a manufacturer, it is an evidence-and-release process connecting product scope, cybersecurity risk assessment, engineering controls, vulnerability handling, technical documentation, the applicable conformity-assessment route, CE/DoC release controls and post-market reporting.

As of 7 October 2026, the CRA is in a transition phase: manufacturer reporting obligations under Article 14 have applied since 11 September 2026, while the Regulation applies generally from 11 December 2027. A sound project therefore has two tracks: an operational reporting process that works now, and a market-readiness programme that closes product and process evidence before the 2027 application date.

What an end-to-end CRA compliance service should deliver

The service should convert the legal requirements into controlled project outputs. The core deliverable is not a generic opinion; it is a traceable file showing what product and version were assessed, which risks and requirements apply, how each requirement was implemented or justified, what testing supports the conclusion, which conformity route was used, and what must continue after release.

The manufacturer remains responsible for the product and the EU declaration of conformity. External advisers, laboratories and conformity-assessment bodies can supply analysis or evidence, but responsibility and decision gates must be assigned inside the manufacturer’s own release process.

Intake gate: lock the product, operator, scope and route

Before ordering tests, freeze the regulatory object. Record the manufacturer, product family and exact variants, software and firmware versions, remote data-processing dependencies, intended purpose, reasonably foreseeable use, markets, distribution model, third-party components and the entity that controls updates and vulnerability handling.

Then decide whether the product is in CRA scope and whether it is a default, important class I, important class II or potentially critical product. This classification matters because it changes the permitted conformity-assessment route. If scope or classification is uncertain, treat it as an explicit open decision with evidence and an owner rather than hiding it inside a testing work order.

Operational workflow from intake to market readiness

Stage	Key input	Execution output	Release / handoff gate
1. Intake and scope	Architecture, versions, supply chain, intended use	Controlled product definition and CRA applicability memo	No regulatory testing until the assessed configuration is identifiable
2. Classification and route	Annex III/IV functionality; available standards, specifications and schemes	Classification record and planned conformity route	Escalate if class or route is uncertain
3. Risk and requirement map	Threats, assets, interfaces, operational environment	Documented cybersecurity risk assessment and requirement-to-control matrix	Every applicable Annex I requirement has an owner and evidence plan
4. Evidence plan	Controls, existing reports, development records	Test and evidence plan with acceptance criteria and evidence owners	Avoid duplicate testing and identify missing proof
5. Testing and remediation	Representative build, interfaces, SBOM/dependencies, update path	Test reports, findings, remediation and retest evidence	Critical findings closed or formally risk-resolved before assessment
6. Technical file	Risk record, design, test evidence, vulnerability processes	Annex VII-oriented technical documentation and user/support information	The file matches the released product version
7. Conformity and release	Technical file plus route-specific submission package	Assessment outcome, EU declaration of conformity and CE release package where applicable	No release on unresolved conformity conditions
8. Post-market control	Support plan, reporting access, change pipeline	Vulnerability handling, SRP readiness, update and change-control records	Material changes trigger documented re-evaluation

Testing and evidence: prove the risk assessment, not a generic “CRA test”

The CRA does not reduce compliance to one universal test suite. Testing should be derived from the product’s cybersecurity risk assessment and the applicable Annex I requirements. Depending on the product, the evidence plan may combine architecture review, secure-configuration review, interface and authentication testing, vulnerability scanning, dependency/SBOM analysis, penetration testing, update-mechanism testing, misuse or abuse cases, and verification of vulnerability-handling processes.

For each test, record the tested version, configuration, environment, method, acceptance criterion, result, remediation and retest status. If an external laboratory is used, preserve the statement of work and test scope so that the report can be tied to the exact release candidate. A “pass” on an unidentified or obsolete build is weak conformity evidence.

Technical documentation and the release pack

The technical file should be built while engineering evidence is produced, not reconstructed at the end. A practical release pack normally includes:

product identification, architecture and version/configuration baseline;
cybersecurity risk assessment, including intended and reasonably foreseeable use;
mapping of applicable Annex I requirements to implemented controls and evidence;
design and development information plus relevant component/dependency evidence;
test reports, remediation and retest records;
vulnerability-handling and coordinated-disclosure processes, update mechanism and security-support arrangements;
support-period rationale and required user information/instructions;
route-specific conformity records, EU declaration of conformity and CE-marking release evidence where applicable.

Under the CRA, technical documentation must be prepared before placement on the market and updated where appropriate during the support period. Manufacturers must keep the technical documentation and EU declaration of conformity available for at least ten years after placement on the market or for the support period, whichever is longer.

Conformity-assessment route and third-party handoffs

Product route	Practical execution consequence
Default products	Module A internal control is one available route; evidence still has to demonstrate the applicable essential requirements.
Important class I	Module A remains available for the relevant requirements only when the conditions in Article 32(2) are satisfied through applicable harmonised standards, common specifications or qualifying certification. Otherwise use EU-type examination (B) plus conformity to type (C), or full quality assurance (H).
Important class II	Use B+C, H, or—where available and applicable—a qualifying European cybersecurity certification scheme at least at “substantial” assurance.
Critical products	Check the current Article 8 / Article 32 route and any applicable delegated act or certification requirement before booking assessment; do not assume every Annex IV product follows one fixed path.

Provider coordination should be treated as a controlled handoff. Before sending a file to a notified body or another assessment provider, confirm that the provider is authorised for the required scope, agree the language and submission package, freeze the assessed version and create a query log. In 2026, CRA conformity-assessment infrastructure and standards are still being rolled out, so provider status and applicable standards should be checked live rather than assumed from older marketing material.

Launch gate, reporting and change control

Market readiness is a release decision, not merely completion of testing. The gate should confirm that the released product matches the assessed baseline, required conformity documentation is approved, user and security-support information is ready, the support period has been determined, and post-market owners have access to vulnerability intake, update and reporting systems.

Since 11 September 2026, manufacturers must already report actively exploited vulnerabilities and severe incidents having an impact on product security through the CRA Single Reporting Platform. The Commission describes an early warning within 24 hours and a full notification within 72 hours; the relevant final report follows the CRA timelines for the event type. This reporting workflow should be rehearsed before an incident occurs, including who can submit, who approves facts and how engineering evidence is preserved.

After release, changes to code, hardware, dependencies, cryptography, interfaces, remote processing, intended purpose, support arrangements or vulnerability-handling processes should enter a documented impact review. The question is not only whether a feature changed, but whether the cybersecurity risk assessment, evidence, user information or conformity conclusion must be updated.

Common bottlenecks that delay CRA market readiness

classification is left unresolved while testing starts, so the wrong assessment route is budgeted;
product variants and cloud or remote-processing dependencies are not configuration-controlled;
risk assessment, SBOM/dependency inventory and test scope describe different versions;
supplier evidence is missing for security-critical components or update dependencies;
findings are fixed in code but remediation and retest evidence is not retained;
support period, vulnerability intake and incident-reporting ownership are decided only at launch;
a third-party assessment is booked before the technical file is internally consistent.

What this page does not replace

If the main question is how to choose an adviser, structure governance or obtain a strategic gap analysis, see the CRA consultant page. If the main question is budgeting and cost drivers, see the CRA cost page. For multi-regime CE release mechanics beyond CRA, see CE marking services. This page owns the execution chain and handoffs required to turn CRA requirements into a release-ready evidence package.

CRA compliance services FAQ

Can we start testing before the CRA classification is final?

You can run engineering security tests early, but do not treat them as a complete conformity programme until scope, product baseline and assessment route are controlled. Classification can change which evidence and third-party involvement are required.

Does a penetration test prove CRA compliance?

No. Penetration testing may support selected requirements and risks, but CRA conformity also depends on risk assessment, secure product properties, vulnerability-handling processes, documentation, the applicable conformity route, user information and post-market obligations.

Do we need a notified body for every product?

No. The route depends on product classification and, for important class I products, on the conditions in Article 32(2). Important class II products require the stricter routes listed in Article 32(3). The specific route should be locked before submission.

What must already be operational in October 2026?

Manufacturer reporting under Article 14 has applied since 11 September 2026. An organisation placing relevant products on the EU market should therefore have an SRP reporting workflow, incident and vulnerability triage, decision ownership and evidence preservation in operation now, even though the CRA generally applies from 11 December 2027.

When should a released product be re-evaluated?

Use change control whenever a modification can affect cybersecurity risk, the assessed configuration, essential-requirement evidence, support arrangements or conformity. The CRA guidance also addresses substantial modification; borderline cases should be documented and escalated rather than treated as routine maintenance by default.