What is a dead man's switch?

A dead man’s switch is a mechanism that automatically triggers a pre-planned action when a person stops performing a regular, expected action — usually a simple check-in. If you go silent past a defined threshold, the switch assumes something has happened to you and executes the task you configured in advance, without anyone needing to notice your absence or intervene manually.

The concept is simple, but the implications for a one-person business are significant. This post explains where the idea comes from, how software dead man’s switches work, who uses them, and what separates a good one from a dangerous one.

Where the term comes from

The original dead man’s switch was a physical safety device, not a piece of software. Locomotives, heavy machinery, and industrial vehicles were fitted with pedals or levers that the operator had to hold down continuously. If the operator became incapacitated — a heart attack at the controls of a train, for example — they would release the lever and the machine would automatically brake or shut down.

The logic is worth noticing: the switch does not detect death. It detects the absence of an ongoing action from a live, functioning operator. That distinction is what makes the concept portable to software. You do not need to prove anything bad happened. You only need to notice that the expected activity stopped.

How a software dead man’s switch works

A software dead man’s switch replaces the physical lever with a heartbeat: a small, regular signal you send to prove you are still around. The general model looks like this:

1. You configure an action in advance. Write the message, upload the file, or define the task that should run if you disappear.
2. You check in on a schedule. Weekly, monthly, whatever interval fits your risk tolerance. Each check-in resets a timer.
3. The system watches the timer. If a check-in is missed, a good switch does not immediately fire — it starts an escalation sequence: reminders, then notifications to people you trust.
4. Only after the full escalation fails does the action execute. The pre-written payload is delivered to its intended recipient.

The critical design property is that the system acts on inaction, which is exactly the scenario no human-based process handles well. If you run a business alone, there is no colleague who notices you have not shown up. The switch is the colleague.

Who uses dead man’s switches?

The use cases span anyone whose absence would strand something important:

• Solopreneurs and indie founders — their business credentials, client relationships, and revenue flows exist only in their head and their accounts. This is the use case Imok is built for.
• Sysadmins and solo developers — the one person holding deployment keys, server access, or an undocumented production system.
• Journalists and whistleblowers — publishing sensitive material automatically if they are detained or silenced.
• Remote workers and expats — people whose families are far away and might not notice silence for weeks.

For this article, the relevant case is the first one: the person who is the business.

Dead man’s switch vs. the alternatives

It helps to position the switch against the other ways people try to solve the same problem:

Scheduled messages (“if I don’t cancel this email, it sends”) are the lightweight cousin of a dead man’s switch. They work for one-off messages but lack escalation, encryption guarantees, and controlled delivery — and they fire on a timer, not on verified unreachability.

Sharing credentials in advance solves access but not timing: the information is available now (a standing security risk) and goes stale every time you rotate a password or change a tool.

Platform legacy features (Apple Legacy Contact, Google Inactive Account Manager) are official and worth enabling, but they cover only that platform’s data. They do not transfer the operational map of a business spread across a dozen providers.

A will handles legal ownership and is essential — but executors routinely discover they have legal authority over accounts they cannot log into. A will says who gets the business; it does not say how to run it.

A dead man’s switch occupies the gap none of these cover: verified inactivity as the trigger, encrypted storage while you are alive, and controlled delivery of operational instructions to exactly one person.

Why solopreneurs specifically need one

If you run a one-person business, your operational knowledge is a single point of failure, and that point is you. Your Stripe account, your domain registrar, your hosting, your client list, the password reset email for everything — all of it routes through accounts only you can access.

The same logic applies beyond businesses: self-custody bitcoin holders use a dead man’s switch to tell family where their seed backups are hidden — see the bitcoin inheritance use case and our bitcoin inheritance planning guide.

When a solopreneur dies or is incapacitated without a plan, the default outcome is grim: subscriptions keep billing a dead person’s card, clients are left wondering, two-factor authentication locks every account to a phone no one can unlock, and platforms demand death certificates and court orders before they will talk to anyone. The full picture is covered in what happens to your online business when you die.

A dead man’s switch does not solve the legal side — that is what wills and estate attorneys are for. It solves the operational side: making sure the person you choose receives the map to your business while things can still be salvaged.

What makes a good dead man’s switch?

Not all implementations are equal. A switch protecting something as important as your business should meet four criteria:

