What Is a Bitcoin Security Test

Theft Resistance, Access Survivability, and the Tension Between Them

This memo is published by CustodyStress, an independent Bitcoin custody stress test that produces reference documents for individuals, families, and professionals.

Security Testing in Custody Runs in Two Directions

Most people asking about bitcoin security tests are thinking about one direction: whether someone can steal their bitcoin. That's the conventional framing, and it addresses a real concern. Unauthorized access, seed phrase exposure, weak device PINs, phishing attacks against exchange accounts — these are legitimate failure surfaces that security evaluation addresses.

In custody, that framing covers only half the territory. A setup that no attacker can breach is also a setup that no heir can access if the original holder is gone and the access credentials exist only in the holder's memory. The same question — can someone get to this bitcoin — runs in two directions simultaneously. Security testing in a custody context has to account for both, because the properties that produce a passing score in one direction frequently produce a failing score in the other.

---

Why Theft Resistance and Access Survivability Pull Against Each Other

The tension is structural. Security improvements in bitcoin custody typically work by reducing the number of places where credentials exist, increasing the complexity of what those credentials require, and removing written records that could be discovered by unauthorized parties. Each of those measures reduces attack surface. Each also narrows the access path available to anyone other than the original holder.

A passphrase added to a hardware wallet makes the seed phrase alone insufficient for access — an attacker with the seed phrase still cannot reach the funds. That same property means an heir with the seed phrase cannot reach the funds either. The security measure and the access barrier are identical. Distinguishing between them requires knowing whether the passphrase was documented somewhere the heir can find, which is exactly the kind of written record security improvement tends to eliminate.

Undocumented derivation paths create a similar pattern. Standard derivation paths are widely known, so a custody arrangement using a non-standard path gains some obscurity benefit against automated recovery attempts. That obscurity disappears if the holder knows the path by memory and documents it nowhere. An heir restoring from the seed phrase with standard derivation software reaches empty addresses. The security property that created this outcome is invisible — there's no indication in any document that the path was customized, because documentation of the customization would partially undermine it.

---

What Conventional Security Testing Examines

Conventional bitcoin security testing evaluates whether the custody arrangement resists unauthorized access. Whether called a bitcoin security assessment, a security review, or a security evaluation, the standard version of this examination covers a consistent set of surfaces: whether seed phrase backups are stored where they can't be discovered by household visitors or burglars, whether hardware wallet PINs are not written adjacent to the devices they unlock, whether exchange accounts use strong credentials and two-factor authentication, and whether the holder has avoided storing private key material in internet-connected locations.

These are real and meaningful properties. A custody arrangement with exposed seed phrases, PINs written on sticky notes attached to devices, and exchange accounts protected by weak passwords presents significant theft risk. A bitcoin security check that identifies these conditions is identifying genuine vulnerabilities. The evaluation is not wrong — it's incomplete in one specific dimension that custody stress makes visible.

What conventional testing doesn't examine is what an heir encounters when attempting access. The questions it asks — is this exposed? is this discoverable? is this weak? — are the inverse of the questions custody testing asks. Custody testing asks: is this findable by the heir? is this complete enough to use? is this still accurate? A setup can answer the security questions well and the custody questions poorly, with no contradiction between the two outcomes.

---

How Security Properties Become Access Barriers

The translation from security property to access barrier happens quietly, often without anyone noticing it has occurred. Security decisions made at setup time don't announce their downstream custody consequences. They appear in the documentation — if they appear at all — as correct technical choices, not as risks to future access.

Hardware-only signing represents one example of this pattern. A holder configures their custody arrangement to require physical device confirmation for every transaction, with no software-only signing path available. This eliminates a class of remote attack that software wallets face. It also means the physical device is the only path to any transaction. If that device fails, is lost, or requires a PIN that wasn't recorded, the security property that eliminated the remote attack also eliminated the recovery path.

Minimal documentation is another. A holder who understands security keeps written records sparse — seed phrase backup exists, other details are memorized. The sparse documentation doesn't reveal account structure, balance locations, or the full custody configuration to anyone who might find it. An executor who finds that documentation also can't determine what holdings exist, which platforms are involved, or how the pieces connect. The sparse record was a security feature. For the executor, it's an access barrier.

