Showing posts with label SBOM. Show all posts
Showing posts with label SBOM. Show all posts

Sunday, August 2, 2026

CRA Annex II vs Annex IV Classification Explained: A Practical 2026 Guide


CRA Annex II vs Annex IV Classification Explained: A Practical 2026 Guide

CRA Annex II vs Annex IV classification explained sits at the heart of every EU Cyber Resilience Act project. We break down each product tier, show you how to pick the right conformity route, and share a simple step-by-step method. So you avoid costly mistakes and reach CE marking with confidence in 2026.

Why Product Classification Is the First Step in CRA Compliance

We always start CRA work with one question: how risky is your product? The CRA Annex II vs Annex IV classification explained approach helps answer that fast. Classification decides everything that follows. So getting it right early saves time, money, and stress.

The Cyber Resilience Act splits products into risk tiers. Each tier carries different rules. And each rule shapes your workload for months.


How Classification Determines Your Conformity Assessment Route

Your product tier sets your conformity assessment route CRA teams must follow. A low-risk product often needs only self-declaration of conformity. But a critical product may need a notified body EU CRA review.

So the tier is not just paperwork. It decides cost, timeline, and effort. Above all, it decides whether you can self-assess or must bring in outside help.


Getting It Wrong - Consequences of Misclassification

Misclassification hurts. Firstly, you may pick the wrong assessment path. Secondly, you may fail your audit and delay your launch.

Regulators can also impose fines. And a wrong CE marking route for software can trigger recalls. So we treat classification as a serious first step, not a quick guess.


CRA Product Categories Explained

The CRA uses a product risk tier system. Most products sit low. A few sit very high. Let us walk through each level clearly.


Default Category - The Majority of Digital Products

Most software and connected devices land here. This default category cybersecurity regulation covers apps, games, and simple tools. These products carry lower risk.


Self-Assessment Path and Documentation Requirements

Here you can use self-declaration of conformity. You test against the CRA rules yourself. Then you keep technical files, risk notes, and update records ready for inspection.


Annex III Class I - Important Products With Digital Elements

Class I covers important digital products with digital elements. These carry more risk than default products. So they need extra care.


Examples - Identity Management, VPNs, Network Management Systems

Think password managers, VPNs, and network management systems. Firewalls for home use also fit here. These tools protect access and data.


Assessment Options - Harmonised Standards or Third Party

You get a choice. Follow harmonised standards CRA fully, and you may self-assess. But skip them, and you must use a third party instead.


Annex III Class II - More Critical Products

Class II holds more critical products with digital elements. The CRA Annex III class I class II difference comes down to risk and impact. Class II products can cause wider harm if breached.


Examples - Operating Systems, Industrial Firewalls, Secure Elements


Examples include operating systems, industrial firewalls, and secure elements. Industrial automation CRA classification often lands here too. These sit deep inside critical systems.


Mandatory Third-Party Assessment

Self-assessment is not enough here. You must use a third-party body. So plan for extra time and budget.

Annex IV - Highly Critical Products


Annex IV holds the highest-risk products. These are critical products with digital elements at the top tier. They protect the most sensitive systems.

Examples - Smart Meter Gateways, Hardware Security Modules

Examples include smart meter gateways and hardware security modules. These guard energy grids and encryption keys. A breach here spreads far.


EU Type-Examination Required

Annex IV needs EU type-examination. A notified body checks your product design directly. So this route takes the most effort of all.


How to Classify Your Own Product Step by Step

We use a simple method with every client. It removes doubt. And it keeps teams aligned.


Decision Tree - Functionality, Intended Use, and Risk Level

First, look at what your product does. Secondly, check its intended use. After that, weigh the risk if it fails.


How to Classify Your Own Product Step by Step

This is how to classify product under CRA in plain terms. Match your product against the CRA critical product categories lists. Then place it in the right tier.

Tier

Risk Level

Assessment Route (2026)

Notified Body?

