Annex III class I important products under the CRA

Which products fall into Annex III class I and why the route matters

Annex III class I covers 19 categories of important products, and whether a class I product can use self-assessment depends on one question: has the manufacturer applied the relevant harmonized standards, common specifications or a European cybersecurity certification scheme at assurance level at least substantial, in full. If yes, internal control under module A is available. If not, a notified body must be involved under module B with module C, or under module H. Start by mapping your product's core functionality against the 19 category descriptions in Commission Implementing Regulation (EU) 2025/2392, which is the authoritative technical description, and record why each matching category does or does not apply. Read the full Annex III text alongside it, since the category names alone are not enough.

The classification test in Article 7(2) asks whether a category either primarily performs functions critical to the cybersecurity of other products, networks or services, or performs functions carrying a significant risk of adverse effects, such as central system functions. A product that manages credentials, filters network traffic or runs the operating layer of other devices can plausibly meet that test, even when its marketing describes it as a convenience feature. Classification is hard when one product spans several categories. A smart home camera that runs a local virtual assistant, a browser with built-in password management, or a router with integrated VPN functions can each match more than one category. Document the primary function, the secondary functions and the reasoning for the category you select, because that record is what an assessor or market surveillance authority will ask to see.

Confirm two things before you commit to a route. First, check whether the harmonized standards that will cover your category are published and whether you can apply them in full, since partial application pushes you back to a notified body. Second, if your product is free and open-source software in an Annex III category, Article 32(5) allows any Article 32(1) procedure, including module A, provided the technical documentation is made public when the product is placed on the market. Ask your conformity assessment advisers to put the classification rationale, the standards applied and the route decision in writing, so the choice is traceable for the life of the product.

The 19 class I categories, grouped by function

Annex III lists 19 class I categories. Grouped by what they do in a product or network, they fall into a small number of clusters, and the grouping matters because it shows which products sit closest to the cybersecurity of other systems. The exact wording of each category sits in Annex III, and the technical description of each sits in Implementing Regulation (EU) 2025/2392.

Access and identity

This cluster covers identity management and privileged access management systems, password managers, and PKI and certificate issuance software. Implementing Regulation (EU) 2025/2392 expressly includes single sign-on, federated identity, one-time password and multi-factor authentication software in the identity management category. Check whether your product issues credentials, brokers authentication, or holds secrets, because those functions drive its classification.

Network and security tooling

This cluster groups VPN products, network management systems, SIEM systems and anti-malware software. Each one either protects other systems or sits in the middle of network traffic and security telemetry, which is why Article 7(2) treats them as functions critical to the cybersecurity of other products, networks or services. Confirm whether the product enforces security decisions or only reports on them, since that affects how an assessor reads its role.

Endpoint and platform software

This cluster includes standalone and embedded browsers, operating systems and boot managers. These products run on user devices or form the base layer that other software depends on, so a defect in them can spread widely. The browser category covers browsers with AI agent integration, so check whether your browser build includes such features before assuming it falls outside the category.

Network hardware and chips

This cluster covers network interfaces, routers, modems and switches, plus microprocessors, microcontrollers, ASICs and FPGAs with security-related functionalities. Hardware in this group is often built on a fixed firmware base, so the manufacturer must track firmware updates over the support period. Confirm which chip functions are security-related, because the wording of the category turns on that test rather than on the chip type alone.

Smart home and consumer devices

This cluster includes smart home virtual assistants, smart home security products such as door locks, cameras, baby monitors and alarms, and internet-connected toys with social or location features. These products reach consumers directly and often collect personal data, which makes weak default credentials and unpatched firmware a visible risk. Confirm the exact feature set of each device against the Annex III wording before deciding its category.

Health and children's wearables

This cluster covers certain health-monitoring wearables and children's wearables. Annex III limits this category to specific functions, so a general fitness or lifestyle device may fall outside it while a child-focused device with location or social features may fall inside. Review the Annex III entry word by word and document why your product does or does not match it.

