EN 18031 Asset Identification Guide for Cybersecurity Assessments

EN 18031 asset identification is the step that makes or breaks a cybersecurity assessment under the standard — yet the definitions in EN 18031-1, -2, and -3 make it genuinely difficult to get right. The terminology is inconsistent across all three parts, circular in places, and anchored in definitions that refer to each other. Alex Toohie of Element, working with Filippo Melzani and Arianna Gringiani from Security Pattern, sets out a structured four-step method that cuts through the ambiguity and works across all three parts of the standard. Two fully worked device examples show how to apply it in practice.  

 

What EN 18031 asset identification requires and why it is harder than it looks

EN 18031 is the harmonised three-part standard that sets cybersecurity requirements for connected devices under the Radio Equipment Directive (RED). Since August 2025, compliance with the RED cybersecurity delegated act has been mandatory for most wireless devices sold in the EU, making testing to EN 18031 a legal requirement for a significant proportion of connected product manufacturers.

The standard relies heavily on decision trees, but nearly all those trees begin with a "for each…" statement, meaning you need a complete, correctly classified asset list before you can work through any of them. Get the asset list wrong at this stage and every subsequent step of your assessment is built on a flawed foundation.

The challenge is that the key terms are not straightforward. The definitions for network asset, security function, privacy asset, and financial asset differ across all three parts. Some definitions refer to each other, and EN 18031-3 contains a circular reference in the definition of security function. For a product designer or compliance engineer approaching this for the first time, the standards offer little practical guidance on where to begin.

The most effective approach is to reverse the direction of the typical assessment. Rather than asking "what assets does the product have?", start by asking "what does the product do, and what data does it process?" Working backwards from functionality to assets cuts through the definitional ambiguity and ensures your asset list reflects how the product operates, not how you think the standard might categorise it.

 

Understanding the three parts of EN 18031

EN 18031-1: Network and security assets

Part 1 focuses on network functions. Any functionality on the product that provides or uses network resources, and security functions, which protect the network from harm or misuse. Assets arise not only from the functions themselves, but also from the parameters and configurations those functions depend on, where manipulating or disclosing a parameter could harm the network or lead to misuse of network resources.

One practical ambiguity to be aware of: there is no precise definition of what constitutes a network in EN 18031-1. Some assessors interpret this narrowly (a serial port connecting only two devices is not a network interface; Ethernet is). Others apply it more broadly. It is important to adopt a consistent interpretation and apply it throughout your assessment. Element and Security Pattern recommend documenting your interpretation rationale as part of the assessment record.

 

EN 18031-2: Privacy assets

Part 2 centres on personal information, defined as personal data, traffic data, or location data as used in the GDPR and the ePrivacy Directive. Any product functionality that processes personal information is a privacy function and therefore a privacy asset. Functions that protect users' or subscribers' privacy are classified as security functions.

Parameters and configurations become assets under Part 2 when their disclosure or manipulation could compromise user or subscriber privacy. Note that the definition of security function under EN 18031-2 is different from that in EN 18031-1, it refers specifically to measures that protect personal data and the privacy of the user and subscriber, rather than to network protection more broadly.

 

EN 18031-3: Financial assets

Part 3 deals with financial data, data that represents, provides information about, or is processed for transferring money, monetary assets, or virtual currencies. Functions that process financial data are financial functions. The standard is concerned with fraud prevention: parameters and configurations become assets when their manipulation or disclosure could enable fraud.

Part 3 contains a circular reference worth flagging: the definition of security function under EN 18031-3 refers to functionality that protects security assets or financial assets from being misused for fraud. In practice, this means you need to identify financial assets first before you can formally classify security functions. The pragmatic approach is to run through the financial function identification steps first, then revisit security function classification once your financial assets are confirmed.

 

The four-step method for consistent asset identification

Across all three parts, the same top-down method applies. Step 0 is additional and only required for Parts 2 and 3.

Step 0 — List all personal or financial data (EN 18031-2 and -3 only)

Create a comprehensive list of all personal data, traffic data, and location data (for EN 18031-2), or all financial data (for EN 18031-3) that the product processes. Identify which items are sensitive, meaning their manipulation presents a risk, or confidential, meaning their disclosure presents a risk. These items are immediately assets before you work through any other step.

 

Step 1 — List all product functionality

Create a complete list of every function the product performs. Include every interface, connection type, processing function, and feature, however minor it may seem. Completeness here is critical: missing a function at this stage means missing potential assets downstream.

 

Step 2 — Classify each function

Work through the list from Step 1 and determine which functions meet the definition of a network function, privacy function, financial function, or security function under the relevant part of the standard. Each qualifying function is an asset. Functions that do not meet any of these definitions can be set aside.

 

Step 3 — List all parameters and configurations for each qualifying function

For each function identified in Step 2, list every parameter and configuration that the function depends on. This includes cryptographic keys, credentials, identifiers, protocol settings, and any other data that defines how the function behaves.

 

Step 4 — Identify sensitive and confidential parameters