Default

Low

Self-declaration of conformity

No

Annex III Class I

Elevated

Harmonised standards or third party

Sometimes

Annex III Class II

High

Mandatory third-party assessment

Yes

Annex IV

Highest

EU type-examination

Yes, always

 

Borderline Cases - When a Product Sits Between Two Categories


Some products sit on the edge. A tool might act like Class I and Class II at once. So we check its most critical function first.

When in doubt, we pick the higher tier. This keeps you safe. And it prevents audit surprises later.

Using an Automated Classification Engine to Remove Guesswork


Manual classification takes hours. An automated engine cuts that to minutes. We use one that maps your product features against the CRA product classification rules.

The engine flags borderline cases too. So you never miss a hidden risk. Meanwhile, your team stays focused on building.

What Happens After Classification


Classification is the start, not the end. Next, you turn your tier into real controls. Then you pick your assessment body.

Mapping Classification to Your CRA Control Matrix


Each tier links to a control set. We map your class to a clear control matrix. So every rule ties back to a task and an owner.

This keeps your team on track. And it makes audits far smoother.

Control Matrix for Team Management Tier 1 Tier 2 Tiers Rule 1 Tier 3 Control Sets Rule 2 Rule 3 Task A Control Matrix Task B Tasks Owner X Task C Owners Owner Y Owner Z Team on Track Benefits Smoother Audits

Choosing Between Internal and External Conformity Assessment Bodies


Default and some Class I products allow internal checks. But Class II and Annex IV need external bodies. So choose your notified body early, since good ones book up fast in 2026.

FAQ

What is the difference between Annex III Class I and Class II?

Class I holds important products like VPNs and password managers. Class II holds more critical ones like operating systems and industrial firewalls. Class II always needs third-party assessment.


Does the CRA apply to SaaS products?

Mostly no. Pure SaaS often falls under other rules. But software sold as a product with digital elements can fall under the CRA.


Who decides which Annex my product falls under?

You classify first, based on the CRA lists. But a notified body confirms it for higher tiers. So responsibility is shared.


Can a single product fall under multiple categories?

Yes. A product may show features from two tiers. In that case, we apply the highest tier that fits.


What are harmonised standards under the CRA?

These are agreed EU technical standards. Follow them, and you gain a presumption of conformity. So they simplify your path.


Is a notified body always required for Annex IV products?

Yes. Annex IV always needs EU type-examination by a notified body. There is no self-assessment route here.


Conclusion

We hope this guide made CRA Annex II vs Annex IV classification explained clear and simple. Classification shapes your entire CRA journey. So start it early and get it right.

Above all, treat your product tier as the foundation for every control that follows. UbiComply.ai automates classification, control mapping, and audit readiness for you. So you can reach CE marking faster and with full confidence in 2026.


Thursday, July 30, 2026

SBOM Requirements for CRA Compliance: The Definitive Guide to Getting Your Software Bill of Materials Audit-Ready

Cybersecurity dashboard displaying a Software Bill of Materials (SBOM), software dependencies, vulnerability monitoring, and Cyber Resilience Act compliance automation.

Understanding SBOM requirements for CRA compliance is now critical for every manufacturer shipping digital products into the EU. This guide breaks down exactly what your software bill of materials must contain, which formats satisfy the Cyber Resilience Act, and how to automate SBOM generation inside your CI/CD pipeline - so you pass conformity assessments without scrambling at the last minute.

The SBOM requirements for CRA compliance have caught many product teams off guard. A software bill of materials is no longer a nice-to-have document tucked inside a developer wiki. Under the Cyber Resilience Act, it is a legal obligation. And the EU means business.

We have helped dozens of teams navigate this shift. The questions we hear most often sound the same: What goes into the SBOM? Which format do we pick? How often do we update it? This guide answers all of that - step by step, in plain language.

If you sell any product with digital elements inside the European market, this article is for you. The SBOM mandatory EU regulation deadline is approaching, and preparation needs to start now.