Time compounds both of these dynamics. Security properties established in 2019 interact with an estate opened in 2026 in ways no one evaluated at setup. Hardware devices age. Manufacturer support ends. Platform account recovery procedures change. The security property that was correctly established years ago now coexists with a different technical environment that wasn't present when the tradeoff was made.

---

Where Security Testing and Custody Testing Overlap

The shared territory is the access path itself. Both evaluations trace the sequence from nothing — no device, no credentials — through each layer to the bitcoin. Security testing asks whether that path is properly restricted at each layer. Custody testing asks whether the path remains traversable by someone other than the holder.

This overlap makes it possible to conduct both evaluations together using the same structural trace. An heir attempting to follow the access path from the holder's documentation encounters both the security properties the holder established and the gaps those properties may have created. Where the path is correctly restricted against unauthorized access, the security evaluation notes a passing condition. Where the path breaks because documentation is missing or incomplete, the custody evaluation notes a failure.

The distinction matters because the remedies for each failure type are different — and in some cases, incompatible. Improving theft resistance may require reducing documentation. Improving access survivability may require expanding it. A custody arrangement navigates that tension in one direction or the other at every layer of its design, and neither security testing nor custody testing alone makes that tradeoff visible. Both evaluations together do.

---

What Security Testing Misses When It Only Checks One Direction

A security review that only examines intrusion resistance produces results that look complete. The seed phrase is properly stored. The device PIN is not recorded adjacent to the device. Exchange credentials are strong. Two-factor authentication is enabled. The review finds nothing alarming and concludes the arrangement is in order.

None of those findings address what a spouse discovers after a sudden death. The seed phrase is stored somewhere she doesn't know about, because proper storage meant not telling family members. The device PIN exists only in the holder's memory, because writing it down would have undermined the security of the hardware wallet. Two-factor authentication is tied to a phone that is now locked and whose carrier account she doesn't control. The security review was accurate. The custody outcome is the same as if no review had occurred.

This failure pattern doesn't appear in the security review results because the review wasn't designed to look for it. The questions it asked were answered correctly. The condition it missed — whether an heir can traverse the access path — was never among the questions. That's not a flaw in security testing. It's the boundary of what security testing addresses, which only becomes a problem when the full scope of custody risk is understood to extend beyond it.

---

Security Testing in Custody as a Complete Concept

A complete bitcoin security test in a custody context examines both directions: what the arrangement resists and what it permits. The first direction asks whether unauthorized access is blocked at each layer. The second asks whether authorized access — by an heir, an executor, a trustee — remains possible when the original holder is unavailable.

Most arrangements that have received any security attention perform well in the first direction. Theft has been a concern for bitcoin holders since early in the asset's history, and the available security measures are well-documented and widely practiced. The second direction receives less attention because the failure it addresses — permanent inaccessibility — doesn't feel like a security failure in the conventional sense. It feels like an estate planning failure, or a documentation failure, or a communication failure. The security framing makes it easier to miss.

The connection between the two directions is that the same design decisions shape both outcomes. Security choices made without considering their custody consequences produce arrangements that resist theft and resist inheritance with equal effectiveness. Understanding security testing as a two-directional evaluation makes that tradeoff visible at the point where it can still be examined, rather than at the point where it has already determined what an heir receives.

---

Summary

A bitcoin security test in the conventional sense examines whether unauthorized access is blocked. In custody, that evaluation addresses one of two relevant failure surfaces. The other is whether authorized access — by heirs, executors, and trustees — survives the holder's absence. Both surfaces are shaped by the same design decisions, and they frequently pull in opposite directions.

The properties that make a custody arrangement difficult to breach — sparse documentation, hardware-only signing, undocumented derivation paths, memorized credentials — also narrow the access path available to anyone who wasn't the original holder. Security testing that checks only intrusion resistance finds no failure in these properties. Custody testing exposes the access barrier they create.

A complete security evaluation in custody traces the access path in both directions: what the arrangement blocks, and what it permits when the holder is gone. The tension between those two questions doesn't resolve cleanly. Every custody arrangement navigates it, whether or not the navigation was deliberate, and the outcome of that navigation is what an heir encounters.

System Context

Bitcoin Custody Complexity vs Security

Elemental Destruction as a Backup Test

Defined Terms

← Return to CustodyStress