Security without the theater

No "military-grade" buzzwords. Here's exactly how DeadVault protects your files, with honest claims about what we do and what we don't.

Encryption architecture

Three layers of protection, each designed to limit the blast radius of any single compromise.

1

Per-File Encryption

Every file uploaded to DeadVault is encrypted with a unique AES-256-GCM key before being written to storage. GCM mode provides authenticated encryption, guaranteeing both confidentiality (no one can read it) and integrity (no one can tamper with it without detection).

  • ✓Algorithm: AES-256-GCM (256-bit key, 96-bit nonce, 128-bit auth tag)
  • ✓Each file gets its own encryption key: compromising one key cannot decrypt other files
  • ✓Encryption happens server-side before storage write
2

Key Architecture

Encryption keys are never stored alongside file data. Per-file keys are wrapped (encrypted) with a master key and stored in a separate key_store table. The master key is managed separately from the application database.

  • ✓Per-file keys stored in dedicated key_store table
  • ✓Keys are wrapped with a master key before storage
  • ✓Key material is separate from file storage
  • ✓Master key rotation supported without re-encrypting files
3

Cryptographic Erasure

This is the real security story. When a box reaches its deadline, we destroy the encryption keys. Without the key, AES-256-GCM encrypted data is mathematically unrecoverable, by anyone, including us. The encrypted file data becomes meaningless noise.

  • ✓Key destruction at deadline: not just file deletion
  • ✓Encrypted data without its key is computationally impossible to decrypt
  • ✓Best-effort byte overwrite on local storage (honest: not guaranteed on cloud block storage)
  • ✓Hard cap of 45 days from box creation. Nothing lingers

A note on honest security claims

We don't claim "DoD-level wiping" or "military-grade encryption." Here's what's true:

  • •Cryptographic erasure is real. When we destroy the encryption key, the data is mathematically unrecoverable. This is a well-established cryptographic principle, not marketing.
  • •Multi-pass overwrite on cloud storage is theater. Cloud block storage may be deduplicated, cached, or replicated in ways we can't control. We do best-effort overwrite, but cryptographic erasure is what actually protects you.
  • •AES-256-GCM is a specific, auditable claim. When we say AES-256-GCM, that's exactly what we use. Not a vague "256-bit encryption" that could mean anything.

Access controls

Multiple layers of access control, each independently configurable per drop.

Unique Secure Links

Each box gets a unique, unguessable URL. No directory listing, no enumeration.

Optional PIN Protection

PIN codes delivered via separate channel. Brute-force protected with rate limiting and lockout.

Payment Gates

Require Stripe payment before file access. Payment verification is server-side, no client-side bypasses.

Upload Rate Limiting

Per-box, per-hour upload limits enforced at the API level. Prevents abuse and storage attacks.

Audit trail

Every interaction with a drop is logged. The audit trail is immutable, entries cannot be modified or deleted. Export in CSV or JSON for compliance reviews, regulatory audits, or internal record-keeping.

All timestamps are stored in UTC with timezone awareness.

Logged fields

  • ✓Timestamp (UTC, timezone-aware)
  • ✓Action type (view, download, upload, payment, PIN attempt)
  • ✓IP address
  • ✓User agent
  • ✓Success/failure status
  • ✓File identifier (for file-specific actions)

Compliance positioning

We're building toward formal certifications. Here's where we stand, no false claims.

SOC 2 Type II

In progress

We're pursuing SOC 2 Type II certification. Our architecture is designed around the Trust Services Criteria from day one.

GLBA (Gramm-Leach-Bliley Act)

Architecture ready

DeadVault's encryption, access controls, and audit trail meet the technical safeguards requirements for financial institutions handling NPI.

HIPAA

Architecture ready

Our encryption and access controls align with HIPAA Technical Safeguard requirements. BAA available on Enterprise plans.

IRS Publication 4557

Compliant

Meets the data security requirements for tax preparers: encryption at rest, secure transmission, access controls, and audit logging.

Infrastructure

The platform and operational practices behind the encryption.

HTTPS Everywhere

All traffic encrypted in transit with TLS 1.2+. HSTS headers enforce HTTPS.

Database Encryption

PostgreSQL with encryption at rest. Async SQLAlchemy for connection pooling and performance.

Rate Limiting

API-level rate limiting on all endpoints. Per-box upload limits. Brute-force protection on PIN entry.

Security Headers

CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy. No iframe embedding.

Questions about our security?

We're happy to discuss our security architecture in detail. No NDAs required for honest answers.

Contact usSecurity FAQ