What Article 8 critical products under the CRA means for your product
Article 8 keeps three Annex IV product categories on a stricter conformity route and lets the Commission require an EU cybersecurity certificate for them. If your product is a hardware device with a security box, a smart meter gateway or advanced security device, or a smartcard or secure element, you should assume it may be critical until you have checked the technical description. The risk behind this rule is concentrated trust: a compromised component that other systems rely on for keys, identity, payment or metering can undermine every product that depends on it, which is why the regulation treats these categories differently from the default and important tiers.
Classification is harder than it looks. Annex IV is written in functional terms, and Commission Implementing Regulation (EU) 2025/2392 gives the technical description of each category, including examples such as physical payment terminals, hardware security modules and tachographs for security boxes, and TPMs, embedded UICCs and access cards for smartcards and secure elements. Read the description against your product's core function, not its marketing name or its place in your catalogue. A device that only uses a secure element for one feature may still sit outside the category, so record the reasoning in your technical file and confirm the reading with your notified body or legal counsel before you pick a route.
Article 8 is a classification and route rule, not a separate set of technical requirements. Your product still has to meet the Annex I essential requirements. What changes is the procedure: where no delegated act under Article 8(1) applies, critical products use the class II procedures of Article 32(3), meaning module B with module C, module H, or an applicable EU certification scheme. Ask your notified body which modules and schemes are available for your category, how long its assessment takes, and what it needs from you in technical documentation. The full text of Regulation (EU) 2024/2847 on EUR-Lex is the primary reference for these articles.
Which products fall into the three Annex IV categories
Annex IV lists three critical product categories, and each one is defined by what the product does in a security role. Work through the cards in order, then confirm your product against the technical description in Implementing Regulation (EU) 2025/2392 before choosing a conformity route.
Hardware devices with security boxes
This category covers hardware devices that contain a security box, a protected enclosure that holds security functions such as key storage and cryptographic processing. The implementing regulation names physical payment terminals, hardware security modules and tachographs as examples. Check whether your device has a dedicated security box or whether security functions run on a general-purpose processor, because that distinction decides whether the product sits in this category at all.
Smart meter gateways and advanced security devices
The second category covers smart meter gateways within smart metering systems and other devices built for advanced security purposes, including secure cryptoprocessing. Products here usually perform security functions as their core job, not as a supporting feature. Confirm with your legal and technical teams whether your product's primary purpose falls inside the Annex IV wording, and document that reasoning in your risk assessment.
Smartcards and secure elements
This category covers smartcards and similar devices, including secure elements. The implementing regulation gives examples such as TPMs, embedded UICCs, identity documents, payment cards and access cards. Secure elements must provide protection of at least Common Criteria AVA_VAN.4. If your product embeds a secure element from a supplier, ask that supplier for evidence of its assurance level before you assume the category applies or does not apply to your product.
Components sold separately or inside a larger product
A secure element or security box sold on its own can fall in an Annex IV category, while the same component built into a larger product may be assessed as part of that product. Decide early which unit you place on the market and who makes the conformity claim. Mixed supply chains, where one supplier sells a component and an integrator sells the finished product, need a written allocation of responsibilities.
Commission power to add or remove categories
Article 8(2) lets the Commission add or withdraw Annex IV categories. The trigger is either that essential entities under the NIS 2 Directive critically depend on the product type, or that an incident could seriously disrupt critical supply chains. Your product may move in or out of the critical tier without any change to its design. Monitor Commission publications and build a periodic scope review into your compliance calendar.
Confirm against the technical description
Do not rely on category names alone. Read the technical description in Implementing Regulation (EU) 2025/2392 for your category, compare the product's functions and security boundary against it, and record the result. Where the match is unclear, document the open question and seek legal or notified body advice early, since the conformity route depends on this classification.
How Article 8 sets the conformity assessment route
Critical products never use self-assessment under module A. Article 8 places the three Annex IV categories outside the default route. Unless the Commission has adopted a delegated act under Article 8(1) requiring a European cybersecurity certificate at assurance level at least substantial for a given category, a critical product must follow the class II procedures in Article 32(3): module B (EU-type examination) combined with module C (conformity to type), module H (full quality assurance), or an applicable EU cybersecurity certification scheme. For a product in an Annex IV category, the manufacturer's first decision is therefore which of these routes is open to it today, and whether a certification scheme already covers its category.
The certificate route is the one to watch. Where the Commission adopts a delegated act under Article 8(1), that act sets the requirement, and it must give manufacturers a transition period of at least six months, unless urgency justifies a shorter one. Ask the notified body and the product's category in *Commission Implementing Regulation (EU) 2025/2392* whether any such delegated act exists or is in preparation, and plan the certification timeline against the transition period it sets. Check the Commission's CRA implementation page for updates before committing budget to either route.
A notified body is involved whichever route applies to a critical product, because Article 32 requires third-party assessment for class II and critical products. The manufacturer still owns the technical documentation, the risk assessment and the EU declaration of conformity, and the notified body reviews and tests against that documentation rather than producing it. Before engaging a notified body, confirm the notification scope that covers your category in the Commission's NANDO database, and ask who prepares which parts of the technical file. Outside implementation help can prepare evidence and test records, but only the notified body issues the conformity certificate.
How an assessor tests the critical product route
An assessor starts by asking whether the product belongs in an Annex IV category at all. The manufacturer must show a written classification that ties the product's core functionality to the technical description in Commission Implementing Regulation (EU) 2025/2392, which gives the detail for each of the three critical categories. The record should explain why the product fits, and why nearby categories do not.
- Category match: the record names the Annex IV category and quotes the functional features that trigger it, such as a security box in a hardware device or a secure element in a smartcard.
- Boundary cases: components that look critical but are sold only as parts of a larger product need a documented view on whether they are placed on the market separately.
- Examples in the regulation: the implementing regulation names physical payment terminals, hardware security modules and tachographs as hardware examples, and TPMs, embedded UICCs and payment cards as smartcard examples. Assessors compare the product against these named examples.
- Version control: the record is dated and tied to the product version, so a later change in functionality triggers a fresh review.
- Common finding: a classification memo written at launch that was never revisited after a firmware change added a security function.
Confirm with your notified body or the market surveillance authority which evidence format they expect for the classification rationale before the file is finalized.
Once the category is settled, the assessor checks which conformity route applies. For critical products, the default is the class II procedure in Article 32(3): module B with module C, module H, or an applicable EU certification scheme. The assessor also asks whether the Commission has adopted a delegated act under Article 8(1) requiring a European cybersecurity certificate for this category. If such an act exists, its transition period and certificate requirement override the general route.
- Delegated act check: the file states whether an Article 8(1) delegated act covers the product and, if one is in force, which assurance level it requires.
- Fallback logic: where no delegated act applies, the record shows module B with module C, module H, or a certification scheme, and explains the choice.
- Notified body engagement: the contract, scope letter and the notified body's identification number are on file, since a critical product cannot use self-assessment.
- Transition timing: the file dates the route decision against any transition period, so a product placed on the market mid-transition is not left on an expired route.
- Common finding: a manufacturer that selected module H for a product where a certification scheme was the more defensible route, with no written reasoning.
Ask the notified body to confirm in writing which modules they will assess for your product category before you commit to a timeline.
Where the product contains or is a secure element, the assessor looks for evidence of the protection level that Implementing Regulation (EU) 2025/2392 describes. Under that regulation, secure elements are designed to provide protection of at least Common Criteria AVA_VAN.4. The assessor asks for the evaluation basis that supports this claim, not a statement that the component is secure.
- Assurance claim: the file names the secure element, its hardware and software versions, and the protection level it is designed to meet at AVA_VAN.4.
- Evaluation evidence: a Common Criteria certificate or evaluation report, with its scope, target of evaluation and any conditions, is requested where the component relies on one.
- Scope match: the assessor checks that the evaluated configuration is the one shipped in the product, including firmware and the operating environment.
- Vendor dependency: when the secure element comes from a supplier, the manufacturer obtains the supplier's evidence and the terms under which it can be shared with the assessor.
- Common finding: an evaluation certificate covering an earlier chip revision or a different firmware build than the one in the product.
Confirm with your component supplier and the evaluating body which assurance evidence can be disclosed to a notified body and under what confidentiality terms.
The final test is whether the technical documentation and the EU declaration of conformity match everything above. The assessor reads the file as a whole and checks that the classification, route, assurance evidence and product description agree. The EU declaration is issued by the manufacturer and must reflect the conformity assessment actually performed, including the notified body's involvement on a critical product.
- Consistency check: product name, version, category and route appear identically in the classification record, the technical file and the declaration.
- Essential requirements: the file shows how Annex I requirements were applied on the basis of the manufacturer's cybersecurity risk assessment, with traceable evidence for each.
- Declaration accuracy: the declaration cites the correct conformity route and notified body, and it is kept available for the period the regulation requires.
- Update trail: each substantial modification produces a new assessment, and the file records which version each declaration covers.
- Common finding: a declaration that names self-assessment for a product whose file records a notified body certificate.
Before submission, ask the notified body to review the technical file against the route they are assessing, since the consistency of this one document often decides how many review cycles the file needs.
Steps to classify and prepare a critical product
This sequence takes a product from an initial Annex IV check to a documented, notified body ready conformity route, so the manufacturer can show why the product is critical, which assessment path applies and what evidence the assessor will need. Each step closes with a written output that the next step relies on.
Confirm the product fits an Annex IV category
Start by comparing the product against the three Annex IV categories: hardware devices with security boxes, smart meter gateways and other advanced security devices, and smartcards or similar devices including secure elements. Read the category wording together with the technical description in Implementing Regulation (EU) 2025/2392, which names physical payment terminals, hardware security modules and tachographs as hardware examples, and TPMs, embedded UICCs, identity documents, payment cards and access cards as smartcard examples. The manufacturer's product or engineering lead owns this check, with legal input where the product sits near a boundary. The step is complete when the team can state which category applies, or that none does and the product falls into a lower class.
Record the classification rationale
Write a short classification memo that names the Annex IV category, quotes the product features that match the technical description and lists the features that were considered and rejected. Include the product version, the intended use and any component that makes the product a security box, secure element or advanced security device. Keep the memo with the technical documentation so that a notified body, market surveillance authority or auditor can trace the decision. The output is a dated, versioned rationale signed off by an accountable manager, and it must be revisited when the product design changes materially.
Check for Article 8(1) delegated acts and certification schemes
Before choosing a route, check whether the Commission has adopted a delegated act under Article 8(1) that requires the product category to hold a European cybersecurity certificate at assurance level at least substantial. Such an act carries a minimum six-month transition period unless urgency justifies a shorter one. Also check whether an applicable EU cybersecurity certification scheme exists for the category. The compliance lead records the result of both checks in the classification file. The output is a documented statement that either a delegated act or scheme applies, with its effective date, or that none applies at the time of the check.
Select the class II conformity route
Where no Article 8(1) delegated act applies, Article 32(3) requires critical products to follow a class II procedure: module B combined with module C, module H, or an applicable EU certification scheme. Module B and module C involve a notified body examining the design and production, while module H is built on full quality assurance. The engineering and compliance leads compare the options against the product's production model, existing quality system and internal capacity, then document the chosen module and the reason. The output is a written route decision that names the module or scheme, the notified body candidates and the scope of the assessment.
Engage a notified body early
Critical products need a notified body under the class II route, so contact candidate bodies before the design freezes. Ask each body whether it is notified for the relevant Annex IV category and module, how it plans its assessment of the technical documentation and what samples, access and staff time it expects from the manufacturer. Notified bodies are listed in the Commission's NANDO system, so check that listing before signing. Quotes should break out assessment fees, re-assessment for changes, and any testing the body subcontracts. The output is a signed assessment agreement and an agreed timetable, and no one should promise dates until that timetable is confirmed in writing.
Prepare technical documentation and secure element evidence
Assemble the technical documentation that the chosen module requires, covering the product description, the cybersecurity risk assessment, the Annex I essential requirements, the vulnerability handling process and the test results. For secure elements, collect evidence that the element is designed to provide protection of at least Common Criteria AVA_VAN.4, such as the security target, evaluation reports and the evaluation level stated by the supplier. Where a component comes from a third party, collect that supplier's evidence and record the due diligence. The implementation partner can prepare systems, test records and evidence packs, but the manufacturer keeps ownership of the declarations. The output is a complete, version-controlled documentation set that the notified body can review without further engineering input.
Monitor Article 8(2) and delegated act changes
Set up a standing watch on two triggers. The first is an Article 8(1) delegated act that could add a certification requirement to the product category. The second is an Article 8(2) decision by which the Commission adds or withdraws Annex IV categories, which can happen where essential entities under the NIS 2 Directive critically depend on a product or where incidents could seriously disrupt critical supply chains. The compliance lead reviews the Commission's publications and the notified body's guidance on a fixed cadence and records each review. The output is a dated monitoring log that shows what was checked, what changed and what action followed, so the classification memo and route decision stay current.
Assessor test approach and evidence for Article 8
This table sets out the questions an assessor is likely to ask about an Annex IV critical product, the evidence each question calls for, and the findings that most often delay conformity. Read it as a pre-assessment checklist, and confirm the open points with the notified body or the Commission before relying on a route.
| Test question | Evidence requested | Common finding |
|---|---|---|
| Is the product correctly classified as critical? | Written classification analysis against the three Annex IV categories and the technical description in Implementing Regulation (EU) 2025/2392, with the core functionality stated | Core functionality described too broadly, or a component that performs the Annex IV function treated as out of scope |
| Does the chosen route match Article 32(3)? | Conformity route record showing module B with module C, module H, or an applicable EU certification scheme, and the notified body involved | Self-assessment used by default, which is not available for critical products without an applicable Article 8(1) delegated act |
| Does a secure element show AVA_VAN.4 evidence? | Common Criteria evaluation evidence showing protection at AVA_VAN.4 or higher, with the evaluation scope matching the shipped hardware and firmware | Certificate covers a different chip, platform or configuration than the product placed on the market |
| Is there a delegated act requiring a European certificate? | Confirmation of whether an Article 8(1) delegated act applies to the category, with the required assurance level and any transition period | Teams assume no delegated act exists without checking the Commission's current publications, or miss a transition deadline |
| Are changes to the Annex IV categories monitored? | Dated watch record of Commission acts under Article 8(2), with an owner and a documented review of impact on the product's classification and route | No owner for regulatory watch, so a category change is found only during a later assessment |
| Are hardware security boxes and smartcard products matched to their listed examples? | Mapping of each product variant to the example devices named in Implementing Regulation (EU) 2025/2392, with reasons where the product sits outside the examples | Product families grouped together, so a variant that does not fit the description is assessed under the wrong category |
Evidence that satisfies the critical product route
A critical product route rests on a short set of records that prove the product sits in an Annex IV category and that the right conformity procedure was followed. Each card below is a record the manufacturer owns, and each needs a named owner and a review trigger so it stays accurate between assessments.
Classification memo with Annex IV mapping
A dated memo that states the product's core functionality, names the Annex IV category it falls into, and quotes the matching technical description in Implementing Regulation (EU) 2025/2392. Map each product feature to the category wording, so the reasoning is visible to an assessor. Re-open the memo whenever the hardware, the secure element supplier or the intended use changes. Ask a qualified reviewer outside the product team to sign off, because the category decision drives every later step.
Route decision record
A record showing why the manufacturer chose the Article 8(1) certificate route or the class II procedures of Article 32(3), such as module B with module C, module H, or an applicable EU certification scheme. Note which Article 8(1) delegated acts exist for the category at the decision date. Store the record with the classification memo and date each review, because a later delegated act can change the route and the transition period matters for planning.
Notified body certificate or EU certificate
The certificate issued by an independent notified body, or the European cybersecurity certificate where a delegated act requires one. The manufacturer keeps the original, the scope statement it refers to, and the product versions it covers. Confirm the certificate's validity dates, the issuing body's notification status in the Commission's NANDO system, and what happens to coverage when firmware or hardware changes. DeployOpen can prepare the evidence for the assessment, but only the certification body issues the certificate.
Common Criteria evaluation evidence for secure elements
For secure elements in the smartcard category, the evaluation evidence that shows protection at least at Common Criteria AVA_VAN.4, as set out in Implementing Regulation (EU) 2025/2392. Keep the evaluation report, the security target, the certified product identifier and the assurance level claimed. Check that the evaluated configuration matches the shipped firmware and that any composite product still falls within the evaluated boundary. Ask the supplier for this evidence in the procurement contract rather than assembling it after the product ships.
Technical documentation index
An index that lists every document the assessor will request for the critical product: design descriptions, the essential requirements evidence under Annex I, the vulnerability handling records under Annex I Part II, and the EU declaration of conformity. Assign each entry a document owner, a version and a review date. A current index lets the team answer an assessor or market surveillance request quickly, and it reveals gaps before the assessment starts.
Article 8 watch log
A running log of two kinds of change: Article 8(2) proposals that could add or withdraw Annex IV categories, and Article 8(1) delegated acts that could require a European cybersecurity certificate. For each entry, record the date reviewed, the effect on the product, the transition period stated, and the action taken. Assign one person to check the Commission's CRA pages and the Official Journal at a fixed interval, and tie each change to a decision record so the log proves the product stayed compliant over time.
What meeting the critical product route costs
This table compares the six cost components a manufacturer of a critical product under Article 8 is likely to carry, who is paid for each, and whether it is one-time or recurring. Use it to shape a request for quote, not as a price estimate, since no figures for these components are set out in the regulation itself.
| Cost component | One-time or recurring | What drives it | How to reduce it |
|---|---|---|---|
| Classification and legal review | One-time, repeated when the product changes | Whether the product falls in one of the three Annex IV categories, and how closely its design matches the technical description in Implementing Regulation (EU) 2025/2392 | Document the classification reasoning early, and ask the notified body or counsel to confirm the category in writing before design freeze |
| Notified body assessment | Largely one-time per certificate, with recurring surveillance and re-assessment after significant change | Module B with module C, module H, or an applicable EU certification scheme, the size of the product family, and the number of design changes that trigger re-assessment | Ask which module the body will apply, request a fixed scope and fee schedule, and group product variants under one assessment where the body accepts it |
| Secure element evaluation (where applicable) | One-time per evaluated component, with recurring cost if the component changes | The Common Criteria level the secure element must reach (AVA_VAN.4 under Implementing Regulation (EU) 2025/2392), the number of components, and whether an existing evaluated component can be reused | Select components that already hold a suitable evaluation, and confirm with the supplier which evaluation covers the exact hardware and firmware version |
| Technical documentation upkeep | Recurring across the support period | Number of product versions, the depth of the cybersecurity risk assessment, the volume of SBOM and vulnerability records, and how many people update the file | Generate SBOMs and test evidence from the build pipeline, and keep one controlled document set tied to each release |
| Watch-list monitoring | Recurring | How often the Commission updates implementing acts, guidance and harmonized standards, and how many critical categories the product touches | Assign one owner to track official Commission and ENISA publications, and review the list at each planned release |
| Internal engineering time | Recurring, with a higher one-time load before the first conformity assessment | Gaps between current security practice and the Annex I Part I and Part II requirements, the number of teams involved, and the size of the codebase and hardware platform | Map existing security controls to Annex I before engaging outside help, and ask any partner for a fixed-scope list of deliverables |
Who does what on a critical product assessment
As the manufacturer, your organization remains legally responsible for conformity. Nothing in an outside engagement moves that duty. Internally, the work divides across three groups. The classification owner confirms which Annex IV category the product falls into, using the technical description in Implementing Regulation (EU) 2025/2392, and records the reasoning. Product and security engineering owns the design decisions, the cybersecurity risk assessment and the Annex I requirements that the product must meet. Legal and compliance owns the EU declaration of conformity, the technical documentation sign-off and the contract terms with suppliers and partners.
- Classification ownership: One named person decides the category and keeps a dated record of why the product is or is not a security box, smart meter gateway or secure element.
- Engineering ownership: Product and security engineers make and document the design choices that the assessment will examine.
- Legal sign-off: Legal reviews the declaration of conformity, the labeling obligations and the wording of any public claims.
- Supplier control: Procurement and engineering confirm that secure element and component suppliers can supply the evidence the assessment needs.
- Decision rights: Name who may approve a release and who may stop one.
Before the engagement starts, confirm in writing which of these owners is accountable for each piece of evidence.
An implementation partner such as DeployOpen helps prepare systems, controls and evidence for the assessment. The partner does not decide conformity, does not classify the product on the manufacturer's behalf and does not issue any certificate. Work is typically agreed as a fixed-scope engagement with written deliverables. Typical areas include preparing evidence and technical documentation, running a readiness review against the Annex I requirements, and supporting security testing whose results feed the assessment file.
- Evidence preparation: Organize build records, configuration baselines, test results and update procedures into a form an assessor can trace.
- Documentation support: Draft technical documentation sections for the manufacturer to review, approve and own.
- Readiness review: Compare the product and its evidence against the requirements and list gaps with owners and dates.
- Testing support: Arrange penetration testing and vulnerability analysis of the product, and record findings and fixes.
- Remediation work: Implement agreed fixes in the client's own infrastructure and document what changed.
Ask the partner to state in the scope which deliverables are documents, which are configured systems and which are test reports, and that the manufacturer keeps final approval of every item.
For critical products, the conformity assessment route runs through a notified body or another body the rules recognize. The notified body is designated by a Member State and listed in the Commission's NANDO system. It is the party that independently examines the product, the technical documentation and the manufacturer's processes, and it issues the certificate where the route requires one. Its independence is the reason the certificate carries weight, so the manufacturer and its advisers must not take over that judgment.
- Independent assessment: The body examines evidence and testing against the applicable requirements and reaches its own conclusion.
- Certificate issuance: Only the notified body or certification body issues the certificate that the route requires.
- Scope agreement: The body confirms the product, version and documentation it will assess before work begins.
- Findings and corrections: Non-conformities are reported to the manufacturer, which corrects them and resubmits evidence.
- Ongoing oversight: Confirm with the body how surveillance, re-assessment and changes to the product are handled.
Before you engage a body, confirm that it is designated for the relevant category, check its listing in NANDO, and ask it what evidence format it expects.
Common gaps in critical product classification
Most classification errors under Article 8 come from skipping a step: checking the Annex IV categories, testing secure element assurance, watching for delegated acts, or assuming self-assessment. Each card below names one gap, why it matters for critical products, and the check that closes it.
Assuming default or important status without checking Annex IV
Teams often classify a product as default or important from its marketing category and never test it against the three Annex IV categories. Hardware with security boxes, smart meter gateways and advanced security devices, and smartcards or secure elements each have a technical description in Implementing Regulation (EU) 2025/2392. A product that fits one of them is critical even if its label says otherwise. Closing step: write down the core functionality, compare it line by line with each Annex IV category, and record the result with the reasoning for your technical file.
Missing the secure element evaluation requirement
For secure elements, the implementing regulation expects protection of at least Common Criteria AVA_VAN.4. Teams that assume a certified chip or a vendor datasheet covers this often find that the evaluation level, the scope of the certificate and the product configuration do not match what they ship. Ask the component supplier for the exact certificate, its assurance level, the evaluated target and the configuration tested, then confirm that your product uses that configuration. Closing step: map each secure element in the bill of materials to its evaluation evidence before the conformity route is chosen.
Not tracking Article 8(1) and 8(2) changes
Article 8(1) lets the Commission require some Annex IV products to obtain a European cybersecurity certificate at assurance level at least substantial, through delegated acts with a minimum six-month transition period unless urgency justifies a shorter one. Article 8(2) lets the Commission add or withdraw Annex IV categories. A product classified today may face a new certificate requirement later, or a category may change. Closing step: assign an owner to watch Commission delegated acts and the Annex IV list, and review the classification at each release and before each market entry.
Treating the route as self-assessment
Self-assessment under module A is the default for most products, but critical products do not qualify for it. Without a delegated act under Article 8(1), critical products must use the class II procedures of Article 32(3): module B with module C, module H, or an applicable EU certification scheme. Teams that prepare only an internal declaration can end up with a file that does not support the CE marking they intended. Closing step: confirm the conformity route in writing with the notified body you plan to use before technical documentation work begins.
Questions buyers ask about Article 8 critical products
How do I know if my product is a critical product under the Cyber Resilience Act?
A product is critical when it falls within one of the three Annex IV categories: hardware devices with security boxes, smart meter gateways and other devices for advanced security purposes including secure cryptoprocessing, and smartcards or similar devices including secure elements. Commission Implementing Regulation (EU) 2025/2392 gives the technical description of each category and names examples, such as physical payment terminals, hardware security modules and tachographs for the first category, and TPMs, embedded UICCs, identity documents, payment cards and access cards for the third. Check the core functionality of your product against those descriptions, not just its marketing name. If the match is unclear, record your reasoning in the technical documentation and confirm the classification with your national market surveillance authority or a legal adviser.
Does a critical product always need a notified body?
In practice, yes, unless a Commission delegated act under Article 8(1) requires a European cybersecurity certificate instead. Where no such act applies, critical products must follow the class II procedures in Article 32(3): module B with module C, module H, or an applicable EU certification scheme. Module B involves a notified body examining the design, so an independent third party is part of the route. Confirm with your notified body and the current Commission guidance which modules and schemes apply to your specific category before you commit to a route.
What drives the cost and effort of conformity for a critical product?
The main drivers are the complexity of the product's security architecture, how much of the design you must document, the number of product variants and firmware releases, and whether the chosen route requires a notified body examination. Secure elements, for example, must provide protection of at least Common Criteria AVA_VAN.4 under Implementing Regulation (EU) 2025/2392, which adds evaluation work to the design. Your costs split into internal engineering time, third-party assessment fees, and recurring work such as vulnerability handling across the support period. Ask any partner for a quote that separates one-time documentation and testing from recurring obligations.
How long does the conformity route for a critical product take?
No researched timeline for conformity assessment of critical products is available for this page, so treat any duration you hear as unverified. The length depends on the route chosen, the notified body's queue, how complete your technical documentation is, and how many remediation cycles the assessment needs. Ask your notified body for its published workload and a written estimate of each stage. Note that the Article 14 reporting duty already applies from 11 September 2026, and the regulation applies to products generally from 11 December 2027, so plan your schedule against those dates.
Can our team handle critical product conformity in-house?
Often a team can handle the internal parts, such as the risk assessment, technical documentation, secure development records and vulnerability handling process, if it has engineers and compliance staff with the right skills. The notified body examination, and any Common Criteria evaluation for secure elements, usually needs an accredited third party. DeployOpen does not issue reports or certificates. It can plan, implement, harden and document the self-hosted open-source platforms, the evidence and the controls your team owns, under a fixed-scope written agreement, while the independent assessor makes the decision. Confirm which tasks your staff can carry out before you scope outside help.
What should I ask a partner for in a fixed-scope quote for critical product conformity?
Ask for a written scope that names the product, the Annex IV category and the conformity route, and lists each deliverable with its owner. A useful quote separates the work the partner performs, such as preparing systems, controls and evidence, from work the notified body or your staff performs. Request the assumptions behind the scope, including which product versions and environments are covered, what is excluded, how changes are priced, and what happens if the assessor requests additional evidence. Also ask who maintains the evidence after the first assessment, because the support period extends the obligations. Finally, confirm that the partner will not issue attestations or certifications.
How DeployOpen prepares evidence for critical product conformity
DeployOpen works on Article 8 critical products with digital elements by scoping the product's class and conformity route, building the self-hosted platform and records that support the manufacturer's evidence, and handing over documentation the manufacturer owns. Conformity decisions stay with the manufacturer and the independent body that assesses the product.
How we scope
- Confirm which Annex IV category, if any, the product falls under before any build work starts.
- Map the product's security boxes or secure elements to the Implementing Regulation (EU) 2025/2392 technical description.
- Agree a fixed-scope written plan covering deliverables, timelines and the systems in scope before work begins.
How we build
- Prepare self-hosted build, test and vulnerability tracking environments inside the manufacturer's own infrastructure.
- Set up component inventories and software bill of materials generation so dependencies can be traced for each release.
- Run security testing against the product, including secure element and hardware interface assessments where the scope includes them.
How we hand over
- Deliver technical documentation, test records and configuration baselines the manufacturer retains and maintains.
- Document how each evidence item maps to the relevant essential requirement, so the independent assessor can trace it.
- Transfer administration of all platforms and accounts to the client, with runbooks for operating them after handover.
How we support
- Support the manufacturer while the notified body or certification body reviews evidence and asks follow-up questions.
- Offer ongoing support, upgrades and continuous testing as a retainer once the initial engagement closes.
- Confirm with the assessing body which evidence format and certification scheme it will accept before final delivery.
