Why Your Circuit Board is Leaking Data

A circuit board can expose data even when it has no screen, keyboard, or visible network connection. I have seen teams focus on software security while leaving test ports, memory chips, wireless modules, and debug logs open. The board may not “leak” data by itself. Data often escapes through a connected interface, weak firmware settings, poor access control, or a component that was not reviewed during testing.

The risk becomes easier to understand when I trace the full path:

A sensor board collects information.

A processor stores or handles it.

A port, radio module, memory chip, or cable provides a way out.

If that path is not protected, someone with physical access may copy files, read commands, change firmware, or capture sensitive signals.

Open debug ports create a hidden access path

Many boards include JTAG, SWD, UART, SPI, or test pads. Engineers use them during development, but production units sometimes keep them active.

A technician may connect to a UART port and see boot messages, device IDs, network settings, or software errors. A JTAG connection may provide deeper access to memory and processor functions. A test pad that looks harmless can become a direct entry point when the device is placed in a public location.

I check these points on every production board:

• Is the debug port still enabled?
• Can it read memory?
• Can it change firmware?
• Does it reveal passwords, tokens, or system details?
• Can the port be disabled through a secure setting?
• Is physical removal or tamper detection suitable for the product?

Unused test pads should not remain exposed without a reason. Some designs add removable components, access controls, or production fuses that disable debug functions after testing.

Unprotected memory can expose stored information

Flash memory, EEPROM, SD cards, and external storage may contain more data than the design team expects. A board may store device credentials, configuration files, customer records, event logs, or temporary data.

I once reviewed an embedded design where error logs stayed on local storage long after the device had been returned for service. The logs were created to help engineers find faults, but they also contained network names and user-related details. The issue was not a complex attack. A person with physical access could remove the storage chip and read it with common hardware.

Data protection should cover:

• Data stored in flash and EEPROM
• Temporary files and crash logs
• Backup copies
• Factory configuration files
• Cached network information
• Deleted data that remains in unused storage blocks

Encryption helps, but the key must be protected as well. If the key is stored beside the encrypted data or embedded in an easy-to-find firmware file, the protection may provide limited value.

Firmware may reveal more than expected

Firmware often contains API keys, service passwords, test accounts, encryption keys, debug commands, and internal URLs. A person can extract firmware from a chip, update package, or exposed maintenance port.

I use a firmware review process that checks:

1. Hard-coded credentials
2. Test accounts
3. Debug commands
4. Plain-text configuration files
5. Old libraries with known security issues
6. Update packages without signature checks
7. Error messages that disclose internal details

A secure boot process can help the board accept only approved firmware. Signed updates can reduce the chance of unauthorized software being installed. These controls need careful key management and a recovery plan for legitimate updates.

Wireless components can send data outside the board

Wi-Fi, Bluetooth, Zigbee, cellular, NFC, and other radio modules create communication paths. A board may send information to a phone, gateway, cloud service, or maintenance tool without the user seeing the full exchange.

The radio module may also have its own firmware, default settings, logs, and update process. A secure main processor does not remove risk from a poorly configured wireless chip.

I map every wireless data path and record:

• What data leaves the device
• Which device receives it
• Whether encryption is used
• How keys are created and stored
• Whether pairing requires user approval
• Whether old or unknown devices can reconnect
• What happens when the network is unavailable

A practical test uses a controlled lab network. I capture traffic, compare it with the product design, and check whether sensitive data appears in plain text or travels to an unexpected address.

Physical tampering can change what the board reports

A circuit board placed in a cabinet, vehicle, payment terminal, medical device, or public machine may face physical access attempts. Someone may replace a chip, add a small recording device, alter a cable, or install modified firmware.

Supply chain checks matter here. A board can pass software testing and still contain an unexpected component or altered assembly. Visual inspection, component verification, secure procurement records, and firmware checks help reduce this risk.

For sensitive products, I also consider:

• Tamper-evident seals
• Enclosure sensors
• Secure component identity
• Controlled service procedures
• Hardware-based key storage
• Audit records for repairs and replacements

These measures should match the product’s risk. A small consumer sensor and a controller used in a factory do not need the same controls.

Electromagnetic and power signals may reveal activity

