Is Your Product Important Under the CRA? Annex III and the Conformity Routes

Most products with digital elements can demonstrate conformity with the Cyber Resilience Act by internal control, which is self-assessment. The exceptions are listed, not judged: Annex III class I products can still self-assess, but only where the manufacturer applies harmonized standards or a relevant European cybersecurity certification scheme in full, and where it does not, Article 32 pushes it to an EU-type examination or a full quality assurance route involving a notified body. Annex III class II products and Annex IV critical products go through a third-party route regardless. Since the harmonized standards that would let a class I manufacturer self-assess are still being developed, the planning assumption for anything on the class I list should be that third-party assessment is possible rather than that it is avoidable.

Which list your product lands on is therefore the single largest cost and schedule variable in a CRA program, and it is decided by a fixed list rather than by risk appetite. Here is the list, what it means, and how to plan against it.

Key takeaways

• Most products with digital elements demonstrate conformity by internal control, which is self-assessment.
• The exceptions are listed, not judged. Which of the four tiers your product lands on is decided by a fixed list rather than by risk appetite, and it is the single largest cost and schedule variable in a CRA program.
• Annex III class I products keep self-assessment only where harmonized standards or a relevant certification scheme are applied in full. Those standards are still being developed, so plan for third-party assessment being possible rather than avoidable.
• Annex III class II and Annex IV critical products go through a third-party route regardless.
• Read the class I list line by line. Several entries, "identity management systems" and "network management systems" in particular, capture ordinary business software whose makers do not think of it as a security product.

The four tiers

There is one accommodation worth knowing: free and open-source software falling in the class I or class II important categories can self-assess where its technical documentation is publicly available, per the European Commission's summary of the legislative text.

Annex III class I: the list

This is a list to read line by line, because several entries capture ordinary business software that its makers do not think of as security products.

• Identity management systems, and privileged access management software and hardware, including authentication and access control readers, including biometric readers
• Standalone and embedded browsers
• Password managers
• Software that searches for, removes, or quarantines malicious software
• Products with a virtual private network function
• Network management systems
• Security information and event management (SIEM) systems
• Boot managers
• Public key infrastructure and digital certificate issuance software
• Physical and virtual network interfaces
• Operating systems
• Routers, modems intended for connection to the internet, and switches
• Microprocessors, microcontrollers, and ASICs or FPGAs with security-related functionalities
• Smart home general purpose virtual assistants
• Smart home products with security functionalities, including smart door locks, security cameras, baby monitoring systems, and alarm systems
• Internet-connected toys with social interactive features or location tracking, covered by the toy safety directive
• Personal wearable products with a health monitoring purpose

Two entries catch companies by surprise more than the rest. "Identity management systems" is broad enough to reach a B2B SaaS product whose main job is provisioning and access, not only a dedicated IAM vendor. And "network management systems" reaches infrastructure tooling that is sold as an operations product rather than a security one.

Annex III class II, and Annex IV

Class II is short and unambiguous:

• Hypervisors and container runtime systems that support virtualized execution of operating systems and similar environments
• Firewalls, intrusion detection and prevention systems
• Tamper-resistant microprocessors
• Tamper-resistant microcontrollers

If you build a hypervisor, a container runtime, or a firewall or IDS or IPS, a third-party conformity route is your baseline assumption and it belongs in the plan and the budget now rather than in 2027.

Annex IV covers critical products, where the Commission may require European cybersecurity certification at substantial level. For most companies reading this, class I is the live question and Annex IV is not.

Why the class I self-assessment route is not a plan yet

On paper, class I manufacturers can self-assess by applying harmonized standards in full. The harmonized standards that would make that possible are still being developed under the standardization request issued to support the CRA, and they arrive on their own schedule rather than on yours.

That creates a planning asymmetry worth taking seriously. If the standards land in time and cover your product type, self-assessment is available and the conformity work is documentation plus internal process. If they do not, or if they do not cover your product's characteristics fully, you need a notified body. Chapter IV, the machinery for notifying conformity assessment bodies, applies from June 11, 2026 precisely so that capacity exists before the December 11, 2027 deadline, and there is no reason to expect that capacity to be abundant in the final months.

The practical posture: plan for the third-party route, and treat a harmonized-standards self-assessment as an upside that shortens the project. Companies planning the other way round are the ones who will be queueing in 2027.

