Security Overview
This document explains how MediMic.Ai protects your data in plain language. For the full technical and regulatory breakdown, see HIPAA Compliance Details.
The Short Version
- MediMic's own servers never see or store the plaintext words spoken in a session. The stored transcript record is encrypted on your device before it's sent for storage; our servers keep ciphertext only. (Live audio is necessarily processed in the clear, in real time, by our speech-to-text/translation vendor in order to produce the transcript in the first place — see "Where Your Data Lives" below.)
- Each session has its own unique key. Keys are generated randomly and stored in your device's secure hardware store — not on our servers.
- The session key is never sent anywhere — each device derives it independently. Two-device sessions agree on a key using an ephemeral Diffie-Hellman exchange, so only public values cross the network and our servers cannot compute the result.
- We don't sell your data. We are a HIPAA Business Associate — we are legally bound to protect PHI and cannot use it for any purpose other than providing the service.
End-to-End Encryption
What it means: The content of your sessions (speech transcriptions, translations) is encrypted on your device using a key that only your device knows. It is transmitted and stored in encrypted form. No one — including MediMic employees and our cloud infrastructure — can decrypt and read session content.
How it works:
- Each session has its own 256-bit key, held in your device's hardware-backed secure storage (iOS Keychain / Android Keystore).
- All session content is encrypted with AES-256-GCM — an authenticated encryption algorithm that also detects any tampering.
- Encrypted data is what gets sent to MediMic servers for relay and storage.
For Two-Device sessions: both devices need the same key. Rather than transmitting a key, the two devices agree on one:
- Each device generates an ephemeral elliptic-curve key pair (ECDH, P-256) for that session.
- The devices exchange public keys through the session channel.
- Each side combines its own private key with the other's public key to compute an identical shared secret, then runs it through HKDF-SHA256 — salted with the session ID — to produce the AES-256-GCM session key.
The private halves never leave their devices, and the shared secret is never transmitted. An observer relaying the handshake — including our own servers — sees only public keys, from which the session key cannot be derived.
The invite link carries an invite token only (?token=…). That token authenticates the join; it is not the encryption key.
This replaced an earlier design in which the key was passed in the invite link's URL fragment (
#secret=…). Older documentation describing that mechanism is out of date.
Encryption Standards
| Layer | Algorithm | Key Size |
|---|---|---|
| Session transcript records (stored) | AES-256-GCM | 256 bits |
| Key derivation | CSPRNG (OS-level) | 256 bits |
| Data in transit | TLS | Per TLS spec |
AES-256-GCM provides both confidentiality (no one can read it) and integrity (any tampering is detected and rejected).
Where Your Data Lives
| Data | Location | Encrypted? |
|---|---|---|
| Session audio | Not stored by MediMic — streamed to our speech-to-text vendor for live processing, then discarded | In transit only (TLS); the vendor necessarily processes it in the clear to transcribe it |
| Session transcripts (stored record) | MediMic cloud | Yes — end-to-end encrypted, key never reaches our servers |
| Encryption keys | Device only (Keychain/Keystore) | Yes — OS-protected |
| Account credentials | MediMic cloud | N/A — passwordless (magic link / one-time email code); no password is stored |
| Session metadata | MediMic cloud | In transit via TLS; at rest, protected by our access controls |
| Device IDs | Device secure storage + MediMic cloud | Device-side: yes. Server-side: access-controlled |
Audio is not stored by MediMic. Speech is streamed to our speech-to-text vendor, converted to text, and the audio is discarded — MediMic does not retain a copy. Only the resulting encrypted text transcript is retained.
Account Security
- No passwords to steal or reuse — sign-in is passwordless, via a magic link or one-time code sent to your registered email.
- Portal sessions use secure HttpOnly cookies with
SameSite=Strict, protecting against cross-site request forgery and client-side token theft. - Email verification happens implicitly — you can only sign in from an inbox you control.
- Device revocation is available from Account Settings if a device is lost or stolen.
- Session tokens expire — access tokens are short-lived and are reissued from your signed-in session as needed.
- Multi-factor authentication is on our roadmap for both customer and staff accounts; it is not yet available.
HIPAA Compliance
MediMic is built specifically for healthcare. We comply with:
- 45 CFR §164.312 — Technical Safeguards (access control, encryption, audit, integrity, transmission security)
- 45 CFR §164.308 — Administrative Safeguards (policies, training, incident response)
- 45 CFR §164.310 — Physical Safeguards (data center security, workstation controls)
We sign a Business Associate Agreement (BAA) with all Practitioner, Clinic, and Enterprise plan customers. The BAA is a legally binding contract that establishes our obligations as a HIPAA Business Associate.
For the full regulatory mapping, see HIPAA Compliance Details.
Data Retention
| Data Type | Default Retention |
|---|---|
| Session transcripts | 365 days from session end |
| Audit logs | 6 years (HIPAA minimum) |
| Account data | Duration of account + 90 days post-cancellation |
| Push notification tokens | Updated on each app open; removed on revocation |
Enterprise customers can configure custom retention policies.
Incident Response
If MediMic detects a security incident affecting Protected Health Information:
- We will notify affected customers within 60 days of discovery, as required by HIPAA Breach Notification Rule (45 CFR §164.400–414).
- We will provide the nature of the breach, types of PHI involved, steps you should take, and what we are doing to mitigate.
To report a security issue: [email protected]
Infrastructure
- All data remains within the United States.
- Session transcript content is encrypted end-to-end and stored as ciphertext only.
- Access to production systems is restricted to authorized staff, with audit logging of administrative actions.
- Ask your account team for our current infrastructure and subprocessor details as part of your vendor assessment.
What MediMic Cannot Do
Because of end-to-end encryption, MediMic cannot:
- Read the content of any session transcript
- Recover a session transcript if the originating device's key is lost
- Share PHI with law enforcement, advertisers, or any third party (except as required by law and described in our BAA)