Some boards can expose information through electromagnetic emissions, power use, timing changes, or sound from components. This type of leakage usually requires specialized equipment and close access, but it should not be ignored for high-value systems.

For example, a device that performs different operations for different data may create measurable changes in power consumption. A lab can test whether those changes reveal keys or other sensitive values.

Useful design steps include:

• Reducing unnecessary signal exposure
• Separating sensitive processing paths
• Improving power filtering
• Controlling clock and timing behavior
• Testing the finished enclosure, not only the bare board

This area requires controlled testing. I do not treat a clean software review as proof that the hardware reveals nothing.

Production and service settings often cause trouble

A board may be secure during development and less secure after deployment. Production teams may enable a temporary account, leave a maintenance cable connected, or reuse a factory password to save time.

Service staff may also copy logs or firmware to personal storage. Returned units may keep customer data after repair. These process problems can create the same result as a technical weakness.

I set clear rules for:

• Factory reset behavior
• Service account use
• Technician access
• Log collection
• Returned hardware
• Replacement boards
• Secure disposal
• Record keeping

Each action should have an owner. A security control that exists only in a document will not protect a board during a busy repair cycle.

How I investigate a suspected data leak

I start by creating a data-flow map. It shows where data enters, where it is processed, where it is stored, and where it leaves. I include cables, ports, radios, chips, test equipment, mobile apps, gateways, and cloud services.

Then I follow these steps:

1. Identify the data.
   Separate personal data, credentials, operational data, logs, and harmless telemetry.

2. List every interface.
   Include USB, Ethernet, UART, JTAG, SPI, I2C, radio modules, memory sockets, and test pads.

3. Review firmware and configuration.
   Search for test credentials, hidden commands, update paths, and stored secrets.

4. Capture network and radio traffic.
   Use a controlled environment and compare observed traffic with approved behavior.

5. Inspect storage.
   Check encryption, deletion behavior, backup files, and access permissions.

6. Test physical access.
   Ask what a person can do with the board, tools, several minutes, and no administrator password.

7. Check the build process.
   Confirm component sources, firmware versions, signing keys, and production settings.

8. Record evidence before changing the device.
   Keep copies of logs, firmware versions, photos, and test results for later review.

When a leak is confirmed, I isolate affected devices, rotate exposed credentials, preserve evidence, review connected systems, and prepare a clear notice for the people responsible for the data. The response should match the actual scope. Guessing can cause more confusion than the original fault.

A practical example

Consider a smart access controller used in an office building. The controller stores entry events and connects to a cloud dashboard. Its Ethernet traffic is encrypted, but the board still has an active UART port inside the cabinet. The boot log reveals the device address and a maintenance account name. A technician can also read an unencrypted configuration file from external flash.

The network encryption does not solve the whole problem. The exposed UART and storage chip create separate paths to the same system.

A suitable repair plan could include disabling the port after production testing, encrypting sensitive storage, removing the maintenance account, signing firmware updates, limiting service access, and checking already deployed devices for the same configuration.

A circuit board becomes safer when I treat hardware, firmware, production, service, and connected systems as one design. I do not ask only whether the board can send data. I ask where data can be copied, changed, stored, observed, or recovered.

That approach helps reveal quiet leaks before they become public incidents.

A printed circuit board can look harmless while still creating a path to sensitive data.

I usually think of a PCB as the physical layer behind a device. It carries power, signals, firmware, and communication links. When a board is used in a router, payment terminal, access controller, medical device, or industrial system, a small design choice can affect the security of the entire product.

The risk is not always a visible hacking device. It may be an open debug port, an unprotected memory chip, a copied component, or a firmware update path that was never reviewed.

Where PCB-related data risks appear

Many devices keep useful information on or near the board:

• Network credentials
• Encryption keys
• User settings
• Access logs
• Payment records
• Sensor data
• Firmware images
• Device identification details

A person does not always need administrator access through the network. Physical access to the board may provide another route.

A technician could connect to test pads. A counterfeit component could behave differently from the approved part. A discarded device could still contain readable flash memory. A poorly protected communication bus could expose data while the device is operating.

Each issue may look small during product development. Together, they can increase the chance of data loss.

1. Unprotected debug ports

Engineers often use UART, JTAG, SWD, SPI, or I²C connections during testing. These ports help with firmware loading, diagnostics, and board repair.