Why the Cyber Resilience Act Makes SBOMs Mandatory

The Cyber Resilience Act treats software supply chain transparency as a core safety requirement. Regulators want to know exactly what is inside every connected product. An SBOM delivers that visibility.

Think of it like an ingredient list on food packaging. Consumers deserve to know what they are consuming. Likewise, the EU believes buyers of digital products deserve to know which software components sit under the hood. The SBOM makes that possible.

Where SBOM Obligations Appear

The software bill of materials cyber resilience act obligations appear in several places. Annex I, Part II lists vulnerability handling requirements that lean on the SBOM. Annex VII references technical documentation that must include a component inventory digital products rely on daily.

The CRA does not use the word "SBOM" on every page. But the requirements it describes - listing components, tracking dependencies, linking them to vulnerabilities - add up to exactly what an SBOM provides. We always tell clients: if the regulation asks for a full ingredient list of your software, that is an SBOM.

SBOM as the Foundation of Vulnerability Management Under CRA

A vulnerability handling process is only as strong as the data behind it. When a new CVE drops, your security team needs to know within minutes whether your product uses the affected library. Without an SBOM, that search becomes a painful manual dig.

Illustration of a Software Bill of Materials showing software components, versions, suppliers, and dependency relationships.

We see teams waste days chasing down answers that a well-maintained SBOM surfaces in seconds. Vulnerability disclosure SBOM workflows make patching faster, reporting to ENISA smoother, and your overall risk posture stronger. The SBOM is not just paperwork. It is your early warning system.

What an SBOM Must Include to Satisfy CRA Requirements

Meeting SBOM requirements for CRA compliance starts with knowing the minimum data fields. An incomplete SBOM will fail a conformity assessment just as quickly as having no SBOM at all.

Minimum Fields - Component Name, Version, Supplier, Dependency Relationships

At a minimum, each entry in your SBOM must include the component name, its version number, the supplier or author, and its relationship to other components. This means you must capture both direct and indirect dependencies.

We also recommend including license information, download URLs, and cryptographic hashes. While the CRA does not mandate every one of these fields explicitly, notified bodies expect thorough documentation. The richer your SBOM, the smoother your audit.

Format Standards - CycloneDX vs SPDX for EU Conformity

Two dominant formats exist: CycloneDX and SPDX. Both produce a machine-readable SBOM format that satisfies the CRA's technical documentation expectations. But they differ in structure, ecosystem support, and adoption trends.

Here is a comparison to help you choose:

Factor

CycloneDX

SPDX

Maintained By

OWASP

Linux Foundation (ISO/IEC 5962:2021)

Primary Focus

Security and vulnerability tracking

License compliance and software provenance

ISO Standard

Not yet (under consideration)

Yes - ISO/IEC 5962

Vulnerability Linking

Native VEX integration

Supported via external documents

EU Regulatory Alignment (2026)

Growing preference among security-focused bodies

Strong due to ISO recognition

Output Formats

JSON, XML, Protobuf

JSON, RDF, XML, YAML, Tag-value

CI/CD Tooling Support

Broad (Syft, Trivy, cdxgen)

Broad (Syft, SPDX tools, Tern)

Dependency Depth

Excellent transitive support

Good but varies by tool

Learning Curve

Moderate

Moderate to steep

Best Suited For

CRA vulnerability management workflows

Organizations needing ISO-backed provenance

The CycloneDX vs SPDX CRA debate does not have a single winner. We recommend choosing based on your primary use case. If vulnerability management is your top priority, CycloneDX often fits better. If ISO recognition matters most for your conformity path, SPDX has the edge.

Which Format European Notified Bodies Prefer

As of 2026, most European notified bodies accept both formats. However, we see a growing lean toward CycloneDX for security-focused audits - largely because of its native VEX (Vulnerability Exploitability eXchange) support. That said, SPDX's ISO backing gives it strong standing in formal conformity processes.

