To review a device's external interfaces, list every way data or commands can enter it, mark which ones production units need, disable or lock the rest, and write down the reason for each one you keep. Annex I of the Cyber Resilience Act asks manufacturers to limit attack surfaces, including external interfaces.
What Annex I Part I says
The regulation text, in Annex I Part I, lists properties of products. Among them: products are made available with a secure by default configuration and a way to reset them to the original state (point 2(b)); they protect against unauthorised access with appropriate control mechanisms such as authentication, and report possible unauthorised access (point 2(d)); they process data that is adequate, relevant and limited to what is necessary (point 2(g)); and they are designed, developed and produced to limit attack surfaces, including external interfaces (point 2(j)). Read the text yourself, or with counsel, because this blog is a summary.
The one hour review
Gather the hardware lead, firmware lead and whoever owns the app. Use a whiteboard or a table.
| Interface | Needed in production? | Control | Owner |
|---|---|---|---|
| Wireless pairing | Yes | Authenticated pairing, timeout | Firmware |
| Wired debug port | No | Locked before shipment | Hardware |
| Serial console | No | Disabled in production build | Firmware |
| Local network service | Maybe | Off by default, authenticated | Firmware |
| Cloud API | Yes | Per-device identity | Backend |
| Update channel | Yes | Signed images | Firmware |
| Companion app API | Yes | Version checks, authentication | App |
Four questions per row
- Does a customer need this on a shipped unit?
- If yes, is it off until the user turns it on?
- Who can talk to it, and how does it check?
- If it is abused, what is the worst result, and would we notice?
A row with a weak answer to any question gets an action, an owner and a date.
Secure by default in practice
Defaults are what most customers will run forever. That means no shared default password across units, no open service waiting for a connection nobody asked for, and a factory reset that brings the device back to a safe state. If setup needs a credential, make it unique per device.
Record the result
Keep the table. It is your design record for a security review, for a buyer's questionnaire and for the next product. When a new feature adds an interface, add a row before the code merges, not after.
What a review cannot do
A table does not find bugs in the code behind an interface. It narrows the set of places those bugs can be reached from. Pair it with testing of the interfaces you keep.
Quick check
Does disabling an interface in software count as limiting it?
It helps, but a determined attacker with physical access may re-enable it. For hardware ports, lock them in a way that survives a reset, and test that.
Is this review enough to be compliant?
No. It is one design activity. Compliance depends on the full regulation and on advice for your product.
Sources
Last reviewed: 19 October 2026.
