LastSignal vs Burning Ash Protocol vs Posthumous: Which Open-Source Dead Man's Switch?

If you are evaluating open-source dead man's switch software, three projects consistently appear in search results and community recommendations: LastSignal, Burning Ash Protocol (BAP), and Posthumous. Each takes a meaningfully different approach to the same core problem --- ensuring your digital assets and final messages reach the right people when you are no longer around.

This comparison examines the architecture, encryption model, deployment complexity, notification system, and long-term viability of each project to help you make an informed choice.

The Core Problem All Three Solve

A dead man's switch monitors whether you are still alive and active. If you fail to respond to periodic liveness checks, the system assumes you are incapacitated or deceased and triggers a pre-configured action --- typically delivering messages, documents, or access credentials to designated beneficiaries.

The differences between these three projects lie in how they implement each component of that workflow: how they check your liveness, how they store your data, how they protect it cryptographically, and how they deliver it to your beneficiaries.

Architecture Overview

LastSignal

LastSignal is a Python application with a straightforward architecture. It consists of a web server for configuration and status monitoring, a background scheduler for sending liveness check emails, and a delivery system for dispatching messages when the switch triggers. Data is stored in a relational database, and the application exposes a basic web interface for configuration.

The architecture is monolithic and intentionally simple. Everything runs in a single process with background threads handling the scheduling logic.

Burning Ash Protocol

BAP is built on a Go backend (Chi router, GORM ORM) with a Next.js frontend. The architecture separates concerns into an HTTP API layer, a background scheduler for liveness checks and transfer operations, a storage abstraction layer supporting multiple cloud providers, and a cryptographic layer handling AES-256-GCM encryption and Shamir's Secret Sharing.

The scheduler runs as a goroutine within the main process, polling on a 30-second interval for liveness check deadlines, transfer triggers, and OAuth token refreshes. The frontend is a full single-page application with dashboards for both the Host (account owner) and Survivors.

Posthumous

Posthumous is a Python application similar in structure to LastSignal. It provides a web interface for writing encrypted messages, a scheduler for liveness checks, and an email delivery system. The architecture is straightforward, with all components running within a single application.

Encryption Comparison

Encryption is where these three projects diverge most significantly, and it is arguably the most important differentiator for a dead man's switch.

Why This Matters

The encryption model determines who can access your data and under what conditions.

LastSignal encrypts stored messages, but the details of the encryption mode and key management are less documented. When the switch triggers, recipients receive the decrypted message directly. Anyone who intercepts the delivery email gets full access.

Posthumous uses AES-256-CBC, which encrypts data but does not authenticate it. CBC mode is susceptible to padding oracle attacks if the implementation does not include separate integrity verification. Like LastSignal, recipients receive decrypted content directly.

BAP uses AES-256-GCM, which provides both encryption and authentication in a single operation. The ciphertext includes a tag that verifies the data has not been tampered with. Beyond the algorithm choice, BAP's key architecture is fundamentally different: each will has its own Data Encryption Key (DEK), encrypted by a master key. When the switch triggers, the DEK is split using Shamir's Secret Sharing across Survivors. A configurable threshold (say, 3-of-5) of Survivors must cooperate to reconstruct the key. No single Survivor --- and no single point of compromise --- can access the encrypted documents.

This is a meaningful security difference. If you have multiple Survivors, threshold recovery ensures that your will requires cooperation to access, preventing a single compromised or malicious Survivor from accessing everything.

Liveness Check Mechanisms

The liveness check is the heart of any dead man's switch. It determines when the system decides you are no longer responsive and triggers the delivery process.

LastSignal's Approach

LastSignal sends periodic emails containing a confirmation link. You click the link to confirm you are alive. If you miss a configurable number of confirmations, the switch triggers.

The email-based approach has the advantage of simplicity --- no app to install, no API to call. The disadvantage is that email deliverability is unreliable. Spam filters, full inboxes, or email provider outages can cause missed check-ins that are not your fault.

BAP's Approach

BAP uses a three-parameter system for liveness checks:

• HCIT (Host Check-In Interval): How frequently you are pinged. This could be daily, weekly, or any custom interval.
• HCRT (Host Check-In Response Time): The window you have to respond after being pinged. A 24-hour HCRT means you have a full day to check in after the notification is sent.
• HCRAC (Host Check-In Response Action Count): How many consecutive missed check-ins are required before the Will Transfer Protocol triggers.

This three-parameter model lets you tune the system's sensitivity. A configuration of HCIT=7 days, HCRT=48 hours, HCRAC=3 means you are pinged weekly, have two days to respond, and the switch only triggers after three consecutive misses --- roughly a month of total non-responsiveness. This significantly reduces false positives from vacations, illness, or technical issues.

Notifications for liveness checks can be sent via Email, SMS, WhatsApp, or Telegram, ensuring you receive the check-in prompt even if one channel fails.

Posthumous's Approach

Posthumous uses email-based liveness checks similar to LastSignal. The check-in mechanism sends periodic emails that require a response action. The configuration options for timing and threshold are more limited than BAP's three-parameter model.

Notification and Delivery Channels

For a dead man's switch, notification reliability is not a convenience feature --- it is a safety-critical requirement. If your Survivors do not receive the notification, the entire system fails at the last step.

BAP's multi-channel approach addresses this by ensuring that Survivors can be reached through multiple independent communication channels. If the email goes to spam, the SMS or Telegram message still arrives. LastSignal and Posthumous both rely exclusively on email, which introduces a single point of failure in the delivery chain.

