Am I Affected by the Cyber Resilience Act?

In my daily work, I guide companies through the regulatory jungle of the Cyber Resilience Act, or CRA for short. It involves areas of application, manufacturer obligations, risk assessments, technical documentation, draft standards, and very specific security requirements.

Until recently, this was mainly part of my consulting routine.

Then the question suddenly became personal.

I founded HAPP Digital GmbH to develop a professional PowerPoint plugin. The working title is DrakeUp. After an initial mockup for technical validation, the redesign of the actual product is now underway. And with that came the exact question that also concerns many of my clients:

Does the CRA actually apply to my own project?

Is a PowerPoint plugin a CRA product?

DrakeUp is not a classic piece of software that you download as a file and install locally. Technically, it is an Office web add-in. PowerPoint loads, among other things, a manifest file in XML format. This describes how the add-in integrates into PowerPoint and which web resources it references. The manifest is not the actual application but the entry point through which PowerPoint loads the DrakeUp application.

At first glance, one might be tempted to say: "That's just a configuration file. Is that even software?"

For the CRA assessment, however, this question falls short. The decisive factor is not whether a single XML file, viewed in isolation, is already "software." I want to look at the overall picture: DrakeUp consists of an add-in concept, a manifest, loaded web resources, and a DrakeUp service that provides the product logic. There are also authentication services and a license server. Thus, it is no longer just a technical file in question, but a functional digital product.

Nevertheless, the classification remains non-trivial.

The CRA defines software as part of an electronic information system consisting of computer code. Furthermore, the CRA covers "products with digital elements," not only the software or hardware product itself but also the associated remote data processing or data teleprocessing, insofar as this is necessary for the product function.

My preliminary working hypothesis is therefore:

DrakeUp should be treated as a product with digital elements.

Not because every XML file would automatically be a CRA product, but because the overall offering as a PowerPoint add-in provides a software function that is to be loaded via the DrakeUp service and offered on the market.

The next question is at least as important: What role does the DrakeUp service play if no product function is available without it?

The CRA knows the term "Remote Data Processing Solution," meaning remote data processing. This refers to data processing at a distance when the software was developed by the manufacturer or under their responsibility and the product could not fulfill one of its functions without this processing.

This is relevant for DrakeUp. If the DrakeUp service is offline, the add-in does not function meaningfully. The service is thus not merely hosting or technical infrastructure but provides the product logic.

This is an important difference.

An isolated SaaS service does not automatically fall under the CRA just because it runs in the cloud. Cloud solutions only fall within the scope as a remote data processing solution if they meet the CRA definition and are necessary for a product function. Websites or cloud services that do not support the function of a product with digital elements or were developed outside the manufacturer's responsibility are not covered by the CRA for that reason alone.

With DrakeUp, it looks different: If HAPP Digital offers the add-in and the associated service from a single source, I must consider the entire system.

Of course, I could now spend a lot of energy formulating the business model so that DrakeUp lands as far outside the CRA as possible.

But that would be the wrong approach from my perspective.

I do not advise companies with the goal of avoiding regulation through verbal acrobatics. I advise companies with the goal of making digital products safer, more robust, and marketable. I must apply this exact standard to my own product.

The CRA is not just a compliance obligation. It is also a quality benchmark for me and my software.

I want to know what risks my product has. I want to know what components I use. I want to know how I deal with vulnerabilities. I want to know how updates are distributed. And I want to be able to explain to customers later why DrakeUp is professionally developed and operated.

This is all the more true because business models can change. Today, DrakeUp is intended as a web add-in with a central service. Tomorrow, a corporate customer might demand to operate the service themselves or receive a dedicated environment. At the latest, this turns an abstract scope discussion into a very concrete manufacturer question.

From a predominantly SaaS-oriented offering, a clearly deliverable software product can then emerge.

If I only start with CRA structures then, I am too late.

Therefore, I have decided not to develop DrakeUp bypassing the CRA but to use the CRA as a guideline for product conception.

This does not mean that I claim today that DrakeUp is "CRA-compliant." It would be too early for that. But I will systematically make the product CRA-ready.

The first step is an orderly cybersecurity risk assessment. The CRA requires manufacturers to assess the cybersecurity risks of their product and consider the result in planning, design, development, delivery, and maintenance.

This is exactly where I start.

For DrakeUp, I will clarify, among other things:

Part of the CRA implementation will be oriented towards harmonized standards. In May 2026, however, the standardization landscape is still in motion. The EN 40000 series includes, among other things, planned horizontal standards on principles of cyber resilience, generic security requirements, and vulnerability handling. Central horizontal standardization projects include EN 40000-1-2, EN 40000-1-3, and EN 40000-1-4.

I will therefore not pretend that there is already a final standard answer for every question.

Instead, I use the already recognizable guidelines:

• the requirements of the CRA itself

• the emerging European standards

• established security practices for web applications

• OWASP-oriented assessments

• traceable risk decisions

• documentation that can later be transferred into a technical CRA file

The CRA does not require academic perfection. It requires an appropriate level of cybersecurity based on the risks. For products with digital elements, this includes, among other things, secure default settings and providing without known exploitable vulnerabilities, as far as applicable based on the risk assessment.

Most of the material manufacturer obligations of the CRA apply from December 11, 2027. The reporting obligations for actively exploited vulnerabilities and serious security incidents apply from September 11, 2026.

That sounds like a lot of time. But for a real product, it is not. And for many companies with established existing products, it is even less time.

Anyone who only starts with risk analysis, component overview, vulnerability handling, update process, support logic, and technical documentation shortly before the end of the transition period will end up under pressure.

I want to avoid this pressure. And I want to show that CRA implementation is also feasible for small manufacturers if it is integrated early and pragmatically into product development.

I am aware that a new development is fundamentally easier than the subsequent securing of product architectures that have grown over years or decades. I can align decisions early and relatively cost-effectively with security requirements. I do not have large legacy software for which I must already consider reporting obligations organizationally this year. Moreover, the development and operation of a single software are significantly more manageable than CRA implementation in companies with hundreds or thousands of products.

Precisely for this reason, DrakeUp is suitable as a case study. It does not show the most difficult conceivable starting position. But it shows how to take CRA requirements seriously from the start and translate them into concrete product decisions.

In this series, I will document the CRA implementation for DrakeUp step by step.

Not as a theoretical textbook, but as a real product journey.

I will show how I assess the scope, how I formulate the intended use, how I identify risks, what security requirements arise from them, how I consider third-party components, how a vulnerability handling process for a small company can look, and how a robust technical documentation emerges from it in the end.

I hope that my thoughts and examples will inspire one or another entrepreneur, software developer, security architect, or compliance engineer.

I am looking forward to your reactions.