Eu Cyber Resilience Act Cra Consultant
A CRA consultant should settle product scope, legal role and conformity-assessment route before anyone books a laboratory or drafts a declaration. The useful output is a reasoned decision record for each product family—not a generic certificate offer.
Regulation (EU) 2024/2847 is already in force. Manufacturer vulnerability and serious-incident reporting has applied since 11 September 2026; most other obligations apply from 11 December 2027. Distinguish duties already live from future market-entry work.
1. Define the product and the responsible operator
Decide what is actually supplied on the EU market and by whom. A marketing label such as “platform” or “IoT” cannot resolve the CRA scope.
- Inventory each hardware/software product, separately supplied component, version, intended purpose, interfaces and any remote data processing necessary for its functions.
- Identify the manufacturer, brand owner, importer and distributor; assess contractual development and substantial modifications rather than assuming the factory owns all obligations.
- Test commercial supply, exemptions and interaction with sector-specific EU rules; assess free/open-source activity on its facts, not on the licence name alone.
2. Route matrix: category is not the same as testing intensity
Use core functionality against Annex III (important) and Annex IV (critical), including the Commission's technical category descriptions, before selecting a procedure under Article 32.
| Product category | Strategic assessment route |
|---|---|
| Default category | Module A internal control is available; an external laboratory is not automatically mandatory. |
| Important class I | Module A can be available when the relevant harmonised standards, common specifications or qualifying certification conditions are fully met; otherwise use a notified-body route (B+C or H), unless the specific Article 32(5) free/open-source software derogation applies. |
| Important class II | Plan for B+C or H through a notified body, or an expressly applicable qualifying EU cybersecurity certification scheme where legally available; separately check the Article 32(5) free/open-source software derogation. |
| Critical (Annex IV) | Treat notified-body involvement as the baseline; examine Article 32 and any legally available certification alternative before committing to a route. |
Exception for qualifying free and open-source software: under Article 32(5), manufacturers of Annex III products may use a procedure listed in Article 32(1), including Module A, if the Article 31 technical documentation is publicly available when the product is placed on the market. This is not a blanket CRA exemption.
For class I, merely citing a draft standard or testing one clause does not establish the conditions for Module A. A consultant should record the exact category provision, technical basis and remaining assumptions.
3. Facts that can change the recommendation
The route is a classification conclusion, not an inference from an attractive product name or an existing CE label.
- Core security function: a firewall function may matter more than the overall device label; component integration alone does not automatically reclassify the finished product.
- Release and supply model: separately marketed component, embedded firmware, cloud-dependent functionality, non-commercial open source and a substantial post-market modification raise different questions.
- State of standards: distinguish published harmonised standards with relevant coverage from drafts, voluntary standards and evidence that does not meet the statutory route condition.
4. Gap triage: match each deficiency to a decision
A gap analysis compares the applicable Annex I duties with actual controls and usable evidence. It should distinguish a missing process from a merely missing document.
| Gap or trigger | Evidence and decision |
|---|---|
| Unclear classification | Freeze the route decision; obtain architecture, intended-use and Annex category analysis first. |
| Security design risk | Map threat model, default settings, access control and security testing to the product-specific cybersecurity risk assessment. |
| Unproven vulnerability handling | Verify reporting ownership, intake, coordinated disclosure, fixes, security updates and a defensible support-period rationale. |
| Weak evidence chain | Trace component inventory/SBOM, supplier assurances, test scope, versions and technical-file links; identify what must be regenerated. |
Prioritise gaps that change the legal route or block risk controls before commissioning broad testing. Record gap, owner, evidence, decision and residual uncertainty as separate fields.
5. Reuse evidence, but do not inherit an unsupported conclusion
Existing penetration tests, ISO/IEC 27001 materials, supplier reports and CE documentation can reduce duplication, but none by itself settles CRA conformity.
- Reuse a report only against the same product/version, risk, requirement and method; note stale coverage and required retesting.
- Map third-party components and software dependencies to the manufacturer's own assessment; supplier certificates do not transfer legal responsibility automatically.
- Keep the manufacturer risk assessment, technical documentation and post-market vulnerability processes coherent with the selected conformity route.
6. Sequence the decisions before execution
A practical strategic engagement should leave a traceable plan, not a promise of automatic approval.
- Create a product-by-product scope, role and exemption register; mark open classification issues.
- Prepare a written route memo with Annex references, standards status and the chosen procedure, including any notified-body dependency.
- Rank Annex I, documentation and support-process gaps; assign responsible teams and evidence-reuse decisions.
- Separately activate the reporting pathway already applicable since 11 September 2026, then plan conformity work toward 11 December 2027, revisiting transitions and changes product by product.
7. Where advisory ends and execution begins
This page addresses pre-execution route choice. Detailed implementation, testing coordination and technical-file production belong to a separate service scope; budgeting is a separate cost-driver exercise. Ask any adviser for a documented classification rationale and list of unresolved assumptions before buying downstream services.
Official primary sources
Frequently asked questions
Does an EU-facing SaaS backend automatically fall under the CRA?
No. Determine whether remote data processing is part of the product with digital elements and necessary for its functions; standalone services cannot simply be treated as hardware. Review architecture and contractual supply.
Can a class I product always be self-assessed?
No. Check the precise Article 32(2) conditions concerning harmonised standards, common specifications or applicable certification. If unmet, choose an appropriate notified-body procedure unless the specific Article 32(5) free/open-source software derogation applies.
Does using open-source code exclude the finished product?
No. Commercial placement of the finished product and the organisation's role matter. Non-commercial open-source activity and open-source software stewards require distinct analysis.
What about devices already on the EU market?
The manufacturer reporting obligations apply from 11 September 2026, including applicable products already made available. For 2027 conformity duties, assess first placement, later substantial modifications and transition provisions on their facts.
Will a penetration-test report or ISO certificate replace the CRA assessment?
No. Reuse relevant evidence, but document applicability, risk assessment, route conditions, conformity assessment and lifecycle duties separately.