Our advice? Pick one, master it, and make sure your tooling generates it consistently. Meeting the CRA SBOM format requirements matters far more than the format label itself.

How to Generate a CRA-Compliant SBOM

Knowing what to include is one thing. Actually generating a compliant SBOM at scale is another. Here is how we approach it when helping teams figure out how to generate SBOM for EU compliance.

Scanning Source Repositories vs Analyzing Build Artifacts

You can generate an SBOM by scanning source code or by analyzing compiled build artifacts. Each approach has trade-offs.

Source scanning catches declared dependencies early. But it often misses runtime-only libraries and dynamically linked components. Build artifact analysis captures the actual shipped product - giving you a more accurate picture of what reaches the end user.

We recommend combining both. Scan source repos during development for early visibility. Then analyze the final build artifact before release to catch anything the source scan missed. This two-pass approach satisfies SBOM requirements for CRA compliance more reliably than either method alone.

Automating SBOM Creation Inside Your CI/CD Pipeline

Manual SBOM creation does not scale. Every release needs a fresh, accurate SBOM. The only practical way to achieve this is through automated SBOM generation CI/CD integration.

Automated CI/CD pipeline generating an SBOM and performing continuous security and compliance checks.

We wire SBOM generation directly into the build pipeline. Every merge to the main branch triggers a scan, produces a new SBOM, and stores it alongside the release artifact. Software composition analysis tools like Syft, Trivy, or cdxgen handle the heavy lifting.

GitHub and GitLab Integration Examples

On GitHub, a simple workflow step runs Syft against your container image after the build job finishes. The output SBOM file gets attached as a release asset. On GitLab, a similar stage in your .gitlab-ci.yml runs the scan and pushes the result to the package registry.

We have built templates for both platforms. The setup takes less than an hour. After that, every release ships with a compliant SBOM - no manual intervention needed.

Handling Transitive and Vendored Dependencies

Transitive dependency mapping is where most teams stumble. Your product might declare ten direct dependencies. But those ten could pull in hundreds of indirect libraries. Every single one belongs in the SBOM.

Vendored dependencies - libraries copied directly into your repository instead of pulled from a package manager - create a different challenge. Standard scanners often miss them. We run secondary scans targeting vendor directories and statically linked binaries to catch these hidden components. Open source dependency tracking tools help flag anything the primary scanner overlooks.

Maintaining the SBOM Across the Product Lifecycle

Generating the SBOM once is not enough. The CRA demands ongoing SBOM lifecycle management throughout your product's supported life. This is where many teams fall short.

Versioning - New SBOM per Product Release

Every product release needs its own SBOM. Version 2.3.1 and version 2.4.0 may share most components, but even a single updated library changes the picture. We tag each SBOM with the product version, build ID, and generation timestamp.

This practice makes it easy to trace issues back to specific releases. When a vulnerability surfaces, you can check exactly which product versions carry the affected component - in seconds, not days.

Linking SBOM Components to Known Vulnerabilities in Real Time

A static SBOM sitting in a folder does nothing for your security posture. We connect SBOM data to live vulnerability databases like NVD and OSV. Every time a new CVE publishes, our system cross-references it against your component inventory.

This real-time linking is what turns an SBOM from a compliance artifact into an active defense tool. It supports the SBOM requirements for CRA compliance around vulnerability handling and makes your post-market surveillance obligations much simpler to meet.

Post-Market Update Obligations and SBOM Refresh Cadence

Under the CRA, manufacturers must provide security updates for at least five years - or the product's expected lifetime, whichever is shorter. Each update that changes the software composition triggers an SBOM refresh.

We recommend refreshing the SBOM with every patch, minor release, and major release. Between releases, continuous monitoring ensures you catch newly disclosed vulnerabilities in existing components. This cadence keeps you aligned with CRA post-market requirements and ready for spot checks by market surveillance authorities.

