What CRA Annex I (2)(j) asks manufacturers to do with attack surfaces
Point (2)(j) of Annex I Part I asks manufacturers to design, develop and produce their products so that the attack surface is limited, including the external interfaces. In practice, the attack surface is every place an attacker could try to get into or influence the product: network listeners, web administration pages, USB and serial ports, debugging and test interfaces, APIs, wireless radios, and any service that runs by default whether or not the customer needs it. An external interface is any of these that is reachable from outside the device or the product's own boundary. The manufacturer owns this decision. It is not enough to ship a product and document a firewall recommendation for the customer to apply.
The point is applied through the manufacturer's cybersecurity risk assessment under Article 13(2), which decides what the product needs to do and therefore which interfaces and services are justified. Every exposure that remains after removal or disabling should trace back to a recorded reason in that assessment. The Commission's FAQ gives a useful illustration: a printer whose motherboard keeps a debugging interface enabled is a vulnerability the manufacturer has to assess, not a detail left to the integrator. Confirm with your assessor how they expect debug and factory-test access to be closed in production firmware, because this is where teams most often find undocumented exposure.
This is hard in practice for three reasons. Debug ports and default services are often added during development and never removed from the release build. Inherited components, such as an operating system image, a web framework or an embedded library, bring their own listeners and default accounts that the product team did not choose. And hardware and software variants multiply the interfaces that must be reviewed for each model. Ask your engineering team to produce an inventory of listening services and enabled interfaces per release, compare it against the risk assessment, and record each remaining exposure with its justification and the controls protecting it.
Which interfaces, services and components fall inside the (2)(j) scope
Point (2)(j) reaches every route into and out of the product, not only the features marketed to users. The cards below walk through the surfaces a manufacturer should inventory, and each one changes the design and documentation work in a different way.
Network-facing services
Every listening port, daemon and web endpoint the product opens on its default build is in scope, including services that run only during setup or first boot. Inventory them from the shipped image, not from the design document, because a service enabled by a default configuration file is easy to miss. For each one, record whether it is needed for the essential functions and, if not, whether it can be disabled by default.
Debug, serial and USB interfaces
Physical interfaces such as JTAG headers, UART consoles and USB ports can expose a shell, memory or firmware even when no network port is open. The Commission's example of an office printer with a debugging interface left enabled shows why these belong in the risk assessment. Confirm which of these pins, ports and bootloader modes remain functional in production hardware and firmware.
APIs and admin consoles
Management APIs, configuration portals and administrative consoles often carry more privilege than end-user functions. Check which ones are reachable from outside the intended network segment, which authentication they require, and whether they are enabled in every product variant. Document the exposure that remains, such as an admin console that must stay reachable for remote support, so that the decision can be reviewed later.
Bundled third-party components
Libraries, runtimes, databases and base images shipped inside the product add their own services and interfaces. A component can open a port or debug feature that the manufacturer never wrote. Build a component list from the release artifacts and check each one for listening services and optional features that the product does not use. Scanners such as Trivy can help identify the packages, but they do not show whether a shipped feature is reachable.
Build and update channels
The pipelines, signing keys, update servers and package repositories that deliver the product are part of its attack surface, because an attacker who reaches them can change what customers install. Record which channels accept inbound connections, who can publish to them, and whether test or debug builds can reach production users. Treat any leftover build-time switch that enables extra access as a scope item in its own right.
Interfaces added after release
Adding an externally reachable interface after release can change the product's status. The Commission guidance states that new interfaces not foreseen in the risk assessment can make even a security update a substantial modification. Before every feature release, compare the interface inventory with the last documented baseline, update the risk assessment, and confirm whether the change is a substantial modification that requires a new conformity assessment.
How an assessor tests limited attack surfaces
This table walks through the four steps an assessor is likely to take when checking point (2)(j), with the evidence each step draws on and the findings that commonly come up. Read it as a preparation checklist: each row is something the manufacturer should be able to show before the assessment starts.
| Test step | What the assessor checks | Evidence requested | Common finding |
|---|---|---|---|
| Review the risk assessment | Whether the Article 13(2) risk assessment identifies external interfaces, debug functions and services, and records how each was handled | Risk assessment entries for each interface, with the decision and its rationale | Interfaces appear in the design but are missing from the risk assessment |
| Inspect the interface inventory | Whether every external and internal interface is listed, with its purpose, protocol and default state | Interface inventory tied to the architecture description in the technical documentation | Debugging or test interfaces are not listed at all |
| Check production builds against the design | Whether the shipped build enables only the interfaces and services the design says it needs | Build configuration, firmware or image manifests, and port or service scan results from production-like builds | Debug interfaces remain enabled in production firmware, as in the printer example in FAQ 4.3.1 |
| Test exposed interfaces | Whether reachable interfaces can be used beyond their intended function, and whether unused ones respond at all | Test reports, scan outputs and the remediation or disablement record for each finding | Open ports with no documented purpose, or services that answer on interfaces the manufacturer says are disabled |
| Confirm documented residual exposure | Whether the exposure that remains after hardening is explained and justified for users | Documented residual exposure statement, user-facing guidance and the link to the support period | Residual exposure is not documented, so the assessor cannot tell accepted risk from oversight |
How to implement (2)(j) step by step
This sequence takes a product from an unknown set of interfaces to a documented, justified attack surface that matches the manufacturer's risk assessment. Each step produces a record that the next step relies on, so an assessor can trace any exposed interface back to a decision.
Inventory every external and internal interface
Engineering lists every way the product can be reached or accessed: network ports and services, management consoles, APIs, debug and test interfaces, physical ports such as serial or JTAG headers, USB, update channels, and interfaces between internal components. Include interfaces in third-party components and bundled services, not only the parts the team wrote. The output is an interface register with one entry per interface, its owner, its protocol or medium, and the component it belongs to. The step is done when a build-level scan and a hardware review have both been compared against the register and no unlisted interface remains.
Classify each interface as needed or not needed
For each register entry, the product owner and security lead record whether the interface supports the product's intended purpose, is required for a supported installation or maintenance task, or serves only development, testing or manufacturing. Interfaces that fall outside those categories are marked for removal or disabling. Each classification cites the intended-purpose statement from the technical documentation. The output is a classified register where every entry has a decision and a named approver, and the same register feeds the risk assessment.
Remove or disable unneeded interfaces in the build
Build engineers change the product configuration so unneeded services are not compiled in, not started at boot, or not listening on any address. Debug ports are disabled in firmware or fused off where the hardware allows, and default accounts and sample endpoints are removed from the image. Where hardware cannot be changed, the team documents the software control that blocks the interface. The output is a build configuration under version control with a reference to each removed or disabled interface. The step is complete when the change is reviewed and merged, not when a developer reports it works locally.
Verify the exposure on the shipped image
Test the image or firmware that will actually be placed on the market, not the development build. Run a port and service scan from each network segment the product is designed for, confirm that disabled interfaces do not respond, and check the file system for leftover debug tools, shells or test keys. Configuration checks such as those in Wazuh Security Configuration Assessment or Fleet policies can confirm the expected state on deployed devices. The output is a test report showing the expected and observed state of every register entry, with failures logged as defects.
Record the residual exposure with justification
Some interfaces must remain open for the product to work. For each one, the team writes the reason it is needed, the users and systems allowed to reach it, the authentication and access controls protecting it, and the monitoring that records its use. This record is the documented residual exposure that a reader of the technical documentation should be able to understand without asking the engineering team. The output is a residual exposure list approved by the product owner and the security lead, with a review date set by the manufacturer's own process.
Link each decision back to the risk assessment
The cybersecurity risk assessment is the document that justifies every Annex I decision, so each interface decision is linked to the risk scenario it addresses: an interface removed because an attacker could use it to reach a service, or a residual interface accepted with a stated risk treatment. Where the assessment does not cover an interface, the assessment is updated before release. The output is a traceability table from risk items to register entries, build changes and test results, and it is the artifact an assessor will sample first.
Keep the record current across updates
Any new interface, service or external endpoint added in a later release triggers the same inventory, classification and verification steps before it ships. Commission guidance C(2026) 5252 notes that adding new externally reachable interfaces not foreseen in the risk assessment can make even a security update a substantial modification, so change control must check the register before a release is approved. The output is a change-control gate that blocks release when the register or traceability table has not been updated. Confirm with the market surveillance and legal teams how your release process will be documented.
How the attack surface review differs for hardware, firmware and software
For physical products, the review starts on the board. Engineers check which debug headers, test points, serial consoles, JTAG or SWD ports, USB interfaces and wireless radios exist on the production design, and whether each one is populated, enabled or reachable after assembly. A debug interface that works on the bench can still be exposed in the field, so the review should be run against production units, not only prototypes. The Commission's FAQ example of an office printer with a debugging interface left enabled on its motherboard shows the kind of finding this review must surface and assess.
- Board inventory: list every physical interface from schematics and the physical unit, including those hidden under covers or unpopulated pads that a later revision could enable.
- Enablement state: record whether each debug port is disabled in fuses, firmware or hardware, and how that state is verified on shipped units.
- Disabling method: document whether removal, fuse blowing, or a locked configuration is used, and whether the method can be reversed in the field.
- Remaining exposure: describe any interface that must stay active, such as a service port, with its access control and the risk it carries.
- Supplier changes: track interfaces introduced by component substitutions, since a new chip can add an interface the original design did not have.
Confirm with your hardware and test teams that the production configuration matches the reviewed design before the risk assessment is signed off.
Embedded firmware exposes its attack surface through what it runs by default. The review inventories every network service, listening port, management protocol, web interface, default account and bootloader setting in the built image, then compares that list with what the intended use case requires. Services left in the image because they were convenient during development are the usual finding. Because firmware is often updated in the field, the review also has to cover how the update mechanism itself is reachable and protected.
- Service inventory: list every daemon, open port and protocol in the shipped image, and map each one to a documented function.
- Default configuration: record which services start at boot, which default credentials or test accounts exist, and which are removed or disabled before release.
- Build-time removal: show that unneeded components are excluded at build time, not merely hidden at runtime, so they cannot be re-enabled by a configuration change.
- Update path exposure: document the reachability and authentication of the update channel and any recovery or bootloader interface.
- Configuration evidence: keep build manifests and a scan of the running image that shows the same services as the design.
Check that the documented service list matches the image that ships, and that the list is regenerated for each firmware version.
Software and SaaS-backed products usually expose the most interfaces, and many of them are added over time. The review covers public and internal APIs, administrative consoles, plugin or extension points, message queues, file import paths, and the container images or virtual machine images that package the product. Where a SaaS backend is part of the product, the review also covers the cloud services and network paths it depends on. The documentation burden is heavier here because each release can change the surface, so the record has to be kept current through the support period.
- API and endpoint inventory: list routes, authentication requirements and whether each is intended for customers, integrators or internal use only.
- Container and image contents: scan images for packages and services that are not needed at runtime, and remove build tools and shells from production images.
- Dependency exposure: identify libraries that open listeners or accept input from untrusted sources, and document how each is constrained.
- Environment defaults: review default ports, debug endpoints, verbose error pages and sample applications shipped with the product.
- Change tracking: tie each new interface to a release record and to an update of the architecture description in the technical documentation.
Confirm that the inventory is generated from the release build and not maintained by hand, since manual lists drift from the shipped product.
Evidence that shows limited attack surfaces and documented exposure
Point (2)(j) is proven by a set of artifacts, not a single statement that the product is hardened. Each artifact below shows what was removed or disabled, what remains exposed, and why, and each must stay current for the support period and feed the technical documentation under Annex VII point 2(a).
Interface and port inventory
A dated list of every external interface the product exposes, including network ports, management consoles, APIs, USB and serial ports, and wireless radios, with the component that owns each one. Compare the inventory against the architecture in the technical documentation, since an interface missing from the inventory is the usual gap assessors find. Confirm that each entry names a documented reason for being open.
Configuration baselines
Hardened default configurations for each shipped component, recorded as a versioned baseline and compared against running devices or images. Drift between the baseline and the shipped state is the evidence that defaults were not weakened in production. Ask whether the baseline is generated from policy or edited by hand, and who approves changes to it.
Build-time disable records
Records showing which services, packages, kernel modules, compiler features and sample applications were removed or excluded at build time, with the reason for each. Keep these records in the build pipeline so each release can be reproduced. Confirm that the list of removed components is reviewed when the bill of materials changes.
Debug interface disablement proof
Evidence that debugging and test interfaces, such as JTAG, UART consoles and developer endpoints, are disabled or fused off in production hardware and firmware. The Commission FAQ uses a printer motherboard with an enabled debug interface as an example of a vulnerability the risk assessment must address. Ask the manufacturer to show the verification on production units, not only on development boards.
Scan results and exposure checks
Port scans, vulnerability scans and misconfiguration checks run against released images and devices, with the scanner version, date and findings retained. Trivy reports known vulnerabilities in OS packages and dependencies, Greenbone (OpenVAS) runs network vulnerability tests, and Fleet policies show which devices pass or fail a yes or no check. Each finding should map to a fixed issue, an accepted exposure or an open item.
Documented residual exposure
A register of the interfaces and functions that must remain open, such as update endpoints or the service port a customer needs, with the justification, the compensating controls and the owner who accepted the risk. This register is the core output of the (2)(j) decision. Check that every residual item is traceable to the risk assessment and that the register is reissued when a new interface is added.
What new interfaces do to the attack surface and to conformity
Adding an externally reachable interface can turn a routine security update into a substantial modification. The Commission's guidance C(2026) 5252, in section 4.3, notes that new externally reachable interfaces not foreseen in the risk assessment can have this effect. The practical consequence for a product team is that the attack surface recorded in the risk assessment is a legal baseline, not just an engineering document. A new management port, a webhook endpoint, a remote diagnostics service or a cloud sync API that was never assessed can move the product outside the conformity assessment it was previously cleared under, even if the code change itself looks small.
A change gate is the control that catches this before release. Build it into the same pipeline that produces the release candidate, and have it compare the current interface inventory against the baseline in the risk assessment and technical documentation. The inventory should list every listening port, exposed API route, admin console, debug or service interface, and remote update endpoint, along with the component that owns it and whether it is enabled in the default build. A release fails the gate when an interface appears that has no matching entry, when a documented interface changes its authentication or exposure, or when a debug interface is enabled in a production image. Each failure needs a named owner and a documented decision: remove the interface, assess it and update the risk assessment, or confirm with counsel or the conformity assessment body that the change does not alter the assessed product.
Ask your conformity assessment body or legal adviser to confirm, in writing, how they treat a new interface found during a security update. The answer determines whether your gate can approve a change internally or must route it to a reassessment, and it should be recorded alongside the gate's decision log. Retain the gate output as evidence for each release so that an authority reviewing the product can see which interfaces existed, which were added or removed, and who approved the exposure that remained.
What limiting attack surfaces costs in money and effort
The largest share of the work is usually engineering time spent building an inventory of every external interface, service, port, debug path and default account, then removing or disabling what the product does not need. This is mostly one-time work for the initial release, but each new interface added in later versions repeats part of it. The manufacturer pays its own staff or an implementation partner for this time, and the amount depends on how many components the product contains and how much of the code base the team must review.
- Inventory scope: The cost rises with the number of services, network listeners, administrative endpoints and hardware debug interfaces that must be traced.
- Removal and disablement: Each interface the product does not need costs time to remove, test and confirm it does not break dependent functions.
- Regression testing: Turning off a service can affect functions that depend on it, so regression testing adds effort to every removal.
- Hardware review: Products with physical interfaces need a separate review of board-level debug access, which takes specialist time.
- Repeat work: Every new external interface added in a later release must pass the same review before it ships.
Ask the vendor or partner to state, in the quote, which interfaces are in scope and which engineering roles are included in the estimate.
Tooling costs depend on whether the team builds its own checks or uses open-source scanners. Several open-source tools support the evidence side of this requirement, and their licenses are generally free to use, but deployment, configuration, hosting and staff time still carry cost. Commercial tools may add license fees, which vary by vendor and are not covered here.
- Configuration checks: Wazuh Security Configuration Assessment (GPL-2.0-only) uses YAML policies, mostly based on CIS benchmarks, to check files, directories, registry keys and running processes for misconfigurations.
- Device policy checks: Fleet (MIT) policies are yes or no osquery questions that show which devices pass or fail each policy.
- Vulnerability scanning: Greenbone Community Edition (AGPL-3.0-or-later) runs vulnerability tests from the Greenbone Community Feed against target systems.
- Dependency and image scanning: Trivy (Apache-2.0) detects known CVEs in OS packages, language dependencies and container images, which helps find exposed components.
- Hosting and upkeep: Each tool needs hosting, updates, rule maintenance and log storage, which recur for as long as the product is supported.
Confirm which tools the quote includes, who maintains rule sets and whether licensing for any commercial component is in scope.
Evidence is the recurring cost that many teams underestimate. The regulation expects the manufacturer to document the exposure that remains after removals, and that record must stay current through the support period. Each release that changes interfaces, dependencies or default settings requires the attack surface record and technical documentation to be updated, which is ongoing staff time.
- Attack surface record: The list of remaining interfaces, their purpose and their risk owner must be updated with every release.
- Architecture documentation: Annex VII point 2(a) asks for a description of how software components build on or feed into each other, so changes to component relationships must be recorded.
- Risk assessment linkage: Decisions to keep an interface must trace back to the cybersecurity risk assessment, which also needs periodic review.
- Scan outputs: Scanner results, exception approvals and remediation tickets must be retained so they can be shown on request.
- Ownership: Someone must own the record, which is usually a product security role whose time recurs each cycle.
Ask the quote to name who keeps the record current after handover and how often reviews are scheduled.
External review covers independent testing or a second opinion on the attack surface. It is optional for most products under self-assessment, but many organizations buy it to test whether removals were complete. DeployOpen provides security testing of applications, APIs, cloud and infrastructure, which can cover exposed interfaces. Testing does not replace the manufacturer's own decisions, and it is priced from a written scope rather than a standard rate.
- Scope of testing: The cost depends on how many interfaces are tested, whether hardware is included and whether testing is one-time or repeated.
- Retesting: Findings usually require a second test to confirm the fix, which adds cost.
- Retainers: Continuous testing and ongoing support are available as retainers, which recur on a fixed schedule agreed in writing.
- Notified body involvement: Where a notified body is needed, its assessment is a separate cost that depends on the body and the product class.
- Deliverables: Ask whether the test report includes a list of remaining exposure that feeds the attack surface record.
Request a written scope that states interfaces, deliverables, retest rules and the schedule for any retainer.
Auditors and assessors test a sample of the product's interfaces, configurations and records. The cost to the manufacturer comes from preparing that sample: finding the right records, explaining decisions and fixing gaps the sample reveals. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, and only the independent assessor or certification body does that.
- Sample preparation: Staff time goes into pulling interface lists, scan results and approval records in a form an assessor can follow.
- Gap remediation: A sampled interface without a recorded justification may need removal or a documented exception, which adds engineering work.
- Assessor fees: The assessor's fee is paid to the assessor, and the amount depends on scope, sample size and product class. No fee figure is supplied here.
- Conformity route: Most products use self-assessment under module A, while class II and critical products need a notified body, which changes the sampling effort.
- Re-assessment: Changes to the product after assessment can require the sample to be drawn again.
Before engaging anyone, ask the assessor how it will select samples and what records it expects to see.
Which self-hosted open-source tools support attack surface evidence
This table maps four self-hosted open-source tools to the attack surface questions an assessor will ask under point (2)(j). Read each row as one source of evidence: configuration state, device state, externally reachable services, and component vulnerabilities. No single tool covers the whole attack surface, and the license column shows what to confirm before distributing or embedding any of them in a product.
| Tool | What it produces for (2)(j) | License caveat |
|---|---|---|
| Wazuh Security Configuration Assessment | Scans monitored endpoints against YAML policies that check files, directories, registry keys and running processes, and recommends remediation. Useful for showing that unneeded services and insecure settings were removed or disabled on the reference build. | GPL-2.0-only. Confirm how the policies and agent are packaged if they are shipped inside your product rather than run in your own environment. |
| Fleet policies (osquery queries) | Asks yes or no questions of devices, such as whether an unneeded service or listening port is present, and shows which devices pass or fail each policy. Supports evidence that the deployed state matches the documented attack surface. | MIT. Confirm the license terms of osquery and any agent components you distribute with the product. |
| Greenbone Community Edition (OpenVAS) | Runs vulnerability tests from the daily updated Greenbone Community Feed against target systems, producing findings on exposed services. Supports testing whether externally reachable interfaces respond as documented and whether any remain open that the risk assessment did not foresee. | AGPL-3.0-or-later. Confirm obligations if you modify the software and make it available over a network. The feed has its own terms, so check them separately. |
| Trivy | Detects known vulnerabilities (CVEs) in OS packages and language dependencies found in filesystems, Git repositories, virtual machine images and container images. Supports evidence that unneeded packages and vulnerable components are identified in the shipped artifact. | Apache-2.0. Confirm that the vulnerability databases it pulls and the scan results you retain meet your own data handling and license review. |
Who owns the (2)(j) work, and what a partner can take on
The manufacturer's product, architecture and engineering teams own the design decisions that determine the attack surface. They decide which external interfaces exist, which services start by default, which debug and maintenance paths ship, and which third-party components are bundled. These decisions must be traceable to the cybersecurity risk assessment and recorded in the technical documentation, because a later security update that adds a new externally reachable interface can change the regulatory position of the product.
- Interface decisions: Each network port, API, physical debug header and service endpoint has a named owner and a stated reason for existing.
- Default configuration: Engineering signs off on which features are enabled at shipment and which can be turned on only by an authorized user.
- Removal backlog: Unneeded libraries, sample code, test accounts and diagnostic tools are tracked as work items with a due date.
- Architecture records: Diagrams show how components connect so the attack surface can be reviewed when the design changes.
- Remaining exposure: Engineering states which surface is intentionally kept and why.
Confirm with your engineering leads which decisions are already recorded in design documents and which exist only in people's heads.
An implementation partner such as DeployOpen can take on preparatory and technical work that feeds the manufacturer's decisions. Typical tasks include building an inventory of services, ports and interfaces across the product and its deployment, scanning builds for exposed or unnecessary components, hardening images and configurations, and assembling the evidence that shows what was removed or disabled. The partner prepares systems and evidence; it does not decide the product's risk acceptance and does not sign declarations on the manufacturer's behalf.
- Surface inventory: A documented list of external and internal interfaces, collected from configuration, network scans and build outputs.
- Hardening work: Disabling services and debug paths, and reducing installed packages, in a fixed scope agreed in writing.
- Scanning and checks: Configuration assessment and vulnerability scanning of images and endpoints, with results mapped to findings.
- Evidence packages: Before and after configurations, change records and test output that the manufacturer can hand to its assessor.
- Knowledge transfer: Runbooks so the manufacturer's own teams can repeat the checks after each release.
Ask any partner which outputs they will deliver and who keeps the rights to the documentation.
An independent auditor, assessor or notified body tests the manufacturer's claims and issues any formal result. Under the CRA, most products follow self-assessment under module A, so the manufacturer performs the conformity assessment itself, while class II and critical products require a notified body. The assessor's independence is the reason a partner cannot both build the controls and certify them. Where a partner has designed or hardened the product, the assessor must review that work as an outside party would.
- Independence limit: A party that designed the hardening should not be the body that judges whether it was adequate.
- Route confirmation: Whether a notified body is required depends on the product's classification, which should be confirmed before work starts.
- Test approach: The assessor samples interfaces, configurations and evidence rather than accepting summaries.
- Formal output: Only the assessor or notified body issues a certificate or report that carries regulatory weight.
- Scope agreement: The assessor's scope and any fees are agreed directly with the manufacturer.
Check with the assessor early which evidence they expect for (2)(j) before the build is frozen.
Where manufacturers fall short on attack surface limits
Most attack surface failures are not exotic. They are interfaces, services and accounts that shipped because nobody decided they were needed, and exposure that nobody wrote down. The cards below cover the gaps assessors and market surveillance authorities are most likely to find, each with the check that closes it.
Debug interfaces left enabled
Debugging ports, JTAG or serial consoles and diagnostic shells often stay active after development because they are useful during testing. Under point (2)(j), each one is an external interface the manufacturer must justify or remove. The Commission's own example of an office printer with a debugging interface left enabled shows how a single hardware leftover becomes a finding. Check the production board and firmware build for every debug interface and confirm each is disabled or locked in shipped units.
Default services and accounts
Products often ship with services enabled, sample accounts or default credentials that the target use case never needs. Each enabled service listens on a port that an attacker can reach, and each default account is a known entry point. The risk assessment should list every service and account shipped, with the reason it is present. Confirm that unneeded services are disabled by default and that any remaining default account is removed or forced to change at first use.
Undocumented residual exposure
Some exposure is necessary, but manufacturers often fail to record which ports, protocols and interfaces remain reachable after hardening. Without that record, the risk assessment cannot show that the remaining surface was accepted on purpose, and technical documentation cannot describe it accurately. Keep an inventory of every reachable interface, its purpose, its authentication and its owner, and tie each entry to a decision in the risk assessment.
Inherited third-party components with open ports
Libraries, operating system images and bundled services can open listeners that the manufacturer did not design. A component in the software bill of materials may still expose a network port in the final product. Scan the built image or firmware, not only the source tree, and compare open ports against the documented interface inventory. Any port found that is absent from the inventory is a gap to close before release.
No change gate for new interfaces
Interfaces tend to appear during feature work, integration projects or emergency fixes, and nothing stops them from reaching production. The Commission's guidance notes that adding externally reachable interfaces not foreseen in the risk assessment can make even a security update a substantial modification. Add a release gate that requires any new external interface to update the interface inventory and the risk assessment before merge, and record who approved it.
Questions buyers ask about CRA (2)(j) effort, cost and outsourcing
How much effort does limiting attack surfaces under CRA Annex I (2)(j) take?
The effort depends on how many external interfaces, services and optional components your product ships with, and on how much of that inventory already exists. Most of the work is discovery and decision-making: listing every interface, port, service, debug function and default account, then deciding which ones the product needs. Removal and hardening are usually smaller tasks than the inventory and the documentation that explains what remains. No duration figure is supplied for this work, so ask your implementation partner for a written estimate based on your product's architecture and firmware or software build pipeline.
Can our own team meet CRA (2)(j) without outside help?
Yes, the obligation sits with the manufacturer, and a capable engineering and security team can do the work in-house. The usual gaps are not technical skill but time and independence: product teams often lack a current inventory of interfaces across hardware, firmware, software and cloud backends, and they may not have a neutral reviewer for the exposure documentation. Ask whether your team can produce the interface inventory, the default configuration baseline and the residual exposure record in a form that an independent assessor can follow.
What parts of CRA (2)(j) are worth outsourcing?
Outsourcing usually makes most sense for three parts: an independent attack surface review, configuration and hardening checks against a documented baseline, and testing of external interfaces. Penetration testing can confirm that a debugging interface or unused service is actually reachable, which the Commission's FAQ treats as a question the risk assessment must address. Keep ownership of the decisions to remove, disable or accept each interface, and of the signed-off residual exposure documentation. An outside firm can prepare evidence, but it cannot issue a conformity result.
Can a partner issue a CRA conformity result for our product?
No. An implementation partner can prepare the product, its configuration baseline, the test results and the documentation, but it cannot issue a conformity assessment, a declaration or a certificate. The manufacturer draws up the EU declaration of conformity and affixes the CE marking, and depending on the product class, a notified body may be involved. Ask any provider to state in writing which deliverables it prepares and which decisions and sign-offs remain with your organization.
What does CRA (2)(j) need from our engineering teams day to day?
Engineering teams need to keep the interface inventory current as the product changes, not only before release. Each new port, API endpoint, debug header, management service or cloud-facing feature should be reviewed against the risk assessment before it ships, because the Commission's guidance notes that adding externally reachable interfaces not foreseen in the risk assessment can change the regulatory position of a later update. In practice this means a build-time check, an owner for each external interface and a rule that debugging functions are disabled in production images.
What evidence should we ask a partner to deliver for (2)(j)?
Ask for an interface and service inventory, the documented removal or disabling decision for each item, the default configuration baseline, scan and test reports that show which exposure remains, and a residual exposure statement signed by the manufacturer. Also ask how the inventory will be refreshed through the support period. Tools such as Wazuh Security Configuration Assessment, Fleet policies and Greenbone Community Edition can generate parts of this evidence on endpoints and networks you control, but you should confirm with each vendor which checks their current release supports for your environment.
What drives the cost of CRA (2)(j) work, and what should a quote include?
The main cost drivers are the number of product variants, the number of external interfaces, the age and complexity of the firmware or software stack, and how much of the evidence must be rebuilt by hand. Costs are one-time for the initial inventory and hardening, then recurring for review of new releases and testing across the support period. A fixed-scope quote should list the systems in scope, the deliverables, the assumptions about existing documentation and the handover of evidence. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and it does not publish a price list.
How DeployOpen scopes and prepares attack surface evidence
DeployOpen works on Annex I Part I (2)(j) by helping manufacturers define what their product exposes, remove or disable what it does not need, and document the exposure that remains. The organization keeps ownership of its risk assessment and release decisions, while DeployOpen prepares the systems, configurations and evidence that support them.
How we scope
- Engagements are fixed-scope, with the product, interfaces and deliverables for (2)(j) agreed in writing before work starts.
- The written scope lists every external interface, debug port, service and default account the product ships with.
- We confirm with your team which exposures the Article 13(2) risk assessment already covers and which remain open.
How we build
- Disable unused services, debugging interfaces and optional modules in the build or image, then verify the change on a running build.
- Run configuration checks against hardened baselines and record each deviation with its risk rationale.
- Use vulnerability and configuration scanners on the product image and dependencies to confirm no unexpected listeners remain.
How we hand over
- Deliver an interface and service inventory showing what is enabled, why, and what remains exposed after hardening.
- Provide architecture documentation that maps external interfaces to the technical documentation described in Annex VII.
- Hand over test results, configuration baselines and a record of accepted residual exposure for your conformity file.
How we support
- Ongoing support and upgrades are available as a retainer, so new interfaces are reviewed before each release.
- Re-check the exposure inventory when firmware, dependencies or features change during the support period.
- Confirm with your independent assessor or notified body which evidence formats and review cadence they expect.