How Article 7(2) decides whether a product is important

Article 7(2) of the Cyber Resilience Act gives two tests, and a product in an Annex III category is important if it meets either one. The first is whether the product primarily performs a function critical to the cybersecurity of other products, networks or services. The second is whether it performs a function carrying a significant risk of adverse effects, with central system functions named as the typical example. Classification is therefore not decided by the product's label alone. It depends on what the product does in the customer's environment and what breaks if it fails or is compromised. Read the category wording in Annex III first, then apply both tests to the product as it is actually shipped and configured.

The technical description in Commission Implementing Regulation (EU) 2025/2392 shows how a category can widen or narrow. Its identity management entry expressly includes single sign-on, federated identity, one-time password and multi-factor authentication software. A vendor that ships only a directory synchronization tool may find that its product does not sit inside that wording, while a product that issues federated tokens or enforces MFA for privileged logins clearly does, and that product almost certainly passes the first test because other systems depend on it for authentication. The browser entry includes browsers with AI agent integration. A browser that lets an agent take actions on behalf of a user or hold credentials is a different risk profile from a plain rendering engine, so the agent functions belong in the classification analysis. Check the product's feature set against each named element, not just the headline category. Confirm the current text of the regulation and implementing act on the official sources before you finalize any position.

Record the classification reasoning in the technical file. Name the Annex III category, quote the technical description element that matches, state which Article 7(2) test applies and why, and list the features you considered and excluded. Note the assessor-facing consequence too: if the product is class I, the manufacturer can use internal control only where harmonized standards are applied in full, so the reasoning should also show which standards are in use. Review the classification when a feature is added, such as an AI agent capability, a new authentication method or a central management function, because a change in function can move a product into a different category or change the route it must follow.

Self-assessment or notified body: the class I decision

When a class I manufacturer has applied in full the harmonized standards, common specifications or a European cybersecurity certification scheme at assurance level at least substantial, Article 32(2) allows internal control under module A. The manufacturer checks its own product, prepares technical documentation, issues the EU declaration of conformity and affixes the CE marking without a notified body reviewing the product. Full application means every requirement of the relevant standard is covered, not a selection of clauses that matter most to the team.

Full coverage: Map every clause of the chosen standard to a product feature, process or record, and document any clause that does not apply with a reason.
Published standards only: Confirm that the standard is published and cited in the Official Journal, because standards under request M/606 are still in development.
Assurance level: Where a certification scheme is used, confirm it is at assurance level at least substantial.
Technical documentation: Keep it current for the support period, since it must be available to market surveillance authorities.
Partial application: Applying some clauses of a standard does not qualify for module A, and the route falls back to a notified body.

Before relying on this route, confirm with the standardization bodies and your national authority which standards are published and whether they cover your category in full.

How to confirm class I status before you commit to a route

This sequence tests whether a product sits in an Annex III class I category, and whether it qualifies for internal control or needs a notified body. Each step ends with a record that goes into the technical file, so the route decision can be defended to an assessor or market surveillance authority.

