TL;DR: A custom CW308 target board for the Nordic nRF52840 makes fault injection and side-channel testing on Matter-class smart devices repeatable, helping researchers bypass debug protection, dump firmware and recover a device attestation private key without risking a scarce commercial sample, according to Nozomi Networks research. That shifts authenticity testing from one-off lab work to controlled, reproducible hardware security analysis.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Nozomi Networks's blog post: A custom CW308 target board for the Nordic nRF52840 enabled repeatable fault injection testing against a Matter-certified smart device.
Why it matters: It matters to practitioners because device authenticity, debug protection and embedded key storage are only as strong as the physical controls around them, not the cryptography alone.
Context
Smart device security often assumes that certified silicon, signed firmware and encrypted links are enough to preserve trust. In practice, the physical device is part of the security boundary, and attackers who can manipulate power, clocking and reset behaviour may bypass protections that look strong on paper.
That is why repeatable test hardware matters for embedded security research. A controlled target board lets researchers isolate a specific SoC, reproduce fault conditions and measure how authenticity mechanisms fail under physical attack rather than assuming the production device behaves like the datasheet says.
Key questions
Q: What breaks when debug protection can be bypassed during boot?
A: When boot-time debug protection is glitchable, the device can expose its debug interface long enough for firmware dumping and deeper inspection. That breaks the assumption that disabled debugging is a durable control. It also means certificate-backed trust can be undermined if the protected key or identity material is stored in recoverable flash.
Q: Why does fault injection create a trust problem for smart devices?
A: Fault injection turns the device’s physical behaviour into an attack path that can defeat software controls such as debug locks and boot checks. Once an attacker can recover identity material or firmware, the device may no longer be trustworthy even if it still appears compliant on paper.
Q: How should teams test embedded devices for authenticity failure?
A: They should test the device as an adversary would, by validating power, clock and reset behaviour under controlled glitch attempts, then checking whether debug access, firmware extraction or key recovery is possible. The goal is to prove the trust boundary holds under stress, not only in the normal boot path.
Q: What is the difference between certificate issuance and device identity protection?
A: Certificate issuance proves that a device was provisioned correctly at some point. Device identity protection is the ongoing ability to keep the corresponding private key inaccessible under firmware, debug and physical attack. A device can be correctly issued and still fail authenticity if its key can later be extracted.
Technical breakdown
Why fault injection works against debug protection
Fault injection changes the timing or stability of a device at a critical execution point, often by glitching voltage or clock inputs. On SoCs such as the nRF52840, debug protection can be enforced in boot code, which means a brief disturbance at the right moment may skip the instruction that disables SWD access. Once debug is re-enabled, firmware extraction and deeper inspection become possible. The attack is not about breaking cryptography directly. It is about turning a momentary physical fault into a control bypass that exposes the device’s internal state. Practical implication: treat physical boot-time protection as an attack surface, not just a boot configuration choice. See the Edge Device Security Guide.
How a CW308 target board standardises hardware attacks
The CW308 UFO platform provides a repeatable victim interface for hardware testing by standardising power, clock, reset, debug and measurement paths. That matters because side-channel and glitch experiments are highly sensitive to layout, decoupling, rail routing and trigger access. A custom target board built to the CW308 interface gives researchers a stable way to vary one factor at a time while keeping the rest of the setup constant. This is what turns a fragile lab experiment into a methodical workflow. Practical implication: use standardised research targets when you need reproducible measurements, not improvised board hacking.
Why Matter device attestation depends on private key protection
Matter uses device attestation to prove that a device is genuine before it joins a fabric. That model depends on a private key remaining inaccessible even when the firmware, bootloader and debug paths are under attack. If an attacker can dump flash and recover the attestation key, the device’s identity can be cloned and used to commission rogue hardware that appears legitimate. The security model therefore extends beyond certificate issuance into key storage, boot protection and physical tamper resistance. Practical implication: evaluate attestation as a full lifecycle control, not just a certificate feature. Read the Ultimate Guide to NHIs: What are Non-Human Identities.
Threat narrative
Attacker objective: The attacker wants to clone device identity and bypass trust checks so counterfeit hardware can join a Matter environment as a legitimate device.
- Entry occurs through physical access to the device and the ability to apply a timed voltage glitch during boot.
- Credential harvested is the device attestation private key recovered after the debug port is re-enabled and flash is dumped.
- Impact is that a malicious actor can commission rogue devices into a Matter fabric as if they were genuine, certified products.
Breaches seen in the wild
- HPE Aruba Instant On hard-coded credentials: Hard-coded admin credentials in HPE Aruba Instant On access point firmware let anyone bypass login (CVE-2025-37103); no exploitation reported.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Physical device security is now an identity problem, not just a hardware problem. The article shows that a device attestation key can be extracted after a debug bypass, which means the trust relationship behind embedded identity is only as strong as the physical boot path. That is a direct governance issue for programmes that treat certificates as sufficient proof of authenticity. Practitioners should manage device identity as a hardware-backed lifecycle, not a static credential artifact.
Repeatable test fixtures are becoming essential to embedded assurance. Security teams cannot evaluate fault injection or side-channel resilience on production units alone because the cost of a failed experiment changes the risk calculus. A controlled target board makes it possible to validate whether debug gating, clock routing and flash protection actually withstand adversarial testing. Practitioners should build reproducible lab paths for device authenticity testing before they rely on certification claims.
Debug disablement is a control assumption, not a guarantee. The post illustrates a specific failure mode in which APPROTECT-style mechanisms can be bypassed during boot, turning a design-time protection into a temporary condition rather than a durable barrier. That means assurance reviews must ask how the chip behaves under glitch conditions, not only whether the setting is enabled in firmware. Practitioners should treat debug access as a recoverable state that needs independent verification.
Smart home and IoT trust chains need physical tamper considerations. Matter-style attestation assumes the private key remains protected even when the device is in hostile hands, but this article shows how physical access can defeat that assumption. That has implications for procurement, lab validation and incident response when counterfeit or cloned devices may enter a fabric. Practitioners should align device trust controls with physical attack testing, not just software review.
What this signals
Hardware authenticity testing needs to be part of device governance. The main lesson is not that every embedded device is vulnerable in the same way, but that trust models based on attestation and signed firmware must be stress-tested against physical bypass conditions. Programmes that certify devices without adversarial hardware testing may miss the exact failure mode that matters most.
Physical attack resilience is emerging as a first-class control for IoT and smart home environments. When a device can be made to reveal its identity secrets through repeatable lab techniques, the control conversation shifts from policy compliance to resistance under manipulation. For teams managing fleets of embedded devices, that means lab validation, procurement requirements and trust assumptions need to converge.
Attestation without tamper validation creates a verification trust gap. The device may present a valid identity while the underlying secret is no longer protected, which is precisely the kind of gap that creates counterfeit-device risk. Practitioners should treat physical-key protection as part of the attestation control plane, not a separate hardware concern.
For practitioners
- Validate boot-time debug protection under fault conditions Test whether APPROTECT, SWD lockout and related boot controls still hold when voltage and clock timing are manipulated during startup.
- Build a repeatable hardware test fixture Use a standardised target platform, stable power rails and accessible trigger points so glitching and power analysis can be reproduced across runs.
- Treat device attestation keys as high-value secrets Review how attestation private keys are generated, stored and protected, and verify that flash extraction or debug recovery does not expose them.
- Separate lab devices from production samples Use sacrificial research hardware for destructive testing so a failed experiment does not destroy the only production unit available for validation.
Key takeaways
- The article shows that embedded trust can fail at the physical layer even when a device is using certified silicon, signed firmware and attestation.
- The evidence is operational, not theoretical: fault injection enabled debug recovery, firmware dumping and private key extraction from a Matter-class device.
- Teams should validate boot-time protection and key isolation under adversarial hardware conditions before relying on device identity claims.
Related NHI Mgmt Group resources: Ultimate Guide to NHIs: What are Non-Human Identities · NHI Lifecycle Management Guide · Edge Device Security Guide · Top 10 NHI Issues
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The device attestation bypass shows how identity proof fails when debug controls are recoverable. |
| NHI-02 — Secret Leakage | The article ends with extraction of the private key used for device authenticity. | |
| Recommendation — Validate NHI authentication paths against physical bypass and confirm the attestation secret cannot be recovered. Protect attestation keys as secrets that must resist firmware dumping and debug recovery. | ||
| MITRE ATT&CK | TA0006;TA0004 — Credential Access; Privilege Escalation | The attack chain relies on recovering a protected key after bypassing debug protections. |
| Recommendation — Map physical key recovery paths to credential access and privilege escalation in your threat model. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Debug access and device trust both depend on correctly enforced permissions at boot and runtime. |
| Recommendation — Verify that access permissions remain enforced even under fault-injection conditions. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The device attestation key functions as a protected authenticator whose compromise breaks trust. |
| Recommendation — Apply authenticator management controls to protect, rotate and recover device identity secrets. | ||
Key terms
- Fault Injection: Fault injection is a resilience testing technique that intentionally introduces failures into a system to observe how it behaves. It helps teams validate recovery paths, policy enforcement, and service stability under abnormal conditions. Used well, it exposes hidden dependencies before production incidents do.
- Device Attestation: Device attestation is the process of checking whether a device and its software environment meet expected integrity conditions before trust is extended. For identity workflows, it should support the verification decision, not replace stronger evidence about whether the capture stream itself is authentic.
- Debug Protection: Debug protection is the set of controls that prevents external interfaces such as SWD or JTAG from being used after deployment. It is intended to stop firmware extraction, tampering and inspection, but it only works if the lockout cannot be reversed through physical attack or boot-time manipulation.
- Side-Channel Attack: A side-channel attack extracts information indirectly from a system by observing timing, resource usage, or other signals rather than breaking encryption or authentication directly. In multitenant environments, shared hardware can create opportunities for attackers to infer sensitive information across tenant boundaries if isolation is not carefully engineered.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It is a practical fit for teams that need to connect device identity, secrets management and governance across a wider security programme.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org