Category: Coverage Types

Bricking Coverage

Also known as: Bricking Endorsement

Simply put

Bricking coverage is an optional feature in some cyber insurance policies that helps pay to replace or restore physical devices that a cyberattack has rendered unusable, effectively turning them into a 'brick.' It addresses situations where hardware such as computers or connected devices no longer functions after an attack, sometimes because the device's low-level software (firmware) has been corrupted. Whether any given loss is covered depends on the specific policy wording, endorsements, and exclusions.

Formal definition

Bricking coverage is a first-party cyber insurance enhancement, typically added by endorsement, that responds to the cost of replacing or restoring physical devices rendered inoperable as a result of a covered cyber event. 'Bricking' refers to a device becoming unusable, in some cases through corruption of the firmware or other low-level software on which the device depends to function. Coverage commonly extends to the cost of replacing hardware that cannot be restored, and may address a range of affected devices, but the scope, sublimits, and applicable conditions and exclusions vary by insurer form and specific policy wording. This coverage is distinct from third-party liability coverages and from data restoration coverage, and it does not by itself reduce the likelihood of an attack; it is a risk-transfer mechanism, not a resilience control. The precise triggers and whether firmware corruption, failed updates, or other causes fall within scope depend on the individual policy language.

Why it matters

Standard cyber insurance has historically focused on intangible losses such as data restoration, business interruption, and liability to affected third parties. Bricking coverage addresses a gap that these coverages may leave open: the physical hardware itself. When a cyberattack renders a device permanently unusable, sometimes by corrupting the firmware or other low-level software on which it depends to function, the affected organization may face the cost of replacing that hardware outright. Without a specific grant of coverage for this exposure, an insured could find that its policy responds to the lost data or the operational downtime but not to the cost of the physical devices that have been turned into 'bricks.'

The relevance of this coverage has grown as organizations depend on larger populations of connected devices, any of which could be affected by an attack. The cost implications are a function of how many devices are involved and whether they can be restored or must be replaced entirely, though the actual financial impact in any given event depends on the circumstances and is not something that can be generalized. Because bricking coverage is typically offered by endorsement rather than as a standard part of the base form, whether an organization carries it at all is a deliberate purchasing decision that risk managers and brokers must weigh.

It is important to keep this coverage in perspective as a risk-transfer mechanism. Bricking coverage does not reduce the likelihood that an attack will occur, and it is not a substitute for resilience measures such as maintaining spare hardware, tested recovery procedures, or firmware integrity controls. It helps pay for a loss after the fact; it does not prevent the loss. Whether any specific bricking event is covered depends on the policy wording, applicable sublimits, conditions, and exclusions.

Who it's relevant to

Risk Managers

Risk managers assessing an organization's hardware exposure need to determine whether the cost of replacing devices rendered unusable by a cyberattack is addressed anywhere in their program. Because bricking coverage is typically optional and added by endorsement, its absence from a base cyber form can leave a gap that other insuring agreements do not fill. This coverage should be evaluated as one component of a broader approach that also includes mitigation and recovery planning, not as a replacement for them.

Insurance Brokers and Underwriters

Brokers advising clients should be able to explain that bricking coverage is a distinct enhancement, how it differs from data restoration and third-party coverages, and that its scope, sublimits, and exclusions vary by insurer form. Underwriters evaluating this exposure must consider how it is triggered and worded on their particular form. Both should be prepared to identify which causes of a device becoming inoperable fall within a given policy's language and which do not.

Chief Information Security Officers

CISOs whose environments include large populations of connected devices, particularly those dependent on firmware, have a stake in whether the cost of replacing bricked hardware is transferred through insurance or retained by the organization. This coverage complements but does not replace security controls and resilience measures; it responds after a loss and does not reduce the likelihood of an attack that corrupts firmware or otherwise renders devices unusable.

Resilience and Business Continuity Planners

Planners should treat bricking coverage as a financial backstop rather than a recovery capability. Insurance that helps pay to replace inoperable hardware does not restore operations on its own; the time to source and reconfigure replacement devices remains a continuity concern that plans must address separately through measures such as spare inventory and tested recovery procedures.

Inside Bricking Coverage

Bricking as a first-party loss

Bricking coverage responds to the insured's own loss when hardware is rendered inoperable ('bricked') as a result of a covered cyber event, typically because firmware or embedded software is corrupted and the device will no longer function. It is a first-party coverage, addressing the insured's own property and restoration costs rather than liability owed to third parties.

Covered trigger

Coverage generally depends on the loss arising from a cyber peril defined in the policy, such as malware, unauthorized access, or a security failure. Whether a given bricking event is covered is subject to the specific wording, including how the policy defines a security incident or system failure and any conditions precedent that must be met.

Scope of recoverable cost

Depending on the wording, recoverable amounts may include the cost to replace or reinstall firmware, re-flash the device, or replace the physical hardware when reinstallation is not feasible. Some forms limit recovery to restoration or reinstallation costs and treat outright hardware replacement differently, so the precise measure of loss varies by form.

Sublimits and retentions

Bricking cover is frequently provided subject to a sublimit that sits within the broader policy limit, and it is typically subject to a retention. These are coverage terms that cap or condition the insurer's obligation and should not be confused with any resilience metric.

Relationship to other first-party coverages

