Most controls wait for someone to do something. A dead man's switch waits for them to stop. The hand leaves the locomotive controls, the watchdog misses its ping, the account goes quiet—and a decision made earlier begins to run. That sounds like safety. Sometimes it is. The engineering problem is that silence has more than one meaning.

So let us begin with the sentence that usually gets buried beneath euphemism: Cyberdelia Skunkworks has a dead man's switch.

We believe in them. We advocate their responsible use. We also believe the useful version is almost the opposite of the cinematic one. It is not a digital grenade clenched in a fist. It is not a threat designed to frighten critics, employers, governments or estranged partners into compliance. It is not a machine that interprets a missed text message as permission to ruin lives. A defensible dead man's switch is continuity engineering: a deliberately conservative system for handling the possibility that a human being who normally authorizes, explains, protects or maintains important work can no longer do so.

We are publishing the fact of ours because the principle should not depend on secrecy. We are not publishing its trigger conditions, timing, custodians, architecture or actions because a continuity system is not improved by handing strangers a map of its attack surface. The public claim is narrow. The design argument is broader.

The old mechanism has a modern life.

The term comes from a family of controls that treat the loss of a human signal as meaningful. In rail systems, an alerter monitors an engineer's control activity, gives a warning when activity stops and can apply the brakes when the warning goes unanswered. On covered recreational boats, an engine cut-off device connects the operator to the propulsion system through a lanyard or electronic link so that displacement from the controls stops the engine. Neither mechanism tries to establish why the operator stopped responding. It moves the machine toward a safer state because continued motion has become the greater risk.

Computing inherited the same idea. A hardware or software watchdog expects a periodic signal from a living process. If the signal does not arrive, the watchdog can reset the system. Kubernetes liveness probes ask whether a container is still functioning and can restart it after repeated failures. Consumer account services use inactivity plans to notify trusted contacts or transfer selected data after prolonged silence. The details differ, but the shared question is simple: what should happen when the expected source of control is absent?

That question becomes harder when the absent component is a person rather than a process. A server that stops answering a probe is probably unhealthy. A person who misses a check-in may be asleep, traveling, ill, disconnected, grieving, hiding from danger, locked out of an account or simply unwilling to be monitored. Human absence is ambiguous. Any system that acts on it must be built around that ambiguity.

One person is a single point of institutional failure.

Small organizations celebrate the person who knows everything. One founder holds the domain registration, publication keys, encryption credentials, source relationships, financial context and unfinished investigations. One engineer understands the strange service that has run quietly for six years. One artist controls the archive. One activist remembers which promises were made to whom. This concentration feels efficient until that person becomes unreachable.

The failure is not limited to death. Incapacity can be temporary or permanent. A person can be hospitalized, detained, displaced by disaster, cut off by a communications outage, targeted through account compromise or overwhelmed at exactly the moment an institution needs judgment. Ordinary succession documents help, but they often assume an orderly event followed by cooperative access. Technology fails less politely.

A dead man's switch addresses a specific gap between daily operation and formal succession. It does not replace a will, an estate plan, corporate governance, backups, emergency contacts or a durable incident-response process. It asks whether essential work remains intelligible and recoverable when the person at the center cannot perform the handoff.

For a publication, the protected value may be the continuity of lawful records, the ability to correct the archive, the preservation of source-protection obligations and enough institutional memory for another person to distinguish a draft from a verified finding. For an engineer, it may be safe service shutdown and documented recovery. For a family, it may be carefully selected account access. The payload should serve a legitimate continuity purpose. If its value depends on surprising or punishing someone, the design has already drifted away from safety.

The two errors are not symmetrical.

Every absence detector faces two failure modes. A false negative occurs when the human is truly unavailable but the system does nothing. A false positive occurs when the system acts even though the human is alive, capable or only briefly unreachable. Both matter, but they do not necessarily carry equal costs.

If the first automated action is a reversible notification to a trusted person, a false positive may be inconvenient. If the first action is public release, destructive deletion, financial transfer or irreversible shutdown, the same false positive can become a catastrophe. Responsible design therefore does not begin with the timer. It begins with the consequences.

The safest architecture assumes the signal will occasionally lie. Networks fail. Phones break. Authentication tokens expire. Travel disrupts routines. People make mistakes. Attackers can suppress a check-in or forge one. A dead man's switch that requires perfect communications and perfect human behavior is not a safety mechanism. It is a delayed accident.