Map product functions to Annex III wording
The product owner and the engineering lead list every function the product performs, including features that run on a server, in a companion app or in a cloud backend that the product depends on. Each function is matched against the 19 class I category descriptions in Annex III of Regulation (EU) 2024/2847. Where a function appears to fall in a category, the team notes the exact Annex III wording it relies on. The output is a function-to-category mapping table, with any unmatched functions marked for review. The step is complete when every function has either a matched category or a documented reason for no match.
Check the implementing regulation technical description
The compliance lead reads the technical description of each candidate category in Commission Implementing Regulation (EU) 2025/2392, which gives the scope detail that Annex III leaves open. For example, the identity management description expressly covers single sign-on, federated identity, one-time password and multi-factor authentication software, and the browser description covers browsers with AI agent integration. The team records whether each candidate category still applies after reading the technical description. The output is a short annotated extract for each candidate, citing the category it tests against. The step is complete when each candidate is either confirmed or dropped with a reason.
Test primary function against Article 7(2)
The security architect tests each confirmed category against the two limbs of Article 7(2). The first question is whether the product primarily performs a function critical to the cybersecurity of other products, networks or services. The second is whether it performs a function that carries a significant risk of adverse effects, such as a central system function. A product can fail the test even if its category matches, so the team records the answer to each limb separately. The output is a two-line Article 7(2) assessment per product, signed off by the person accountable for the product. The step is complete when the class I placement is either supported by at least one limb or withdrawn.
Record the rationale in the technical file
The compliance lead writes a rationale that links each product function to its Annex III category, its implementing regulation description and its Article 7(2) result. The rationale also states the product version and the date of the assessment, so it can be compared with later releases. Where the product is a free and open-source software product that the manufacturer intends to place on the market, the team notes this for the Article 32 route decision in the next step. The output is a dated classification rationale stored with the technical documentation. The step is complete when another engineer can reproduce the classification from the record alone.
Confirm the harmonized standards position
The compliance lead checks whether the harmonized standards, common specifications or European cybersecurity certification scheme that apply to the product category have been applied in full. Under Article 32(2), internal control under module A is available for class I products only where that application is complete. The team confirms the current status of the relevant standards with the standardization bodies and the Commission's published materials, because standardization work is ongoing and the position may change before the regulation applies. Where full application cannot be shown, the team records that a notified body route applies. The output is a standards status note listing each standard, its scope and whether it was applied in full. The step is complete when every standard is marked as applied in full, partly applied or not applicable.
Document the route decision and its output
The accountable executive approves one of three outcomes: internal control under module A, module B with module C, or module H with a notified body. Where module A is chosen for a free and open-source software product in an Annex III category, the decision records that the technical documentation will be made public when the product is placed on the market, as Article 32(5) requires. The decision record cites the rationale, the standards status note and the date of approval. The output is a signed route decision and a list of evidence to be produced for the chosen route. The step is complete when the decision is stored with the technical file and the team knows which independent body, if any, it must engage before the product is placed on the market.

How an assessor tests the class I classification and route

This table compares each test point an assessor applies to a class I important product, from the category match to the conformity route. Read it as a checklist: each row names what is checked, the evidence to prepare, and where manufacturers usually fall short.

Test point	Evidence requested	Common findings
Category match to Annex III class I	Written classification rationale mapping the product's core functions to one of the 19 class I categories	Rationale describes the product marketing name, not its core cybersecurity function, so the category is weakly justified
Technical description fit	Side-by-side comparison of product functions against the category description in Implementing Regulation (EU) 2025/2392	Products with embedded features (for example, AI agent browser integration or single sign-on) are not checked against the expanded category wording
Article 7(2) functional test	Explanation of whether the product primarily performs cybersecurity-critical functions for other products or carries significant risk of adverse effects	Manufacturer argues only the main use case and ignores central system or network-level roles
Standards applied in full	Register of harmonized standards, common specifications or certification scheme applied, with the scope each one covers and the assurance level	Standards cited selectively or only in part, which removes the basis for self-assessment under module A
Notified body involvement	Notified body certificate or the route chosen under module B with C, or module H, where full application is not shown	Manufacturer assumes self-assessment is available without confirming full application, so the conformity route is wrong
Open-source public documentation condition	Public release of the technical documentation at placing on the market, with the access location and version recorded	Documentation is published late, incomplete or behind a login, which breaks the condition for using module A
Route decision record	Dated decision memo tying classification, standards status and chosen module together, reviewed before CE marking	No record exists, so the manufacturer cannot show why a route was chosen during a market surveillance check

Evidence that supports class I classification and the chosen route

A class I product can only use self-assessment when the manufacturer can show both how the product was classified and how the chosen route was justified. The cards below are the records an assessor or market surveillance authority is likely to ask for, and each one needs an owner and a review date so it stays accurate as the product changes.

