Financial assets according to EN 18031-3: what they are and how to identify them
If you are reading EN 18031-3 because you manufacture (or integrate) radio equipment with payment, wallet, banking, trading, or even "just" transaction authorization functions via app/device, sooner or later you will come across the concept of financial assets.
This is a deliberate choice by the standard: instead of saying "protect payments," EN 18031 reasons by assets, threats, mechanisms, evidence, and tests.
The key idea is simple: an attacker does not necessarily have to "steal money" directly. Often, it is enough for them to obtain (or alter) data and configurations that allow them to commit fraud. For this reason, EN 18031-3 deliberately defines "financial asset" broadly, including not only data, but also functions and configurations.
If you have read the EN 18031-3 standard, perhaps because you manufacture or integrate radio devices with payment, wallet, banking, or trading functions, or even "just" to authorize transactions from apps, sooner or later you will have come across the term financial asset.
The regulation has a very specific logic and serves to ensure that manufacturers of devices that carry out transactions launch products on the market that protect their customers.
The underlying concept is quite simple and worrying: an attacker does not necessarily need to "steal money" in the traditional sense of the term. Often, all they need to do is get their hands on certain data or modify certain configurations to pave the way for fraud.
The EN 18031-3 standard defines financial assets as the set of sensitive financial data, confidential financial data, sensitive financial function configuration, confidential financial function configuration, and the financial functions themselves.
This sentence alone tells you two important things:
It is not just about "data."
The standard distinguishes between "sensitive" and "confidential" aspects because the risk is not only disclosure but also manipulation.
To complete the picture, the standard also defines:
financial data: data that represents, provides information about, or is processed to transfer money/monetary assets/virtual currencies.
financial function: functionality of equipment that processes financial data.
financial function configuration: data processed by equipment that defines the behavior of financial functions.
Let's look at some examples
Here, it is best to think in terms of categories, following the structure of the standard's definition.
Financial data
In regulatory terms, financial data is any data that:
represents value
describes value
or is processed to transfer value.
Typical examples:
transaction details: amount, beneficiary, references, metadata
data identifying accounts or instruments: IBAN, account references, beneficiary aliases
in the case of crypto: wallet addresses, transaction payloads, parameters used for signature/authorization
tokens or references that enable a payment or disposition (pay attention to where they are logged or tracked)
The rule of thumb is that if that data, alone or in combination with other data, makes fraud or undue transfer possible, then it is financial data (and therefore potentially a financial asset).
Financial function configuration
This includes things that teams often underestimate:
limits and thresholds (daily limits, maximum amount)
beneficiary whitelists/blacklists
authorization rules: when MFA, OTP, strong signature are required
"routing" parameters: backend endpoints, certificates/keys used for validation, pinning, etc.
If someone manages to read or alter these configurations, they can transform a legitimate function into a "fraud-friendly" function. And that is precisely why EN 18031-3 includes them in financial assets.
Financial functions
Financial functions relate to operations such as sending, approving, signing, and enabling.
Here are some examples:
sending money, approving payments, signing transactions
managing beneficiaries (add/edit), setting limits
wallet management functions (depending on the product and scope)
The point is that even if data is well protected, if a hacker attacks a financial function and it does not have the right controls in place, fraud can still occur.
The EN 18031-3 standard states that assets are introduced as the main "targets" to which the requirements are applied and to which the three horizontal standards of the 18031 family are aligned.
There is also a summary table linking asset types to essential requirements (and for EN 18031-3, essential requirement 3.3.f is relevant).
One of the most useful phrases that clearly explains the main concept of this standard is summarized in this sentence:
> Protecting an asset does not only mean protecting "data," but also protecting the functions and configurations that use it.
The definition of financial asset includes the words "confidential" and "sensitive," which apply to both data and configurations.
In general, the most practical way to understand this is to know that:
confidential: if disclosure of the information enables damage (typically fraud)
sensitive: if the manipulation of the information enables damage (typically fraud)
In the financial domain, the standard is particularly explicit about the link between "confidentiality → disclosure → fraud," even in the definitions (for financial data and configuration).
You need this distinction to classify assets and decide what to test.
If the asset is confidential, you must demonstrate confidentiality protections (e.g., prevent leakage via logs, storage, traffic).
If the asset is sensitive, you must demonstrate integrity protections (e.g., prevent tampering with amounts/beneficiaries/configurations).
If we were to describe a clear and repeatable approach, these are the main points:
Inventory: create a complete list of financial assets, clearly distinguishing between data, configurations, and functions.
Classification: mark each asset as either primarily "confidential" (leak → fraud) or "sensitive" (tamper → fraud).
Data flow: draw the end-to-end flow of the financial function (client, backend, storage, log).
EN mechanisms: for each point in the flow and for each external interface, link the relevant security mechanisms.
Evidence: prepare the documentation required by the standard (the "required information" for the applicable mechanisms).
Testing: transform the assessment criteria into concrete test cases (including completeness and sufficiency).
Remember that financial assets are information or functional assets related to money that your device/app creates, processes, stores, or transmits and that, if compromised, can cause economic loss, fraud, unauthorized charges, tampering with amounts/transactions, or unauthorized access to funds/credit.
To fill in the "Financial assets" table, you need to think row by row, where each row describes a single financial asset (data or "object" that enables/conditions an economic transaction).
How to fill in field by field
1) asset_name (Financial Assets)
Here you must give this data a clear name. It is best to use a unique and descriptive name.
For example: `FA01PaymentToken`, `FA02TransactionData`, `FA03_Balance` (simply describe "what it is").
Avoid generic names such as "Payment."
2) accessible_by_entity (Is it accessible by an entity?)
This field asks whether any entity (user, administrator, service, app, remote system) can read, use, or modify the asset through any channel (UI, API, SSH, file system, etc.).
Answer:
Yes: if someone can access, manage, or use it in some way.
No: if no one can access it (rare case; it would be totally internal and inaccessible).
3) persisted_on_device (Is persisted on the device?)
Asks whether the asset is persistently stored on the device.
Yes: it is saved to storage (file, database, NVRAM, config) and remains after reboot.
No: it exists only temporarily (in RAM or session) and disappears on reboot.
4) Confidential (Sensitive or Confidential financial function configuration?)
This is used to distinguish the "importance" of the asset:
Here you must choose between:
Sensitive: if the compromise could enable fraud/charges/transfers or allow economic transactions to be authorized or executed, or reveal high-impact payment data.
Examples: payment token "charge," wallet credentials, card data, transaction signature keys/secrets, consents/debit mandates.
Confidential: if it is financial but its disclosure or tampering is typically less "enabling" than credentials/tokens, while still having an economic or privacy impact.
Examples: transaction history with amounts, price lists/discounts, invoices/orders (without authorization tools).
If you are unsure, for compliance purposes it is safer to classify as Sensitive when the asset can be used to cause direct damage (pay, charge, transfer, change amounts).
5) impacted_external_if (Potentially impacted via external interfaces?)
Here we ask whether the asset can be read or modified via external interfaces (physical or local) of the device (USB, UART/serial, HDMI in certain architectures, etc.).
Yes: if you can influence it from those interfaces (e.g., extract configuration, change it, debug with file access).
No: if those interfaces do not provide a realistic way to impact it.
6) communicated_over_network_if (Is communicated over a network interface?)
Asks whether the asset is transmitted over the network (even if only as part of a protocol or exchange).
Yes: if it passes over Ethernet/Wi-Fi/the Internet (e.g., tokens/cookies sent, certificates exchanged, configurations downloaded).
No: it is never sent over the network.
7) accessible_via_network_if (Is communicated via network interfaces?)
This field is used to understand how "accessible via network" the asset is and whether it can be accessed or modified:
Yes: if the asset is accessible or modifiable via network (WebUI/API/SSH/exposed service).
No: if you cannot read/modify it via the network (even if the device uses it internally).
If your system has an API that receives an amount, an order, or a token, the answer is almost always "Yes."
8) crypto_used (Cryptography used to protect the asset)
Asks whether the asset is protected with cryptography:
in transit (e.g., TLS/SSH/VPN when communicated),
and/or at rest (encrypted file, keystore, secret storage).
Yes: if there is cryptographic protection.
No: if it is unencrypted or without cryptographic protection.
Note: "hash" (e.g., password hash) is often protection, but it is not "cryptography" in the strict sense; it depends on how you want to interpret it in the project (we can align it consistently).
Practical and repeatable procedure for each row
For each asset (row), perform this mini-analysis and then evaluate the columns:
Define the asset in one sentence: "What it is and what it is used for economically."
Where it appears in the lifecycle: Created by whom? Used by whom? Sent to whom?
Where it resides: RAM only / log / DB / secure element / cloud / app.
Which interfaces touch it:
- local external (USB/BLE/debug) → `impactedexternalif`
- network (IP/Internet/API) → `communicatedovernetworkif` and `accessiblevianetworkif`
What protections: TLS? Storage encryption? Signature? → `crypto_used`
Confidentiality classification: "enables fraud?" → Sensitive, otherwise Confidential.
Identifying financial assets manually on firmware is a weeks-long task: file system analysis, network scans, review of startup scripts, searching for configurations scattered across non-standard directories.
Done manually, it takes weeks.
With our platform, you will reduce the time needed to comply with this regulation by over 90%!
This is because RedComply automates the most labor-intensive parts of the process.
Automatic analysis
Upload your project documentation and, for each financial function and configuration identified, the platform will:
Suggest sensitive/confidential classification
Report library versions with known CVEs
Identify undocumented exposed services
Verify consistency with GEC-2, GEC-3, and GEC-4 requirements
Version tracking
With each firmware update, RedComply compares the new version with the previous one and detects:
New financial functions introduced
Modified or added configurations
New exposed services
Changes in the compliance profile
As of August 1, 2025, RED compliance has become mandatory for IoT devices with radio interfaces. Financial assets must be identified before any EN 18031-3 requirements can be assessed.
RedComply speeds up the compilation of security and all RED regulations by over 90%.
Upload your firmware and get an initial automatic mapping of your financial assets in just a few days.
Request a demo and our team will contact you to help you!
RedComply reduces EN 18031 compliance time by over 90%. Learn more at redcomply.com.