The problem starts when the same access remains active in production units.

A UART console may reveal boot messages or open a command shell. JTAG or SWD may allow memory inspection. An exposed SPI connection may make it easier to read firmware or configuration data from a flash chip.

I do not treat hidden test pads as safe just because they are not visible from the outside. A person with the device, basic tools, and enough time may locate them by studying the board layout or service documentation.

Useful controls include:

• Disable debug access before shipment
• Remove unnecessary test headers
• Lock debug features with hardware settings
• Require authentication for service tools
• Erase sensitive logs before repair or resale
• Check production boards with a port-detection test

A port used during development should have a clear security decision before mass production.

2. Sensitive data stored in memory chips

Many boards contain EEPROM, NOR flash, NAND flash, or removable storage. These parts may hold more than firmware.

They can also contain Wi-Fi credentials, certificates, device keys, customer settings, and system logs.

If the data is stored without encryption, someone may remove the memory chip or connect to its pins and copy the contents. Encryption helps, but only when the keys are protected separately. Storing the key beside the encrypted data reduces the value of the protection.

A simple review should ask:

• What data is written to the board?
• Is the data required for device operation?
• How long does the device keep it?
• Is it encrypted at rest?
• Where is the encryption key stored?
• What happens when the device is repaired or discarded?

For a small office router, old configuration data may reveal network names and access settings. For a payment terminal, stored logs may expose transaction details. The exact risk depends on the product and its data-handling design.

3. Counterfeit and substituted components

A component that looks identical may not have the same security behavior.

Supply chain pressure can lead to substituted memory, microcontrollers, power parts, or communication chips. A part with different firmware, altered settings, or weak manufacturing control can create unexpected access or reliability problems.

This does not mean every substitute part is malicious. It means the security team may lose visibility into what the product actually contains.

I recommend tracking:

• Approved part numbers
• Supplier and factory records
• Component lot information
• Firmware versions
• Electrical test results
• Changes made during production

Random sample testing can help detect differences between approved boards and delivered boards. X-ray inspection, electrical analysis, firmware comparison, and chip authentication may be useful for higher-risk products.

A company that cannot identify the parts on its own board may struggle to explain a security event later.

4. Malicious or altered firmware

The PCB may be secure while the firmware loaded onto it is not.

Firmware controls boot behavior, communication, access checks, and data storage. If an attacker changes the firmware, the device could record traffic, bypass authentication, or send information to an unauthorized system.

Secure boot can help confirm that the device starts approved code. Signed firmware updates can reduce the chance of unauthorized software being installed. These controls need careful key management. If signing keys are exposed, the protection becomes weaker.

A practical firmware review should cover:

1. How firmware is created
2. Who can approve a release
3. How signing keys are stored
4. How updates are delivered
5. What happens when an update fails
6. How old firmware versions are blocked
7. How devices report their current version

I prefer a design that can show its firmware state through a trusted management system. A device that cannot report what it is running is harder to monitor.

5. Data leakage through board interfaces

Communication buses such as USB, Ethernet, CAN, SPI, and I²C may carry sensitive information. The risk increases when the bus is not authenticated or encrypted.

For example, an industrial controller may exchange commands over CAN. A smart device may send user settings through an internal I²C link. A network appliance may expose diagnostic traffic through an Ethernet service port.

An attacker with physical access may connect a probe, capture signals, and study the messages. This does not always give direct access to useful data, but it can reveal device behavior and help identify weak points.

Design teams can reduce exposure by:

• Encrypting sensitive data where the device supports it
• Adding authentication to important commands
• Separating control traffic from user data
• Removing unused interfaces
• Restricting service access to approved equipment
• Recording access to maintenance ports

Security testing should include the device while it is running, not just the finished product casing.

6. Side-channel information

A board can reveal clues through power use, electromagnetic signals, timing, or heat.

Researchers have shown that these signals may help estimate what a chip is processing. The risk is greater for devices handling cryptographic operations, access credentials, or other high-value information.

Most products do not need expensive protection against every side-channel method. The right response depends on the threat model. A consumer sensor and a hardware security module do not face the same pressure.

Possible controls include:

• Constant-time cryptographic code
• Reduced signal leakage from board layout
• Filtering and shielding where needed
• Secure key storage
• Testing under different workloads
• Independent review for high-risk products

