Preparing for a Cyber Resilience Act (CRA) notified-body assessment means confirming that an independent conformity assessment is the right legal route, selecting a body notified for the relevant scope, and making the product and its security evidence reviewable. The manufacturer should arrive with a controlled product baseline, a current cybersecurity risk assessment, traceable Annex I evidence, and a plan for handling questions, findings and later changes.
The preparation work is distinct from the assessment itself. A well-organised technical file helps the notified body evaluate the product, but it does not predetermine the body's conclusion. This guide focuses on the manufacturer's practical handover and coordination tasks rather than repeating the detailed procedures for each assessment module.
1. Confirm that the notified-body route applies
Start with the product's intended purpose and its classification under the CRA. Article 32 sets out the conformity assessment routes, while Annexes III and IV identify important and critical product categories. The category and the conditions for using relevant technical specifications determine whether internal control is available or a third-party procedure is needed.
A practical route-decision record should state:
- the product's intended purpose and core functionality;
- whether it falls into the default, important Class I, important Class II or critical category;
- the precise legal provisions supporting that classification;
- the harmonised standards, common specifications or qualifying certification arrangements considered;
- the conformity route selected and why it is available; and
- the person responsible for reviewing the decision when regulatory conditions change.
For important Class I products, the extent to which qualifying specifications or schemes are applied can affect access to internal control. Important Class II products generally require an applicable third-party route or qualifying certification route. Critical products have specific Article 8 and Article 32 conditions. Do not assume that every product needs a notified body, or that every cybersecurity certificate substitutes for a CRA procedure.
2. Choose the procedure before requesting a quotation
The two main notified-body routes under Annex VIII have different assessment objects:
| Route | What the external assessment concentrates on | Manufacturer preparation priority | |---|---|---| | Module B followed by Module C | EU-type examination of the technical design, development and vulnerability-handling processes, followed by manufacturer control of conformity to the approved type | Precisely defined type, technical evidence, representative critical parts, and later type/change control | | Module H | Approval and surveillance of a full quality system covering design, development, final inspection and testing, and vulnerability handling | Controlled processes, documented responsibilities, operating records, internal review and product-specific traceability |
The selected procedure changes the application, evidence package, assessment interactions and follow-up obligations. Module B is not simply a penetration test; it also addresses vulnerability-handling processes. Module H is not merely a document review; it involves ongoing surveillance of the approved quality system.
The manufacturer's conformity declaration remains its own responsibility under the applicable procedure. A notified body's participation should not be described as transferring all product-security accountability to an external assessor.
3. Verify the body's legal notification and scope
A testing laboratory, consultant or organisation with experience in cybersecurity is not automatically a CRA notified body. Under Chapter IV, Member States assess and notify conformity assessment bodies. The European Commission explains that notified bodies appear in the NANDO register once the notification process has been completed.
Before committing to an assessment, verify the live register entry and request written confirmation of:
- the legal entity and its notified-body identification;
- notification under Regulation (EU) 2024/2847, not only another EU law;
- the procedures the body is authorised to perform;
- the product categories and technical scope covered;
- the locations or teams that will perform the assessment; and
- any scope limitations relevant to the product.
A manufacturer's location in Austria does not, by itself, require choosing a body established in Austria. The decisive check is the body's applicable notification and scope. Keep a dated record of the register check, since designations and scopes can change.
ENISA's June 2026 technical-competence report describes high-level competence expectations for CRA notified-body personnel. It is useful background when discussing assessor expertise, but it is not a substitute for checking the body's formal notification.
4. Freeze an identifiable assessment baseline
The first evidence problem is often ambiguity about which product is actually under review. Create an assessment baseline before transferring technical files.
For a hardware or embedded product, identify model, hardware revision, firmware baseline, interfaces, configuration and any relevant remote processing. For software, identify the release or version family, deployment assumptions, supported platforms, update mechanism and relevant services. For either type, record intended purpose, variants, support period and third-party dependencies.
Give the baseline an internal identifier. Link every assessment artefact to that identifier and retain the date and version of the evidence. A later security fix or architecture change should be distinguishable from the originally submitted product state.
The baseline is an engineering control, not a new CRA-prescribed certificate. Its purpose is to make the assessed scope reproducible and the conclusions understandable.
5. Build a requirement-to-evidence index
Annex I sets the essential cybersecurity requirements. Annex VII describes technical documentation, and Annex VIII specifies what the relevant assessment procedure requires. Instead of sending an unstructured archive, prepare an index that lets the reviewer navigate from each applicable requirement to the manufacturer's rationale and evidence.
A practical index can use these columns:
| Field | Example | |---|---| | Requirement | Annex I provision and internal control identifier | | Applicability | Why the provision applies to the defined product | | Design response | Architecture decision, control or documented rationale | | Verification | Test, review, analysis or inspection result | | Evidence reference | Controlled document ID and revision | | Product scope | Model, variant, firmware or release baseline | | Open issue | Finding, deviation, mitigation and owner |
Include the cybersecurity risk assessment, product architecture, relevant security design, update mechanisms, component and software bill of materials (SBOM) information, test results, vulnerability-handling processes, support-period rationale and user-facing security information where applicable.
This table is a recommended preparation format, not a mandatory CRA template. The notified body may require a different submission structure.
6. Demonstrate processes with operating records
A policy stating that vulnerabilities are handled is weaker evidence than records showing how the process works. Prepare a small set of representative, appropriately redacted examples: vulnerability intake, severity or impact assessment, remediation decision, verification, release approval and communication where relevant.
For Module H, add quality-system evidence such as process ownership, training, internal audit results, management review, corrective actions and controlled process changes. For Module B, ensure that design and vulnerability-handling records support the examined product type. Both routes benefit from evidence tied to actual product versions rather than generic organisational statements.
Keep confidential information appropriately controlled. Agree the secure exchange channel, access permissions, retention arrangements and any redaction rules with the assessor before transferring sensitive architecture or vulnerability details.
7. Run an internal evidence walk-through
Before the formal submission, have someone who did not assemble the package try to answer five questions using only the index and linked evidence:
- What exact product and configuration are being assessed?
- Which Annex I requirements apply, and why?
- Where is the current cybersecurity risk assessment?
- Which verification records support the claimed controls?
- How are discovered vulnerabilities, changes and open findings managed?
Record unanswered questions as preparation gaps with owners and due dates. This is an internal readiness exercise; it does not replace independent evaluation.
The most useful outcome is a list of missing links, ambiguous scope statements and stale documents. Fixing those issues before formal review makes the evidence easier to evaluate without assuming a particular assessment result.
8. Agree the assessment working model
Treat the engagement as a controlled project with technical and regulatory interfaces. Before the application is finalised, clarify the expected submission format, review stages, sample or test access, communication channel, language, lead times, fees and how nonconformities will be recorded and resolved.
For Module B, Annex VIII requires an application to a single notified body of the manufacturer's choice and a written declaration that the same application has not been lodged with another notified body. Avoid sending competing formal applications for the same type while seeking quotations.
Assign internal owners for product scope, architecture, security testing, vulnerability handling, quality management, legal/regulatory interpretation and release control. Agree who can approve evidence changes and who communicates with the notified body.
A schedule should include time for questions and rework, but no article can promise an assessment duration or approval date. The actual timeline depends on the product, procedure, evidence and assessor capacity.
9. Plan for findings, product changes and follow-up
Assessment preparation does not end when the technical file is submitted. Define how the team will track reviewer questions, nonconformities, corrective actions and evidence revisions without silently overwriting the original submission.
Maintain a simple decision log: issue identifier, affected requirement, product baseline, responsible owner, corrective action, verification result and closure evidence. Where a change affects the approved type or certificate conditions under Module B, the applicable notification and additional-approval requirements must be assessed. Module H also requires control of relevant quality-system changes and continuing surveillance.
A security update released during assessment can change the evidence baseline. Record whether it is in scope for the current examination and agree the handling with the notified body. Do not assume that an earlier assessment automatically covers every later release.
10. Account for the implementation timeline
The CRA's Chapter IV rules on notifying conformity assessment bodies have applied since 11 June 2026. Article 14 reporting obligations have applied since 11 September 2026. The main CRA obligations apply from 11 December 2027, subject to the Regulation's transitional provisions.
The Commission's implementation timeline identifies further notified-body and standardisation milestones during 2026 and 2027. These planning milestones should not be confused with an individual manufacturer's assessment booking or with a guarantee that a particular body will have the necessary scope at a given date.
For an Austrian manufacturer, the useful near-term actions are to establish the route decision, watch the relevant notified-body register entries and standards status, and prepare evidence early enough to support the intended market timeline.
Keeping assessment evidence connected
A recurring operational difficulty is maintaining the link between a requirement, its verification record, the assessed product baseline and later release decisions. AA-sec is designed around traceability between requirements, security evidence, assessments and exact product or lifecycle context. Its MVP scope includes assessment/readiness workflows and evidence packages; the manufacturer and notified body still make their respective decisions.
Readiness checklist
Before submitting an application, confirm that:
- the product classification and legal assessment route have a recorded rationale;
- the selected body's CRA notification and procedure scope have been checked;
- the product, versions, variants and deployment assumptions are unambiguous;
- the risk assessment and Annex I mapping are current;
- technical documentation and verification results have stable identifiers;
- vulnerability-handling records show the process in operation;
- the submission and communication arrangements are agreed;
- owners exist for findings, evidence revisions and corrective actions; and
- later product and process changes can be assessed against the submitted baseline.
Key takeaway
A CRA notified-body assessment is easier to coordinate when the manufacturer can show exactly what is being assessed, why the chosen procedure applies, and how each relevant requirement is supported by current evidence. Start with legal scope and the body's notified remit, then prepare a controlled product baseline and an auditable evidence index. The assessment itself remains an independent process, with follow-up obligations that continue beyond the initial submission.
Official sources
- Regulation (EU) 2024/2847 - Cyber Resilience Act, Articles 32 and 35-51 and Annexes I, VII and VIII — EUR-Lex
- Cyber Resilience Act - Conformity assessment — European Commission
- The Cyber Resilience Act - Summary of the legislative text — European Commission
- Cyber Resilience Act - Implementation — European Commission
- Technical Competence Requirements for CRA Notified Bodies — ENISA