The technical documentation is the actual deliverable

Whichever route applies, what a notified body or a market surveillance authority reads is the technical file, and it is assembled from the same underlying work in every case: the risk assessment required by Article 13(2), evidence against each applicable Annex I Part I product requirement, the vulnerability-handling process from Annex I Part II with its software bill of materials, the support period determination under Article 13(8) and the reasoning behind it, the security update distribution mechanism, and the user information required by Annex II.

The strategic point is that the technical file is route-independent. Building it well is not wasted if you later discover you can self-assess, and building it badly does not become acceptable because you self-assessed. Teams that start with the file rather than with the route make progress under uncertainty; teams that wait for the standards to settle lose a year.

An existing ISO 27001 management system helps with the process discipline and the document control, and it does not substitute for any part of the technical file. Two different questions: is your organization managing information security systematically, and does this product meet the essential requirements.

When you should not be doing this yet

The honest boundary. If your products are all default-tier and your first CRA milestone is the September 11, 2026 reporting obligation, the right sequence is reporting capability first, technical file second. Reporting binds sooner, reaches products already on the market, and needs the least infrastructure.

If you are a class II manufacturer with no product security program at all, the conformity route is not your first problem either. The Annex I Part II vulnerability-handling requirements are, because a notified body assessing a product with no coordinated disclosure policy, no update mechanism, and no component inventory is going to find exactly that.

And if your product is not in scope at all, none of this applies, which is why the scoping question is worth answering carefully before any of this work starts.

Where Top Floor fits

We do the classification call and the technical file. Our EU Cyber Resilience Act practice covers the Annex III determination with the reasoning written down so it survives challenge, the gap assessment against Annex I Parts I and II, the vulnerability-handling program, and the documentation structure a notified body can read. Where testing evidence is thin, penetration testing supplies the security testing the vulnerability-handling requirements ask for.

We are not a notified body and we do not perform conformity assessments or issue CE marks. That separation matters for the same reason it matters in audit and assurance work: the party that builds your evidence should not be the party that certifies it.

How to decide this week

Take your CRA product inventory and put every item into one of four buckets: default, Annex III class I, Annex III class II, Annex IV. Use the lists above rather than a judgment about how security-relevant the product feels, and write down the reasoning for anything close to a boundary.

For everything in class I or class II, add a line to the 2027 plan for a third-party assessment, with the assumption that harmonized standards may not rescue you. For everything in any bucket, start the technical file now, because it is the same file either way.

Frequently asked questions

What is an important product under the CRA?

An important product with digital elements is one listed in Annex III of Regulation (EU) 2024/2847, split into class I and class II. Class I covers categories including identity and access management, browsers, password managers, antimalware, VPNs, network management systems, SIEM, boot managers, PKI software, operating systems, routers and switches, security-relevant microprocessors, smart home assistants and security devices, connected toys with interactive or tracking features, and health-monitoring wearables. Class II covers hypervisors and container runtimes, firewalls and intrusion detection and prevention systems, and tamper-resistant microprocessors and microcontrollers.

When does the CRA require a notified body?

Class II important products and critical products always take a third-party route, whether an EU-type examination, full quality assurance, or a European cybersecurity certification scheme at substantial level. Class I important products can self-assess where the manufacturer applies harmonized standards or a relevant certification scheme in full, and otherwise need a notified body. Default products can self-assess by internal control. Free and open-source class I and class II products can self-assess where their technical documentation is publicly available.

Can we self-assess our CRA conformity?

For default products, yes, using internal control. For Annex III class I products, only where you apply harmonized standards or a relevant European cybersecurity certification scheme in full, which depends on standards that are still being developed. The safe planning assumption for a class I product today is that a third-party route may be required, since notified body capacity is finite and Chapter IV only opens the notification machinery from June 11, 2026.

Does ISO 27001 help with CRA conformity?

It helps with the surrounding discipline and not with the conformity itself. ISO 27001 certifies that your organization runs an information security management system; the CRA asks whether a specific product meets the Annex I essential requirements and has a compliant vulnerability-handling process. The management system gives you document control, risk process, and supplier management that make assembling a technical file faster. It does not evidence a single Annex I product requirement on its own.