Classification memo

A dated memo that places each product function against the Annex III class I category text and the technical description in Implementing Regulation (EU) 2025/2392. It should state which function is decisive, why it meets the Article 7(2) test of primarily performing functions critical to cybersecurity or carrying a significant risk of adverse effects, and who approved it. Review the memo whenever a new feature, such as an AI agent integration or a new authentication method, changes what the product does.

Function-to-category mapping

A table that lists each product function, the Annex III category it falls under, and the component or module that delivers it. Products that bundle several functions, such as a router with a built-in VPN or a browser with password management, can fall into more than one category, so the mapping must show every overlap. Keep it in version control next to the product's architecture diagrams so the two cannot drift apart.

Harmonized standards compliance record

For self-assessment under Article 32(2), the record must show that each harmonized standard, common specification or certification scheme was applied in full, not in part. List every clause or requirement applied, the version used, and the evidence for each. Confirm the status of the standards with the European standardization organizations before relying on them, because the standardization request M/606 timelines are still being delivered.

Technical documentation and public release

Free and open-source products may use module A under Article 32(5), but only if the technical documentation is made public when the product is placed on the market. Publish the documentation in a stable location, record the release tag or commit it describes, and check that every later release has a matching public version. Ask legal counsel to confirm how the publication requirement applies to your licensing model.

Notified body certificate or contract

Where module A is not available, a notified body must be involved under module B with module C, or module H. Keep the signed contract, the certificate, its scope and its expiry or review date on file. Confirm that the notified body is listed in the Commission's NANDO system for the relevant category, and check that the certificate covers the exact product version you ship.

Substantial modification change log

A change log that links each release to an assessment of whether the change is a substantial modification. A substantial modification can move a product into the regulation's requirements or change its classification, so each entry needs a decision, a rationale and a reviewer. Keep the log with the classification memo so that a change in function triggers a review of the category and the route at the same time.

What classification and the conformity route cost in money and effort

This table compares the main cost components of placing a class I important product on the EU market, who is paid for each, and whether the cost is one-time or recurring. Read it as a checklist for building a quote, since no fee or duration figures are supplied for this route and the notified body fee is set by the body itself.

Cost component	Who is paid or who carries it	One-time or recurring, and what drives it
Internal classification of the product against Annex III	Your engineering, product and legal staff	One-time at first, then recurring whenever features change. Driven by how many functions the product performs and how many Annex III categories they touch.
Legal or product review of category and route	Outside counsel or a regulatory adviser, if used	One-time per product line. Driven by product ambiguity, such as embedded browsers or AI agent integration.
Standards gap work against harmonized standards	Internal teams or an implementation partner, with a fixed-scope written agreement	One-time for the initial gap. Driven by how many harmonized standards you must apply in full to keep the self-assessment route.
Technical documentation and evidence preparation	Internal engineering, plus any partner preparing systems and evidence	Mostly one-time per release, then recurring per version. Driven by product complexity and the number of releases.
Notified body assessment, where required	The notified body, whose fee it sets and you should request in a written quote	Recurring per assessment cycle. Required if harmonized standards are not applied in full, so confirm the route before budgeting.
Recurring review on substantial change	Internal teams, plus any assessor or partner you engage	Recurring. Triggered by substantial modification, so the cost rises with the frequency of major releases.

Who owns classification, who prepares evidence and who decides

The manufacturer is the legal owner of the Cyber Resilience Act position for a product. For a class I important product, the manufacturer decides whether the product falls in an Annex III class I category, reads the technical description in Commission Implementing Regulation (EU) 2025/2392, selects the conformity assessment route and signs the EU declaration of conformity. Nobody else can take those decisions on the manufacturer's behalf, and an outside party cannot make the product compliant by reviewing it.