Security operations dashboard monitoring software vulnerabilities and SBOM data for continuous Cyber Resilience Act compliance.

Common SBOM Mistakes That Will Fail a CRA Audit

We have reviewed dozens of SBOM submissions. These three mistakes show up again and again.

Incomplete Dependency Trees

The most frequent failure: listing only top-level dependencies. An auditor will check for transitive components. If they find a library in your product binary that does not appear in the SBOM, the conformity assessment fails. Always run deep scans that capture the full dependency tree.

Static One-Time Generation Without Continuous Updates

Some teams generate an SBOM during initial development and never touch it again. By the time an audit arrives, the SBOM is months - sometimes years - out of date. Continuous updates through CI/CD integration eliminate this risk entirely.

Ignoring Firmware and Embedded Components

If your product contains firmware or embedded software, those components need an SBOM too. We see hardware manufacturers focus entirely on their application layer and forget the underlying firmware. The CRA covers all digital elements. No exceptions.

How UbiComply.ai Helps You Meet SBOM Requirements for CRA Compliance

We built UbiComply.ai to take the guesswork out of CRA compliance. Our CRA compliance platform maps every SBOM obligation to actionable controls. It tracks your progress, stores evidence, and flags gaps before auditors find them.

For teams that want hands-on tooling, our CRA-specific module integrates directly with your development pipeline. It automates SBOM generation, links components to vulnerabilities, and produces audit-ready documentation in the formats notified bodies expect.

Above all, we help you move from "we think we are compliant" to "we can prove it." That shift is what separates teams that pass audits from teams that scramble.

FAQ

What SBOM format does the Cyber Resilience Act require? 

The CRA does not mandate one specific format. Both CycloneDX and SPDX satisfy the machine-readable SBOM format expectation. We recommend picking the one that fits your tooling and sticking with it consistently.

Is an SBOM alone enough for CRA compliance? 

No. The SBOM is one piece of a larger puzzle. You also need a vulnerability handling process, technical documentation, a risk assessment, and a conformity assessment. But without a solid SBOM, none of those other pieces hold together. Think of the SBOM as the foundation.

How often do I need to update my SBOM under the CRA? 

We recommend updating with every product release and every security patch. Between releases, monitor for newly disclosed vulnerabilities across your existing SBOM components. This cadence satisfies SBOM requirements for CRA compliance and keeps you audit-ready.

Do I need an SBOM for open source projects? 

If you distribute an open source product commercially on the EU market, yes. Non-commercial open source projects may qualify for exemptions. But the moment your project enters a commercial product, SBOM obligations apply.

What tools can generate an SBOM automatically? 

Several strong options exist. Syft, Trivy, and cdxgen handle most ecosystems well. We connect these tools to our platform for automated SBOM generation CI/CD workflows that produce compliant output with every build.

What happens if my SBOM is incomplete during a conformity assessment? 

The assessment will likely flag non-conformities. Depending on severity, this can delay your CE marking, trigger additional audits, or block market access. An incomplete SBOM signals to auditors that your SBOM requirements for CRA compliance process needs serious improvement.

Conclusion

The SBOM requirements for CRA compliance are not optional, and they are not simple. But with the right process, tooling, and partner, they become manageable.

We have walked you through what your SBOM must contain, which formats work, how to automate generation, and which mistakes to avoid. Every step ties back to one goal: proving to regulators and customers that you know exactly what is inside your product.

Start building your SBOM process today with UbiComply.ai. The teams that treat SBOM requirements for CRA compliance as a continuous practice - not a last-minute checkbox - will be the ones that ship with confidence in 2027 and beyond.


UbiComply.ai - Compliance automation, cybersecurity governance, and audit readiness for the frameworks that matter most.


Your Complete Cyber Resilience Act Compliance Checklist for 2026: An 8-Step Guide for Manufacturers

The cyber resilience act compliance checklist is now a top priority for every digital product manufacturer selling into the EU. This guide w...