Work through the list from Step 3 and determine which parameters and configurations are sensitive, meaning harmful if manipulated, or confidential, meaning harmful if disclosed. Promote each qualifying item to an asset.

Combine the outputs from Steps 0, 2, and 4 to build your complete asset list.

 

Worked example 1: IoT environmental sensor (EN 18031-1 only)

Consider a simple IoT sensor designed to monitor temperature and air quality in a remote location. It transmits data to a backend server over a cellular connection. The device does not process personal or financial information, so only EN 18031-1 applies.

 

Step 1 and Step 2: List all functions and classify them

The device has four functions: temperature sensing, air quality sensing, cellular connectivity, and data processing. Of these, only cellular connectivity qualifies as a network function, as it is the only function that provides or uses network resources.

Temperature sensing, air quality sensing, and data processing do not meet the definition of a network function or a security function and can be set aside. Cellular connectivity is the first asset.

 

Step 3 and Step 4: List configurations and assess sensitivity

The cellular connectivity function depends on three parameters: the cellular IMSI, the cellular IMEI, and the SIM secret key. The IMSI and IMEI are neither sensitive nor confidential; disclosing or manipulating them does not present a meaningful network risk.

The SIM secret key is confidential because its disclosure could allow an attacker to misuse network resources.

Output - complete asset list for this device

• Cellular connectivity (network function)
• SIM secret key (confidential network function configuration)

 

Worked example 2: Biometric attendance tracker (EN 18031-1 and EN 18031-2)

Now consider a more complex device: a clocking-in and clocking-out system for a factory. Users sign in and out using an RFID fob or their fingerprint. The device connects to a backend server over Ethernet using TLS. A USB port allows data export, protected by an admin login. This device processes personal information (fingerprints, names, addresses), so both EN 18031-1 and EN 18031-2 apply. It does not process financial data, so EN 18031-3 does not apply.

 

Step 0 (EN 18031-2 only): Identify personal information

The device processes personal data, including names, addresses, and fingerprints. This information is confidential: its disclosure could compromise user privacy. Personal data is, therefore, immediately a privacy asset.

In practice, if different types of personal data are stored or transmitted separately, for example, fingerprints handled differently from names and addresses, each should be treated as a separate asset. For this example, all personal data is handled uniformly and can be grouped.

 

Step 1 and Step 2: List all functions and classify them

The device has six functions. Fingerprint reading is a privacy function because it processes personal data. RFID reading does not process personal information in this example and does not qualify. Data processing is a privacy function because it handles personal data.

Ethernet connectivity is both a network function and a security function: it uses network resources and protects personal data in transit through TLS. USB connectivity does not qualify. The admin login function is a security function because it protects access to personal data.

Note that RFID reading is classified as not qualifying here because we are assuming no personal information is transferred over RFID in this device. For other RFID implementations, this assumption may not hold and should be verified.

Data processing is an asset here, whereas it was not in the IoT sensor example. The difference is that this device's data processing function handles personal information, making it a privacy function.

 

Step 3 and Step 4: List configurations and assess sensitivity

Fingerprint reading and data processing have no dependent parameters worth noting in this example, so neither contributes additional assets at this stage.

Ethernet connectivity depends on a MAC address and TLS keys. The MAC address is public and is neither sensitive nor confidential. The TLS keys are confidential: their disclosure could compromise personal data in transit.

The admin login function depends on admin usernames and admin passwords. Usernames may be public and do not qualify. Passwords are confidential. Note that if the device uses a password hash rather than a plaintext password, the hash may be sensitive, meaning it should be protected from manipulation, but not necessarily confidential, meaning it is not necessarily a disclosure risk. The classification depends on the specific implementation.

 

Output: complete asset list for this device

• Personal data (confidential personal information)
• Fingerprint reading (privacy function)
• Data processing (privacy function)
• Ethernet connectivity (network function and security function)
• Admin login function (security function)
• TLS key (confidential security parameter)
• Admin passwords (confidential security parameter)

These two examples show how the same four-step method scales across both simple and complex devices. The key difference is not the device complexity, but whether personal or financial data is in scope, which determines which parts of EN 18031 apply and which additional steps are required.

 

Applying the four-step EN 18031 asset identification method to your product

Following this four-step process, product designers and engineers can work through EN 18031's complex, interdependent definitions without getting lost in them. Getting EN 18031 asset identification right at the start means your decision trees are grounded in accurate inputs, which reduces the risk of failing conformity assessment, avoids costly rework, and gets your product to market faster.

Starting from what your product does also protects you from two common mistakes: under-scoping, which creates compliance gaps, and over-scoping, which adds unnecessary cost and delays certification.

The method scales to any device. For a simple sensor, the process is quick. For a device handling personal data across multiple interfaces, the same steps apply; you repeat them for each relevant function.

Download the Asset Identification Guide below for a printable reference with the full definition diagrams, formatted for use alongside your assessment.

To understand more about Element's approach to cybersecurity testing for connected devices and the full range of services available to support EN 18031 conformity, visit our Connected Technologies page.