EN 18031-1 differs from the "classic" cybersecurity standards ETSI 303 645 or EN IEC 62443-4-2 due to its asset-based approach. In EN 18031-1, network and security assets are identified and analyzed in order to apply the appropriate requirements to the assets.
An asset is an asset worth protecting, i.e. information that is of value to a potential attacker - such as a password, a symmetric key, a network configuration file and more. Such assets therefore require access control, must be securely communicated and securely stored.
Which assets this applies to exactly can be determined using the standard's decision trees. If a requirement is applicable to an asset, it must also be implemented appropriately. To facilitate appropriate implementation, EN 18031-1 provides implementation categories. If an access control is not applicable, it does not have to be implemented.
However, EN 18031-1 clearly shows that an asset-based approach also has its limitations.
Which implementation category of access control does, for example, a simple password authentication to access a specific interface fall into?
The following are available
- Role-based access control
- user-defined access control
- mandatory access control
From a technical perspective, none of the above access controls are correct. In reality, access is not usually restricted to a single asset, but usually to an interface or configuration file with many different assets, not all of which need to be network or security assets.
But without access control, there is no authentication, as required by the standard:
The required access control mechanisms should use authentication mechanisms to manage access by entities.
The standard does not provide for authentication mechanisms if there is no underlying access control. These are interpreted very narrowly in EN 18031-1, which is why it is cumbersome in parts to map some radio systems and their software correctly using the structural specifications of the standard.
The asset-based approach is also not strictly implemented in all requirements.
Secure update mechanisms, resilience mechanisms, cryptographic keys and algorithms are considered separately from assets to a certain extent. This is similar to the requirements for general device functions:
- Always provide up-to-date software without known, exploitable security vulnerabilities
- Keep the services and interfaces accessible in the factory settings to a minimum
- Make optional services and their interfaces configurable
- Document open interfaces and services in the operating instructions
- No unnecessary physical interfaces on the device
- Input validation
In general, however, the above requirements are only mandatory if network or security assets are affected. It is not always easy to clearly determine whether this is the case.
One of the problems with the asset-based approach is that a user of the standard can get lost in the level of detail of the assets. The more detailed the individual assets and their use are broken down into configuration or functions, the more complex the documentation of the standard becomes and this is difficult to understand even at a coarse granularity. There is deliberately no requirement for granularity.
To a certain extent, the application of standards is pure hard work, documenting the status quo in writing. This seems to be about as popular as documentation in software development. However, its unpopularity does not make it any less important; on the contrary, such diligence makes a lot of work easier for us in the future and forms a solid basis for new employees, auditors and others.
EN 18031-1 adds an extra hurdle to this already frustrating process by listing assets that are not always easy to determine.
For example:
A password that is only stored as a hash on the device itself can be communicated in plain text.
The password itself does not require access control because it is not stored at all, only its hash is stored.
However, it should always be communicated in encrypted form if it is transmitted in plain text. However, Implementing Decision (EU) 2025/138 excludes the "Justification" and "Guideline" sections from the presumption of conformity, leaving the manufacturer with the "Required information" for documentation.
The manufacturer must fill in the following field E.Info.SCM-1.SecurityAsset. The description of what this field must be filled in with reads as follows:
Description of each stored security asset that is communicated via network interfaces...
But the password described above is never stored, yet there is no question that it must be communicated securely.
Here the standard itself seems to have lost its way in its asset-based approach.
In general, by focusing on assets, the standard sometimes loses sight of the goal of cyber security.
A well-known guiding principle in security is that a device itself can be the most secure in the world, but if it is integrated or used incorrectly, it becomes vulnerable.
In the OWASP (Open Web Application Security Project), "Incorrect configuration in security" is number 5 of the 10 biggest security risks. [1]
Making manufacturers responsible for making devices and software secure is without question the right decision, as not every user will have made cyber security a hobby.
However, cyber security is not always simple, but often complex and multifaceted. An insecure IoT device in a WPA2-encrypted WLAN is more difficult to attack than a more secure IoT device in an open WLAN.
The easier a standard is for manufacturers to understand, the more this standard will be able to contribute to a more secure environment. EN 18031-1 is a solid foundation, but it also has gaps where there is potential for improvement.
However, there will be no improvement, as it is already clear that the EN 18031 family of standards will not be continued, but will be replaced by the standards of the Cyber Resilience Act.
These will be based on EN IEC 62443-4-2. [2]
This means that manufacturers have had to implement a newly organized, complicated standard since 1 August 2025 in the knowledge that it will be obsolete when the CRA comes into force in December 2027, even though ETSI 303 645 or EN IEC 62443-4-2 have been available for comparison all this time.
However, every manufacturer should also see this as an opportunity to address the issue of cybersecurity. It will become increasingly present in the future and will not disappear.
If you have any questions about the practical implementation of EN 18031-1 or would like to know what specific impact the upcoming regulations - such as the Cyber Resilience Act - will have on your company, please send us an email or use our contact form. Together we will find the right way through the complex requirements of the cyber security standards.
Author's note
This article has been machine translated into English.
DEFINITIONS AND ABBREVIATIONS
OWASP stands for Open Worldwide Application Security Project and is a non-profit organization dedicated to improving software security. It provides a free global community, free tools, training, documentation and research to help organizations develop and maintain secure applications.
CENELEC is the European Committee for Electrotechnical Standardization. As a non-profit organization, it develops European standards in the field of electrical engineering.