This area deserves attention when an attacker can obtain repeated physical access to the device.

7. Poor disposal and repair practices

A returned or retired device may still contain data.

I have seen organizations focus on deleting cloud accounts while forgetting the storage chip inside the equipment. A device reset may remove user settings but leave logs, certificates, or recoverable files.

A disposal process should define how each device is handled:

• Remove or securely erase storage
• Reset cryptographic keys
• Record the device serial number
• Separate damaged boards from reusable parts
• Control access during repair
• Confirm the wipe with a suitable test

For products that cannot reliably erase their memory, physical destruction may be the safer choice.

A practical review process

I use a simple process when reviewing PCB security.

Step 1: Map the board

List every processor, memory chip, radio, connector, test pad, and external interface. Note what each part does and what data passes through it.

Step 2: Classify the data

Mark credentials, keys, personal data, logs, firmware, and device identifiers. Ask whether each item needs to remain on the board.

Step 3: Check physical access

Assume someone may obtain a returned unit, open the case, or access a maintenance area. Test the board under that condition.

Step 4: Review production controls

Compare the approved bill of materials with the parts found on production boards. Confirm firmware versions and supplier records.

Step 5: Test the update path

Try to load altered firmware, use an old firmware version, or interrupt an update. The goal is to see how the device responds to common failure conditions.

Step 6: Plan for retirement

Document data removal, key revocation, repair access, and disposal. Security should continue after the product leaves active service.

A simple example

Imagine a warehouse scanner that stores Wi-Fi settings and scan history in a flash chip. Its debug pads are hidden beneath a label, but they remain active. The scanner is sent for repair after a damaged screen stops working.

If the repair process does not erase the flash chip, a person with board access may read the stored data. The organization may believe the device is safe because the scanner is no longer connected to the warehouse network. The remaining data can still reveal internal settings or user activity.

A better design would disable debug access, encrypt stored information, limit retention, and require a verified wipe before the device leaves the repair area.

PCB security is not only a hardware task. It connects product design, firmware, procurement, repair, IT operations, and disposal.

When I review a device, I ask a direct question: if someone obtains the board, what can they learn, change, or copy?

The answer helps reveal risks that network scans may miss. A secure product needs protection across the full device life cycle, from component selection to final disposal.

A PCB can expose more than power and signals. It may also provide access to firmware, debug data, encryption keys, sensor records, and communication settings. When a product reaches the field, a poorly protected board can make data theft easier than many teams expect.

I look at PCB security from the physical layer outward. Software controls matter, yet an exposed test pad, unlocked UART port, or unprotected memory chip may give an attacker a useful starting point.

A secure PCB design can reduce these entry points before production begins.

Check every exposed interface

Development ports often remain on production boards because they help engineers test and repair products. JTAG, SWD, UART, SPI, and I²C connections can also reveal internal data.

I review each interface and ask:

• Does the product need this port after manufacturing?
• Can a user reach it without opening the enclosure?
• Does it provide firmware access or memory access?
• Can the port be disabled through hardware or software?
• Are test pads clearly separated from normal signal paths?

A production board may use removable headers during development, then omit those headers after validation. Some teams also add access control, port locks, or firmware settings that disable debug functions before shipment.

A small test pad can create a large security problem when it connects directly to a system-on-chip or memory device.

Protect firmware and stored data

Many PCB-based products store firmware, calibration values, device settings, or customer data in external flash or EEPROM. Anyone who can remove the chip or connect to its bus may try to copy or change that information.

I recommend reviewing the data stored on each memory device. Separate public information from sensitive material. Encrypt data that requires protection, and keep encryption keys in a protected area rather than placing them beside ordinary firmware files.

Secure boot can help the processor check whether firmware has been approved before it runs. Firmware signing can reduce the risk of unauthorized code being loaded during servicing or refurbishment.

These controls need support from the processor, secure element, or trusted platform used in the product. A PCB layout alone cannot replace a complete key-management plan.

Keep secret signals away from easy access

Signal routing affects physical attack risk. Traces that carry keys, authentication data, or raw sensor information should not pass close to exposed test points or accessible connectors without a clear reason.

During layout review, I check:

