Security
Last updated 2026-08-18
Beacon stores messages written by people who may be in vulnerable situations. The security posture below describes how we treat those messages, what we can and cannot disclose in response to government requests, and the transparency commitments we make to users and partners.
Encryption
Every message is encrypted in transit (TLS 1.3) and at rest in Cloudflare R2. The encryption keys live with Cloudflare's key management service; Foundation staff do not handle raw key material. Message content is not available to us in plaintext through normal operational tools — only the delivery pipeline, at the moment of delivery, decrypts the payload.
What we can and cannot see
We can see
- Your account metadata (email, plan, sign-up date).
- The recipient's name and contact method.
- Your schedule and check-in history (whether, not when-within-the-window).
- The decrypted message content, but only at the moment of delivery.
We cannot see
- The message content in bulk or for analytics.
- Whether a given user's message has been drafted or is blank, from encrypted storage alone.
- Payment card numbers — only Stripe sees them.
Government requests
If law enforcement contacts us for user data, our response is governed by the policy below:
- We require valid legal process — a subpoena, court order, or search warrant scaled to what's being asked for.
- We notify the affected user unless we are legally prohibited from doing so (e.g., a valid non-disclosure order accompanying a subpoena).
- We produce only what the legal process compels, and push back in writing on overbroad requests.
- We maintain a warrant canary (below). When the canary stops updating, the absence is the signal.
- Annual transparency reports beginning 2027 will publish aggregate counts of requests received and data produced.
Incident response
Beacon runs on the One Final Message platform, operated by EGBT Technologies, LLC. Breach notification procedures, public disclosure thresholds, and incident response timelines are governed by the One Final Message Security policy. Beacon-specific incidents follow the same procedures as any other product on the platform — there is no separate Beacon incident-response posture.
Independent security review
Independent third-party security reviews and audit posture for the platform that operates Beacon are documented in the One Final Message Security policy. Beacon does not commission separate audits — by sharing infrastructure with the One Final Message platform, the same audits cover both products. Current audit status and timelines live on the policy linked below.
Canary Statement
Last updated: 2026-08-18 · Next scheduled update: 2026-11-16
As of the date above, the following statements are true:
1. Government Orders
EGBT Technologies LLC has not received any National Security Letters, FISA court orders, or government requests accompanied by a gag order.
2. Warrants & Disclosure
EGBT Technologies LLC has not received any warrants or court orders requiring the disclosure of user message content, recipient information, or check-in activity.
3. Platform Integrity
No backdoor, key escrow, or content interception capability has been added to the One Final Message platform at the request of any government or third party.
4. Credential Security
No user encryption keys or authentication credentials have been turned over to any third party.
5. Message Security
No stored user messages have been accessed, modified, or delivered outside of the normal platform operation as defined in our Terms of Service.
6. Operational Control
EGBT Technologies LLC maintains full operational control of the One Final Message platform and its infrastructure.
If this statement is not updated within 90 days of the date above, or if it is removed from this page, users should treat that as a meaningful signal.
For questions about this canary, contact: support@onefinalmessage.com
Contact
Security issues: security@milkweed.foundation. Responsible disclosure is welcomed; we commit to acknowledging within three business days.