This is why we believe in staged responses. Silence should first create questions, not conclusions. Warnings should arrive through more than one independent route. Verification should involve evidence beyond a single account. Trusted humans should have a defined way to pause, recover or revoke the process. Higher-impact actions should require stronger evidence and, where feasible, more than one custodian. The authority granted at each stage should be no broader than the purpose requires.

Good switches are deliberately boring.

The fantasy version is dramatic because drama is easy to describe: miss a heartbeat and the vault opens. Real resilience is slower and less photogenic. It depends on boring disciplines such as least privilege, separation of duties, multiple warnings, independent verification, encrypted backups, documented recovery, audit trails, regular testing and a clear legal basis for every action.

Least privilege matters because a continuity mechanism should not inherit every power its owner possesses. If the purpose is to preserve records, it may need access to a specific archive rather than every account. If the purpose is to notify people, it may need a current contact list rather than control of the organization. A narrow system limits the damage of both error and compromise.

Separation of duties matters because a single custodian can become another single point of failure. It also prevents one frightened, angry or compromised person from turning a safety process into an instrument of coercion. The appropriate arrangement depends on the institution, but the principle is stable: high-consequence decisions deserve independent confirmation.

Reversibility matters because uncertainty is highest at the beginning. Early stages should preserve options. Later stages may gradually widen access or activate a prepared continuity plan, but the system should avoid crossing irreversible boundaries until its evidentiary threshold matches the consequence. The mechanism should fail toward preservation and human review, not toward maximum spectacle.

Testing matters because an untested switch is a story someone tells themselves. Credentials change, APIs disappear, storage expires, custodians move and instructions become obsolete. A test does not need to expose private contents or simulate disaster in public. It must establish that the chain still works, that the right people understand their roles and that recovery is possible when the signal is wrong.

There are things a dead man's switch should not do.

It should not become a booby trap. It should not use indiscriminate release as insurance against accountability. It should not distribute private information about uninvolved people merely because its owner is unavailable. It should not destroy evidence, evade lawful process, trigger physical harm or automate allegations that no living editor can verify. It should not pretend that cryptography turns a reckless decision into an ethical one.

Journalists and researchers face a particularly sharp version of this problem. Preserving an investigation can protect the public record, but publishing unfinished material can expose a source, misidentify a subject or convert uncertainty into a permanent accusation. Continuity should preserve the ability to finish the work responsibly. It should not eliminate the editorial judgment that makes publication responsible in the first place.

The same constraint applies to cybersecurity. An organization may need to preserve logs, hand over documentation or disable access when an administrator disappears. That does not justify code that retaliates against a network, deletes systems on suspicion or releases credentials into the world. A safety mechanism should reduce the blast radius of a human absence. It should not manufacture a new one.

Why say this publicly?

Some security practitioners will argue that even acknowledging a switch invites attention. That risk is real. So is the cultural risk of treating continuity planning as melodrama until a crisis exposes that no one can reach the archive, renew the domain, protect the sources or explain the system. We can disclose the existence and the values without disclosing the mechanism.

Our declaration is also a commitment against misuse. By describing the switch as preservation rather than revenge, we create a standard against which our own conduct can be judged. If it were ever used as a threat, built around indiscriminate harm or treated as a substitute for evidence, it would violate the reason we say it exists.

We advocate responsible dead man's switches for journalists, researchers, artists, engineers, activists, small organizations and anyone whose lawful work should not vanish with one person. Not everyone needs automation. Some need a sealed envelope, two trusted people and an annual calendar reminder. Some need legal documents and a password manager with emergency access. Some need a carefully tested technical process. The right mechanism follows from the risk; the fashionable mechanism does not define it.

Start with the continuity question. What becomes inaccessible, unsafe or unintelligible if the central person cannot answer tomorrow? Decide what must be preserved, what must remain private and who can lawfully act. Make the earliest responses reversible. Require stronger evidence as consequences grow. Test the handoff. Keep the plan narrow. Then accept the most important fact about the entire design: a missed signal is evidence of silence, not proof of death.

Cyberdelia has made that calculation. We have a dead man's switch. We believe responsible institutions should confront the same class of failure before it arrives. We will tell you what principle it serves. We will not tell you how to defeat it.

CYBERDELIA ASSESSMENT

A responsible dead man's switch is a continuity control, not a threat. Its job is to preserve lawful work and institutional memory when a key person becomes unavailable while resisting false triggers, compromised signals and irreversible error. The strongest designs are staged, narrow, independently verified, recoverable and intentionally undramatic. Cyberdelia maintains one and advocates that other single-point institutions build the appropriate version of their own.

News DeskResearch DeskFeatures