Encryption Policy
Last updated: April 5, 2026
This policy describes the encryption standards and practices used by M&R Edge Studio (operated by Michelle & Rich Essence Ltd) to protect user data at rest, in transit, and during processing.
1. Encryption in Transit
- TLS 1.2 / 1.3 — All communication between users and our platform is encrypted using Transport Layer Security. We enforce HTTPS on all endpoints with no fallback to HTTP.
- HSTS — HTTP Strict Transport Security headers are enabled to prevent protocol downgrade attacks.
- Certificate management — SSL/TLS certificates are managed by Cloudflare with automatic renewal and pinning.
- API communications — All calls to third-party APIs (Meta, TikTok, Stripe, ElevenLabs) use TLS-encrypted connections.
- Webhook payloads — Incoming webhooks are verified using cryptographic signatures (HMAC-SHA256) before processing.
2. Encryption at Rest
- Database encryption — All database storage uses AES-256 encryption at the volume level, managed by our infrastructure provider (SOC2 Type II compliant).
- OAuth token encryption — Social platform tokens are additionally encrypted at the application level using AES-256-GCM with unique initialisation vectors (IVs) per record before storage.
- File storage — All uploaded media (images, audio, video) in storage buckets is encrypted at rest using AES-256.
- Backups — Database backups are encrypted using the same AES-256 standard and stored in geographically separate, access-controlled locations.
- Secrets vault — API keys and service credentials are stored in an encrypted vault with access restricted to authorised server-side functions only.
3. Application-Level Encryption
Beyond infrastructure encryption, we implement additional layers:
- Token encryption module — A dedicated cryptographic module handles encryption/decryption of sensitive tokens using the Web Crypto API with AES-256-GCM.
- Key derivation — Encryption keys are derived using secure key derivation functions and are never hardcoded in source code.
- Initialisation vectors — Each encrypted record uses a unique, cryptographically random IV to prevent pattern analysis.
- Password hashing — User passwords are hashed using bcrypt with a minimum cost factor of 10. Plaintext passwords are never stored or logged.
- HIBP check — Passwords are checked against the Have I Been Pwned database during signup to prevent use of compromised credentials.
4. Key Management
- Separation of concerns — Encryption keys are stored separately from the data they protect
- Access control — Only authorised backend functions can access encryption keys; client-side code has zero access
- Rotation — Encryption keys are subject to periodic rotation with backward-compatible decryption
- Audit trail — All key access and rotation events are logged for compliance monitoring
5. Compliance & Standards
- Our encryption practices align with UK GDPR Article 32 requirements for appropriate technical measures
- Infrastructure provider maintains SOC2 Type II compliance
- We follow OWASP cryptographic storage guidelines
- Payment data is handled by PCI DSS-compliant processors (Stripe, Paystack) — we never store card details
- We comply with Nigeria's NDPA requirements for adequate data security measures
For questions about our encryption practices, contact security@mredgestudios.com.
© 2026 Michelle & Rich Essence Ltd. All rights reserved.