CRA in Your Own Product: How Important Am I Really?

The first post in this series addressed the fundamental question: Does a PowerPoint add-in like DrakeUp even fall under the Cyber Resilience Act?

My preliminary answer from a business perspective was: yes, probably.

DrakeUp is a software product, thus a product with digital elements, provided under the name of HAPP Digital GmbH and intended for use in a networked IT environment.

For this post, the working hypothesis is sufficient: I treat DrakeUp as a product with digital elements and thus consciously take the conservative path. The more interesting question is no longer the "whether," but the "how severe":

Into which CRA category does the product fall?

Is it a normal product with digital elements? An important product? Or even a critical product?

This classification determines which conformity assessment path is considered, whether a notified body needs to be involved, and how complex the proof of compliance will be. For a large company, this is an additional project strand. For a small product team, it can decide on budget, schedule, and market entry.

For DrakeUp, this question is business-critical. It directly affects product and profitability planning. In this early phase, external testing and verification costs can quickly exceed the planned annual revenues.

Modern software rarely consists of a single function. An add-in can authenticate users, store data, use interfaces, employ encryption, integrate libraries, or address an external service. However, this does not automatically mean that each of these functions determines the CRA category of the entire product.

For classification, it depends on what the product essentially is.

Is it a browser? A password manager? An operating system? A firewall? A hypervisor? An identity management system? Or is it another product that merely uses individual security-relevant functions or components?

This distinction is important for manufacturers. If every integrated component determined the classification of the overall product, hardly any normal software could be classified cleanly. Almost every modern application contains authentication, encryption, update mechanisms, or third-party libraries.

The correct initial question is therefore not:

"Which security-relevant functions are present somewhere in the product?"

But rather:

"Which function essentially defines the product?"

Only then can it be sensibly checked whether this core function falls into one of the lists for important or critical products.

For initial orientation, a simple structure helps. I use the term "standard product" as a working term. It refers to products with digital elements that fall under the CRA but are not explicitly listed as important or critical products.

DrakeUp is a PowerPoint add-in. Its core function is to support work in PowerPoint: to create content more structured, to prepare presentations more efficiently, and to facilitate recurring steps in the presentation process.

Therefore, it is not a security product, nor an identity management system, browser, or network component, even if these functions represent aspects of the software.

The initial description is: Productivity software for PowerPoint.

From there, the alignment with the CRA categories begins.

Based on the current product configuration, I see no category from Annex III that describes the core function of DrakeUp. DrakeUp is not a password manager, not a browser, not a hypervisor, not a firewall, not a SIEM, not a PAM system, and not an operating system. Annex IV also does not fit. DrakeUp is not a secure element, not a smart card, not a smart meter gateway, and not a hardware security module.

My classification is therefore: DrakeUp is a standard product.

For HAPP Digital, this is the essential insight. Even as a standard product, DrakeUp must meet the basic catalog of CRA security requirements. The difference lies not in whether security is required, but in how conformity is demonstrated and whether external bodies are involved.

For a small software product, this makes a significant difference.

One of the most common uncertainties arises with third-party components.

What happens if a product uses an encryption library? Or an embedded browser control? Or an authentication function? Does the overall product automatically become an important product?

The answer is: not automatically. The core functionality of the overall product remains decisive. A security-relevant component can increase risks and trigger documentation obligations, but it does not automatically change the CRA category of the product.

However, this does not mean that components disappear from consideration.

If DrakeUp uses a library for authentication, encryption, or API communication, this component must be included in the security consideration. It belongs in the risk analysis, in vulnerability management, and in the technical documentation. The software bill of materials (SBOM) also becomes more relevant as a result.

The category of the overall product thus remains a question of core function. The security requirements still affect the product as a whole, including the components used.

The CRA classification is not just a legal exercise. It affects product management and corporate governance.

An underestimation can lead to choosing the wrong conformity assessment path. This can later burden technical documentation, EU declaration of conformity, application of harmonized standards, CE marking, and market access or lead to market exclusion. An overestimation, on the other hand, can create unnecessary costs, delays, and coordination effort.

Both are avoidable if the classification is done early, thoughtfully, and transparently. It should consider current development but also potential further developments of the product.

I would therefore treat it like a documented product decision:

The last point is particularly important. Products evolve. If a product later receives functions that lean more towards identity management, security monitoring, privileged access, or network control, the classification must be re-evaluated.

The CRA classification is therefore to be actively managed by product management and re-evaluated in the event of significant changes.

It is also possible for the EU Commission to add new product categories to Annex III for important or Annex IV for critical products. This could subject CRA-compliant products to stricter conformity assessment procedures.

The following table is deliberately simplified. It does not replace an individual case assessment but shows the logic of classification.

A detailed listing of the affected products along with technical descriptions was provided by the EU Commission in December 2025 through an Implementing Regulation (EU 2025/2392).

For DrakeUp, the classification as a standard product is initially a good starting point. It means that the CRA does not automatically trigger an external testing procedure based on the current product configuration. The focus is on internal conformity assessment, technical documentation, and the actual implementation of appropriate security.

This may be less confidence-inspiring than holding an external certificate, but for this product, it is the economically right decision.

I now need to clarify what data the add-in really requires, which Office API functions are used, which external services are connected, which third-party components are used, and how updates, vulnerability reports, and security information are organized. These questions are regulatory relevant on one hand, but they are also normal questions of good product development.

The practical value of this self-experiment lies in turning abstract CRA requirements into concrete product decisions.

As a consultant, I can explain requirements, but as a manufacturer, I must translate them into product decisions. With DrakeUp, it's not about formally meeting regulatory minimum requirements. I want to build a useful add-in with security and traceability considered from the start.

After the scope check, classification begins. For many software manufacturers, this is the moment when the CRA becomes more practical because it has consequences. Now it is decided whether the path leads through internal control or whether stricter procedures and external bodies need to be planned.

For DrakeUp, the preliminary answer is clear: The core function is a productivity add-in for PowerPoint. Based on the current status, this core function fits neither in Annex III nor in Annex IV. Thus, DrakeUp is likely to remain a standard product, with internal control according to Module A as the obvious path.

The classification as a standard product makes the proof path more manageable. Risk analysis, technical documentation, and vulnerability management remain necessary.

I want to check product security not just shortly before launch, but treat it as part of product development.