Resource_Centre_600x320

Practical resources for navigating compliance, testing, and global market access.

Blog_writing_600x320

Expert insights on compliance, testing, certification, and evolving regulatory requirements.

Certificate_Finder_600x320

Verify certificate authenticity and certification status through Nemko’s online platform.

Locations_600x320

Find Nemko locations worldwide and connect with local experts for testing, certification, compliance, and global market access services.

Cybersecurity access control for EN 18031
Øyvind StorhaugJuly 1, 20262 min read

Cybersecurity Under EN 18031: Why Access Control Exceptions Need Strong Justification

 

Many of the cybersecurity requirements in EN18031-series focuses on how a product is protected. However, several requirements include decision nodes that allow a manufacturer to justify why a mechanism is not needed. 

In many cases, these exceptions are reasonable. For example, a vulnerability that has a very low impact and risk shouldn’t necessarily prevent the product being placed on the market. 

However, some exceptions are intentionally difficult to justify. One of the most misunderstood exceptions is Decision node 2 (DN-2) in ACM-1. 

Why does this matter?

ACM-1 is the first requirement in the standard and forms the foundation for the Access Control Mechanism chain. Choices made here will affect the rest of the ACM section as well as the Authentication Mechanism (AUM). 

If an access control mechanism is classified as not applicable under ACM-1, it will no longer have to satisfy any of the other requirements in ACM or AUM. This means an incorrect choice in this requirement can make a product seem more secure than it actually is.

What ACM-1 requires

ACM-1 states a manufacturer shall use access control mechanisms to protect access to assets with some exceptions. This requirement does not apply if it meets one of these exceptions: 

  • Public access is intended 

  • Legal constraint prevents it 

  • The operational environment provides security 

They all require justification to be used, but the third option is where most issues arise. This justification must demonstrate that access is effectively limited to authorized entities without relying on the product itself.

Common mistakes

One of the most common mistakes is assuming the environment is secure. For example, a consumer product to be placed in a home, which is usually considered a secure environment by default. However, unlike theft of physical items, interfering with home devices can be seen as entertaining or a prank with low risk of getting caught. Once a guest has been given access to the Wi-Fi network, their activity is rarely tracked. In addition, most homeowners might not realize or consider that unless they create a guest network, they will give all guests access to poorly protected devices at the same time. In these cases, the environment may provide some level of protection, but not to the extent required to justify the absence of access control mechanisms.

What should be included in the justification

A clear and well justified usage of this exception should contain a description of the environment the device will be placed in. This should include the reasoning as to why this is the environment it will be placed in as well as the security measures. This might be different for each access method, as physical security measures might not be enough to prevent someone from connecting to Wi-Fi. The level of detail should be sufficient for an independent evaluator to assess the claim without relying on assumptions. 

An example could be lab equipment that is only used in environments subject to regulatory requirements for physical security. In such cases, the justification may reference those requirements and describe the associated security measures, such as restricted access controls or controlled networks.

Conclusion

The exceptions found in EN18031, when used correctly, do not inherently reduce cybersecurity and provide manufacturers with some flexibility when designing their devices for certain uses. After all, a radar system used only by military and government would have vastly different security considerations and expectations than a home use label maker. 

 

 

avatar
Øyvind Storhaug
Øyvind Storhaug is a seasoned cybersecurity professional with over a decade of experience in this field. He has served as a Security Consultant at Nemko for the past two years. In this role, Øyvind has been responsible for testing IoT products, performing penetration testing, and scanning for system vulnerabilities. Before joining System Sikkerhet AS, Øyvind held several key roles, including Technical Account Manager, Security Analyst and Tool Expert in McAfee IPS and Firepower IPS.
COMMENTS

RELATED ARTICLES