The Cyber Resilience Act (CRA) requires products with digital elements to be designed, developed and produced so that their attack surfaces are limited, including external interfaces. For product teams, that means more than closing unused network ports: the practical task is to know every reachable interface and service, justify why it exists, remove unnecessary exposure, and retain evidence that the released product matches the approved design.
This requirement is risk-based. The manufacturer’s cybersecurity risk assessment determines which controls are appropriate for the product, its intended purpose and its reasonably foreseeable use. The CRA does not prescribe one universal hardening checklist for every device or software product.
What the CRA requires
Annex I Part I point 2(j) of Regulation (EU) 2024/2847 requires products with digital elements, where applicable on the basis of the cybersecurity risk assessment, to be designed, developed and produced to limit attack surfaces, including external interfaces.
That wording is deliberately broader than “secure the internet-facing API.” An attack surface is the set of product elements through which an attacker may try to influence, observe or reach security-relevant functionality. Depending on the product, that can include network listeners, local ports, administration interfaces, update channels, wireless protocols, debug functions, service endpoints, parsers, optional modules and exposed dependency functionality.
The Commission’s manufacturer guidance places Annex I requirements inside a lifecycle process: manufacturers first perform a cybersecurity risk assessment, then use it to determine how the applicable essential cybersecurity requirements should be implemented and documented.
The legal requirement is therefore the outcome to achieve: limit the attack surface. The concrete engineering controls are product-specific.
Start with an exposure inventory
A team cannot reduce exposure it has not identified. The useful starting point is an inventory of all interfaces and externally reachable functionality for the exact product and release.
For each entry, record:
- interface or service name;
- protocol, port, endpoint or physical interface where applicable;
- whether it is reachable remotely, locally or only from a privileged environment;
- intended user or system actor;
- business or product function that requires it;
- authentication and authorisation boundary;
- default state in a production installation;
- configuration mechanism that can enable or disable it;
- component or dependency that implements it; and
- verification method used to confirm the production state.
Do not restrict the inventory to TCP and UDP ports. A product may expose a local USB maintenance interface, Bluetooth pairing function, serial console, browser administration page, cloud API, plugin interface, update endpoint or inter-process interface that materially changes its attack surface.
The inventory should be specific enough that a reviewer can compare the intended exposure with what the release actually contains.
Separate required interfaces from convenient ones
Every exposed interface should have a current justification tied to an intended product function.
A practical review asks three questions:
- Is the interface required for normal operation?
- If it is optional, must it be enabled by default?
- If it is not required for production use, why is it present at all?
This distinction matters because interfaces often survive for historical rather than functional reasons. A service may remain enabled because an earlier release used it. A diagnostic endpoint may have become part of a support routine. A legacy protocol may still be present because removing it would require migration work.
Those explanations can be operationally understandable while still representing unnecessary exposure. The review should force an explicit decision rather than allowing inherited functionality to remain indefinitely.
Use a default-deny production baseline
ENISA’s 2026 Secure by Design and Default Playbook treats attack-surface minimisation as a secure-by-design principle and recommends exposing only what is necessary. Its attack-surface playbook calls for a default-deny posture in which ports, APIs and interfaces are closed unless production use requires them.
For many products, this translates into a production baseline such as:
- only approved network listeners enabled;
- optional administration functions disabled until explicitly configured;
- firewall or access-control rules generated from an allowlist;
- unused protocols removed from the production image;
- no test endpoints exposed;
- development features excluded from production builds; and
- deployment profiles that do not inherit permissive development settings.
Default deny is an engineering pattern, not wording prescribed by Annex I point 2(j). The manufacturer should use it where appropriate to the product and risk assessment.
The important evidence is not the policy statement “unused services are disabled.” It is the production configuration or test result showing which services are actually enabled.
Treat local and physical interfaces as part of the attack surface
“External interface” does not mean only “internet-facing.”
Industrial products, embedded devices and appliances may contain physical or local interfaces that become security-relevant when an attacker, service technician or adjacent system can reach them. Examples include:
- serial consoles;
- JTAG or other debug access;
- USB service ports;
- removable media interfaces;
- maintenance Ethernet ports;
- local web administration;
- Bluetooth or other short-range wireless interfaces; and
- fieldbus or proprietary service protocols.
The risk assessment should consider the deployment environment. A physical debug header inside a sealed device has a different exposure profile from an unauthenticated maintenance port available from a shared network, but neither should be ignored simply because it is not public on the internet.
Where an interface must remain for manufacturing, servicing or recovery, document why it is needed and how access is constrained.
Remove development and diagnostic functionality from production
Development features are especially important because they are often intentionally powerful.
ENISA’s attack-surface playbook recommends removing debuggers, test endpoints, debug modes and other development features from production builds unless there is evidence that they cannot affect security.
Typical review targets include:
- debug shells;
- verbose management endpoints;
- developer backdoors or bypasses;
- test credentials;
- diagnostic APIs;
- compiler or scripting environments not required by the product;
- factory-only services;
- unrestricted tracing functions; and
- hidden support URLs or commands.
A production build pipeline can make this easier by treating development functionality as an explicit build-time feature set rather than something operators must remember to disable manually.
Verification should inspect the actual production artefact or deployed configuration. Reviewing source flags alone may miss packaging, dependency or deployment behaviour that reintroduces a service.
Minimise optional components and dependencies
Attack surface is also influenced by the amount of executable functionality shipped with the product.
An unused library is not automatically an externally reachable interface, but unnecessary packages, runtimes, plugins, protocol stacks and optional modules can create additional reachable code paths or future vulnerability handling work. ENISA therefore includes dependency and minimal-build review in its attack-surface guidance.
For software and firmware products, useful questions include:
- Which packages are required by an intended function?
- Are optional modules installed even when the feature is disabled?
- Does a runtime expose functionality the product never uses?
- Are unused protocol handlers present?
- Does a plugin framework load components that are unnecessary for this deployment?
- Can the base image or firmware profile be reduced without breaking intended functionality?
This review should stay connected to the release-specific SBOM or component inventory so that the product team can distinguish intentional dependencies from accidental packaging.
Review administrative and management paths separately
Management interfaces often deserve a stricter review than ordinary user-facing interfaces because compromise may provide privileged product control.
For each administrative path, verify:
- who is expected to use it;
- how the user or system authenticates;
- which privileges it grants;
- whether it is remotely reachable by default;
- whether it can be restricted to a management network or local context;
- whether failed and successful access attempts produce relevant security evidence; and
- whether the interface can be disabled when it is not needed.
This connects attack-surface minimisation with other Annex I requirements, such as protection against unauthorised access and security-relevant monitoring. Those are separate requirements, but they affect the risk created by an interface that remains exposed.
Revisit the attack surface when the product changes
An interface inventory becomes stale quickly if it is treated as release documentation created once.
Changes that should trigger review include:
- a new API or protocol;
- a new cloud or remote-processing dependency;
- a new administration function;
- new wireless connectivity;
- a new update or recovery mechanism;
- a major dependency or platform change;
- a new plugin or extension mechanism;
- a change in default configuration; or
- migration from local processing to remote processing.
The review should answer what became reachable, what stopped being reachable, and whether the risk assessment or controls must change.
ENISA’s playbook also recommends reviewing legacy exposure continuously so that deprecated APIs, old protocols and unused resources do not accumulate across releases.
Verify the shipped product, not just the architecture
Documentation describes intent. Verification establishes whether the release behaves that way.
Depending on the product, useful verification may include:
- port and service discovery against the production image;
- API route enumeration;
- testing that optional interfaces are disabled by default;
- checking firewall, gateway or access-control configuration;
- inspecting firmware or package contents for debug tooling;
- testing physical maintenance ports;
- confirming that production credentials and configuration differ from development defaults;
- comparing enabled services with the approved exposure inventory; and
- negative tests showing that removed or disabled interfaces are not reachable.
The goal is not to run a particular scanner. It is to produce evidence that the implementation matches the attack-surface decision for that product and release.
Keep exceptions explicit
Some products genuinely need broad or unusual interfaces. A support shell may be necessary for field recovery. A protocol may be required for backward compatibility. An industrial service port may be part of the intended maintenance model.
In those cases, “necessary” should be an explicit engineering decision with an owner and rationale.
A useful exception record contains:
- the interface or component;
- why it must remain;
- the relevant risk scenario;
- compensating controls;
- verification evidence;
- product or release scope;
- review owner; and
- trigger or date for reassessment.
This is stronger than silently accepting the interface because removing it is inconvenient.
What evidence should manufacturers retain?
Attack-surface evidence should make the design decision traceable to the product and release.
A practical evidence set can include:
- exposure and interface inventory;
- architecture or data-flow diagrams;
- relevant cybersecurity risk-assessment entries;
- production service and port configuration;
- firewall or allowlist configuration;
- production build manifests;
- release-specific SBOM or component inventory;
- results from interface and service discovery;
- evidence that development and diagnostic functions are absent or controlled;
- documented exceptions with compensating controls; and
- release-review records showing that new or changed interfaces were assessed.
The CRA does not prescribe this exact evidence package. These records are practical ways to support technical documentation and demonstrate how the manufacturer implemented the requirement.
Build the check into release governance
Attack-surface review is most reliable when it is part of the release process rather than an occasional hardening exercise.
A release gate can ask:
- Has the interface inventory been updated?
- Are all exposed services justified?
- Are unnecessary interfaces disabled or removed?
- Are debug and development features absent from the production build unless explicitly justified?
- Does the production configuration enforce the intended baseline?
- Have new dependencies or optional modules changed exposure?
- Have relevant exceptions been reviewed?
- Do verification results match the approved inventory?
The gate should not make the legal conformity decision automatically. It is an engineering control that makes the evidence and accountable decision visible.
Keeping the interface inventory, risk decision, verification evidence and release scope connected is the operational challenge behind this requirement. AA-sec is designed around traceability between requirements, evidence, decisions and exact product or lifecycle context, which can help teams keep attack-surface decisions attached to the release they support. AA-sec does not make the manufacturer’s legal CRA conformity decision.
Practical checklist
Before treating attack-surface reduction as covered for a release, confirm that the team can answer:
- Do we have a current inventory of network, local, physical and administrative interfaces?
- Is every exposed interface tied to an intended product function?
- Are optional services disabled by default where appropriate?
- Are development, test and diagnostic functions removed or controlled in production?
- Are unnecessary packages, protocols and optional components excluded?
- Have administrative paths received a separate privilege and reachability review?
- Have product changes triggered an updated exposure review?
- Have documented exceptions been reassessed?
- Does verification of the shipped product match the approved exposure inventory?
- Can the evidence be tied to the exact product, variant and release?
Key takeaway
Cyber Resilience Act attack surface minimisation is a lifecycle engineering requirement, not a one-time port scan. The manufacturer needs to identify what is exposed, justify what remains, remove or disable what is unnecessary, verify the production state and repeat the review as the product changes.
ENISA’s 2026 playbook provides a practical implementation model through exposure inventories, default-deny baselines, minimal production builds, development-feature removal and release evidence. The manufacturer still has to apply those practices in the context of its own cybersecurity risk assessment and product architecture.
Official sources
- Regulation (EU) 2024/2847 - Cyber Resilience Act — EUR-Lex
- Cyber Resilience Act - Manufacturers — European Commission
- Commission publishes new guidance to support timely Cyber Resilience Act implementation — European Commission
- ENISA Secure by Design and Default Playbook — ENISA