EN 18031-3:2024
(Main)Common security requirements for radio equipment - Part 3: Internet connected radio equipment processing virtual money or monetary value
Common security requirements for radio equipment - Part 3: Internet connected radio equipment processing virtual money or monetary value
Common security requirements for internet connected radio equipment that equipment enables the holder or user to transfer money, monetary value or virtual currency. This document provides technical specifications for radio equipment processing virtual money or monetary value, which apply to electrical or electronic products that are capable to communicate over the internet, regardless of whether these products communicate directly or via any other equipment.
Gemeinsame Sicherheitsanforderungen für Funkanlagen - Teil 3: Internetfähige Funkanlagen, die virtuelles Geld oder Geldwerte verarbeiten
The harmonised standard includes test methods or equivalent approaches and conditions to verify compliance of the radio equipment with the essential requirement set out in Article 3(3), point (f) of Directive 2014/53/EU for the categories and classes specified by Article 1(3) of Delegated Regulation (EU) 2022/.
Exigences de sécurité communes applicables aux équipements radioélectriques - Partie 3 : Équipements radioélectriques connectés à l'internet qui traitent une monnaie virtuelle ou de la valeur monétaire
Exigences de sécurité communes applicables aux équipements radioélectriques connectés à l'internet qui permettent au détenteur ou à l'utilisateur de transférer de l'argent, une valeur monétaire ou une monnaie virtuelle. Le présent document fournit des spécifications techniques pour les équipements radioélectriques qui traitent une monnaie virtuelle ou de la valeur monétaire, qui s'appliquent aux produits électriques ou électroniques capables de communiquer via l'internet, que ces produits communiquent directement ou par l'intermédiaire d'un autre équipement.
Skupne varnostne zahteve za radijsko opremo - 3. del: Z internetom povezana radijska oprema, ki obdeluje virtualni denar ali denarno vrednost
Skupne varnostne zahteve za z internetom povezano radijsko opremo, na podlagi katerih oprema omogoča imetniku ali uporabniku prenos oziroma nakazilo denarja, denarne vrednosti ali virtualnih valut. Ta dokument določa tehnične specifikacije za radijsko opremo, ki obdeluje virtualni denar ali denarno vrednost, ki se uporabljajo za električne ali elektronske izdelke z zmožnostjo komunikacije prek interneta, ne glede na to, ali takšna komunikacija poteka neposredno ali prek druge opreme.
General Information
Overview
EN 18031-3:2024 defines common cybersecurity requirements for internet‑connected radio equipment that enables the holder or user to transfer money, monetary value or virtual currency. It applies to electrical/electronic products capable of communicating over the internet - whether directly or via other equipment - and sets baseline technical specifications to reduce exploitable vulnerabilities and protect financial assets. The standard was prepared by CEN/CENELEC JTC 13 and approved in 2024.
Key topics and technical requirements
The standard groups requirements into coherent, testable families focused on protecting devices that process monetary value. Major topics include:
- Access Control Mechanisms (ACM) - applicability and appropriate access control for users and services.
- Authentication Mechanisms (AUM) - authentication applicability, authenticator validation, change management, password strength and brute‑force protections.
- Secure Update Mechanisms (SUM) - secure and automated update processes for firmware/software.
- Secure Storage Mechanisms (SSM) - integrity and confidentiality protections for persisted sensitive data.
- Secure Communication Mechanisms (SCM) - integrity, authenticity, confidentiality and replay protection for network communications.
- Logging Mechanisms (LGM) - persistent log storage, minimum event sets and time‑related logging requirements.
- Confidential Cryptographic Keys (CCK) - key generation, protection and avoidance of static default keys.
- General Equipment Capabilities (GEC) - requirement for up‑to‑date components, interface exposure limits, input validation and equipment integrity.
- Cryptography (CRY) - alignment to best‑practice cryptographic algorithms and implementations.
Annexes provide rationale and mappings to related frameworks (EN IEC 62443‑4‑2, ETSI EN 303 645, SESIP) plus a relationship with EU Delegated Regulation (EU) 2022/30.
Practical applications - who uses this standard
SIST EN 18031‑3 is practical for organizations involved in the design, manufacture, assessment and procurement of internet‑connected payment or monetary‑processing devices, including:
- Device manufacturers and firmware developers building connected payment terminals, smart wallets or IoT devices that handle monetary value.
- Security architects and compliance teams performing threat modelling, risk assessment and product security by design.
- Test laboratories, certification bodies and auditors assessing device security against baseline criteria.
- Procurement and regulatory authorities specifying minimum cybersecurity controls for devices used in financial services and public deployments.
Related standards and interoperability
This part of EN 18031 is intentionally mapped to established cybersecurity standards and IoT baselines:
- EN IEC 62443‑4‑2 (industrial device security)
- ETSI EN 303 645 (consumer IoT baseline)
- SESIP (IoT platform security evaluation)
- Annex ZA for alignment with EU Delegated Regulation (EU) 2022/30
SIST EN 18031‑3 provides a focused, assessable baseline for securing internet‑connected radio equipment that processes virtual currency or monetary value, supporting secure product design, testing and regulatory compliance.
Frequently Asked Questions
EN 18031-3:2024 is a standard published by the European Committee for Standardization (CEN). Its full title is "Common security requirements for radio equipment - Part 3: Internet connected radio equipment processing virtual money or monetary value". This standard covers: Common security requirements for internet connected radio equipment that equipment enables the holder or user to transfer money, monetary value or virtual currency. This document provides technical specifications for radio equipment processing virtual money or monetary value, which apply to electrical or electronic products that are capable to communicate over the internet, regardless of whether these products communicate directly or via any other equipment.
Common security requirements for internet connected radio equipment that equipment enables the holder or user to transfer money, monetary value or virtual currency. This document provides technical specifications for radio equipment processing virtual money or monetary value, which apply to electrical or electronic products that are capable to communicate over the internet, regardless of whether these products communicate directly or via any other equipment.
EN 18031-3:2024 is classified under the following ICS (International Classification for Standards) categories: 33.060.20 - Receiving and transmitting equipment; 35.030 - IT Security; 35.240.40 - IT applications in banking. The ICS classification helps identify the subject area and facilitates finding related standards.
EN 18031-3:2024 is associated with the following European legislation: EU Directives/Regulations: 2014/53/EU; Standardization Mandates: M/585. When a standard is cited in the Official Journal of the European Union, products manufactured in conformity with it benefit from a presumption of conformity with the essential requirements of the corresponding EU directive or regulation.
You can purchase EN 18031-3:2024 directly from iTeh Standards. The document is available in PDF format and is delivered instantly after payment. Add the standard to your cart and complete the secure checkout process. iTeh Standards is an authorized distributor of CEN standards.
Standards Content (Sample)
SLOVENSKI STANDARD
01-oktober-2024
Skupne varnostne zahteve za radijsko opremo - 3. del: Z internetom povezana
radijska oprema, ki obdeluje virtualni denar ali denarno vrednost
Common security requirements for radio equipment - Part 3: Internet connected radio
equipment processing virtual money or monetary value
Gemeinsame Sicherheitsanforderungen für mit dem Internet verbundene Funkanlagen,
die für die Datenverarbeitung im Zusammenhang mit virtuellen Währungen oder
monetären Werten eingesetzt werden
Exigences de sécurité communes applicables aux équipements radioélectriques
connectés à linternet qui traitent une monnaie virtuelle ou de la valeur monétaire
Ta slovenski standard je istoveten z: EN 18031-3:2024
ICS:
33.060.01 Radijske komunikacije na Radiocommunications in
splošno general
35.030 Informacijska varnost IT Security
35.240.40 Uporabniške rešitve IT v IT applications in banking
bančništvu
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
EUROPEAN STANDARD EN 18031-3
NORME EUROPÉENNE
EUROPÄISCHE NORM
August 2024
ICS 33.060.20
English version
Common security requirements for radio equipment - Part
3: Internet connected radio equipment processing virtual
money or monetary value
Exigences de sécurité communes applicables aux Gemeinsame Sicherheitsanforderungen für mit dem
équipements radioélectriques - Partie 3 : Équipements Internet verbundene Funkanlagen, die für die
radioélectriques connectés à l'internet qui traitent une Datenverarbeitung im Zusammenhang mit virtuellen
monnaie virtuelle ou de la valeur monétaire Währungen oder monetären Werten eingesetzt
werden
This European Standard was approved by CEN on 1 August 2024.
CEN and CENELEC members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for
giving this European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical
references concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to
any CEN and CENELEC member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by
translation under the responsibility of a CEN and CENELEC member into its own language and notified to the CEN-CENELEC
Management Centre has the same status as the official versions.
CEN and CENELEC members are the national standards bodies and national electrotechnical committees of Austria, Belgium,
Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy,
Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of North Macedonia, Romania, Serbia,
Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and United Kingdom.
CEN-CENELEC Management Centre:
Rue de la Science 23, B-1040 Brussels
© 2024 CEN/CENELEC All rights of exploitation in any form and by any means
Ref. No. EN 18031-3:2024 E
reserved worldwide for CEN national Members and for
CENELEC Members.
Contents Page
European foreword . 5
Introduction . 6
1 Scope . 7
2 Normative references . 7
3 Terms and definitions . 7
4 Abbreviations . 12
5 Application of this document. 13
6 Requirements . 16
6.1 [ACM] Access control mechanism . 16
6.1.1 [ACM-1] Applicability of access control mechanisms . 16
6.1.2 [ACM-2] Appropriate access control mechanisms . 21
6.2 [AUM] Authentication mechanism . 25
6.2.1 [AUM-1] Applicability of authentication mechanisms . 25
6.2.2 [AUM-2] Appropriate authentication mechanisms . 36
6.2.3 [AUM-3] Authenticator validation . 42
6.2.4 [AUM-4] Changing authenticators. 46
6.2.5 [AUM-5] Password strength . 49
6.2.6 [AUM-6] Brute force protection . 57
6.3 [SUM] Secure update mechanism . 61
6.3.1 [SUM-1] Applicability of update mechanisms. 61
6.3.2 [SUM-2] Secure updates . 64
6.3.3 [SUM-3] Automated updates . 68
6.4 [SSM] Secure storage mechanism . 72
6.4.1 [SSM-1] Applicability of secure storage mechanisms . 72
6.4.2 [SSM-2] Appropriate integrity protection for secure storage mechanisms . 76
6.4.3 [SSM-3] Appropriate confidentiality protection for secure storage mechanisms . 81
6.5 [SCM] Secure communication mechanism . 86
6.5.1 [SCM-1] Applicability of secure communication mechanisms . 86
6.5.2 [SCM-2] Appropriate integrity and authenticity protection for secure communication
mechanisms . 91
6.5.3 [SCM-3] Appropriate confidentiality protection for secure communication
mechanisms . 97
6.5.4 [SCM-4] Appropriate replay protection for secure communication mechanisms . 102
6.6 [LGM] Logging Mechanism . 107
6.6.1 [LGM-1] Applicability of logging mechanisms . 107
6.6.2 [LGM-2] Persistent storage of log data . 110
6.6.3 [LGM-3] Minimum number of persistently stored events . 113
6.6.4 [LGM-4] Time-related information of persistently stored dog data. 116
6.7 [CCK] Confidential cryptographic keys . 119
6.7.1 [CCK-1] Appropriate CCKs . 119
6.7.2 [CCK-2] CCK generation mechanisms . 123
6.7.3 [CCK-3] Preventing static default values for preinstalled CCKs . 127
6.8 [GEC] General equipment capabilities . 131
6.8.1 [GEC-1] Up-to-date software and hardware with no publicly known exploitable
vulnerabilities . 131
6.8.2 [GEC-2] Limit exposure of services via related network interfaces . 135
6.8.3 [GEC-3] Configuration of optional services and the related exposed network
interfaces . 139
6.8.4 [GEC-4] Documentation of exposed network interfaces and exposed services via
network interfaces . 143
6.8.5 [GEC-5] No unnecessary external interfaces . 146
6.8.6 [GEC-6] Input validation . 148
6.8.7 [GEC-7] . 153
6.8.8 [GEC-8] Equipment Integrity . 153
6.9 [CRY] Cryptography . 157
6.9.1 [CRY-1] Best practice cryptography . 157
Annex A (informative) Rationale . 162
A.1 General . 162
A.2 Rationale . 162
A.2.1 Family of standards . 162
A.2.2 Security by design . 162
A.2.3 Threat modelling and security risk assessment . 163
A.2.4 Functional sufficiency assessment . 164
A.2.5 Implementation categories . 164
A.2.6 Assets . 165
A.2.7 Mechanisms . 167
A.2.8 Assessment criteria . 167
A.2.8.1 Decision trees . 167
A.2.8.2 Technical documentation . 168
A.2.8.3 Security testing . 169
A.2.9 Interfaces . 169
A.2.9.1 Example: Laptop with a built-in keyboard . 170
A.2.9.2 Example: Equipment with a USB-keyboard . 170
A.2.9.3 Example: User interface over a network . 171
A.2.9.4 Example: USB-printer. 171
A.2.9.5 Example: Network printer . 172
Annex B (informative) Mapping with EN IEC 62443-4-2:2019 . 173
B.1 General . 173
B.2 Mapping . 173
Annex C (informative) Mapping with ETSI EN 303 645 (Cyber Security for Consumer Internet
of Things: Baseline Requirements) . 176
C.1 General . 176
C.2 Mapping . 176
Annex D (informative) Mapping with Security Evaluation Standard for IoT Platforms (SESIP)
................................................................................................................................................................ 180
D.1 General . 180
D.2 Mapping . 180
Annex ZA (informative) Relationship between this European Standard and the Delegated
Regulation (EU) 2022/30 supplementing Directive 2014/53/EU of the European
Parliament and of the Council with regard to the application of the essential
requirements referred to in Article 3(3), points (d) (e) and (f), of that Directive aimed
to be covered . 183
Bibliography . 184
European foreword
This document (EN 18031-3:2024) has been prepared by Technical Committee CEN/CENELEC JTC 13
“Cybersecurity and Data Protection”, the secretariat of which is held by DIN.
This European Standard shall be given the status of a national standard, either by publication of an
identical text or by endorsement, at the latest by February 2025, and conflicting national standards shall
be withdrawn at the latest by February 2025.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
This document has been prepared under a standardization request addressed to CEN-CENELEC by the
European Commission. The Standing Committee of the EFTA States subsequently approves these
requests for its Member States.
For the relationship with EU Legislation, see informative Annex ZA, which is an integral part of this
document.
Any feedback and questions on this document should be directed to the users’ national standards
body. A complete listing of these bodies can be found on the CEN website.
According to the CEN-CENELEC Internal Regulations, the national standards organisations of
the following countries are bound to implement this European Standard: Austria, Belgium, Bulgaria,
Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary,
Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal,
Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Türkiye and the United Kingdom.
Introduction
Vigilance is required from manufacturers to improve the overall resilience against cybersecurity threats
caused by the increased connectivity of radio equipment [34] and the growing ability of malicious threat
actors to cause harm to users, organizations, and society.
The security requirements presented in this baseline standard are developed to improve the ability of
radio equipment to protect its security and financial assets against common cybersecurity threats and to
mitigate publicly known exploitable vulnerabilities.
It is important to note that to achieve the overall cybersecurity of radio equipment, defence in depth best
practices will be needed by both the manufacturer and user. In particular, no single measure will suffice
to achieve the given objectives, indeed achieving even a single security objective will usually require a
suite of mechanisms and measures. Throughout this document, the guidance material includes lists of
examples. These examples given are only indicative possibilities, as there are other possibilities that are
not listed, and even using the examples given will not be sufficient unless the mechanisms and measures
chosen are implemented in a coordinated fashion.
1 Scope
This document specifies common security requirements and related assessment criteria for internet
connected radio equipment [35]. That equipment enables the holder or user to transfer money, monetary
value or virtual currency [35] (hereinafter referred to as "equipment”).
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
− ISO Online browsing platform: available at https://www.iso.org/obp/
− IEC Electropedia: available at https://www.electropedia.org/
− ISO Online browsing platform: available at https://www.iso.org/obp/
3.1
access control mechanism
equipment functionality to grant, restrict or deny access to specific equipment’s resources
Note 1 to entry: Access to specific equipment’s resources can amongst others be:
- reading specific data; or
- writing specific data to equipment’s persistent storage; or
- performing a specific equipment functionality such as recording audio.
3.2
authentication
provision of assurance that an entity is who or what it claims to be
Note 1 to entry: An entity can amongst others claim to be:
- a specific human, owner of a user account, device, or service; or
- a member of specific groups such as an authorized group to access a specific equipment’s resource; or
- authorized by another entity to access a specific equipment’s resource.
3.3
authentication mechanism
equipment functionality to verify that an entity is who or what it claims to be
Note 1 to entry: Typically, the verification is based on examining evidence from one or more elements of the
categories:
- knowledge; and
- possession; and
- inherence.
3.4
authenticator
something known or possessed, and controlled by an entity that is used for authentication
Note 1 to entry: Typically, it is a physical device or a password.
EXAMPLE A password or token can be used as an authenticator.
3.5
assessment objective
statement, provided as part of the assessment input, which defines the reasons for performing the
assessment
[SOURCE: ISO/IEC 33001:2015, 3.2.6 [28]]
3.6
best practice
measures that have been shown to provide appropriate security for the corresponding use case
3.7
brute force attack
attack on a cryptosystem that employs a trial-and-error search of a set of keys, passwords or other data
3.8
communication mechanism
equipment functionality that allows communication via a machine interface
3.9
confidential cryptographic key
confidential security parameter, excluding passwords, which is used in the operation of a cryptographic
algorithm or cryptographic protocol
3.10
confidential financial data
financial data whose disclosure can lead to fraud
3.11
confidential financial function configuration
financial function configuration whose disclosure can lead to fraud
3.12
confidential security parameters
security parameter whose disclosure can lead to fraud
3.13
denial of service
prevention or interruption of authorized access to an equipment resource or the delaying of the
equipment operations and functions
[SOURCE: IEC 62443-1-1:2019, 3.2.42 [29]] modified
3.14
device
product external to the equipment
3.15
entity
user, device, equipment or service
3.16
entropy
measure of the disorder, randomness or variability in a closed system
3.17
external interface
interface of an equipment that is accessible from outside the equipment
3.18
factory default state
defined state where the configuration settings and configuration of the equipment is set to initial values
Note 1 to entry: A factory default state may include security updates, installed after the equipment being placed on
the market.
3.19
financial asset
sensitive financial data or confidential financial data or sensitive financial function configuration or
confidential financial function configuration or financial functions
3.20
financial data
data that represents, provides information about, or is processed for transferring money, monetary
assets or virtual currencies [35]
3.21
financial function
equipment’s functionality that processes financial data
3.22
financial function configuration
data processed by the equipment that defines the behaviour of the equipment’s financial functions
3.23
hard-coded
software development practice of embedding data directly into the source code of a program or other
executable object
3.24
initialization
process that configures the network connectivity of the equipment for operation
Note 1 to entry: Initialization can provide the possibility to configure authentication features for a user or for
network access.
3.25
interface
shared boundary across which entities exchange information
3.26
justification
documented information providing evidence that a claim is true under the assumption of common
expertise.
Note 1 to entry: Such evidence can be supported for example by:
- a description of the equipment’s intended equipment functionality,
- a descriptions of equipment’s operational environment of use,
- a description of equipment’s technical properties such as security measures
- an analysis of relevant risks related to the operation of the equipment within its reasonably foreseeable
use and intended equipment functionality.
3.27
log data
record(s) of certain events (of processes) on a computing equipment
3.28
logging mechanism
equipment functionality to log internal activities
3.29
machine interface
external interface between the equipment and a service or device
3.30
network interface
external interface enabling the equipment to have or provide access to a network
Note 1 to entry: Examples for network interfaces are a LAN port (wired) or a wireless network interface enabling
WLAN or short range wireless communication, e.g., using a 2.4 GHz antenna.
3.31
operational state
state in which the equipment is functioning normally according its intended equipment functionality [36]
and within its intended operational environment of use
3.32
optional service
services which are not necessary to setup the equipment, and which are not part of the basic functionality
but are still relevant for the intended equipment functionality [36] and are delivered as part of the factory
default.
EXAMPLE An SSH service on the equipment is not required for basic functionality of the equipment, but it can
be used to allow a remote access to the equipment.
3.33
password
sequence of characters (letters, numbers, or other symbols) used to authenticate an entity
Note 1 to entry: Personal identification numbers (PINs) are also considered a form of password.
3.34
public security parameter
sensitive security parameter that is not confidential
3.35
resilient
able to anticipate, withstand, recover from, and adapt to adverse conditions, stresses, attacks, or
compromises on systems that use or are enabled by cyber resources.
[SOURCE: NIST SP 800-172 [30] ]
3.36
resource
functional unit or data item needed to perform required operations
[SOURCE: IEC [31]]
3.37
risk
combination of the probability of occurrence of harm and the severity of that harm
[SOURCE: ISO/IEC Guide 51:2014 [32]]
3.38
security asset
sensitive security parameter or confidential security parameter or security function
3.39
security function
functionality on the equipment that protects security assets or financial assets from being misused for
fraud
3.40
security parameter
data processed by the equipment that defines the behaviour of the equipment‘s security function
3.41
security strength
number associated with the amount of work that is required to break a cryptographic algorithm or
system
Note 1 to entry: The amount of work can for example be the number of operations required to break a
cryptographic algorithm or system.
3.42
sensitive financial data
financial data whose manipulation can lead to fraud
3.43
sensitive financial function configuration
financial function configuration whose unauthorized modification can lead to fraud
3.44
sensitive security parameters
security parameter whose manipulation can lead to fraud
3.45
security update
software update that addresses security vulnerabilities through software patches or other mitigations
3.46
software
assembly of programs, procedures, rules, documentation, and data, pertaining to the operation of an
equipment
Note 1 to entry: Software also includes firmware.
3.47
storage mechanism
equipment functionality that allows to store information
3.48
update mechanism
equipment functionality that allows to change equipment’s software
3.49
user interface
external interface between the equipment and a user
3.50
vulnerability
weakness, design, or implementation error that can lead to an unexpected, undesirable event
compromising the security of the equipment, network, application, or protocol involved.
[SOURCE: (ITSEC) (definition given by ENISA, "computer system" has been replaced by "equipment")
[33]]
4 Abbreviations
ACM access control mechanism
API application programming interface
AU assessment unit
AUM authentication mechanism
CCK confidential cryptographic key(s)
CRY cryptography
CSP confidential security parameter
CWE common weakness enumeration
DN decision node
DT decision tree
E evidence
E.Info evidence.information
E.Just evidence.justification
GEC general equipment capabilities
IC implementation category
IP internet protocol
LAN local area network
LGM logging mechanism
MitM Man-in-the-Middle
OS operating system
OTP one-time password
PIN personal identification number
PKI public key infrastructure
PSP public security parameter
SCM secure communication mechanism
SDO standards developing organization
SQL structured query language
SSM secure storage mechanism
SSP sensitive security parameter
SUM secure update mechanism
USB universal serial bus
WLAN wireless local area network
5 Application of this document
This document uses the concept of mechanisms to instruct the user of this document when to apply
certain security measures. Mechanisms address the applicability and appropriateness through a set of
requirements including assessment criteria. An applicable/non-applicable decision is taken for each of
the items specified. If applicable it is followed by a pass/fail appropriateness decision for each of the items
specified. For example, when checking the applicability of a requirement on external interfaces, then the
decision whether the requirement needs to be fulfilled is determined for each external interface
independently.
The mechanisms and their application are documented using the structure shown in the table below:
Table 1 — Requirements structure
Clause # Title Description on how to apply the
document
6.x XXX Mechanism Mechanism for each specific item
(e.g., external interface or security asset)
6.x.1 XXX-1 Applicability of mechanisms Applicability of the mechanism
6.x.1.1 Requirement For each specific item determine and assess
if the mechanism is required.
6.x.1.2 Rationale
NOTE A mechanism might combine
6.x.1.3 Guidance
applicability and appropriateness in a single
requirement.
6.x.1.4 Assessment criteria
6.x.1.4.1 Assessment objective
6.x.1.4.2 Implementation categories
6.x.1.4.3 Required information
6.x.1.4.4 Conceptual assessment
6.x.1.4.5 Functional completeness assessment
Clause # Title Description on how to apply the
document
6.x.1.4.6 Functional sufficiency assessment
6.x.2 XXX-2 Appropriate mechanisms Appropriateness of the mechanism
6.x.2.1 Requirement For each specific item for which the
mechanism is required as determined by
6.x.2.2 Rationale
XXX-1, determine and assess whether the
mechanism is implemented properly.
6.x.2.3 Guidance
NOTE A mechanism might have multiple
6.x.2.4 Assessment criteria
appropriateness sub-clauses to focus on specific
6.x.2.4.1 Assessment objective properties.
6.x.2.4.2 Implementation categories
6.x.2.4.3 Required information
6.x.2.4.4 Conceptual assessment
6.x.2.4.5 Functional completeness assessment
6.x.2.4.6 Functional sufficiency assessment
6.x.y XXX-# Supporting Requirements Applicability and appropriateness of
supporting requirements for the mechanism
6.x.y.1 Requirement For each specific item for which the
mechanism is required as determined by
6.x.y.2 Rationale
XXX-1, determine and assess if the
6.x.y.3 Guidance supporting requirement needs to be
implemented (there might be specific
6.x.y.4 Assessment criteria
conditions, for instance if the equipment is a
toy) and if it needs to be implemented,
6.x.y.4.1 Assessment objective
whether it is implemented properly.
6.x.y.4.2 Implementation categories
NOTE Some chapters contain multiple
6.x.y.4.3 Required information
requirements, which leads to slight deviations in
terms of numbering.
6.x.y.4.4 Conceptual assessment
6.x.y.4.5 Functional completeness assessment
6.x.y.4.6 Functional sufficiency assessment
The assessments are conducted by examining the documented assessment cases, not all assessment cases
might be provided for every mechanism:
— Conceptual assessment
Examine if the provided documentation and rationale provide the required evidence (for example
the rationale why a mechanism is not applicable for a specific network interface).
— Functional completeness assessment
Examine and test if the provided documentation is complete (for example use network scanners
to verify that all external interfaces are properly identified, documented and assessed)
— Functional sufficiency assessment
Examine and test if the implementation is adequate (for example run fuzzing tools on a network
interface to check if it is resilient to attacks with malformed data)
Each of the assessments is further divided into the following sub-clauses which might use a decision tree
to guide the assessment:
— Assessment purpose
— Preconditions
— Assessment units
— Assignment of verdict
Required information lists the information to be provided through technical documentation. This
document does not require each required information element to be provided as a separate document.
For the section assessment criteria, the following identifiers with the defined syntax are used to structure
the elements which are needed to perform an assessment:
— Required information
E..>.
Identifier for the category of the required information excluding DTs
— Required information for decision trees
E..DT.>
Identifier for the category of the required information in the context of DTs
— Implementation Category
IC.>.
Identifier for the implementation category
— Assessment Unit
AU.>.
Identifier for the assessment unit
— Decision Tree Nodes
DT.>.DN-
Identifier for a specific node inside the DT
The placeholders are used as follows:
— : “Info” or “Just” to indicate the kind of required documentation which could by
information” or justification.
— : Name of the category for the required documentation. A
could contain additional Sub-Category-Names divided with "." .
— : Name of the implementation category which describes the
defined implementation.
— : Name of the assessment unit for a specific implementation category.
— >: Abbreviation of the name from the specific requirement
which belongs to the assessment criteria.
6 Requirements
6.1 [ACM] Access control mechanism
6.1.1 [ACM-1] Applicability of access control mechanisms
6.1.1.1 Requirement
The equipment shall use access control mechanisms to manage entities' access to security assets and
financial assets, except for access to security assets or financial assets where:
— public accessibility is the equipment’s intended functionality; or
— physical or logical measures in the equipment’s targeted operational environment limit their
accessibility to authorized entities; or
— legal implications do not allow for access control mechanisms.
6.1.1.2 Rationale
Security and financial assets might be exposed to unauthorized access attempts. Access control
mechanisms limit the ability of any unauthorized entity to access these assets.
6.1.1.3 Guidance
The requirement does not demand access control mechanisms on assets that it does not cover (for
example, the dispense button on a coffee machine). Further it does not demand access control
mechanisms for security assets or financial assets that are in principle covered, but where the intended
equipment functionality [36] is to be generally accessible by the public or where the intended operational
environment of use ensures that only authorized access is possible. If the equipment relies on the access
control given by the intended operational environment, it is to be ensured that this access control is
appropriate as described in ACM-2.
Radio interfaces might be accessible even if the equipment is in an environment preventing physical
manipulation by an unauthorized entity, for instance a wireless network is often accessible from outside
a user’s home.
For example, depending on the equipment’s technical properties, intended equipment functionality and
intended operational environment of use access control mechanisms might not be necessary for relevant
security assets or financial assets where:
— all entities with access to the equipment (the equipment is intended to be operated in an area
which has physical access control) are authorized to access these assets (for example, the WPS
button on a home router);
— the equipment’s functionality only provides information (on security assets or financial
assets) that is intended to be publicly accessible (for instance broadcasting Bluetooth
advertising beacons).
Access control mechanisms need properties to tie access rights to. Such properties can amongst others
be:
— verified claims of entities (for instance being owner of a user account, member of specific
group, authorized by another entity);
— certain states of the equipment or the equipment’s environment (for instance an electronic
flight bag might have different access rights for a local user when it is operated in the air, than
when it is stored at the ground);
— the external interface an access is performed from (for instance a local access, where physical
access control is obviously in place, might have different access rights than a remote access);
— various combinations of the properties mentioned, as well as additional ones.
6.1.1.4 Assessment criteria
6.1.1.4.1 Assessment objective
The assessment addresses the requirement ACM-1.
6.1.1.4.2 Implementation categories
Not applicable.
6.1.1.4.3 Required information
[E.Info.ACM-1.SecurityAsset]: Description of each security asset that is accessible by entities, including:
— [E.Info.ACM-1.SecurityAsset.Access]: possible entities’ accesses to the security asset on the
equipment; and
— (if access control by the equipment is absent for public accessibility of the security asset is the
equipment’s intended functionality) [E.Info.ACM-1.SecurityAsset.PublicAccess]: Description
of the equipment’s intended functionality concerning the public accessibility of the security
asset; and
— (if access control by the equipment is absent because physical or logical measures in the
equipment’s targeted operational environment exits, that limit accessibility to authorized
entities) [E.Info.ACM-1.SecurityAsset.Environment]: Description of:
o physical or logical access control measures in the equipment’s targeted operational
environment; and
o how entities are authenticated/authorized in the equipment’s targeted operational
environment; and
— (if legal implications do not allow for access control mechanisms) [E.Info.ACM-
1.SecurityAsset.Legal]: References to all corresponding paragraph(s) or passages in all
relevant legal documents, including a description on how this is applicable for the equipment
or affected asset; and
— (if access control mechanisms are claimed to be required for entities access to the security
asset) [E.Info.ACM-1.SecurityAsset.ACM]: Description of each access control mechanism that
manages entities’ access to the security asset.
[E.Info.ACM-1.FinancialAsset]: Description of each financial asset that is accessible by entities, including:
— [E.Info.ACM-1.NetworkAsset.Access]: possible entities’ accesses to the financial asset on the
equipment; and
— (if access control by the equipment is absent for public accessibility of the financial asset is
the equipment’s intended functionality) [E.Info.ACM-1.FinancialAsset.PublicAccess]:
Description of the equipment’s intended functionality concerning the public accessibility of
the financial asset; and
— (if access control by the equipment is absent because physical or logical measures in the
equipment’s targeted operational environment exits, that limit accessibility to authorized
entities) [E.Info.ACM-1.FinancialAsset.Environment]: Description of:
o physical or logical access control measures in the equipment’s targeted operational
environment; and
o how entities are authenticated/authorized in the equipment’s targeted operational
environment; and
— (if legal implications do not allow for access control mechanisms) [E.Info.ACM-
1.FinancialAsset.Legal]: References to all corresponding paragraph(s) or passages in all
relevant legal documents, including a description on how this is applicable for the equipment
or affected asset; and
— (if access control mechanisms are claimed to be required for entities access to the financial
asset) [E.Info.ACM-1.FinancialAsset.ACM]: Description of each access control mechanism that
manages entities’ access to the financial asset.
[E.Info.DT.ACM-1]: Description of the selected path through the decision tree in Figure 1 for each security
and financial asset documented in [E.Info.ACM-1.SecurityAsset] and [E.Info.ACM-1.FinancialAsset],
respectively.
[E.Just.DT.ACM-1]: Justification for the selected path through the decision tree documented in
[E.Info.DT.ACM-1], with the following properties:
— (if a decision from [DT.ACM-1.DN-1] results in “NOT APPLICABLE”) the justification for the
decision [DT.ACM-1.DN-1] is based on [E.Info.ACM-1.SecurityAsset.PublicAccess] or
[E.Info.ACM-1.FinancialAsset.PublicAccess]; and
— (if a decision from [DT.ACM-1.DN-2] results in “NOT APPLICABLE”) the justification for the
decision [DT.ACM-1.DN-2] is based on [E.Info.ACM-1.SecurityAsset.Environment] or
[E.Info.ACM-1.FinancialAsset.Environment]; and
— (if a decision from [DT.ACM-1.DN-3] results in “NOT APPLICABLE”) the justification for the
decision [DT.ACM-1.DN-3] is based on [E.Info.ACM-1.SecurityAsset.Legal] or [E.Info.ACM-
1.FinancialAsset.Legal]; and
— the justification for the decision [DT.ACM-1.DN-4] is based on [E.Info.ACM-
1.SecurityAsset.ACM] or [E.Info.ACM-1.FinancialAsset.ACM].
6.1.1.4.4 Conceptual assessment
6.1.1.4.4.1 Assessment purpose
The purpose of this assessment case is the conceptual assessment whether access control mechanisms
are implemented when they are required per ACM-1.
6.1.1.4.4.2 Preconditions
None.
6.1.1.4.4.3 Assessment units
Figure 1 — Decision Tree for requirement ACM-1
For each security asset documented in [E.Info.ACM-1.SecurityAsset] and each financial asset documented
in [E.Info.ACM-1.FinancialAsset], check whether the path through the decision tree documented in
[E.Info.DT.ACM-1] ends with “NOT APPLICABLE” or “PASS”.
For each path through the decision tree documented in [E.Info.DT.ACM-1], examine its justification
documented in [E.Just.DT.ACM-1].
6.1.1.4.4.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if:
— at least one path through the decision tree document
...
Die Norm EN 18031-3:2024 definiert die allgemeinen Sicherheitsanforderungen für internetverbundene Funkgeräte, die es dem Nutzer ermöglichen, Geld, monetäre Werte oder virtuelle Währungen zu übertragen. Der Umfang dieser Norm ist besonders relevant in einer Zeit, in der digitale Transaktionen und die Nutzung von virtuellen Währungen stetig zunehmen. Ein wesentlicher Stärke dieser Norm ist die detaillierte technische Spezifikation, die sie für Hersteller und Entwickler bietet. Diese Spezifikationen sind entscheidend, um sicherzustellen, dass die Produkte nicht nur funktional, sondern auch sicher in der Handhabung von finanziellen Transaktionen sind. Dies ist besonders wichtig angesichts der häufigen Cyber-Sicherheitsbedrohungen, denen solche Geräte ausgesetzt sind. Darüber hinaus richtet sich die Norm nicht nur an spezifische Geräte, sondern umfasst alle elektrischen oder elektronischen Produkte, die über das Internet kommunizieren, unabhängig davon, ob die Kommunikation direkt oder über andere Geräte erfolgt. Dies erweitert den Geltungsbereich erheblich und sorgt dafür, dass die Norm auf eine Vielzahl von Produkten anwendbar ist, die immer mehr in unseren Alltag integriert werden. Die Relevanz der EN 18031-3:2024 kann nicht hoch genug eingeschätzt werden, da sie nicht nur Sicherheitsstandards setzt, sondern auch das Vertrauen der Verbraucher in die Verwendung von internetverbundenen Finanzgeräten stärkt. In einem Markt, der zunehmend durch innovative Technologien geprägt ist, bietet diese Norm eine wichtige Grundlage für die Sicherheit und Integrität von finanziellen Transaktionen, die über Funkgeräte abgewickelt werden.
SIST EN 18031-3:2024 문서는 인터넷에 연결된 무선 장비의 보안 요구 사항에 대한 표준으로, 특히 가상 화폐 또는 화폐 가치를 처리하는 장비를 다룹니다. 이 표준은 사용자가 돈이나 화폐 가치를 안전하게 전송할 수 있도록 하는 무선 장비에 대한 공통 보안 요구 사항을 명시하고 있습니다. 이 문서의 범위는 실질적이며, 전자적 또는 전기적 제품이 인터넷을 통해 통신할 수 있는 능력을 가진 경우, 이러한 제품들이 직접 또는 다른 장비를 통해 통신하는지 여부에 관계없이 적용됩니다. 따라서, EN 18031-3:2024 표준은 모든 인터넷 연결 무선 장비에 대한 안전성을 보장하는 데 중요한 역할을 합니다. 이 표준의 강점은 기술 사양이 명확하고 포괄적이라는 점입니다. 가상 화폐를 처리하는 무선 장비는 보안 취약점이 발생할 수 있는 경우가 많기 때문에, 보안 요구 사항을 체계적으로 제시하여 이러한 위험을 최소화하도록 돕습니다. 이에 따라, 현대 금융 환경에서의 안정성 확보와 사용자 보호를 위한 필수 기준으로서의 중요성이 강조됩니다. 또한, EN 18031-3:2024 표준은 지속적으로 변화하는 무선 기술 환경에 적응할 수 있는 유연성을 제공합니다. 이는 향후 기술 발전에 따라 새로운 보안 위협에 대응할 수 있도록 하는 데 큰 도움을 줄 것으로 예상됩니다. 따라서, 본 표준은 인터넷 연결 무선 장비 관련 산업에 있어 매우 중요한 참고자료로 자리 잡을 것입니다.
La norme SIST EN 18031-3:2024 définit les exigences de sécurité communes pour les équipements radio connectés à Internet, en particulier ceux qui permettent le transfert d'argent, de valeur monétaire ou de monnaie virtuelle. Cette norme est essentielle dans le cadre de l'évolution rapide des technologies financières et de la nécessité de garantir la sécurité des transactions numériques. L'un des points forts de cette norme est sa portée étendue. En fournissant des spécifications techniques pour les équipements radio traitant de l'argent virtuel ou de la valeur monétaire, elle établit un cadre robuste qui couvre divers types de produits électriques ou électroniques capables de communiquer via Internet. Ce cadre s'applique non seulement à la communication directe, mais aussi à celle passant par d'autres équipements, ce qui est crucial dans un monde de plus en plus interconnecté. De plus, la norme aborde des aspects critiques de la sécurité, garantissant que les utilisateurs puissent effectuer des transactions en toute confiance. Cela renforce la confiance des utilisateurs dans l'utilisation d'équipements connectés pour des transactions financières, un élément vital pour l'adoption continue de la monnaie virtuelle et des technologies associées. La pertinence de cette norme dans le contexte actuel ne peut être sous-estimée. À une époque où la numérisation des services financiers prend de l'ampleur, la norme SIST EN 18031-3:2024 se positionne comme un document incontournable pour les fabricants et les développeurs d'équipements radio. Elle répond non seulement aux préoccupations de sécurité des utilisateurs, mais favorise également l'innovation en établissant des critères clairs et sûrs pour la conception et l'utilisation d'équipements traitant de l'argent virtuel. En résumé, la norme SIST EN 18031-3:2024 se distingue par sa portée exhaustive, ses exigences de sécurité indispensables et sa pertinence dans le paysage technologique actuel, faisant d'elle une référence précieuse pour tous les acteurs impliqués dans le développement d'équipements radio connectés traitant de valeurs monétaires.
The EN 18031-3:2024 standard presents a comprehensive set of common security requirements specifically designed for internet-connected radio equipment that processes virtual money or monetary value. The scope of this standard is particularly relevant in today's increasingly digital economy, where the transfer of monetary value via radio equipment has become commonplace. By focusing on the technical specifications necessary for ensuring the secure processing of virtual currencies, this document addresses a critical gap in the current regulatory framework. One of the strengths of the EN 18031-3:2024 standard is its thoroughness in presenting security requirements applicable to a wide range of electrical and electronic products. It effectively caters to equipment that communicates over the internet, thereby ensuring that the standards are inclusive of various communication methods, whether direct or indirect. This versatility enhances the applicability of the standard across diverse industry segments, solidifying its importance in safeguarding transactions involving virtual money. Moreover, the standard emphasizes not only the technical capabilities of radio equipment but also the necessity of robust security measures that protect end-users from potential threats posed by cybercriminals. This focus on security is vital in maintaining trust in systems that handle monetary value, as any vulnerabilities could have widespread implications for users and operators alike. In summary, the relevance of the EN 18031-3:2024 standard is underscored by its alignment with emerging technologies and the growing demand for secure transactions in a digital environment. Its detailed specifications and comprehensive security requirements make it a significant reference point for manufacturers and developers of internet-connected radio equipment processing virtual money, ensuring that they adhere to best practices and regulatory compliance in protecting financial data.
EN 18031-3:2024は、インターネット接続された無線機器に関する一般的なセキュリティ要件を定義する重要な標準です。この文書は、ユーザーが金銭や仮想通貨を転送できる無線機器に対して適用される技術仕様を提供しています。特に、この標準は、インターネットを介して通信可能な電気または電子製品に広範に適用されるため、現代のデジタル経済において非常に重要です。 この標準の強みは、無線機器が安全にお金や仮想通貨を処理するための明確なガイドラインを提供している点にあります。これにより、製品の製造者や開発者は、業界内での信頼性を高め、規制への適合を容易にします。特に、セキュリティがますます重要視される現代の市場において、EN 18031-3:2024は、無線技術を用いた金融取引の安全性を保証するための基盤を築いています。 また、この標準は、無線機器に関わるさまざまな関係者が遵守すべき共通のセキュリティ要件を定義することで、業界全体のセキュリティレベルを引き上げる役割も果たしています。そのため、仮想通貨や金銭的価値のあるトランザクションを扱う無線機器の信頼性確保に寄与しています。 総じて、EN 18031-3:2024は、インターネット接続無線機器のセキュリティ要件を厳格に標準化した文書であり、その適用範囲、強み、関連性は、特にデジタル時代における無線機器の役割を考える上で非常に重要です。








Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...