Category decision: Record why the core functionality fits, or does not fit, each class I description, including edge cases such as identity features inside a larger platform.
Route selection: Decide whether harmonized standards are applied in full, which determines whether internal control (module A) is available under Article 32(2).
Declaration and marking: Own the EU declaration of conformity and CE marking once the route has been completed.
Post-market duties: Keep the support period, vulnerability handling and reporting obligations in the manufacturer's own processes.
Open-source treatment: If the product is free and open-source software, confirm the Article 32(5) conditions, including public technical documentation, before relying on module A.

Confirm internally who holds each decision and who signs before any partner begins work.

Where class I classifications usually go wrong

Most class I misclassifications come from reading the category name and stopping there. The gaps below share one root cause: the technical description in Implementing Regulation (EU) 2025/2392 and the conformity route in Article 32 are both narrower and more demanding than a quick read suggests.

Classifying by category name alone

A product named after a class I category can still fall outside it, and a product with a different name can fall inside it. The technical description in Implementing Regulation (EU) 2025/2392 sets the boundary, including what counts as identity management or a browser. Check the product's core functions against that text, record the reasoning in the technical file, and have the classification reviewed by someone who did not write it. Read the description before choosing a category.

Missing embedded browsers and interfaces

Browsers and network interfaces are easy to overlook when they ship inside another product. An embedded browser in a管理 console, a kiosk, a vehicle-adjacent display or an appliance can bring the product into a class I category even when the main function is different. Inventory every component that falls under a listed category, including those supplied by third parties, and decide classification for each one that performs the listed function.

Assuming open source removes obligations

Free and open-source software is not exempt from the regulation. Article 32(5) allows open-source products in Annex III categories to use module A, but only when the technical documentation is made public at placement on the market. A project that is hosted by a foundation or run by volunteers still needs a clear manufacturer, and a commercial company that packages or hosts the software usually takes on manufacturer duties. Confirm who is the manufacturer before publishing anything.

Claiming standards before they exist

Module A is available for class I only when harmonized standards, common specifications or a certification scheme have been applied in full. Several harmonized standards under standardization request M/606 were still in preparation at the time the regulation's guidance was issued, so a product cannot be said to apply them until they are published and cited. Until then, plan for a notified body route under module B with module C or module H, and document the reason for the choice.

Skipping reassessment after changes

A classification is tied to the product as it stood when it was placed on the market. A substantial modification can change its functions, its risk profile or its conformity route, and that triggers a fresh assessment. Adding single sign-on, a VPN client, a password vault or an AI agent integration to an existing product are examples of changes that can move it into a listed category. Set a review trigger in the change process so that every release is checked against the Annex III descriptions.

Leaving the decision undocumented

Auditors and market surveillance authorities will ask why a product was placed in a given category and why a given conformity route was chosen. A short, dated record that names the Annex III category, the technical description it was matched against, the components reviewed and the route selected answers that question. Without it, the classification cannot be defended even if it was correct. Assign an owner for the record and keep it with the technical documentation.

Questions buyers ask about class I important products

Can a class I important product be self-assessed under the Cyber Resilience Act?

Yes, but only under specific conditions. Under Article 32(2), a class I manufacturer may use internal control (module A) only where it has applied in full the harmonized standards, common specifications or a European cybersecurity certification scheme at assurance level at least substantial. If any of those are not applied in full, a notified body must be involved, through module B with module C or module H. The first decision is therefore whether your team can fully apply the relevant harmonized standards for your category, and that depends on which standards exist for your product at the time you place it on the market.

What does a notified body add, and what drives its effort?

A notified body is an independent conformity assessment body that Member States notify and that is listed in the Commission's NANDO system. It examines your technical documentation and conformity evidence, so it adds independent assessment to the work your team has already done. The effort depends on the completeness of your technical documentation, how much of the Annex I essential requirements you have covered through harmonized standards, the number of product variants and firmware versions, and how well your risk assessment and evidence are organized. Ask each candidate body for its assessment procedure, what it needs from you before work starts, and how it prices reassessments after changes.