Document Storage

LastSignal and Posthumous support storing text messages and basic file attachments. BAP provides full encrypted document storage with integrations to major cloud storage providers. This matters if your digital will includes files --- scanned documents, encrypted archives, or media --- rather than just text instructions.

Deployment and Operations

LastSignal

LastSignal deploys as a Python application. You need Python, pip, a database (typically SQLite or PostgreSQL), and SMTP credentials. Community Docker images are available but not officially maintained. The operational footprint is small, and the application has modest resource requirements.

Burning Ash Protocol

BAP ships with an official Docker Compose configuration. Deployment involves cloning the repository, configuring environment variables, and running docker compose up. It uses SQLite for development and supports PostgreSQL for production. Migrations run automatically at startup. The frontend and API run as separate services within the Compose stack.

BAP also offers a SaaS mode for users who want the security model without the operational overhead. The same codebase supports both self-hosted and SaaS deployment, with a deploy mode flag that controls feature availability (SaaS mode adds Stripe billing and platform-managed notification connectors).

Posthumous

Posthumous deploys similarly to LastSignal --- a Python application with a Dockerfile included. Setup requires Python, database configuration, and SMTP credentials. The operational profile is comparable to LastSignal.

User Interface

LastSignal

LastSignal provides a basic web interface for configuring messages, recipients, and check-in schedules. The interface is functional but minimal, focused on the essential operations without extensive polish.

Burning Ash Protocol

BAP includes a full Next.js dashboard with separate views for Hosts and Survivors. The Host dashboard covers will management, Survivor configuration, notification connector setup, storage management, liveness check settings, and billing (in SaaS mode). The Survivor portal provides OTP-based authentication and will access during the transfer process.

The interface is designed for non-technical users, which matters when your Survivors may not be developers.

Posthumous

Posthumous provides a basic web interface similar to LastSignal, focused on message writing and configuration. The interface is functional and straightforward.

Development Activity and Community

Active development matters for security-sensitive software. A dead man's switch that stops receiving updates becomes a liability as dependencies develop vulnerabilities and deployment environments evolve.

BAP is the most actively developed of the three, with a dedicated documentation site, regular releases, and a public roadmap. LastSignal and Posthumous have lower development velocity, which is not inherently a problem for simple, stable software, but it does mean security patches and feature improvements arrive less frequently.

Trust Model Analysis

The trust model defines who you must trust and what you must trust them with.

LastSignal and Posthumous Trust Model

You trust the server operator (yourself, if self-hosted) with access to the decrypted messages. When the switch triggers, recipients receive fully decrypted content. The security boundary is the server itself --- if the server is compromised, all messages are accessible.

BAP Trust Model

BAP's trust model is more nuanced due to Shamir's Secret Sharing. The server stores encrypted documents, but the decryption key is split across Survivors. Even if the server is compromised, the attacker gets only encrypted data. They would also need to compromise a threshold number of Survivors to reconstruct the key.

The master key (stored as an environment variable on the server) encrypts the per-will DEKs, so the server operator does have theoretical access. However, the Shamir split adds a layer of protection that the other two projects do not offer.

This matters for scenarios like:

• Server compromise: Attacker gets encrypted blobs but not the full key
• Single Survivor compromise: That Survivor's share alone is useless
• Hosting provider subpoena: Encrypted data without the threshold of shares is meaningless

When to Choose Each

Choose LastSignal When

• Your succession plan is simple text messages (no large documents or files)
• You have a single beneficiary or do not need threshold access control
• You want the simplest possible setup and maintenance
• Email-only notification is acceptable for your use case
• You prefer a Python ecosystem

Choose Burning Ash Protocol When

• You have multiple Survivors and want threshold-based access (no single person gets everything)
• Your will includes encrypted documents, not just text messages
• You need multi-channel notifications (Email + SMS + WhatsApp + Telegram)
• You want fine-grained control over liveness check parameters
• You need a polished UI that non-technical Survivors can navigate
• Active development and security updates are important to you
• You want the option to switch between self-hosted and SaaS without changing platforms

Choose Posthumous When

• Your use case is specifically sending final messages to a small number of recipients
• You want MIT-licensed software with no copyleft obligations
• Simplicity is your top priority
• You are comfortable with email-only delivery

Migration Considerations

If you start with one tool and later want to switch, consider the migration path.

Moving from LastSignal or Posthumous to BAP is relatively straightforward --- you re-enter your messages and documents into BAP's encrypted will and reconfigure your Survivors. There is no automated migration tool, but the data volume is typically small enough to do manually.

Moving from BAP to a simpler tool means losing threshold recovery and multi-channel notifications. You would need to restructure your succession plan around single-recipient delivery.

The most important advice: pick one, set it up, and test it end-to-end. A working simple system is infinitely better than a planned complex one.

Conclusion

All three projects solve the fundamental dead man's switch problem, but they target different points on the simplicity-security spectrum.

LastSignal and Posthumous offer straightforward, email-based dead man's switches suitable for simple succession plans with a single beneficiary. They are easy to set up and maintain, with minimal operational overhead.

Burning Ash Protocol provides a comprehensive digital will platform with authenticated encryption (AES-256-GCM), threshold key recovery (Shamir's Secret Sharing), multi-channel notifications, and a full web dashboard. It is the right choice when your succession plan involves multiple Survivors, encrypted documents, or when you need the strongest security guarantees available in an open-source dead man's switch.

The right choice depends on the complexity of your succession plan and your tolerance for operational overhead. What matters most is that you choose one and actually deploy it.