Attack-surface reduction under the CRA is an architecture and product-design activity, not merely a penetration-testing task. Manufacturers should inventory externally and internally reachable interfaces, remove unnecessary services and functions, reduce privileges and exposed complexity, control administrative and debugging paths, and revisit the surface when features or integrations change.
Annex I Explicitly Requires Attack-Surface Limitation
Annex I Part I point 2(j) requires products with digital elements to be designed, developed and produced to limit attack surfaces, including external interfaces. The requirement is applied on the basis of the cybersecurity risk assessment and where applicable. An attack surface is broader than a list of known vulnerabilities. It consists of the paths, interfaces, functions and privileges through which an attacker might interact with or influence the product. A product can have a large attack surface even when no known vulnerability has yet been identified. The CRA therefore places value on reducing unnecessary exposure before vulnerabilities are discovered.
- Identify reachable product interfaces.
- Identify unnecessary exposed functionality.
- Reduce avoidable privileges.
- Remove obsolete or unused services.
- Verify the surface of the actual shipped product.
External Interfaces Are Specifically Included
Point 2(j) expressly mentions external interfaces. Depending on the product, these can include network ports, APIs, web interfaces, wireless services, USB or hardware interfaces, management protocols, local sockets, file-import mechanisms, plugin systems and cloud-facing endpoints. An interface does not need to be internet-facing to form part of the attack surface. A local interface can still be exposed to an untrusted application, user, peripheral or adjacent device. Manufacturers should document which external interfaces exist, why they are required and what trust assumptions apply to each one.
- Inventory network interfaces.
- Inventory APIs and management endpoints.
- Inventory physical and peripheral interfaces.
- Inventory file and plugin interfaces.
- Document the purpose and trust boundary of each interface.
Unnecessary Services Increase Exposure
Products frequently inherit services and components from general-purpose operating systems, frameworks, development environments or reference platforms. Some may not be needed for the product's intended purpose. An enabled service creates code paths, parsers, credentials and maintenance responsibilities even when users rarely interact with it. Manufacturers should therefore examine which services are present in the production build and whether they need to be enabled. Secure-by-default configuration and attack-surface limitation reinforce each other here: unnecessary services should ideally be removed entirely, or disabled by default where they are genuinely optional.
- Review listening services.
- Remove development-only services.
- Disable unnecessary optional services.
- Review bundled software and daemons.
- Verify production rather than development configuration.
Administrative Interfaces Deserve Higher Scrutiny
Administrative interfaces can provide broad control over configuration, users, updates, logs and system state. Their compromise can therefore produce greater consequences than compromise of an ordinary feature. Manufacturers should examine whether administrative interfaces need remote exposure, whether they can be separated from public-facing interfaces and whether strong authentication and authorisation are applied. Restricting administrative functionality to appropriate management contexts can materially reduce attack surface. Recovery, maintenance and support interfaces should receive the same scrutiny because attackers often target alternative management paths that receive less security testing.
- Identify privileged management interfaces.
- Avoid unnecessary public exposure.
- Apply appropriate authentication and authorisation.
- Separate management functions where useful.
- Include support and recovery paths in testing.
Debugging and Manufacturing Interfaces Can Survive Into Production
Debug ports, diagnostic APIs, test accounts and manufacturing functions are useful during development and production but can become security liabilities if left accessible in released products. Hardware products can expose serial, JTAG or other debugging functions, while software can retain diagnostic endpoints or test commands. Product release controls should identify these mechanisms and determine whether they need to be removed, disabled, protected or otherwise constrained. An interface that was never intended for end users can still become part of the CRA attack-surface analysis if it remains reachable in the marketed product.
- Inventory development and manufacturing interfaces.
- Remove test accounts.
- Disable unnecessary debug functionality.
- Protect required service interfaces.
- Verify production builds independently.
Privilege Is Part of the Effective Attack Surface
Attack surface is influenced not only by how many interfaces exist but by what compromised code can do. A parser running with broad system privileges can create a larger consequence than the same parser isolated within a restricted process. Least privilege, process separation, sandboxing and permission boundaries can therefore reduce the effective attack surface and limit reachable assets. These measures also support incident-impact reduction under Annex I point 2(k), but the design questions are distinct. Point 2(j) asks whether unnecessary attack paths and exposure can be reduced before exploitation occurs.
- Reduce unnecessary process privileges.
- Separate security domains where appropriate.
- Restrict filesystem and device access.
- Restrict network access by component.
- Review privilege changes during feature development.
Complexity Can Expand Attack Surface
Every additional parser, protocol, plugin, scripting engine, file format or integration can create new input paths and code that processes untrusted information. This does not mean complex products are prohibited, but teams should understand the security cost of unnecessary complexity. Product design reviews can ask whether a feature needs to exist, whether a simpler protocol can provide the same intended function or whether optional functionality can be isolated. Reducing attack surface can therefore involve product-scope decisions as well as technical hardening. Features that have reached end of life should be removed rather than remain indefinitely as unmaintained attack paths.
- Review unnecessary parsers and protocols.
- Review plugin and extension mechanisms.
- Remove obsolete features.
- Reduce duplicated interfaces.
- Document security trade-offs for required complexity.
Attack Surface Changes With the Product
A product's attack surface is not fixed at initial release. New integrations, remote services, APIs, device interfaces and administrative functions can add entry points. Changes to deployment can also expose interfaces that were previously internal. Manufacturers should include attack-surface review in relevant design and release changes. The interface inventory should identify the product version and configuration so that old assumptions do not persist after the architecture changes. Removing an interface should also be recorded because it can affect documentation, testing and user migration.
- Review new interfaces before release.
- Review changed deployment exposure.
- Review new privileges and integrations.
- Retire obsolete interfaces deliberately.
- Update the cybersecurity risk assessment.
Evidence for CRA Attack-Surface Limitation
Useful evidence can include interface inventories, network-service inventories, architecture diagrams, privilege maps, production configuration records, threat models, design-review decisions and security test results. Manufacturers can also retain evidence showing that unnecessary services or interfaces were removed or disabled. Verification should compare intended exposure with the actual production product because packaging, operating-system defaults and deployment configuration can introduce interfaces that architecture documents do not show. Attack-surface evidence should be version-specific and connected to the product's cybersecurity risk assessment.
- External interface inventory.
- Service and port inventory.
- Privilege architecture.
- Production configuration evidence.
- Attack-surface design review.
- Exposure verification and security testing.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.