You’re probably in one of two situations right now.
Your team has a product headed for the EU market, and someone has finally asked the uncomfortable question: is this CRA Annex III Class I or Class II? Or you already suspect the answer, but you need to understand what that classification will do to your roadmap, evidence pack, supplier relationships, and launch date.
That question isn’t administrative. It changes how you build, how you document, and when you can ship. I’ve seen teams treat classification like a labelling exercise, then discover much later that they chose the wrong conformity route, involved the wrong stakeholders, or failed to budget for external assessment. By then, the damage isn’t theoretical. Engineering has to reopen work. Compliance has to rebuild the technical file. Commercial teams have to explain why launch moved.
The practical difference between Class I and Class II is not just “lighter” versus “heavier” compliance. It’s whether your business can keep much of the work inside its own operating model, or whether an external notified body becomes part of your go-to-market path.
The Critical First Step Understanding CRA Product Classification
Classification comes first because it dictates the rest of the programme. Before a team writes a control narrative, books test activity, or finalises release gates, it needs to know which CRA lane the product sits in.
Annex III of the EU Cyber Resilience Act creates a two-tier classification for important products with digital elements, separating Class I from Class II according to cybersecurity risk. Class II requires third-party conformity assessment by notified bodies, while Class I can permit self-assessment under specific conditions. The same Annex III distinction affects over 90% of IoT and connected hardware manufacturers targeting the EU, and the deciding factor is the product’s core functionality, not side features or branding, as outlined in the balena analysis of Annex III categories and their implications for manufacturers: https://forums.balena.io/t/class-i-vs-class-ii-how-to-know-where-your-product-fits/374163
What Annex III is really doing
The Act doesn’t ask whether your product has some security feature somewhere in the stack. It asks what role that product plays in a real environment.
A password manager, VPN client, desktop antivirus product, SIEM system, operating system, connected webcam, thermostat, or Wi-Fi extender may fall into Class I when its function aligns with the Annex III descriptions. Firewalls, IDS or IPS products, hypervisors, container runtimes, tamper-resistant microprocessors, and microcontrollers sit on the more sensitive end and are treated as Class II.
That distinction reflects impact. If a firewall fails or is compromised, the blast radius can affect a broader estate. If a password manager fails, the impact is still serious, but the regulatory treatment recognises a different risk profile.
The question product teams should ask first
Don’t start with the product name. Start with the function a buyer depends on.
Ask:
- What is the product’s main function. Does it protect endpoints, manage credentials, control access, inspect traffic, or maintain system integrity?
- What happens if it fails. Does failure mainly affect one user or device, or can it disrupt a wider environment?
- Which capability is primary. A connected sensor with encrypted transport isn’t automatically a security product. A device sold on access control or intrusion detection likely is.
Practical rule: If the feature appears in marketing but isn’t what the product is fundamentally for, don’t let that feature drive classification on its own.
Many teams go wrong by classifying from packaging language, not technical purpose. The safer approach is to document intended use, foreseeable use, and core function early. If you need a starting point on whether the Act applies at all, this CRA applicability overview is a useful first checkpoint: https://goregulus.com/cra-basics/cyber-resilience-act-applicability/
CRA Class I vs Class II A Detailed Comparison
Most confusion disappears once you compare the two classes side by side, not as legal labels, but as operating models.
| Area | Class I | Class II |
|---|---|---|
| Typical role | Important product with lower-impact cybersecurity profile | Important product with higher-risk or more central security role |
| Example products | Password managers, VPN clients, desktop antivirus, operating systems, SIEM systems, smart thermostats, connected webcams, Wi-Fi extenders | Firewalls, IDS/IPS, hypervisors, container runtimes, tamper-resistant microprocessors, microcontrollers |
| Assessment route | Self-assessment may be available under specific conditions, or Modules B+C / H | Third-party conformity assessment is mandatory via Modules B+C or H |
| Internal burden | Strong internal governance and evidence discipline | Strong internal governance plus external notified body coordination |
| Commercial effect | More control over sequencing and release timing | Less scheduling control, more dependency on outside review |
| Documentation posture | Must be good enough to defend self-assessment | Must be robust enough to survive independent scrutiny |
The real dividing line is conformity assessment
The single most important practical difference is this: Class I may allow self-assessment, but Class II doesn’t.
For Class I, manufacturers can use a bifurcated framework. Self-assessment is available if they apply the relevant harmonised standards or common specifications, and that route depends on showing alignment with prEN 40000-1-2 for risk assessment and cybersecurity lifecycle work and prEN 40000-1-3 for vulnerability handling, which includes 59 mandatory requirements across 6 phases. Class II removes that flexibility and mandates third-party assessment through notified bodies regardless of harmonised standard use, according to the Zealience CRA guide focused on Annex III operational consequences: https://zealience.com/resource-hub/cyber-resilience-act-guide-manufacturers/
That isn’t just a paperwork issue. It changes staffing, sequencing, and cost structure.
Time-to-market doesn’t move by weeks
Product teams usually feel the classification decision.
The operational gap is explicit. Class I manufacturers can compress time-to-market by 3-6 months through internal validation cycles, while Class II products add 6-12 months because external notified body coordination becomes part of the conformity timeline, as described in the same Zealience analysis of Class I versus Class II operating models: https://zealience.com/resource-hub/cyber-resilience-act-guide-manufacturers/
For a product leader, that means:
- Release planning changes. A Class II launch can’t be treated like a normal release with late-stage compliance sign-off.
- Budgeting changes. External assessment, audit preparation, remediation rounds, and scheduling buffers need to be funded earlier.
- Sales timing changes. Commitments to distributors, channel partners, and customers need more conservative dates.
A Class II product isn’t just harder to certify. It’s harder to schedule.
Practical examples that usually clarify the boundary
Consider a VPN client used by end users to establish secure remote access. That sits comfortably in the kind of product set Annex III places in Class I.
Now compare that to a firewall appliance controlling traffic at network boundaries. Its purpose is central to broader system security. That puts it in Class II territory.
A few more useful comparisons:
Class I style examples
- Password manager used by employees or consumers.
- Desktop antivirus shipped to endpoints.
- Connected thermostat with digital connectivity as part of a smart home setup.
- SIEM system in the Annex III category list.
- Operating system where the product aligns with the listed Class I category.
These products still require serious evidence. But the operating assumption is that, under the right conditions, the manufacturer may be able to own more of the assessment path internally.
Class II style examples
- IDS or IPS product inspecting and reacting to malicious activity.
- Hypervisor supporting broader system integrity.
- Container runtime in environments where workload isolation matters.
- Tamper-resistant microprocessor with security-critical significance.
- Firewall used as a core security control.
These products draw more scrutiny because they sit closer to the trust fabric of the environment.
Core functionality beats naming every time
Many mixed-function products become tricky.
A vendor may sell a “smart industrial gateway” that sounds operational rather than security-focused. But if the gateway performs access control, security policy enforcement, or traffic inspection as a core function, classification follows that function, not the product brochure.
Likewise, a “secure edge appliance” isn’t automatically Class II because the word secure appears in the name. If the security capability is supportive rather than primary, that matters.
Use a blunt test:
| Question | If the answer is yes |
|---|---|
| Is the product’s main purpose access control or credential management? | Lean towards Annex III important classification, often Class I depending on the function |
| Is it primarily detecting or preventing intrusions? | Lean towards Class II |
| Does it preserve wider system integrity or sit at a central control point? | Treat Class II as the stronger candidate |
| Is security only an enabling feature for a broader non-security function? | Don’t assume the security feature controls classification |
For teams working across mixed portfolios, this matters at programme level. One portfolio can contain products that fit both classes. That creates two compliance rhythms inside the same company. One stream may run on internal control. The other may need outside assessment, longer gates, and a different procurement plan for assurance work. This discussion of high-risk vendor treatment is also useful context when you’re mapping portfolio-level decisions: https://goregulus.com/cra-basics/eu-cra-revamp-targets-high-risk-vendors/
What works and what doesn’t
What works:
- Classify from architecture and intended use, not product naming.
- Separate core from ancillary features in writing.
- Model launch timing from the conformity route, not the ideal release plan.
- Keep product, security, compliance, and procurement in the same room when a Class II result is possible.
What doesn’t:
- Assuming every product with security features is Class II.
- Assuming harmonised standards make Class II easier in the same way they may help Class I.
- Waiting until documentation is nearly finished before checking whether a notified body is mandatory.
- Letting commercial deadlines drive classification logic.
Differential Obligations for Security and Updates
Once classification is set, engineering has to turn it into repeatable work. The legal category becomes a build and maintenance discipline.
The baseline obligations don’t disappear
Both classes still sit inside the CRA framework for secure development, vulnerability handling, updates, and evidence. The difference is how much scrutiny the manufacturer should expect, and how defensible the process needs to be under independent review.
For Class I, teams can sometimes work with an internally governed control set and produce evidence that supports self-assessment. For Class II, that same engineering workflow needs to withstand external challenge. Every shortcut becomes more expensive.
A few patterns show up quickly in practice:
- Threat modelling gets deeper for products that sit at a central point of trust or control.
- Update design matters earlier because vulnerability remediation has to be operational, not aspirational.
- Dependency visibility becomes a release issue, not just a security team issue.
Support periods and update promises become product commitments
The CRA framework requires manufacturers to think about the support window during development, not after launch. For consumer products, the support period extends to a minimum of 5 years, according to the Annex III overview and related CRA obligations discussed in the balena analysis: https://forums.balena.io/t/class-i-vs-class-ii-how-to-know-where-your-product-fits/374163
That has different consequences depending on class.
For a Class I smart thermostat or connected webcam, support planning is usually about sustaining secure patching, user communication, and component tracking over the declared lifecycle.
For a Class II firewall or hypervisor, the same support commitment often requires tighter patch governance, more formal regression testing, and clearer escalation paths. A bad update can create operational disruption beyond the product itself.
Operational advice: If your product protects a wider estate, treat every update as both a security event and a service continuity event.
Vulnerability handling cannot sit in a silo
The vulnerability workflow under Annex I Part II becomes much more visible when a product falls into Class II. Not because the law creates a separate universe of obligations for each class, but because the evidence burden and risk exposure are different.
A Class I product team can sometimes absorb vulnerability handling into an existing secure development lifecycle with moderate process reinforcement.
A Class II team usually needs sharper controls around:
- Component intake. Teams need reliable visibility into embedded libraries, firmware, and supplier components.
- Triage authority. Someone must be able to make fast decisions about exploitability, impact, and patch priority.
- Release governance. Security fixes can’t wait for a convenient feature release train.
- Cross-team coordination. Product, platform, QA, support, and legal all need a defined role.
That’s why update planning should start at architecture stage, not after technical documentation has been drafted. This CRA update requirements resource is helpful if your team needs to translate obligations into an operational update model: https://goregulus.com/cra-requirements/cra-update-requirements/
Two examples from real-world product planning
Example one: Class I VPN client
A VPN client team can often work effectively with:
- clear ownership of endpoint hardening requirements
- release notes that distinguish feature updates from security updates
- vulnerability intake channels connected to engineering
- documented rollback and support procedures
The work is still serious. But the team retains more room to align compliance with normal product cadence.
Example two: Class II container runtime
A container runtime sits much closer to workload trust, environment isolation, and platform integrity. That changes engineering behaviour.
The team usually needs:
- stronger evidence for architecture choices
- formal vulnerability workflows for runtime and dependency issues
- tighter control over change management
- clearer proof that security updates can be delivered without destabilising dependent environments
In other words, Class II doesn’t just add documentation. It raises the standard for operational discipline.
Documentation and Post-Market Surveillance Requirements
A compliant product is only half the job. The other half is proving it in a form that survives challenge.
Class I documentation has to justify trust
When a manufacturer uses the Class I self-assessment path, the technical file has to carry real weight. It must show how the product meets the applicable requirements, how risk was assessed, how vulnerabilities are handled, and why the chosen route is defensible.
That means weak documentation is not “good enough” because the route is internal.
A Class I file should be able to answer practical questions such as:
- What is the product’s intended purpose?
- Which cybersecurity risks were identified and how were they addressed?
- Which standards or specifications were applied?
- How does the product receive, test, approve, and distribute fixes?
- How long will the manufacturer support it, and why?
Class II documentation has to survive external scrutiny
For Class II, the same core materials are needed, but the mindset changes. You are not preparing a file just to support your own declaration. You are preparing a file that an external body may interrogate.
That affects writing quality, evidence traceability, and review discipline.
Good Class II documentation is organised like an audit-ready case file, not a bundle of engineering artefacts.
In practice, teams often need stronger version control over:
| Documentation area | Class I pressure point | Class II pressure point |
|---|---|---|
| Risk assessment | Adequate justification for internal route | Detailed, traceable rationale that stands up to review |
| Test evidence | Proof that requirements were checked | Proof that methods, scope, and outcomes are robust |
| Vulnerability process | Documented process exists and is used | Documented process is mature, repeatable, and reviewable |
| Change records | Changes are logged | Changes are linked clearly to impact and control evidence |
A solid technical file structure matters from the first release, not just before placement on the market. Teams that build documentation late usually end up reconstructing design intent from tickets, chat threads, and incomplete test outputs. This technical documentation resource is a helpful reference for shaping Annex VII evidence into something usable: https://goregulus.com/cra-documentation/technical-documentation/
Post-market surveillance is a living control
Post-market work often gets underestimated because it doesn’t block the first shipment in the same visible way as conformity assessment. But it becomes the long tail of compliance.
For Class I, post-market surveillance still requires active monitoring, vulnerability intake, corrective action processes, and documentation updates when the product changes.
For Class II, the same activities typically need tighter escalation paths and cleaner accountability. The product’s role in customer environments means field issues can have broader consequences. Support, security, compliance, and product management need a common operating routine, not parallel spreadsheets.
What fails most often isn’t the absence of a process. It’s fragmented ownership. Engineering has one view of the issue, support has another, and compliance only learns about it when evidence is requested.
How Classification Impacts Your Entire Supply Chain
The classification decision doesn’t stay inside product security. It moves through contracts, procurement, logistics, release management, and commercial commitments.
Manufacturers feel it first
For manufacturers, Class I and Class II create different control burdens.
A Class I programme usually lives or dies on internal maturity. Can the company run a disciplined risk assessment process, maintain documentation, control releases, and show credible vulnerability handling without relying on a third party to enforce structure?
A Class II programme adds another layer. The manufacturer still owns all of that, but now also needs to manage the external assessment relationship. That affects procurement, scheduling, and remediation planning.
Typical second-order effects include:
- Roadmap friction when engineering wants to add features near an assessment milestone.
- Budget pressure because outside review often creates rework windows.
- More formal supplier management when third-party components influence risk and evidence quality.
Importers and distributors inherit verification risk
Importers and distributors don’t build the product, but classification changes what prudent verification looks like.
With a Class I product, they still need confidence that the manufacturer has followed the proper conformity route and assembled the required materials.
With a Class II product, tolerance for ambiguity drops. If the product should have gone through notified body assessment, missing or weak evidence is much more than an administrative gap. It creates exposure for everyone placing that product on the EU market.
That has practical consequences in commercial relationships:
- importers ask harder pre-placement questions
- distributors want cleaner declarations and supporting files
- channel partners become less willing to rely on informal assurances
- contract language around updates, vulnerabilities, and corrective action gets tighter
Security and engineering teams feel the supply chain effects too
This is the part many organisations miss. Supply chain impact isn’t only about vendors and logistics. It also changes how internal teams work with external dependencies.
A Class I smart home device team might manage third-party libraries and components through normal supplier due diligence, supported by better recordkeeping and patch procedures.
A Class II firewall team has to think more aggressively about supplier evidence quality, dependency risk, and replacement options. If a key component supplier can’t provide timely vulnerability information, that becomes a compliance and continuity problem.
The higher the class, the less room you have for opaque suppliers.
A useful role-based view
Product management
Product managers need to translate class into launch logic. For Class II, “feature complete” is not the same as “market ready”. Launch commitments should reflect conformity timing, evidence maturity, and update readiness.
Procurement
Procurement teams need to ask suppliers for evidence that supports the manufacturer’s file, especially where components affect security claims or remediation capability. Generic assurances are weak protection.
Legal and compliance
Legal teams need contracts that support access to documentation, cooperation on vulnerabilities, and prompt support during corrective actions. Classification influences the level of contractual precision required.
Customer support and operations
Support teams are often the first to hear about failures or vulnerabilities in the field. If the product sits in a Class II role, support scripts, escalation channels, and issue logging all need more discipline because field intelligence can affect ongoing compliance.
What mature organisations do differently
They stop treating CRA classification as a legal verdict and start treating it as an operating assumption.
That usually means:
- product architecture reviews include classification implications
- supplier onboarding asks for security and evidence commitments
- release governance reflects the likely conformity route
- internal teams know who owns vulnerability intake, triage, approval, and customer communication
The organisations that struggle tend to isolate compliance in one function. The ones that cope best turn classification into a shared planning input across the full chain.
Your CRA Classification Roadmap and Checklist
The fastest way to make a bad classification decision is to rush straight to the Annex list and look for a product label that sounds familiar. Start from function, then document your reasoning.
A practical roadmap
Write down the core functionDescribe what the product is for in plain language. Not the marketing slogan. Not the aspirational roadmap. The actual capability the customer relies on.
Strip out ancillary featuresList supporting functions separately. Remote admin, encryption in transit, telemetry, and companion apps may matter, but they don’t automatically define the class.
Check whether the product’s core role aligns with Annex III examplesPassword managers, VPN clients, desktop antivirus, operating systems, SIEM systems, smart thermostats, connected webcams, and Wi-Fi extenders point in one direction. Firewalls, IDS/IPS, hypervisors, container runtimes, tamper-resistant microprocessors, and microcontrollers point in another.
Decide whether the product sits at a wider point of trust or controlProducts that govern access, inspect threats, preserve platform integrity, or protect broader environments deserve extra caution.
Map the likely conformity route immediatelyIf the result looks like Class II, plan for external assessment from the start. Don’t wait for documentation to mature before booking that logic into the programme.
Recheck on major product changesA significant software release can change the classification analysis if it alters core function, not just because it adds another feature.
Checklist questions that catch most mistakes
- If this function disappeared, would customers say the product no longer does its main job?
- Does the product primarily protect itself, or does it protect other systems, users, or environments?
- Is the security role central or supportive?
- Can one compromised instance create broader operational disruption?
- Do suppliers provide enough transparency to support your evidence and remediation obligations?
- Would an external reviewer understand and accept your reasoning from the file alone?
Edge cases need written reasoning, not intuition
Some products won’t fit neatly. A smart hub may aggregate data in one deployment and enforce access policy in another. A device management platform may look operational until you inspect the control plane. An industrial gateway may combine monitoring, routing, and security functions.
When a product is close to the line, document the logic in full. State what the core function is, what it isn’t, and why. Teams that work from a written rationale make better decisions when the product evolves.
For smaller organisations building this capability from scratch, it can help to pair CRA-specific work with a broader operational readiness list. This small business compliance checklist is a useful general reference for getting the surrounding governance basics in order.
Final working advice
If there’s a real possibility your product falls into Class II, act as though timeline pressure will increase and evidence expectations will rise. That assumption is usually cheaper than discovering it too late.
If your portfolio contains both Class I and Class II candidates, don’t force one governance model across all of them. Segment the programme. Different classes require different review gates, different external dependencies, and different commercial planning.
If you need a practical way to assess applicability, classify products, map obligations, and organise CRA evidence without running the whole programme in spreadsheets, Regulus is built for exactly that workflow.
