Why class II important products cannot self-assess under the CRA
If your product falls in Annex III class II, self-assessment is off the table. Under Article 32(3), a class II product must go through a third-party route: EU-type examination under module B followed by module C, or full quality assurance under module H. Where a European cybersecurity certification scheme exists and applies at assurance level substantial or higher, that route is also available. Plan for an independent conformity assessment from the start, because the schedule and budget for it differ sharply from the self-assessment path most products follow. Annex III class II has four categories: hypervisors and container runtime systems that support virtualized execution of operating systems, firewalls and intrusion detection and prevention systems, tamper-resistant microprocessors, and tamper-resistant microcontrollers. The reasoning behind the higher tier is position. A hypervisor sits beneath every guest it isolates, a firewall or intrusion system decides what traffic reaches a network, and a tamper-resistant chip anchors hardware trust for everything built on it. A flaw in one of these components can expose many systems at once, so the regulation treats them as a higher risk than a typical product with digital elements.
The hard part is settling which category a product belongs to. Implementing Regulation (EU) 2025/2392 describes firewalls broadly, including network firewalls, application firewalls such as web application firewalls, and anti-spam gateways, and it covers intrusion detection in both network-based and host-based forms. Many security products therefore sit close to class I entries, which cover items such as SIEM and other security tooling, and the class I route can be self-assessment only where harmonized standards are applied in full. Before you commit to a route, map each feature of the product against the Implementing Regulation text, record the reasoning, and confirm the classification with your notified body or market surveillance contact. For the microprocessor and microcontroller categories, check whether the product is designed to meet Common Criteria AVA_VAN level 2 or 3, since that design target decides whether the tamper-resistant categories apply.
Which products fall into the four class II categories
Annex III class II lists four categories of important products under the Cyber Resilience Act. Implementing Regulation (EU) 2025/2392 defines what each category covers, so the placement test depends on the technical description rather than the product's marketing name.
Hypervisors and container runtimes
This category covers type 1, type 2 and hybrid hypervisors that support virtualized execution of operating systems, plus container runtime systems that manage the execution and lifecycle of containers on a single host operating system. Check whether your product creates or runs virtual machines, or orchestrates container lifecycles on one host. A management console that only calls an external runtime needs a separate scoping decision. Confirm how each product component is described in the technical documentation.
Network and application firewalls
The firewall category includes network firewalls and application firewalls, such as web application firewalls and anti-spam gateways. Scope turns on what the product filters: traffic at network level, or application requests and messages. Products sold as security appliances, cloud security services or software add-ons can each fall inside this category if they perform these functions. Document every filtering function so the placement decision is traceable.
Intrusion detection and prevention systems
The intrusion detection and prevention category includes both network-based and host-based systems. A network sensor that inspects traffic and an endpoint agent that monitors a host can both qualify, even when they are sold as one product. Check whether detection, blocking or both are performed, because the functionality description drives the classification. Record deployment modes separately so reviewers can see which configuration the placement applies to.
Tamper-resistant microprocessors
A microprocessor falls in this category when it has the security functionalities of the class I categories and is designed to protect at Common Criteria AVA_VAN level 2 or 3. The test has two parts: functional scope, then the assurance level the design targets. Confirm the assurance level in the security target or certification evidence, not only in marketing material. A chip that lacks that design target does not meet this description.
Tamper-resistant microcontrollers
Microcontrollers follow the same test as microprocessors. The chip must carry the security functionalities of the relevant class I categories and be designed to resist attack at Common Criteria AVA_VAN level 2 or 3. Embedded products that bundle a microcontroller with other components should be assessed at component and product level. Ask your component supplier for the assurance level evidence and whether it covers the exact part number you ship.
Module B with module C, module H, or an EU certificate
Class II products cannot be self-assessed. Article 32(3) of the Cyber Resilience Act requires a manufacturer of a class II important product to use one of three routes: EU-type examination (module B) followed by either conformity to type based on internal production control (module C) or full quality assurance (module H), or a European cybersecurity certification scheme at assurance level at least substantial, where such a scheme exists and applies to the product. Module A, the self-assessment route most products use, is not available. Before committing budget, the manufacturer should confirm with its notified body which of the module B routes fits its production model, and check whether any European cybersecurity certification scheme already covers its category and assurance level.
The notified body performs the independent part of the work. For module B, it examines the product design and checks the technical documentation against the essential requirements in Annex I. Under module C, the manufacturer's production surveillance is then verified over time. Under module H, the notified body assesses the manufacturer's full quality system and its design controls. In every route, the notified body issues the certificate and its findings, but it does not take ownership of the product. The manufacturer still owns the technical documentation, the risk assessment, the EU declaration of conformity and the CE marking. Ask any notified body to show in writing which documents it will review and which the manufacturer must sign.
Article 32(5) offers one open-source exception. Free and open-source software in class II may use module A instead, but only where the technical documentation is made public when the product is placed on the market. This is a condition of the route, not a shortcut around it. A steward or open-source maintainer relying on it should decide early whether the documentation, including the risk assessment and vulnerability handling evidence, can be published in full, and whether a commercial offering built on the same code would still qualify. Where the open-source component is embedded in a product sold by a company, confirm the exception applies to that product as placed on the market, not only to the upstream project.
Which route fits which class II product
A closed-source vendor selling a network or application firewall is the clearest class II case. Article 32(3) removes self-assessment, so the vendor must pick between EU-type examination (module B) followed by module C, full quality assurance (module H), or a European cybersecurity certification scheme at assurance level at least substantial where one exists and applies. The notified body will examine the technical documentation, the design of the security functions and the vendor's production and quality processes.
- Category fit: Confirm the product falls within the firewall category, which covers network firewalls and application firewalls such as web application firewalls and anti-spam gateways.
- Module choice: Module B with C suits a stable product with a defined production process, while module H suits vendors with a mature quality system across design and production.
- Documentation load: Expect the technical documentation to show how each Annex I requirement is met across the full support period.
- Scheme check: Ask whether a relevant certification scheme exists at the required assurance level and whether it applies to your product.
- Ongoing duties: The vendor's vulnerability handling and reporting duties run alongside the conformity route.
Before committing, confirm the notified body's scope covers this product category and ask for the written assessment plan.
An open-source intrusion detection project distributed by a foundation or company can use module A under Article 32(5), but only if its technical documentation is made public when the product is placed on the market. The route therefore depends on who places the product on the market and whether that party publishes the documentation in full. Where the project is distributed as a commercial build by a company, the company is the manufacturer and carries the obligations.
- Publication test: Decide whether the complete technical documentation will be public at placement, not only the user guide.
- Distributor role: Identify whether a foundation, a company or an individual places the product on the market, since that party is the manufacturer.
- Commercial builds: Check whether paid support, hosted or packaged versions change the placement and therefore the route.
- Fallback: If publication is not possible for every release, the project must use module B with C or module H.
- Intrusion detection scope: Confirm whether the product is network-based or host-based, as both fall in the category.
Confirm with counsel and the foundation how the Article 32(5) condition will be documented for each release.
A chip maker producing tamper-resistant microprocessors or microcontrollers falls in class II only when the device carries the security functionalities of the class I categories and is designed to provide protection at Common Criteria AVA_VAN level 2 or 3. The route is still module B with C, module H, or a suitable certification scheme, because self-assessment is unavailable. The notified body will focus on the security design, the evidence behind the AVA_VAN claim and the production controls that keep devices consistent.
- Threshold check: Map the chip's security functions against the class I categories and confirm the claimed vulnerability analysis level.
- Evaluation evidence: Gather the vulnerability assessment evidence that supports the AVA_VAN level the datasheet states.
- Production consistency: Module C and module H both depend on controls that ensure each shipped unit matches the assessed design.
- Customer integration: Document what the chip maker supplies to integrators, since the integrator may become responsible for the final product.
- Scheme availability: Confirm whether a European certification scheme exists for this device type at the required assurance level.
Confirm the AVA_VAN level and the notified body's competence for this device class before scheduling work.
A hypervisor vendor falls in class II because the category covers type 1, type 2 and hybrid hypervisors, as well as container runtime systems that manage containers on a single host operating system. The route again sits with module B and C, module H, or a certification scheme, unless the software is free and open source and meets the Article 32(5) publication condition. The notified body will examine how the product isolates virtualized workloads and how the vendor handles updates across the support period.
- Category boundaries: Confirm whether the product is a type 1, type 2 or hybrid hypervisor, or a container runtime, since each sits within the category.
- Isolation evidence: Expect the assessment to focus on how guest execution is separated and how the security design is tested.
- Support period: Show how security updates are delivered for the full period the product is supported.
- Open-source path: If the project is open source, check whether complete technical documentation is public at placement to use module A.
- Customer deployments: Clarify whether the vendor or the customer configures the product, since that affects who controls the evidence.
Ask the notified body early whether it will accept your existing documentation and test evidence.
How a notified body tests a class II product
This table compares what a notified body samples, what evidence it asks for and where class II files commonly fall short under the module B plus C route, the module H route and the open-source documentation check. Read it as a preparation checklist: each row is an area the assessor will test, so gaps found here are cheaper to close before the assessment starts.
| Assessment area | What the assessor samples or requests | Common findings |
|---|---|---|
| Cybersecurity risk assessment | The manufacturer's risk assessment for the class II product, its threat model and how the Annex I Part I requirements were derived from it | Risk assessment is generic, does not cover the specific firewall, hypervisor or microcontroller function, or is not updated after design changes |
| Annex I Part I property evidence | Design and test records showing how each product property, such as secure defaults, access control and data protection, is implemented | Claims made in documentation without test results, or properties described for one configuration but shipped in another |
| Tamper-resistance evidence (microprocessors and microcontrollers) | Security functionality evidence and the Common Criteria AVA_VAN level 2 or 3 assessment basis for the chip or controller | Vulnerability analysis level not clearly documented, or evaluation scope does not match the delivered hardware revision |
| Part II vulnerability handling processes | Written procedures for vulnerability intake, coordinated disclosure, security updates and the process for the full support period | Processes exist in draft only, or no owner and no record of past handling activity |
| Support period documentation | How the stated support period is defined, communicated to users and tied to the update plan | Support period is undocumented or stated inconsistently across the user manual, website and declaration |
| Technical documentation and build consistency | Sampling of the technical documentation against the software or firmware version actually placed on the market | Mismatch between documentation and shipped build, missing version identifiers, or unrecorded changes after the assessment |
| EU declaration of conformity | The declaration, its references to the applicable standards or assessment route and the CE marking conditions | Declaration cites an incorrect module, omits the notified body reference, or does not match the product name and version |
| Article 32(5) open-source documentation check (module A) | Public availability of the technical documentation at placing on the market, for free and open-source class II software | Documentation not published when the product is placed on the market, or published only in part |
Sequence to prepare a class II product for notified body review
This sequence takes a class II product from confirmed placement under Annex III to a signed EU declaration of conformity and CE marking, with each step producing an artifact the notified body can review. It shows the order of work so that the manufacturer, any implementation partner and the notified body agree on what is owed at each stage.
Confirm class II placement against the technical description
The manufacturer compares the product's core functionality with the category wording in Commission Implementing Regulation (EU) 2025/2392, checking whether it is a hypervisor or container runtime, a firewall or intrusion detection or prevention system, or a tamper-resistant microprocessor or microcontroller. Legal or product compliance staff make the decision and record the reasoning. The output is a signed classification memo that names the category and explains why adjacent products were excluded. Ask the notified body early whether it agrees with the placement if the boundary is unclear.
Select the Article 32 conformity route
The manufacturer confirms which route under Article 32(3) applies: EU-type examination (module B) followed by module C, full quality assurance (module H), or a European cybersecurity certification scheme at the required assurance level where one is available and applicable. Self-assessment is not an option for this class. If the product is free and open-source software and the technical documentation will be made public when it is placed on the market, the manufacturer should confirm whether Article 32(5) module A applies. The output is a route decision record that lists the chosen module and the reason for it.
Build the technical documentation and risk assessment
The manufacturer prepares the technical documentation that describes the product, its design, development and vulnerability handling, and the cybersecurity risk assessment that drives the Annex I requirements. Product security engineers and the architecture team own the content, and an implementation partner can help assemble it from existing system records. The output is a versioned documentation set with a risk register linked to each identified risk and its treatment. The reviewer should be able to trace each claim to a design artifact or test result.
Apply Annex I Part I and Part II requirements
Engineering teams implement the essential cybersecurity requirements in Annex I Part I, applied according to the risk assessment, and the eight vulnerability handling requirements in Annex I Part II that run for the whole support period. Security testing, secure defaults, update mechanisms and vulnerability disclosure processes are verified against the requirements they support. The output is a requirement-by-requirement evidence matrix showing the design decision, the test result and the document that proves each item. Gaps are recorded for the next step rather than left implicit.
Choose and brief the notified body
The manufacturer identifies notified bodies that are designated for the relevant module and product category, checking the Commission's NANDO listing, and requests scope and fee quotes in writing. The shortlisted body receives the classification memo, route decision and draft documentation so it can confirm the review plan. Procurement should ask what the review will cover, what samples or access it needs and how findings are reported. The output is a signed engagement letter with an agreed scope and review plan.
Remediate findings and resubmit evidence
The manufacturer works through each finding raised by the notified body, fixes the product or the documentation, and records the change in the evidence matrix. Engineering owns technical fixes, and compliance owns documentation and traceability updates. The output is a findings log that shows each finding, the corrective action, the evidence of closure and the date the notified body accepted it. Any change to the product during review should be assessed for its effect on conformity before it is submitted.
Issue the EU declaration and affix CE marking
Once the notified body has completed its procedure and the route requires it, the manufacturer draws up the EU declaration of conformity and affixes the CE marking to the product as the regulation requires. The manufacturer owns the declaration, and the notified body does not issue it on the manufacturer's behalf. The output is a signed EU declaration of conformity filed with the technical documentation, with the CE marking applied and the file retained for the period the regulation specifies. Confirm the retention and support period obligations against the regulation text before closing the file.
Evidence a notified body reviews for class II products
A notified body for a class II product does not accept a single certificate of compliance as proof. It reviews a connected body of records that shows how the product was designed, tested, documented and maintained. Each card below is one item in that body, and each has to stay current for the whole support period, not just until the assessment closes.
Technical documentation
This is the manufacturer's main file describing the product, its design, its Annex I properties and how they were implemented. For a class II product, the notified body uses it to judge whether the documented design matches what was built and tested. Keep it versioned against each release and record every change that affects a security property. Confirm the exact content list against Annex VII of the regulation before you start drafting.
Cybersecurity risk assessment
The risk assessment explains which threats the product faces and why the chosen Annex I controls are sufficient. Assessors check whether it covers the firewall, hypervisor or tamper-resistant hardware function in realistic attack paths, not only generic risks. Review it when the threat picture changes, when a new vulnerability class emerges and when the product gains a major feature.
Test reports for Annex I properties
These reports show that each applicable Annex I property was tested, with method, scope, results and the version of the product tested. For tamper-resistant microcontrollers, the evidence also covers the Common Criteria AVA_VAN work the category relies on. Store test reports against the build they tested, and rerun the relevant tests after any security-relevant change.
SBOM and vulnerability handling records
The software bill of materials lists the components the product ships with, and the vulnerability handling records show how each finding was triaged, fixed and disclosed. Assessors look for an SBOM generated from the actual build and records that match it. Keep both updated with every release and every newly disclosed dependency issue across the support period.
EU declaration of conformity
The EU declaration of conformity is the manufacturer's written statement that the product meets the regulation's requirements, and it is issued by the manufacturer, not by the notified body. It must reference the assessment route and the certificate or evidence it depends on. Update it whenever the product, its version or its assessment basis changes, and check that its references still point to valid certificates.
Quality management and production controls
Module H requires a quality management system that the notified body audits, covering design, development, production controls and vulnerability handling. Module C relies on controls that keep production consistent with the tested product. Records include internal audits, corrective actions, training and change approvals. Ask the notified body early which of these records it will sample, and maintain them as a routine process rather than a pre-assessment exercise.
What class II conformity costs in money and effort
This table lists each cost component of class II conformity, who is paid for it, whether it is one-time or recurring, and what moves it up or down. No fee figures are supplied for this topic, so use the table to build your question list and request written notified body fee schedules before comparing offers.
| Cost component | Who is paid or who bears it | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Notified body fees for module B and module C or H | The notified body performing EU-type examination and quality assurance review | One-time for the initial examination, recurring for ongoing surveillance | Number of product variants, scope of the quality system, and the notified body's written fee schedule |
| Internal engineering time for technical documentation | Your own engineers, architects and product security staff | One-time for the initial file, recurring when the product changes substantially | Number of firewall, hypervisor or microcontroller variants, and how well design records already exist |
| Test lab or penetration testing against the essential requirements | Accredited or independent test laboratories and security testing firms | Often one-time per release, with retests after fixes | Product architecture complexity, number of interfaces, and whether earlier test evidence can be reused |
| SBOM and vulnerability tooling | Tool vendors or open-source tooling operated by your team | Recurring licenses or hosting, plus staff time to triage findings | Number of components and dependencies, and whether tooling runs in your own pipeline |
| Quality management system setup and upkeep | Internal quality, compliance and engineering staff, plus any consultant you engage | Setup is one-time, upkeep is recurring | Maturity of existing processes, number of product lines sharing one quality system, and audit findings |
| Tamper-resistance evidence for microprocessors and microcontrollers | Specialist evaluation laboratories and your hardware security engineers | One-time per design, recurring for revised silicon or firmware | Common Criteria AVA_VAN level targeted, and whether the design reuses evaluated components |
| Recurring surveillance and re-examination after changes | The notified body, plus your internal change control team | Recurring | Frequency of releases, scope of substantial modifications, and how well change records are kept |
| Cyber resilience certification scheme route, where available | Certification body and your own preparation team | Depends on the scheme; confirm with the scheme owner | Whether a European cybersecurity certification scheme applies to your category at the required assurance level |
Who owns class II conformity and who can help
The manufacturer remains legally responsible for a class II product's conformity with the regulation, whoever built or hosted it. For a class II product, the manufacturer must go through a third-party route, either EU-type examination (module B) followed by module C, or full quality assurance (module H), and it must hold the resulting certificate before it signs the EU declaration of conformity and affixes the CE marking. The manufacturer also keeps the technical documentation and the vulnerability handling process for the whole support period.
- Product ownership: The manufacturer decides the product's design, risk assessment and release decisions and answers to authorities for them.
- Technical file: The manufacturer compiles and keeps the technical documentation, including the risk assessment, SBOM and test records.
- Declaration and marking: Only the manufacturer signs the EU declaration of conformity and affixes the CE marking.
- Vulnerability handling: The manufacturer runs the Annex I Part II process and the Article 14 reporting duty.
- Internal controls: The manufacturer's quality system must support the chosen module, so internal teams need named owners for each process.
Before you engage anyone, confirm internally who holds each of these roles and who signs for the organization.
An implementation partner helps the manufacturer build the systems, controls and evidence that the assessment will examine. Its work is preparation, not judgment: it configures, hardens, documents and tests the product, and it produces material the manufacturer and the notified body can review. It does not decide whether the product conforms, and it does not issue reports or certificates.
- Systems and hardening: The partner can configure and harden the self-hosted open-source components a product depends on, within the client's own infrastructure.
- Evidence preparation: The partner can organize logs, test results, configuration baselines and documentation into a form the manufacturer can present.
- Test support: The partner can run security testing and report findings, which the manufacturer then fixes and records.
- Documentation support: The partner can draft technical documentation for the manufacturer's review and approval.
- Fixed scope: Work is usually defined in a written scope with agreed deliverables before it starts.
Ask the partner in writing which deliverables it will produce and confirm that it will not sign the declaration or act as the notified body.
A notified body is an independent conformity assessment body, designated by a Member State and listed in the Commission's NANDO system, that examines the product and the manufacturer's quality system against the applicable module. It is the party that issues the EU-type examination certificate or quality system approval that class II products require. Its independence is the reason its output carries weight with authorities and buyers.
- Independent examination: The notified body assesses the product and quality system itself, using its own judgment and records.
- Certificate issuance: Only the notified body issues the certificate the manufacturer relies on for the class II route.
- Designation check: Confirm the body is notified for the relevant CRA category in NANDO before you contract with it.
- Ongoing surveillance: The notified body carries out the follow-up activity that the chosen module requires.
- Separation: A notified body cannot design, build or prepare the evidence it later assesses for the same product.
Ask each candidate body for its written process, its fee basis and its timeline, and check its designation status directly.
Independence is the boundary that governs the whole class II route. The notified body must remain separate from the parties that prepared the product and its evidence, and the manufacturer must remain the signatory. An implementation partner that prepares systems and documentation can support the manufacturer, but it cannot take over the notified body's examination or the manufacturer's declaration.
- Partner cannot be the notified body: A firm that built or hardened the product cannot assess its conformity.
- Partner cannot sign: Only the manufacturer signs the EU declaration of conformity.
- Manufacturer keeps responsibility: Outsourced work does not transfer legal liability for conformity.
- Records of separation: Keep contracts and scope documents that show which party did which work.
- Conflicts check: Ask every outside party to disclose any role it holds for the same product.
Confirm these lines in writing with each provider before work starts, so the assessor can trace who did what.
Where class II products usually fall short
Class II products face the strictest route under the Cyber Resilience Act, so small gaps in classification, conformity assessment or evidence tend to stop a product from reaching the EU market. The cards below cover the decisions and records that most often go wrong, each with a check to run before the conformity assessment begins.
Misclassifying a class I product
Teams sometimes place a product in class II because it sounds security-heavy, or leave a product in class I because it looks like a general utility. Class II is limited to four named categories in Annex III, and the technical description in Implementing Regulation (EU) 2025/2392 decides the boundary. Check the product's core function against the category wording before you choose a route, and record the reasoning in the technical documentation.
Missing the Common Criteria condition
A tamper-resistant microprocessor or microcontroller is class II only when it has the security functionalities of the class I categories and is designed to protect at Common Criteria AVA_VAN level 2 or 3. A chip with strong hardware security but no documented vulnerability assessment level will not meet the definition. Ask the chip supplier for the evaluation level and the certificate, and confirm it covers the exact product configuration you ship.
No technical documentation for module A
Open-source class II products can use module A only when the technical documentation is made public when the product is placed on the market. Projects that release code but keep design notes, threat models or test records private lose that route and must use a notified body. Decide before release which documents will be published, who maintains them, and where they will be hosted.
Undefined support period
The conformity file has to state how long security updates will be provided, and the support period has to be defined before the product is placed on the market. Hypervisors, container runtimes, firewalls and IDS/IPS products are often run for many years, so an open-ended promise is hard to evidence. Write a dated support commitment, tie it to the release policy, and confirm that the vulnerability handling process covers the full period.
No SBOM for hypervisor and firewall builds
Hypervisors, container runtimes, firewalls and detection systems are built from many upstream components, including kernel modules, parsers, rule engines and cryptographic libraries. Without a software bill of materials for each shipped build, a manufacturer cannot show which components are affected when a vulnerability is published. Generate an SBOM for every release artifact, store it with the technical documentation, and check that it updates with each build.
Vague vulnerability handling evidence
Annex I Part II asks manufacturers to run a vulnerability handling process for the whole support period, and assessors look for records that show it working. A published disclosure policy with no logged reports, no triage decisions and no patch timelines is weak evidence. Keep a dated record of intake, analysis, fixes and advisories, and run a test case through the process before the assessment so the records exist.
Questions buyers ask about class II important products
Is every firewall automatically a class II important product under the CRA?
Firewalls listed in the class II category are covered, and the category is broader than many buyers expect. Implementing Regulation (EU) 2025/2392 describes it as including network firewalls and application firewalls such as web application firewalls and anti-spam gateways. Whether a specific product falls inside depends on its core functionality, so check its primary purpose against the technical description rather than its marketing name. Intrusion detection and prevention systems are a separate class II category and are read to include both network-based and host-based systems. If your product is a firewall in function, plan for the class II route from the start.
Can open-source class II software use module A self-assessment?
Yes, but only under a specific condition. Article 32(5) allows free and open-source software in class II to use module A, self-assessment, when the technical documentation is made public when the product is placed on the market. Without that public documentation, the normal class II routes apply, which means EU-type examination with module C or full quality assurance with module H, or a European cybersecurity certification scheme where one is available and applicable. Confirm with counsel whether your licensing and distribution model meets the open-source steward and manufacturer definitions before you rely on this route.
What does a notified body route cost, and what drives the price?
No supplied figure sets the cost of a class II conformity assessment, so treat any number you see with caution and ask for the basis. The cost has several parts: the notified body's assessment fee, which depends on product complexity and the depth of review; your internal engineering time to prepare documentation and evidence; quality system work if module H applies; and retesting if findings require changes. Expect some costs to be one-time, such as the initial assessment, and others to recur, such as periodic surveillance and re-assessment after substantial change. Ask each notified body for a written quote listing the modules, sample size, number of review days and what triggers an additional charge.
How long does preparation take for a class II product?
The honest answer depends on your team's starting point, and no reliable duration applies to every product. A team that already runs a documented secure development lifecycle, maintains a software bill of materials and has a vulnerability handling process will usually prepare faster than one building those practices from scratch. Other drivers include the number of components, the state of existing test evidence, how many product variants share one technical file, and how quickly notified body capacity is available. Ask your assessment body for its expected timeline in writing, and ask your implementation partner to scope the gaps in a fixed-scope plan before committing to dates.
Can an implementation partner prepare the technical file for us?
A partner can help prepare the technical documentation and the evidence behind it, but the manufacturer keeps responsibility for the product and its declaration. DeployOpen prepares systems, controls and evidence for compliance assessments, including architecture records, test results, hardening documentation and secure update processes, where those apply to a self-hosted open-source platform in the client's own infrastructure. DeployOpen does not issue audit reports, attestations or certifications, and it does not act as the notified body. Agree in writing which documents the partner drafts, which the manufacturer approves, and which the assessment body reviews.
How does class II differ from class I and critical products?
Class II sits between the default category and critical products, and its conformity route is fixed. Class I important products can use self-assessment when harmonized standards, common specifications or certification schemes are applied in full, and need a notified body otherwise. Class II products always need third-party involvement, either EU-type examination with module C or module H, or a European cybersecurity certification scheme at assurance level at least substantial, and self-assessment is not available. Critical products under Annex IV face the most demanding route and may be subject to a Commission power to require EU certification. Check the category against the current technical description before choosing a route.
Do tamper-resistant microcontrollers always count as class II?
Not always. Under Implementing Regulation (EU) 2025/2392, tamper-resistant microprocessors and microcontrollers are those with the security functionalities of the class I categories that are also designed to provide protection at Common Criteria AVA_VAN level 2 or 3. A component that lacks that combination of functions and assurance level may fall outside this category. Engineers should document the security functions, the design target for vulnerability analysis and the test evidence that supports the level claimed, then confirm the classification with the assessment body early in the project.
How DeployOpen prepares class II products for assessment
DeployOpen starts by confirming whether a product is class II at all. Before any work begins, the manufacturer's team and DeployOpen check the product's core functionality against the four class II categories and the technical descriptions in Commission Implementing Regulation (EU) 2025/2392. Edge cases are common: a firewall product that also ships a web application firewall or anti-spam gateway, a host-based intrusion detection agent bundled with a platform, or a hypervisor component inside a larger appliance. Each boundary decision is recorded in writing with the reasoning, because the assessment route depends on it. The output of this step is a written scope that names the product, its version, the category, and the conformity assessment route the manufacturer intends to use.
Once scope is fixed, DeployOpen implements the self-hosted platform controls and collects the evidence that a notified body will sample. Typical work includes hardening the deployment inside the client's own infrastructure, configuring logging and access controls, setting up vulnerability handling workflows, and producing software bill of materials output from the build pipeline. Where the product uses free and open-source components, the team confirms which components the manufacturer actually controls and which parts depend on upstream projects. Costs are driven mainly by the number of components, the state of existing build and test pipelines, and how much of the evidence already exists. Ask for these as separate line items in the written scope.
DeployOpen also prepares technical documentation inputs and test support, but it does not issue certificates, conformity assessments or EU declarations of conformity. Under the regulation, the manufacturer draws up the EU declaration and affixes CE marking, and a notified body performs the independent assessment that class II requires under Article 32. Confirm with the notified body early which modules it offers, its lead times and what sample it expects, because those answers shape the documentation DeployOpen delivers. Use the Commission's Cyber Resilience Act page to check the current regulatory position before you sign a scope.
