Deep Dive: CRA Requirement (j) – Limiting Attack Surfaces

Requirement (j) of the Cyber Resilience Act addresses the concept of attack surfaces. An attack surface consists of all the ways an external party can interact with a product — for example, through physical ports, communication interfaces, or software services. The more of these points that exist, the greater the potential for misuse if they are not properly managed. The CRA states:

“be designed, developed and produced to limit attack surfaces, including external interfaces”

In practical terms, manufacturers should refrain from exposing unnecessary functions or interfaces and ensure the secure implementation of those that are necessary. The requirement is not about removing functionality for its own sake but about making deliberate design choices. Only what is required for the product’s purpose should be included, while everything else is either disabled or properly protected. This reduces unnecessary exposure and ensures products are better prepared against cyberattacks.

What This Requirement Means

Imagine a smart building gateway with ten different communication interfaces enabled by default: Wi-Fi, Bluetooth, USB, debug ports, and multiple protocol adapters. Each one offers a potential entry point for attackers. Even if some of these interfaces are not used in the actual deployment, they remain open doors unless they are deliberately disabled. Limiting attack surfaces means reducing these points of exposure to the absolute minimum required for the product’s purpose.

Applying this requirement involves two main considerations. First, identify interfaces or functions that are not needed and remove them completely. Typical examples include unneeded operating system packages that come pre-installed but are irrelevant for the application or hardware interfaces supplied by a component vendor that serve no purpose in the final product. Eliminating such elements reduces complexity and removes potential attack vectors. Second, for the functions and interfaces that remain, ensure they are only active when truly needed and secured through restrictions such as access controls, hardened configurations or monitoring.

This principle applies equally to hardware and software. APIs, background services and communication protocols can all create unnecessary exposure. Depending on your CRA risk assessment, the continued use of unsecure protocols may not be acceptable under the CRA. This creates challenges in both embedded devices and industrial IoT or OT systems, where such protocols (e.g. MQTT without TLS, Modbus TCP/RTU, PROFIBUS, HTTP, and many more) are still widely used. In industrial environments especially, replacing them is often complex due to legacy interoperability requirements.

Even so, we expect the CRA to accelerate the transition to secure protocol versions, as new products will be required to avoid insecure options and justify their design decisions based on the risk assessment.

Relevant Standards and Guidelines

Several existing standards can provide a foundation for limiting attack surfaces and secure interface design:

• EN IEC 62443-4-1 and 4-2 (industrial components): Cover secure product development practices and technical requirements, including limiting interface exposure.

• ETSI EN 303 645 (consumer IoT): Requires disabling unused interfaces and restricting exposure of attack surfaces.

• ISO/IEC 15408 (Common Criteria): Provides evaluation criteria for attack surface reduction and interface controls.

While existing standards describe principles and requirements, they often stop short of giving practical guidance on balancing usability and security in IoT and OT devices. For example, how to manage debug interfaces in embedded systems without compromising maintainability is not addressed in detail. It remains to be seen if harmonized standards will close all existing gaps.

However, the 13 essential cybersecurity requirements will be mandatory regardless of the release of new standards. Together with the required CRA risk assessment, they should serve as the main guiding points for manufacturers to start their compliance journey. It is also important to understand that harmonized standards only provide guidance and a presumption of conformity. If a manufacturer follows the standards but does not implement necessary best-practice security measures, a product may still be considered non-compliant, and consequences should be expected if an investigation is initiated.

How to Approach Implementation

To implement Requirement (j), manufacturers need to adopt secure-by-design principles from the start of product development. Attack surface reduction should not be an afterthought but a guiding principle throughout the design, development, and production stages.

Key capabilities to consider include:

• Identify all external and internal interfaces during design, including physical ports, APIs, and services

• Disable or remove unused interfaces before release

• Apply least privilege principles to interfaces and services that remain

• Harden exposed protocols and apply strong authentication where necessary

• Monitor and log interface activity to detect misuse

• Review development and debug features to ensure they are not shipped in production builds

In industrial IoT and OT systems, the main challenge is balancing interoperability with security. Gateways, controllers, and field devices often need to support multiple communication protocols to connect with legacy equipment. However, each additional protocol increases the attack surface. Depending on the risk assessment, the continued use of insecure or legacy protocols may not be acceptable under the CRA. Manufacturers should therefore provide clear options to disable unused or outdated protocols, replace them with secure alternatives wherever possible, and document how exposure is minimised in real deployments.

In embedded IoT devices, the biggest risks stem from physical and low-level interfaces such as UART, JTAG, or USB. These are often left enabled for convenience during development or manufacturing but can be exploited once the device is deployed in the field. To reduce this risk, manufacturers should enforce secure boot, disable or lock debug features in production builds, and apply hardware-based protections where feasible. Even for small devices, there should be a clear separation between essential functions and optional features, ensuring that unnecessary interfaces are either removed or strictly controlled.

Critical considerations include ongoing vulnerability management: the attack surface is not static; it changes as new features are added or interfaces evolve. Regular reviews and updates are required to ensure exposure remains limited over the product’s lifecycle.

Compliance and Strategic Considerations

From a compliance perspective, Annex VII requires manufacturers to document which interfaces exist, why they are necessary, and how exposure is minimised. Annex II requires that the user guide explains configuration options for enabling or disabling interfaces and how these changes can affect security.

When deciding between building your own controls or using vendor platforms, consider how much visibility and configurability you need. Vendor platforms may provide generic interface hardening, but manufacturers are responsible for tailoring exposure to their specific product and use cases. You should not assume that vendor defaults will automatically meet CRA expectations.

Strategically, requirement (j) reinforces the idea that “less is more” in cybersecurity. Every unnecessary interface or service adds complexity, cost, and risk. Companies that adopt a disciplined approach to attack surface management will not only meet CRA obligations but also produce leaner, more robust products that inspire greater trust in the market.

In our next post, we will explore Requirement (k): Mitigation of incident impact, which defines how products need to reduce the impact of cybersecurity incidents.

Previous Blog CRA Requirement (i): https://www.tributech.io/blog/cra-requirement-i-no-harm-to-connected-systemsNext Blog CRA Requirement (k):https://www.tributech.io/blog/cra-requirement-k-mitigation-of-incident-impact