Assets: Security, Network, Privacy and Financial in EN 18031

If you are working on EN 18031 compliance (and therefore on RED regulations), there is one point that often trips up technical teams and documentation: the word "asset."

In common parlance, "asset" = "something of value."

In the EN 18031 standard, however, it is something much more specific: an asset is a target to be protected (or managed) because, if read, manipulated, or abused, it can have an impact on the network, security, or privacy.

And above all: we are not just talking about "data," but also about functions and configurations.

The standard distinguishes three main families which, depending on the part (Part 1 or Part 2), are combined in different ways:

Understanding the difference is very important because it influences which mechanisms become applicable, what you need to put in technical documentation, and what tests a laboratory/assessor expects to see.

Before delving into the three categories, let's establish the idea that EN 18031 formalizes that:

This is why an "asset" is not just "a database" or "a file," but can also be an endpoint, a service, a setting, a mechanism (e.g., update), or a key.

This approach is explicit in the definitions and structure of the requirements (decision tree, required information per asset, assessment of completeness and sufficiency).

In the first part of the standard, namely EN 18031-1, a security asset can be defined in three ways:

The key concept to understand is that security is viewed from the perspective of protecting the network and network resources.

Thus, the security function is "the functionality of the equipment relevant to protecting it from damaging the network or abusing network resources."

In the second part of the standard, EN 18031-2, the definition of security function changes focus: it is a measure that ensures that the personal data and privacy of the user/subscriber are protected.

So "security assets" exist in both parts, and what changes is the context of protection.

Let's look at a few examples to give the reader a better understanding of what classic security assets might be:

If a hacker obtains or alters these elements, they can "open the door" to other impacts: network abuse, pivoting, data access, etc.

In the first part of the standard, namely EN 18031-1, a network asset can be defined in three ways:

The key concept to understand is that it is not "the network" in the abstract that is being protected, but rather the product's ability to provide or use network resources (network functions) and their configurations.

Let's look at a few examples to give the reader a better understanding of what classic network assets might be:

So, the basic concept to keep in mind when talking about network assets is that you need to think about the risk you may have "towards the outside" (network, infrastructure, consumed resources).

In the second part of the standard, namely EN 18031-2, a privacy asset can be defined in five ways:

Here, the standard is very clear, and "personal information" includes personal data, traffic data, and location data (references to GDPR/ePrivacy).

Therefore, a privacy function is nothing more than a feature that processes personal information.

Let's look at a few examples to give the reader a better understanding of what classic privacy assets might be:

A classic mistake that many people often make is to consider only the data (e.g., "geolocation") as a "privacy asset" and ignore the privacy function configuration (e.g., "location sharing ON by default," "365-day retention," "automatic upload").

In the third part of the standard, namely EN 18031-3, a financial asset can be defined in five ways:

The key concept to understand is that the part concerning financial assets is viewed from the perspective of protecting data and functions that manage money/value transfers (including virtual currencies) and the configurations that determine their behavior.

The goal is not "just" to protect data, but to prevent anyone from performing unauthorized financial transactions or manipulating parameters that make fraud or abuse possible.

Let's look at a few examples to better understand what classic financial assets might be:

If a hacker obtains or alters these elements, the impact is immediate, such as theft of value, fraudulent payments, diversion of funds, or bypassing of controls (limits, authorizations, anti-fraud).

So far, we have clarified what security assets, network assets, and privacy assets are, i.e., not just data, but functions and configurations that, if exposed or manipulated, change the risk of the product.

At this point, the question is: ok, so what?

The answer is that this taxonomy is not a "textbook" classification: in EN 18031, it is a compliance routing mechanism.

In other words, the asset category you identify determines:

Many of the requirements in EN 18031 are explicitly written in terms of assets.

For example, access control (ACM) in Part 1 is formulated to manage access to security assets and network assets, while in Part 2 the same concept applies to security assets and privacy assets.

Therefore, if you misclassify an item (or worse, omit it), you risk excluding the very controls that the standard expects from the perimeter.

The standard does not ask you generically "do we have access control": it asks you for information for each accessible asset, i.e., a defensible description of:

Finally, asset classification also guides how an assessor evaluates tests. Typically, there are two levels:

If you have classified the assets incorrectly, you already fail due to lack of completeness, and the assessor finds a service, an endpoint, an undocumented configuration, and the chain of evidence is broken.

One of the questions our customers often ask us is: "How can I decide whether a piece of data is a security/network/privacy/financial asset?"

For simplicity's sake, we suggest using this triage:

1. Is it a network function or configuration (providing/utilizing network resources)?

If the answer is "Yes," then it is a network asset.

2. Is it a security parameter/function (keys, credentials, protection mechanisms)?

If the answer is "Yes," then it is a security asset.

3. Is it personal information or a function/configuration that processes it?

If the answer is "Yes," then it is a Privacy asset.

4. Is it financial data/function/configuration that enables or governs payments or transfers of value (e.g., checkout, wallet, limits, tokens/transaction IDs)?

If the answer is "Yes," then it is a Financial asset.

If it falls into multiple categories, then you can treat it as a "multi-asset," which means you will need to apply more conservative controls and tests.

In EN 18031, the distinction between security, network, and privacy assets is a compliance routing mechanism because it defines what you need to protect, how you need to document it, and how you need to demonstrate it.

To summarize what we have said and create a basic mental framework, you can divide the three assets as follows:

As of August 1, 2025, RED compliance has become mandatory.

All the assets we have discussed must be identified before any other section of the Technical Documentation, and it is important to do everything possible to avoid incurring penalties.

Identifying security assets on real firmware requires specific skills: binary analysis, network scanning, startup script review, dependency mapping.

Done manually, it takes weeks.

Our RedComply platform speeds up the compilation of security and all RED regulations by over 90%.

This is because RedComply automates the most labor-intensive parts of the process.

For example, you can upload the firmware and obtain an initial automatic mapping of all Asset Parameters in just a few days, achieving compliance with EN 18031 in no time.

Request a demo and our team will contact you to help you!

RedComply reduces EN 18031 compliance times by over 90%. Learn more at redcomply.com.