Ship only what the device needs. ETSI EN 303 645 provision 5.6 asks that unused network and logical interfaces be disabled, that only used software services be enabled, that code be minimised to necessary functionality, and that software run with least privilege. Each removed item is one less thing to patch.
What provision 5.6 asks
The standard's section on minimising exposed attack surfaces includes these provisions, paraphrased here.
- 5.6-1. All unused network and logical interfaces shall be disabled.
- 5.6-2. In the initialized state, the network interfaces shall minimise unauthenticated security-relevant information.
- 5.6-3. Hardware should not unnecessarily expose physical interfaces to attack.
- 5.6-4. Where a debug interface is physically accessible, it shall be disabled in software.
- 5.6-5. Only software services that are used or required should be enabled.
- 5.6-6. Code should be minimised to the functionality necessary.
- 5.6-7. Software should run with least necessary privileges.
- 5.6-8. The device should include a hardware-level access control mechanism for memory.
- 5.6-9. The manufacturer should follow secure development processes for software deployed on the device.
Why this is also a supply chain topic
Every library and service in the image is a component you must track and patch. A web server nobody uses, a debug shell, or a diagnostic daemon that stays in the build, adds exposure and adds entries to your inventory. Removing it reduces both.
A checklist
- List listening ports on a running image and justify each one.
- List running services at boot and remove anything without an owner.
- List packages in the image and remove build tools, test utilities and unused libraries.
- Check physical interfaces. The standard gives an example of a power-only micro-USB port configured not to allow command or debug operations, and a UART disabled through the bootloader so no login prompt appears.
- Run services with the least privilege that works, not as root by default.
- Repeat after every release, since features creep back in.
| Item | Question |
|---|---|
| Network port | Needed in the initial state? |
| Service | Used for the intended function? |
| Package | Required at runtime? |
| Debug interface | Disabled in production? |
Keep the evidence
Record what you removed and why, with the release it applies to. It will help a reviewer and your next engineer.
Where Safeguard fits
If you want an inventory your reviewers can query, Safeguard offers SBOM and dependency scanning with policies and gates on pull requests. It works from the source and manifests it supports. A free scan is at gold.safeguard.sh/scan.
Try it yourself
Count the components in the inventory, then ask how many your image truly needs.
Click through it at your own pace, or open it full screen.
Quick check
Is a smaller image automatically safer?
It has less to attack and less to patch, but it is not a guarantee. Still review what remains.
Does disabling a debug port in software count if the pins are exposed?
The provision asks for software disabling where the interface is physically accessible. Reducing physical exposure is a separate provision, 5.6-3.
Sources
Last reviewed: 19 October 2026.