Bricking loss can overlap with or sit adjacent to data restoration, business interruption, and system-failure coverages. How these interact, and whether a single event can recover under more than one insuring agreement, depends on the policy structure and any anti-stacking or apportionment provisions.

Exclusions and conditions

Recovery may be affected by common exclusions such as war, hostile-infrastructure, wear-and-tear, or failure-to-maintain-standards provisions, as well as conditions precedent regarding patching, security controls, or timely notice. Whether bricking loss is ultimately covered is conditional on these terms and on jurisdiction.

Common questions

Answers to the questions practitioners most commonly ask about Bricking Coverage.

Does bricking coverage apply whenever ransomware or malware makes my hardware unusable?

Not automatically. Bricking coverage typically responds to the loss of use or functionality of hardware rendered inoperable as a consequence of a covered cyber event, but whether any given incident triggers it depends on the policy wording, applicable exclusions, and conditions. Some forms require that the hardware be genuinely incapable of restoration through reinstallation or reconfiguration, distinguishing true 'bricking' from software-level disruption that can be remediated without replacing equipment. Read the specific insuring agreement and endorsements rather than assuming coverage follows from any hardware impact.

Isn't bricking coverage just part of my business interruption or data restoration coverage?

No, these address different loss categories and should not be conflated. Bricking coverage is generally a first-party coverage concerned with the cost to replace or, where possible, restore physical hardware that has lost functionality. Business interruption addresses lost income and continuing expenses during a period of restoration, and data restoration addresses recreating or recovering damaged data. A single incident could implicate more than one of these, but each is subject to its own sublimit, retention, waiting period, or conditions, and one being triggered does not mean the others are.

How do I determine whether replacement or restoration costs are the measure of loss under a bricking endorsement?

This depends on the specific wording. Some forms limit recovery to the cost of restoring hardware to functionality where that is feasible, while others contemplate replacement cost when restoration is not possible. The endorsement may also specify valuation basis, betterment considerations, and whether costs are capped by a sublimit. Review the loss-settlement language and any depreciation or obsolescence provisions with your broker, and confirm how the insurer expects replacement necessity to be substantiated.

What documentation should we preserve after an incident to support a potential bricking claim?

While requirements vary by insurer, it is generally prudent to preserve forensic evidence linking the hardware's loss of function to the covered cyber event, records showing attempts to restore or reconfigure the affected equipment, and cost documentation for replacement or restoration. Because many policies include conditions precedent around notice, mitigation, and cooperation, coordinate early with your incident response provider and claims contact so that remediation steps do not inadvertently destroy evidence needed to establish that the hardware was genuinely inoperable.

How does bricking coverage interact with a failure-to-maintain-standards or similar exclusion?

Coverage can be affected if the loss is attributed to circumstances an exclusion addresses, such as failure to maintain agreed security controls or patching practices, subject to the specific wording. Where an insurer asserts such an exclusion, the availability of bricking recovery may turn on whether the hardware's loss of function is causally tied to the excluded conduct. Because these exclusions and their carve-backs differ across forms and jurisdictions, confirm how your policy's exclusions are drafted and whether any conditions are treated as conditions precedent to coverage.

Where should bricking coverage sit relative to our sublimits and retentions when structuring a program?

Bricking coverage is frequently offered subject to its own sublimit and may share or have a separate retention, so its adequacy should be assessed against the plausible cost of replacing critical hardware in a severe scenario. When evaluating limits, consider it alongside, not as a substitute for, business interruption and data restoration coverages, and remember that insurance is a risk-transfer mechanism that does not reduce the likelihood of hardware being compromised. Aligning limits with an inventory of hardware exposure and your resilience planning is a matter to work through with your broker.

Common misconceptions

Bricking coverage is a third-party liability protection.

Bricking coverage is a first-party coverage that addresses the insured's own damaged or inoperable hardware. It does not respond to liability the insured owes to others, which would fall under third-party insuring agreements such as privacy or regulatory liability.

Any cyber event that damages a device is automatically covered as bricking.

Coverage is conditional. It typically requires a covered cyber peril as defined in the policy, and it remains subject to exclusions, sublimits, retentions, and conditions precedent. Whether a specific event qualifies depends on the exact wording and jurisdiction.

Having bricking coverage means the organization is protected against hardware disruption.

Bricking coverage is a risk-transfer mechanism that helps fund recovery after a loss; it does not reduce the likelihood of an incident or by itself constitute resilience. Maintaining continuity and recovery capability still depends on mitigation controls and continuity and disaster-recovery planning.

Best practices

Confirm whether bricking is addressed by an explicit insuring agreement or endorsement rather than assumed under general first-party property or data-restoration wording, and identify the applicable sublimit and retention.

Read the definition of the covered trigger closely to understand which cyber perils must be present for a bricking loss to respond, and check any conditions precedent such as patching or security-control requirements.

Clarify with your broker whether the coverage measures loss by reinstallation and re-flashing costs, physical hardware replacement, or both, since forms differ on the recoverable measure.

Review relevant exclusions (for example war, hostile-infrastructure, wear-and-tear, and failure-to-maintain-standards provisions) to understand where recovery could be limited or defeated.

Map how bricking cover interacts with adjacent first-party coverages such as business interruption and data restoration, and check for anti-stacking or apportionment provisions that affect combined recovery.

Treat bricking coverage as risk transfer that complements, not replaces, mitigation and recovery planning; maintain continuity and disaster-recovery arrangements so hardware can be restored regardless of coverage outcome.