Trust & Security
A message recorded for a grandchild's wedding ten years from now is one of the most personal things a person will ever entrust to a piece of software. We treat that responsibility seriously. This page summarises how earlier.me protects what you — and the people you love — place in our care, and what we ask for in return so the system stays trustworthy at scale.
At a glance
- Message bodies and recipient lists are encrypted at rest with AES‑256 at the database layer.
- Audio and video are encrypted at rest in Amazon S3 (SSE‑S3, AES‑256), and accessed only through short-lived signed URLs.
- All traffic is HTTPS only. HSTS is enabled with subdomain inclusion and preload.
- No human at earlier.me reads message contents. Decryption happens at delivery, on the recipient's terms.
- Every resident carries an explicit consent attestation — resident‑directly or named surrogate — with a full audit trail.
- A message is delivered on the date it was scheduled — even if something happens to the sender in the years between. Honouring that promise is the entire point of the product, and a one-click manual pause is always available if circumstances require it.
- Recipients are emailed a heads‑up roughly thirty days before delivery so they can confirm, change address, or decline.
- An
escrow:exportcommand produces a portable archive of every undelivered message so a successor can honour our delivery promises if we go away. - Business Associate Agreements are available on request from inside your admin panel.
- Family-link URLs are signed and revocable per resident, so access can be cut at any time.
- Errors are surfaced to a monitored exception tracker so failures are seen and fixed quickly.
Encryption
At rest
Two independent layers of encryption protect content at rest. The first is application-level: message bodies and trusted-keeper email lists are encrypted with AES‑256‑CBC using Laravel's encryption framework, keyed to a per-environment application key that is held only on our servers. Even a database backup or filesystem snapshot leaks no readable message text. The second is infrastructure-level: the underlying Amazon RDS volume is encrypted with AWS‑managed keys, and uploaded media in Amazon S3 is stored with SSE‑S3 (AES‑256) server-side encryption.
In transit
Every request to earlier.me is served over TLS 1.2 or TLS 1.3. We send a Strict-Transport-Security header that instructs browsers to refuse plain‑HTTP connections to our domain for one year, applied to subdomains and submitted to the HSTS preload list. Internal traffic between our application servers and the database, queue, and storage backends rides over private network links that are themselves encrypted by AWS.
Key management
The application encryption key never leaves the production environment. It is stored as an environment variable provisioned by our hosting provider, not committed to source control. Rotating the key is a planned, audited operation that re-encrypts every affected row, not a hot swap.
Access control
Authentication
We default to passwordless sign-in: a six-digit code emailed to the address on file, plus a single-use signed magic link in the same email. Both expire within minutes of issue. A traditional password is offered as a backup but is never the only option. We rate-limit code-send and code-verify endpoints aggressively to deter automated guessing.
Authorization
Roles are explicit. A facility admin can manage their facility, residents, staff, and billing, and nothing else. A staff member can record on behalf of residents but cannot see another facility's data. A resident's own messages are tied to their own identifier. Every privileged route is gated by middleware that resolves the organisation from the URL and refuses access to anyone whose record doesn't match.
Family links
When a facility shares a family link, the URL itself carries an HMAC signature plus a per‑resident secret. Either component can be invalidated independently. Rotating the resident's family-link secret immediately revokes every previously-issued URL for that resident — useful when an email account is compromised, a family member should no longer have access, or the resident transfers facilities.
Public message links
A delivered message can be re-viewed via a 32‑character random token in the URL. The token is generated server-side, is not derived from any predictable input, and is only exposed once delivery has actually occurred. Tokens for messages that have not yet been delivered are not visible to anyone, including the recipient.
Subprocessors
The following services process data on our behalf. We do not use any others.
- Amazon Web Services — primary application hosting, database (RDS), and media storage (S3). U.S. region. SOC 2 Type II, ISO 27001, HIPAA-eligible.
- Laravel Cloud — deployment and operations layer over AWS. Inherits AWS controls.
- Stripe — payment processing for individual message purchases and facility subscriptions. PCI DSS Level 1. We never see or store card numbers.
- Postmark — transactional email delivery for sign-in codes, message-saved confirmations, and the actual delivery of messages to recipients. SOC 2 Type II.
- Sentry — application error tracking. We deliberately scrub message bodies and personal-message content from any reports that reach Sentry; only stack traces and request metadata are sent.
Resident lifecycle safety
Recording messages on behalf of older adults is not the same problem as letting a general consumer schedule an email to themselves. Three things can go wrong between a recording being made and a recording being delivered: the resident may not have had capacity to consent in the first place, the resident may die before the delivery date, or the recipient's life may change so completely that the message lands somewhere painful. Each of those is a real risk, not a theoretical one, and the product is built around them.
Consent capacity at intake
Every resident added to a facility account carries an explicit attestation of who is authorized to consent to recordings on their behalf: the resident themselves, or a named surrogate (power of attorney, legal guardian, spouse, adult child, sibling, or other family). The surrogate's name, email, and relationship are stored on the resident profile, and every change to the consent record writes a permanent audit entry tied to the staff member who made it. A resident without an attestation on file is flagged in the admin dashboard and never silently treated as having consented.
Pre‑delivery confirmation
Approximately thirty days before each scheduled message is due, the system emails the intended recipient a courteous heads‑up: a message is on its way, and they have three options — confirm the address is still good, supply a different email, or decline delivery. The links are signed and expire after fourteen days. If the recipient declines, the message is held automatically. If the recipient's address bounces, the message is held automatically and the facility administrator is notified. Recipients who ignore the email get the message on its scheduled date as originally intended.
Continuity & escrow
The product makes a multi‑year promise: a message recorded today will be delivered on the date the resident chose, even if that date is a decade away. We take that seriously enough to plan for what happens if earlier.me itself does not exist on the delivery date.
We maintain an operational continuity plan covering three scenarios: a short outage (resolved by our own infrastructure failover), an extended outage (resolved by manual delivery from our last database backup), and a wind‑down (handled by handing every undelivered message off to a third‑party trustee for completion). The technical mechanism for the third scenario is a portable archive command (escrow:export) that produces a self‑contained directory of all undelivered messages and the metadata needed to deliver them, including encryption keys held in escrow. Facility administrators can review the wind‑down terms in their MSA. We do not assume continuity is guaranteed; we build the technical surface that lets a successor honour our commitments.
Data retention & deletion
Scheduled messages are retained until they are delivered, at which point a single delivered copy remains so the recipient can re-open the public link. Drafts that have not been activated are kept for thirty days and then automatically pruned. Unattached uploaded media is pruned daily.
A facility administrator can deactivate a resident, in which case no new messages can be scheduled for that resident, but already-scheduled messages are honoured to their delivery date. A facility may request full deletion of its account — including all residents, scheduled messages, and undelivered media — by emailing hello@earlier.me. Personal users may do the same.
Once a message has been delivered, the copy in the recipient's inbox is outside our control. We can remove our stored copy on request, but cannot recall an email already sent.
Operational controls
Backups
The production database is backed up automatically every day, with point-in-time recovery covering the previous seven days. Backups are encrypted with AWS-managed keys and live in a separate availability zone from the primary. We periodically perform restore drills against a non-production environment to confirm backups are usable.
Monitoring
Uncaught exceptions are forwarded to a dedicated error-tracking service (Sentry) within seconds of occurring. Delivery jobs — the part of the system that actually emails messages on the day they're due — are queued, idempotent, and retried with exponential backoff for up to roughly one day. A permanent delivery failure raises an alert so an operator can intervene before the family notices.
Change management
All code changes pass an automated test suite before they reach production. Database migrations are reversible where reasonable, and destructive operations (e.g. demo‑environment seed resets) are gated by both an environment match and an explicit configuration flag, so a misconfigured server cannot accidentally wipe customer data.
Incident response
If we detect — or are notified of — a security incident affecting customer data, we will: (1) contain the incident, (2) determine which facilities and individuals are affected, (3) notify affected facility administrators within seventy-two hours of confirming the impact, with a description of what happened, what data was involved, what we have done in response, and what (if anything) the facility should do, and (4) publish a public post-mortem when the underlying cause is shareable without compromising further security.
HIPAA & PHI
earlier.me is built for personal messages — birthday wishes, milestone messages, legacy notes — not for clinical communications. Personal messages of this kind are typically not Protected Health Information under HIPAA, even when they originate inside a care facility. That said, the practical reality is that anything a resident records may incidentally touch on health, medication, or care — and a facility's compliance posture should be the same regardless.
Business Associate Agreements are available. Any facility administrator can request a signed BAA from inside their admin panel under Facility. We counter‑sign and return it within five business days. The technical posture described above (AES‑256 at rest, TLS in transit, audited subprocessors, audit trail of consent and access) is intentionally built to support the controls a BAA implies. If your procurement process requires HITRUST or SOC 2 Type II reports specifically, please reach out at hello@earlier.me — our SOC 2 Type II audit is in progress and an executive summary of the latest third‑party penetration test is available under NDA.
Responsible disclosure
If you believe you've found a security issue affecting earlier.me, please email security@earlier.me with a description of the issue and steps to reproduce. We commit to acknowledging your report within two business days, working with you in good faith on a remediation timeline, and not pursuing legal action against researchers acting in good faith under coordinated disclosure.
Questions?
Procurement teams, IT directors, and family members are all welcome to reach out. We'll answer specific questions about our controls, including ones not covered above, and provide additional documentation where it helps. Email hello@earlier.me.