• Whether sensitive traces reach external connectors
• Whether test pads expose high-value signals
• Whether memory buses are easy to probe
• Whether unused pins are left floating
• Whether board layers reveal sensitive routes through visible vias
• Whether power and communication paths can be monitored from outside the enclosure

Ground planes, controlled routing, shielding, and secure layer planning can make probing harder. They do not make a board impossible to inspect, so the security goal should match the product’s risk level and service model.

A medical sensor, payment terminal, access controller, and hobby device may need different controls.

Add tamper awareness where the product needs it

Some products operate in locations where physical access is expected. A payment device, industrial controller, or access terminal may benefit from tamper switches, conductive mesh, light sensors, or enclosure-open detection.

The response matters as much as the sensor. A device may erase selected secrets, disable sensitive functions, record an event, or require service reauthorization after tampering.

The design should also account for false triggers. A vibration during transport or a battery replacement should not create avoidable service problems. I test the tamper response during assembly, repair, transport, and normal use.

Control the manufacturing and repair chain

PCB data leaks do not always begin with a hacker opening a finished product. Design files, programming images, component reels, rejected boards, and repair stations can also expose useful information.

A practical control plan can include:

• Limiting access to Gerber, ODB++, pick-and-place, and programming files
• Using separate permissions for design, production, and repair teams
• Tracking blank and programmed boards
• Removing sensitive components from scrapped boards
• Protecting firmware files on manufacturing computers
• Logging programming and test activity
• Requiring approval for engineering samples leaving the facility

A board house may need enough data to manufacture the PCB, while a contract programmer may need a different set of files. Sharing every file with every supplier increases exposure without improving production.

Test the board like an attacker

Functional testing confirms that the product works. Security testing asks what happens when someone uses the board in an unintended way.

I would include checks for:

1. Debug-port discovery
2. Firmware extraction attempts
3. Memory-bus probing
4. Unauthorized firmware loading
5. Key exposure through logs or test commands
6. Recovery-mode abuse
7. Enclosure and tamper response
8. Data remaining after reset or repair

A simple laboratory exercise often reveals overlooked paths. For example, an engineer may connect to a UART header and find boot messages that disclose chip details, memory locations, or recovery commands. That information may not expose the full product, yet it can make later attacks easier.

Security testing should cover prototype boards and production samples. Component substitutions, layout changes, and factory programming settings can change the result.

Use a practical example

Consider a connected access controller used in a small office. The main processor stores network settings in external flash. During development, the board includes a UART header for troubleshooting. The finished enclosure hides the header, but the connector remains populated and the bootloader accepts commands without authentication.

A repair technician may use the port correctly. An unauthorized person with physical access may also read configuration data or load altered firmware.

A safer design could remove the header from production boards, disable the debug port after manufacturing, require signed firmware, encrypt stored credentials, and record failed recovery attempts. The enclosure can add tamper detection if the installation environment calls for it.

No single measure handles every risk. The result comes from connecting board layout, firmware settings, manufacturing controls, and service procedures.

Build security into the PCB review

I prefer to add security questions to the same review used for signal integrity, thermal performance, and manufacturability. This keeps the work close to the design instead of leaving it for the end of the project.

A useful review asks:

• Which paths can reveal product data?
• Which components store secrets?
• Which connections remain accessible in the field?
• What happens if someone replaces the flash chip?
• Can the product verify firmware after a reset?
• Can service staff work without receiving permanent secrets?
• What data remains after disposal?

The best PCB security plan is specific to the product. It does not rely on hidden ports, unclear documentation, or assumptions about user behavior. When I map the board’s physical access points early, I can remove several avoidable risks before they reach manufacturing.

Contact us on lingchao: mr.xu@lingchaopcb.com/WhatsApp +8613780181891.

National Institute of Standards and Technology, May 2020, Security and Privacy Controls for Information Systems and Organizations

National Institute of Standards and Technology, May 2018, Platform Firmware Resiliency Guidelines

OWASP Foundation, December 2018, OWASP Internet of Things Top 10

European Union Agency for Cybersecurity, November 2017, Baseline Security Recommendations for IoT in the Context of Critical Information Infrastructures

Cybersecurity and Infrastructure Security Agency, October 2020, Securing Network Infrastructure Devices

International Organization for Standardization, June 2022, IoT Security and Privacy Device Baseline Requirements