Bricking is the state in which a device becomes unusable, behaving like a useless brick. It usually follows a failed firmware update, corruption of boot code, or hardware-level failure that prevents normal startup or recovery, leaving the system unable to function without repair or reflash.
What Bricking Means in Practice
Bricking is more than a device failing to boot, it is a state where the device has lost enough working firmware, boot logic, or hardware integrity that normal operation is no longer possible. The term is used for phones, routers, embedded systems, industrial equipment, and other devices that depend on low-level startup code to recover and run.
For practitioners, the important point is that bricking sits at the boundary between software failure and hardware-like unavailability. A system may appear powered on, yet still be unusable because the boot chain no longer reaches a trusted or functional runtime. That makes bricking a resilience problem as much as a repair problem.
How Bricking Happens
The most common pathway is a failed firmware update, where interrupted writes, incompatible images, or bad flash operations leave the device unable to complete startup. Corruption in the bootloader or other early-stage code can have the same effect, because those components are responsible for launching the rest of the system.
Hardware faults can also produce a bricked state when they affect storage, flash chips, controller logic, or other components the device needs before the operating system loads. In some cases the failure is temporary or recoverable with reflash tools, but in others the loss is complete enough that recovery requires specialist repair or component replacement.
Why Bricking Is Operationally Serious
Bricking creates immediate availability loss because the device cannot perform its intended function until it is restored. In environments that depend on embedded controllers, edge appliances, or remote devices, the impact can extend beyond one endpoint and interrupt dependent services, physical processes, or management access.
It also changes the recovery burden. A bricked device may no longer accept normal updates, diagnostics, or remote administration, which means the organisation loses both service and manageability at the same time. That is why low-level failure modes deserve the same seriousness as higher-visibility outages.
Recovery, Prevention, and Trust Implications
Prevention usually depends on safe update handling, verified firmware images, stable power during flashing, and recovery paths such as dual banks, rollback support, or hardware recovery modes. When those safeguards are absent, even a routine maintenance action can create a permanent outage.
From a security perspective, bricking also matters because firmware and boot code are part of the trust foundation of the device. If recovery requires reflash, administrators should treat the process as a trust reset event and confirm that the replacement image, signing state, and device configuration are known good before returning the system to service.
Risk and Threat Considerations
Bricking is risky because it converts a manageable update or hardware issue into a service-crippling outage, and in some environments attackers may deliberately target firmware or boot paths to force that outcome. Even when no adversary is involved, the same weak points that cause accidental bricking can be abused to deny availability or complicate recovery.
Failure mechanism: A bad firmware flash, corrupted bootloader, damaged flash storage, or interrupted power event can leave the device without a viable startup path, and a hostile actor who can influence update content or recovery state can exploit the same mechanism.
Impact: The device may become unrecoverable through normal administration, causing prolonged downtime, loss of control plane access, and potentially a full replacement cycle if reflash or board-level repair is not possible.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST SP 800-57 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | Bricking often follows failed or tampered firmware updates that integrity controls are meant to prevent. |
| CM-3 — Configuration Change Control | Firmware updates are controlled configuration changes that can fail if not reviewed and approved. | |
| Recommendation — Verify firmware authenticity and integrity before deployment and block untrusted update paths. Subject firmware changes to formal review, approval, testing, and rollback planning before release. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Bricking is strongly affected by secure baseline and recovery configuration for devices and embedded systems. |
| CIS-11 — Data Recovery | Recovery planning matters because a bricked device may require restore or reimage to return to service. | |
| Recommendation — Harden device update and recovery settings so failed flashes do not become unrecoverable outages. Maintain tested recovery media and restoration procedures for devices that may need reflash or rebuild. | ||
| NIST SP 800-57 | SC-12 — Cryptographic Key Establishment and Management | Firmware trust and reflash workflows often depend on managed signing keys and trusted image validation. |
| Recommendation — Protect firmware signing keys and verify that recovery images are authenticated before installation. | ||
Practitioner Guidance
What to watch for: Treat firmware changes, recovery images, and boot-chain maintenance as high-risk operations. Devices that lack rollback support, redundant firmware slots, or physical recovery options should be handled conservatively because one failed write can eliminate the only working startup path.
Practitioner takeaway: Bricking is best managed as a resilience and recovery design problem, not just a patching mishap, because the ability to restore a device is often as important as the ability to update it.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org