1. Automation with a grace period. The switch must trigger on inaction without human intervention — but never instantly. A missed check-in because you were on a flight should start reminders, not a release. Look for a multi-stage escalation, not a hair trigger.

2. Real encryption, ideally zero-knowledge. Your handover packet contains the keys to your livelihood. It should be encrypted so that even the service provider storing it cannot read it. If the provider can read your packet, a breach of their database is a breach of your entire business. Our security page explains how zero-knowledge encryption works in practice, and zero-knowledge encryption explained simply covers the concept in plain language.

3. Escalation before release. Before anything is delivered, the system should try hard to reach you: repeated reminders, then a trusted contact who can check whether you are fine. False positives are the biggest practical risk of any dead man’s switch, and escalation is the mitigation.

4. One-time, controlled delivery. The payload should go to exactly one designated successor through a link that expires — not an email blast, not a publicly accessible file. You want delivery to be deliberate and auditable.

How Imok implements it

Imok is a dead man’s switch built specifically for solopreneurs, with exactly one job: if you stop checking in, it delivers your pre-written, encrypted handover packet to your designated successor. It is not a password manager, not file storage, and not a team tool.

The system runs as a strict state machine:

• ACTIVE — you are checking in normally. Nothing happens.
• REMINDING — you missed a check-in. The system emails you for five days. Any check-in returns you to ACTIVE.
• CONTACTING_TRUSTED — reminders went unanswered, so your trusted contact is notified once and asked to check on you. Deliberately, this notice does not mention the packet — your trusted contact’s job is to find you, not to receive your secrets.
• RELEASED — only after all of the above fails does your successor receive a one-time reveal link, which expires after 30 days or first use.

There is also a manual “Release now” override if you ever want to hand over deliberately. The full flow is documented on the how it works page.

On the security side, your packet is encrypted in your own browser with AES-256-GCM, with the key derived from your passphrase using PBKDF2 (SHA-256, 310,000 iterations). Our servers store only ciphertext, the IV, the salt, and the iteration count. Your passphrase is never transmitted, which means Imok cannot read your packet and cannot recover a lost passphrase. That is a deliberate trade-off: real zero-knowledge means we genuinely cannot peek.

Common objections

”Isn’t this just a fancy timer?”

The timer is the easy part. The hard parts are everything around it: storing your packet so that no one — including the provider — can read it while it waits (zero-knowledge encryption), distinguishing “on a plane” from “genuinely unreachable” (staged escalation with a human verification step), and delivering the payload to exactly one person in a controlled, expiring way (one-time reveal links with hashed tokens). A cron job can fire an event; it cannot exercise judgment about whether it should.

”Isn’t this morbid?”

It is no more morbid than buying insurance or writing a will — it is the same category of adult responsibility, applied to a newer class of asset. Framing it as a business-Imok tool is accurate: you are not planning for death, you are planning for the Imok of something you built. Your clients, your successor, and your family all benefit from the business ending (or continuing) in an orderly way rather than decaying by default.

”What about false triggers?”

False triggers are the main engineering problem of any dead man’s switch, which is why Imok never releases on a single missed check-in. Five days of email reminders come first. Then a trusted contact is asked to verify you are actually unreachable. Only after both stages fail does anything get delivered — and even then, the release is a one-time link to one person, not a broadcast. You would have to ignore five days of email and be unreachable by your trusted contact for a false release to occur.

”Can’t I just leave my passwords with someone?”

You can, but static sharing has three failure modes: it goes stale the moment you rotate a credential, it gives someone access now rather than when it is needed, and it is usually stored somewhere insecure or somewhere no one can find. A dead man’s switch solves the timing problem — delivery happens exactly when it should, not before. Many solopreneurs combine the two: a password manager for credentials, and a handover packet explaining what everything is and what to do with it.

The bottom line

A dead man’s switch is a simple idea with a serious purpose: it converts your silence into a planned, controlled handover instead of chaos. For solopreneurs — whose businesses have no other custodian — it is the difference between a successor receiving a clear map and a family receiving months of locked accounts and unanswered questions.

If you run a one-person business, the checklist above is the standard to hold any solution to: automated triggering with a grace period, zero-knowledge encryption, staged escalation, and one-time delivery. That is exactly what Imok implements — see how it works or the solopreneur use case for the details.

Frequently asked questions