How long does classification take to document?

The duration depends on how many of your product's functions you must map to the Annex III category descriptions and how many components you must check. Classification is not a single step: you match the product's core functionality to the category description in Commission Implementing Regulation (EU) 2025/2392, record why the product falls in or out of that category, and keep the reasoning in your technical file. Teams with a clear product architecture and a current bill of materials usually document it faster. Ask any partner to show how they will record the classification rationale and who signs it off, rather than accepting an estimate without a written scope.

What does the work need from our engineering team?

The work needs engineers who understand the product's security architecture, authentication flows, update mechanisms and third-party components. They provide the facts that the technical documentation and risk assessment depend on, verify that controls described on paper exist in the build, and maintain evidence over time. Expect ongoing involvement for vulnerability handling and support period obligations, not only a one-time pass. If your team lacks capacity, a partner can prepare systems, configuration evidence and documentation under a written scope, but your organization still owns its controls and decisions.

Can an open-source project use module A for class I products?

Yes. Article 32(5) allows free and open-source software in Annex III categories to use any Article 32(1) procedure, including module A, provided the technical documentation is made public when the product is placed on the market. This is a condition you must meet, not a shortcut. If your project is maintained by a foundation or company that commercializes the software, confirm which entity is the manufacturer and who is responsible for publishing the documentation before the release.

When should we bring in outside help?

Bring in outside help early if your product falls in a class I category where you cannot yet apply harmonized standards in full, because that decision determines whether a notified body is needed and how much documentation you must prepare. Outside help is also useful when you run self-hosted platforms that must produce security evidence, or when internal teams lack time for penetration testing and disclosure processes. DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own infrastructure and prepares systems and evidence for assessment. It does not issue reports or certificates, and independent assessors make those decisions. Engagements are fixed-scope, so ask for a written scope and deliverables before work starts.

Which costs should we ask a notified body or partner to break out?

Ask for separate line items for one-time work and recurring work. One-time costs usually include classification analysis, documentation preparation, harmonized standard gap work and the initial notified body assessment. Recurring costs include reassessments after substantial changes, vulnerability handling, security testing and support over the support period. The main cost drivers are the number of product variants, the completeness of your existing evidence and the amount of third-party component analysis. Any figure should come from a written quote tied to a defined scope, and the regulation's own fee levels are not a substitute for that quote.

How DeployOpen prepares class I evidence for your team

DeployOpen prepares the evidence behind a class I claim, but the conformity decision stays with your organization as manufacturer. Every engagement starts with a written scope that names the platform, the version, the class I category it falls under, the deployment environments and the functions in scope. Fixed-scope engagements are the norm, so the deliverables and timeline are agreed before work begins, and any quote follows from that written scope rather than from a published price list. Ask any implementation partner to show you this scope document before you sign anything.

Once the scope is fixed, the work maps the platform's functions to the wording of the class I category in Annex III and to the technical description in Implementing Regulation (EU) 2025/2392. For an identity management product, for example, that means checking whether single sign-on, federated identity, one-time password and multi-factor authentication functions are present, configured and documented, and whether each one is covered by a harmonized standard you intend to apply in full. The output is a traceable map from each class I function to the Annex I essential requirements, the configuration baseline, the test results and the support commitments your technical documentation will cite. Confirm with your assessor which harmonized standards are available for your category before you commit to the self-assessment route under Article 32(2).

DeployOpen does not issue EU declarations of conformity, CE marking decisions, certificates or notified body opinions. Those belong to you as the manufacturer and, where your route requires it, to a notified body. What DeployOpen delivers is the technical documentation package, the security configuration records, the vulnerability handling process evidence and the test reports that your team and any notified body will review. Where your open-source platform is distributed as free and open-source software under Article 32(5), confirm with counsel and your assessor what must be published and when, because the public availability of technical documentation is a condition of that route.

Annex III Class I important products