Yes. ETSI EN 303 645 provision 5.6-4 says that where a debug interface is physically accessible, it shall be disabled in software. Its own example is a UART disabled through the bootloader, leaving no login prompt and no interactive menu. Debug access is for the lab, not for the field.
Why an open debug port matters
The ETSI standard defines a debug interface as a physical interface the manufacturer uses to talk to the device during development. It also warns that physical interfaces can be used by an attacker to compromise firmware or memory. A serial console that drops to a root shell, or a debug port that can read flash, hands over everything the device knows, including any stored keys.
Provision 5.6-3 adds a softer rule: hardware should not unnecessarily expose physical interfaces. Its example is a micro-USB port meant for power only, configured so it cannot also accept commands.
Two layers of defence
The standard asks for a software disable, and that is the floor. A stronger design layers more than one control.
- Software disable in the bootloader. No prompt, no menu, and no input accepted on the console in production builds.
- Hardware options your chip offers. Many parts have fuses or lifecycle states that lock debug access. Check your vendor's reference manual for what exists, since this varies by chip and I have not generalised it here.
- Physical design. Do not populate headers you do not need on production boards, and avoid routing debug pins to easy test points.
Build this into the release process
Debug access tends to survive because it is useful. A few habits keep it from shipping by accident.
- Keep separate development and production build configurations, and make the production one the default for release pipelines.
- Add a release check that boots a production image and confirms the console is silent.
- Record, per hardware revision, which debug interfaces exist and how each is disabled.
- If support needs field diagnostics, design an authenticated, logged path rather than leaving the lab port open.
What about repair and research?
Disabling debug does not make a device unreviewable. Independent testers can still examine firmware images, and a published vulnerability disclosure policy gives them a way to tell you what they find. Closing the port is about removing an easy path for attackers, not hiding the product.
Quick check
Is a disabled UART enough on its own?
ETSI requires it to be disabled in software as a minimum. Layering hardware lockouts and a clean physical design makes a bypass harder.
Does the standard say anything about unused network ports?
Yes. Provision 5.6-1 says all unused network and logical interfaces shall be disabled.
Where Safeguard fits
Safeguard does not replace a bootloader or a hardware root of trust. It covers the software side around them: SBOM and dependency scanning for the components that end up in your builds, policies and gates that block a risky release, and compliance evidence. You can try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
