Security & Encryption

All video and audio calls on TelePortUs are protected with AES-256-GCM end-to-end encryption (E2EE) via LiveKit's built-in E2EE framework. Each session uses a unique per-session key generated by our server, delivered to participants only over authenticated channels (the provider's authenticated session, or the patient's verified LiveKit token), stored encrypted at rest, and destroyed when the session ends. This means a leaked key can never decrypt other sessions — and because the key is never embedded in the client bundle or URLs, it cannot be scraped from the browser. Even TelePortUs cannot decrypt your consultations.

Your calls are protected by five layers of encryption: Layer 1 — WebRTC DTLS-SRTP (AES-128) provides transport-level encryption for media streams. Layer 2 — LiveKit E2EE (AES-256-GCM) adds participant-to-participant encryption that our servers cannot decrypt. Layer 3 — TLS 1.3 encrypts all HTTPS traffic between browsers and our infrastructure. Layer 4 — AES-256-GCM encrypts all personal health information at rest, including shared files. Layer 5 — a SHA-256 hash-chained immutable audit log provides tamper-evident records of all access. This defense-in-depth approach ensures your consultations are private at every level.

All communication between your browser and our servers is protected by TLS 1.3, the latest and most secure version of the TLS protocol. This protects all API calls, authentication data, signaling messages, and page content from eavesdropping or tampering. We enforce HTTPS across all endpoints and maintain an A+ TLS rating.

Personal health information stored in PostgreSQL is encrypted at rest at the application layer using AES-256-GCM (each field encrypted with a unique initialization vector and authentication tag). This includes health numbers, clinical notes, consent documents, shared files, and calendar connection tokens. The encryption key is stored separately from the data it protects, in server-side environment secrets. Database backups inherit this protection and are additionally encrypted. We employ strict access controls to the database layer, with network isolation and least-privilege policies.

We use NextAuth.js v5 with credential-based authentication. Passwords are hashed with bcryptjs (12 rounds). Two-factor authentication (TOTP — Google Authenticator, Authy, 1Password) is being rolled out as a fully verified feature; until it is released, providers should use strong unique passwords. Role-based access control (RBAC) ensures providers can only access their own patients' information. Session tokens expire after 30 minutes of inactivity (sliding renewal), and an auto-lock feature (configurable 1–30 minutes) secures inactive sessions. All authentication attempts are logged in our immutable audit trail.

TelePortUs is designed from the ground up for Canadian privacy law: PHIPA (Ontario), PIPA (Alberta and British Columbia), The Health Information Act (Saskatchewan), PHIA (Manitoba), Law 25 (Quebec), and PIPEDA (Federal and the remaining provinces and territories). We maintain data-processing agreements with all service providers. Our compliance posture is documented on this page and in our Privacy, Terms, and Data Retention policies; a per-province compliance matrix is published as part of our ongoing compliance program.

All patient data is stored exclusively on servers in Toronto, Canada (Fly.io yyz region). Video and audio are routed through our Canadian-hosted LiveKit Selective Forwarding Unit (SFU). Data never leaves Canada. This is a core architectural requirement, not an afterthought — we maintain Canadian data residency by design.

Every access to personal health information is recorded in an immutable audit log. Each entry captures: who accessed the data, what action was taken, which resource was affected, the timestamp, the IP address, and the user agent. Audit logs cannot be modified or deleted — they provide a permanent, verifiable record of all PHI access for compliance and security monitoring.

Sessions expire after 30 minutes of inactivity with sliding renewal (5-minute refresh window), and an auto-lock feature can be configured from 1 to 30 minutes (or disabled). Sessions end when the user logs out or closes the browser. All sessions use HTTP-only, secure, SameSite cookies to prevent cross-site request forgery (CSRF) and cross-site scripting (XSS) attacks.

Our application runs in isolated Docker containers with least-privilege user accounts (non-root). Regular security updates are applied automatically. The database is network-isolated from the public internet. LiveKit runs as a separate service with its own authentication. All infrastructure is monitored with automated alerting for suspicious activity, and our automated bug-hunter pipeline scans for security regressions (rate-limit coverage, input validation, header configuration) on every release.

Files exchanged during a call travel over the end-to-end encrypted data channel and are encrypted at rest with AES-256-GCM when stored. At the end of the retention period (default maximum 90 days), files are securely shredded: the stored bytes are overwritten with random data before the record is deleted, and every shred is logged to the immutable audit trail. Providers and patients may request on-demand shredding of their files at any time.