# End-to-End Encryption for Business Data When a vendor says "your data is encrypted," they usually mean one thing: TLS. Your data is encrypted while it moves between your browser and their server. That's the equivalent of saying your letter is sealed in an envelope during delivery — but sitting in the post office, it's an open postcard anyone can read. True encryption for business data requires more than TLS. ## The Three Layers of Encryption ### Layer 1: In Transit (TLS) TLS encrypts data as it moves over the network. Your browser and the server negotiate an encrypted channel, and all data passes through it. Without TLS, anyone on the network path (your ISP, a coffee shop's WiFi, network intermediaries) could read your data. TLS is table stakes. Every reputable platform has it. If a platform serves traffic over HTTP instead of HTTPS in 2026, run. ### Layer 2: At Rest Encryption at rest means data stored in the database and file system is encrypted on disk. If someone physically steals the server (or gains unauthorized access to the storage volume), they get encrypted gibberish instead of your business data. This protects against: stolen hardware, unauthorized access to storage volumes, improper decommissioning of hard drives, and certain types of backup theft. Most major cloud providers offer encryption at rest for managed databases and storage services. Self-hosted platforms should use LUKS (Linux) or BitLocker (Windows) for disk encryption, plus database-level encryption. ### Layer 3: Application-Level Encryption Application-level encryption means specific sensitive fields are encrypted by the application before they're stored in the database. Even a database administrator with full access sees encrypted values. This is the layer most business platforms skip. And it's the one that protects against the most realistic threat: authorized users (or compromised accounts) accessing data they shouldn't see. ## What Should Be Encrypted at Each Layer **TLS (everything):** Every HTTP request, every WebSocket connection, every API call. No exceptions. **Disk encryption (everything):** The entire database volume and file storage should be encrypted at rest. **Application-level encryption (sensitive fields):** - API keys and OAuth tokens - Personal identification numbers - Financial data (bank accounts, credit card numbers) - Health information - Authentication credentials - Encryption keys themselves (key wrapping) Not all data needs application-level encryption. Product descriptions, blog posts, and public-facing content don't require field-level encryption. Sensitive personal and financial data does. ## Key Management: The Hard Part Encryption is only as strong as key management. If your encryption key is stored alongside the encrypted data, it's like locking your front door and taping the key to the doorframe. ### Key Hierarchy Production systems use a key hierarchy: **Master Key:** The root key that encrypts everything else. Stored in a Hardware Security Module (HSM) or a managed key service (AWS KMS, Azure Key Vault). Never exposed to the application. **Data Encryption Keys (DEKs):** Individual keys that encrypt data. Each tenant, each data category, or each record can have its own DEK. DEKs are encrypted by the master key (envelope encryption). **Key Rotation:** DEKs should be rotated regularly (monthly or quarterly). Old DEKs remain available for decrypting existing data. New data uses new DEKs. This limits the blast radius of a compromised key. ### Self-Hosted Key Management For self-hosted platforms, key management options include: - **HashiCorp Vault:** Open source secrets management with transit encryption capabilities. The gold standard for self-hosted key management. - **File-based keys with restricted permissions:** Simple but less secure. The key file is readable only by the application process. - **Environment variables:** Acceptable for development. Insufficient for production — environment variables can be exposed through process listings and crash dumps. ## Common Encryption Mistakes ### Encrypting Everything Over-encryption creates performance problems without proportional security gains. Encrypting a public blog post adds latency without meaningful protection. Focus encryption on data that would cause harm if exposed. ### Rolling Your Own Crypto Use established libraries and algorithms (AES-256-GCM for symmetric encryption, RSA-OAEP or ECDH for asymmetric). Never implement your own encryption algorithm. Never invent your own key derivation function. The history of cryptography is littered with clever custom algorithms that turned out to be trivially breakable. ### Storing Keys in Code API keys, encryption keys, and secrets hard-coded in source code are exposed to everyone with repository access. Use environment variables, secrets managers, or encrypted configuration files. ### Ignoring Encrypted Search If you encrypt a field, you can't search it with standard database queries. This creates a functionality gap. Solutions include: searchable encryption schemes, encrypted indexes, or maintaining a separate search index with hashed values. ## The Performance Question "Doesn't encryption slow things down?" Yes, but less than you think. AES-256 encryption on modern hardware (which has dedicated AES instructions) processes data at gigabytes per second. Encrypting a typical database field adds microseconds — well below the threshold of human perception and usually below the noise floor of network latency. TLS adds roughly 1-3ms per connection for the handshake (amortized over connection pooling). Disk encryption adds 2-5% overhead on I/O operations. Application-level encryption adds microseconds per field. For a web application with 100-500ms response times, encryption overhead is negligible. ## Encryption in Multi-Tenant Platforms Multi-tenant platforms add a dimension: tenant-level encryption. Each tenant's data can be encrypted with a different key, providing cryptographic isolation on top of logical isolation (RLS). Benefits: - A compromised key exposes only one tenant's data - Individual tenants can manage their own keys (customer-managed keys) - Tenant-level key rotation doesn't affect other tenants - Compliance requirements for one tenant don't mandate changes for others ## Evaluating Platform Encryption When evaluating a platform's encryption: 1. **Is TLS enforced?** Does the platform redirect HTTP to HTTPS? Does it use TLS 1.2+ exclusively? 2. **Is data encrypted at rest?** Which encryption algorithm? Who manages the key? 3. **Which fields are encrypted at the application level?** Ask for specifics — "everything is encrypted" usually means only TLS. 4. **How are keys managed?** Where are keys stored? How often are they rotated? Can you provide your own keys? 5. **What happens if a key is compromised?** Is there a key rotation procedure? How long does rotation take? 6. **Are backups encrypted?** With the same keys as live data, or separate backup keys? ## The Minimum Standard For any business platform handling personal or sensitive data: - TLS 1.2+ for all connections (non-negotiable) - Encryption at rest for all storage volumes (standard) - Application-level encryption for credentials, tokens, and PII (recommended) - Key management through a dedicated service (best practice) - Regular key rotation (quarterly minimum) Encryption isn't a competitive feature. It's a baseline security requirement. The question isn't whether to encrypt — it's whether your current platform encrypts thoroughly enough.