Why Your Patient Portal Needs Per-Tenant Encryption Keys

The Fundamental Problem with Shared Encryption Keys

Most multi-tenant SaaS platforms that store healthcare data begin their encryption journey in the same place: a single application-level encryption key, often stored as an environment variable, used to encrypt every tenant's data in the database. This approach is simple to implement, requires no key management infrastructure, and satisfies a surface-level reading of "we encrypt data at rest." It is also deeply wrong from a security architecture perspective.

The problem is not that the data is unencrypted. The problem is what happens when that single key is compromised. Key material leaks in more ways than most developers anticipate: it can appear in application logs, in deployment configuration files accidentally committed to version control, in infrastructure screenshots shared in support tickets, in memory dumps generated during crash reports, or through insider access by a developer or DevOps engineer who needs it for debugging. A single credential exposure event — the kind that happens routinely to organizations of every size — immediately exposes every patient record on the entire platform.

For a multi-tenant telehealth platform serving dozens of specialty clinics, this is a catastrophic outcome. A breach that touches a single compromised clinic might require notifying a few hundred or a few thousand patients. A breach that exposes the entire platform's data requires notifying every patient of every clinic — potentially tens of thousands of individuals — and triggers HHS investigation for a breach affecting 500 or more individuals per state. The full range of HIPAA technical safeguards that prevent these scenarios is covered in our definitive HIPAA guide for specialty medicine telehealth.

The contrast with per-tenant encryption is stark. If each of those 50 clinics has its own unique encryption key, and one clinic's key is compromised, the attacker can decrypt only that clinic's records. The other 49 clinics' data remains opaque ciphertext. The breach notification obligation is scoped to one clinic's patient population. The regulatory exposure is contained. The other 49 clinics can continue operating without interruption, without notifying their patients, and without being named in an HHS investigation.

Why "database-level encryption" is not sufficient

A common misconception is that enabling full-disk encryption or database-at-rest encryption — the kind provided by cloud database services like Cloud SQL, RDS, or Azure Database — substitutes for application-level per-tenant encryption. It does not, for two important reasons.

First, database-level encryption protects against physical theft of storage media. It does not protect against a compromised application layer. If an attacker gains access to your application server's credentials — which is the far more common attack vector — they can query the database through your application API and receive plaintext records, because your application automatically decrypts data using its credentials before returning it. The database encryption layer is invisible from the application's perspective.

Second, database-level encryption applies a single key (managed by the cloud provider) to the entire database. It provides no isolation between tenants whatsoever. An application-level bug that allows Tenant A to query Tenant B's records will return plaintext Tenant B records whether or not the database disk is encrypted. Application-level per-tenant encryption, by contrast, ensures that even if the query isolation fails, the returned records are still opaque ciphertext that Tenant A cannot decrypt because they do not hold Tenant B's key. The database-level complement to encryption — enforced at the query engine layer — is PostgreSQL row-level security, which prevents cross-tenant queries entirely rather than just making results unreadable. For a complete technical comparison of all encryption approaches, see our guide to field-level vs. full-disk encryption for telehealth.

How Per-Tenant Encryption Works: The Architecture

Per-tenant encryption in a multi-tenant patient portal is most robustly implemented using envelope encryption with cloud KMS-backed key management. This is the same architecture used by Google Cloud, AWS, and Stripe for their own sensitive data storage, and it is the approach LUKE Health uses for all tenant PHI.

Envelope encryption: two layers of keys

Envelope encryption separates the encryption process into two distinct layers:

• Data Encryption Key (DEK): A unique AES-256 key used to encrypt the actual patient records. In a per-tenant model, each tenant has its own DEK (or a small set of DEKs rotated over time). The DEK never leaves the application in plaintext — it is generated once, immediately encrypted, and then only ever exists transiently in application memory during active use.
• Key Encryption Key (KEK): A master key, stored and managed inside a cloud Hardware Security Module (HSM) such as Google Cloud KMS or AWS KMS, used solely to encrypt and decrypt DEKs. The KEK never leaves the HSM. It cannot be extracted. All cryptographic operations using the KEK happen inside the HSM itself.

The encrypted DEK — referred to as the "wrapped" DEK — is stored in the database alongside (or in a key management table) the encrypted records. This means the key material needed to decrypt a tenant's data is protected by both the HSM and the access controls on the KMS, rather than sitting in a plaintext environment variable.

Key derivation for per-tenant keys

Rather than generating a completely independent random DEK for every tenant and managing those as separate KMS keys — which becomes expensive at scale — many well-designed systems use a key derivation function (KDF) approach. A single master secret (stored in the KMS) is used as the root key material. Each tenant's DEK is derived from the master secret combined with a tenant-specific identifier using HKDF (HMAC-based Key Derivation Function), defined in RFC 5869.

This means the derived DEK for Tenant A is cryptographically bound to Tenant A's identifier. Even if an attacker knows the derivation function and the tenant identifier, they cannot compute the DEK without the master secret — which never leaves the KMS HSM. The result is per-tenant key isolation without the need to store and manage dozens of independent key records in the KMS.

In Python, using the cryptography library, a LUKE Health-style key derivation implementation looks like this:

Where keys live in the database

For the envelope encryption approach (distinct DEKs per tenant rather than derived keys), the wrapped DEK is typically stored in a dedicated tenant_keys table, separate from the clinical data tables. This table contains the tenant identifier, the KMS key version used to wrap the DEK, the wrapped (encrypted) DEK bytes, and a creation timestamp. Each row represents one active DEK version for a tenant. During key rotation, a new row is added; old rows are retained until all records encrypted with the old DEK have been re-encrypted with the new one, after which old key rows are archived or deleted.

Critically, the tenant_keys table must itself be access-controlled at the database level. Application service accounts should have read access only, and only for the tenant IDs that correspond to the current request context. Administrative key management operations require a separate, more privileged service account, and every access to the tenant_keys table must be logged to the audit trail.

The Three Approaches: A Direct Comparison

Telehealth SaaS platforms for multi-tenant patient portals generally implement one of three encryption strategies. The table below compares their security properties, compliance posture, and operational characteristics.

Blast Radius: Real Breach Examples Where Shared Keys Failed

The risk of shared encryption keys in multi-tenant systems is not theoretical. Several high-profile healthcare data incidents in recent years involved encryption architectures that, had they implemented per-tenant key isolation, would have produced dramatically smaller breach events.

The database credential leak pattern

One of the most common multi-tenant healthcare breach patterns involves a developer accidentally committing database credentials or an encryption key to a version control system. The repository — often assumed to be private — is discovered by a scanner or made public during a repository migration. Because the single key protects all tenants' data, every patient record on the platform is immediately at risk. The breach notification requirement affects every tenant simultaneously.

With per-tenant encryption, the same credential leak scenario produces a fundamentally different outcome. The leaked database credentials allow an attacker to query the database and retrieve encrypted rows. But without the per-tenant keys — stored separately in the KMS and never committed to version control — the rows are unreadable ciphertext. Unless the attacker also has KMS access, no PHI is exposed. The HIPAA Safe Harbor provision applies, and notification may not be required at all.

The SQL injection to full table dump pattern

SQL injection vulnerabilities in multi-tenant healthcare portals have produced some of the largest single-incident breach events in OCR's enforcement history. A successful injection in a shared-key system allows an attacker to dump entire tables — and since the application decrypts data on read, the injected queries can return plaintext records by exploiting the application's own decryption logic.

Per-tenant encryption provides a meaningful mitigation here as well. If the SQL injection bypasses the application layer and directly accesses the database, the attacker receives encrypted rows. If the injection is within the application layer (for example, accessing another tenant's records through a parameterized query that is improperly scoped), the attacker receives rows encrypted with the victim tenant's key — which the attacker's tenant context cannot decrypt. The isolation is cryptographic, not merely logical.

The terminated employee with key access pattern

Insider threats represent a significant source of HIPAA breaches, particularly in the weeks following employee termination. If an outgoing DevOps engineer or developer copied the application's single encryption key during their tenure, every patient record remains at risk indefinitely until the key is rotated — which, in a shared-key system, requires re-encrypting every row in the database, a potentially disruptive operation that many organizations defer.

Per-tenant encryption changes the calculus here in two ways. First, KMS audit logs record exactly which tenant keys the terminated employee accessed, scoping the investigation to specific tenants rather than the entire platform. Second, key rotation can be performed selectively for only the tenants whose keys were accessible to that employee, rather than requiring a platform-wide re-encryption event.

Key Management Lifecycle: From Provisioning to Rotation

Implementing per-tenant encryption is not only about the initial encryption setup — it requires a well-defined key management lifecycle that covers provisioning, access, monitoring, rotation, and eventual deletion.

Provisioning: when a new clinic joins

• 1
  Create KMS key ring and key for tenant

  In Google Cloud KMS, each tenant gets a key ring scoped to their tenant ID. A primary symmetric key is created with automatic rotation configured (typically 365 days). The key ring and key creation event is logged to Cloud Audit Logs with the tenant ID in the resource labels.

• 2
  Generate and wrap the tenant DEK

  Application generates a cryptographically random 256-bit DEK, immediately wraps it using the tenant's KMS key, and stores the wrapped DEK in the tenant_keys table. The plaintext DEK is discarded. The operation is recorded in the audit trail with the tenant ID, timestamp, and key version used.

• 3
  Bind IAM permissions to tenant key

  The application service account is granted cloudkms.cryptoKeyEncrypterDecrypter role scoped specifically to the tenant's key, not to the entire key ring or project. This means a bug in the application's tenant resolution logic that grants access to the wrong key would fail with a permissions error, not silently succeed.

• 4
  Initialize tenant data partition

  The tenant's first records are written using the newly provisioned DEK. Row-level security policies in PostgreSQL are applied to enforce tenant isolation at the database layer — a defense-in-depth layer that operates independently of the encryption layer.

Rotation: maintaining cryptographic freshness

Key rotation in an envelope encryption system is operationally much lighter than in a direct-encryption system, because rotation does not require re-encrypting every record. The KMS generates a new key version for the tenant's KEK. The application then re-wraps the existing DEKs using the new KEK version and updates the tenant_keys table. The actual patient data rows — encrypted with the DEK, not the KEK — do not need to be touched. Old KEK versions are disabled after re-wrapping is complete.

NIST SP 800-57 recommends cryptoperiods of one year or less for AES-256 symmetric keys protecting sensitive data. For healthcare patient portals, annual KEK rotation is the recommended baseline. DEK rotation is typically triggered by specific events rather than on a fixed schedule:

• Staff member with KMS access is terminated — rotate the keys accessible to that individual
• Suspected key exposure — rotate immediately upon detection, before completing investigation
• Tenant requests rotation — provide self-service rotation as a tenant security control
• Post-incident protocol — rotate all keys touched during or potentially during an incident
• Annual scheduled rotation — baseline requirement regardless of events

Performance Impact: Encryption at Healthcare Scale

The most common objection to per-tenant encryption is performance. Multi-tenant healthcare portals are read-heavy: a provider reviewing a patient's lab history might trigger dozens of database reads per page load. If every read requires a KMS call to decrypt the tenant's key, the latency impact would be unacceptable.

This concern is real but solvable, and the solution is well-established: in-process DEK caching. Once the tenant's DEK has been fetched from the KMS and unwrapped, it is cached in the application process memory for the duration of the request or session — typically 30 seconds to 5 minutes depending on the security requirements. Subsequent reads for the same tenant reuse the cached DEK without any KMS calls. The KMS is only involved when the DEK cache expires or when a new application instance starts without a cached key.

Measured latency in production

In LUKE Health's production environment, the measured latency impact of per-tenant AES-256-GCM encryption with in-process DEK caching is as follows:

• First request per tenant, cold DEK cache: +12–18ms (one KMS API call to unwrap DEK)
• Subsequent requests, warm DEK cache: +1–3ms (AES-256-GCM hardware acceleration only)
• Typical portal page load (10–20 DB reads): +2–8ms total overhead
• KMS API call rate at scale: One call per tenant per 5-minute window per instance — negligible at any realistic scale

The per-record cryptographic overhead of AES-256-GCM is negligible because modern CPUs include dedicated AES-NI instructions that perform symmetric encryption at multiple gigabytes per second. For a patient record of a few kilobytes, the actual encryption or decryption takes microseconds. The only meaningful latency source is the KMS API call to unwrap the DEK — and caching eliminates that overhead for all but the first request per session.

Implementing Per-Tenant Encryption: The Key per tenant_id Pattern

For developers building multi-tenant telehealth platforms, the most important implementation principle is: the tenant_id must be the root of all key derivation and key lookup operations, and it must be established from a server-side trust boundary, never from client-supplied input.

In practice, this means the tenant ID is extracted from the JWT session token — which is signed with a server-side secret and validated on every request — rather than from a URL parameter, a form field, or an HTTP header supplied by the client. A patient cannot change their tenant ID by modifying a request. A provider cannot escalate to another tenant's context by submitting a different tenant identifier. The tenant context is cryptographically bound to the session.

The read path: decrypt on access

In a well-implemented per-tenant encrypted patient portal, the read path works as follows:

1. Request arrives with a signed JWT. The JWT is validated; the tenant ID and user ID are extracted from verified claims.
2. Row-level security policy in PostgreSQL ensures the query can only return rows where tenant_id = current_tenant_id.
3. Encrypted ciphertext rows are returned from the database.
4. The application checks the in-process DEK cache for the tenant's key. If cached and not expired, it proceeds. If not cached, it fetches the wrapped DEK from the tenant_keys table, calls the KMS to unwrap it, and caches the plaintext DEK for the session window.
5. Each ciphertext field is decrypted using AES-256-GCM with the tenant's DEK. The authentication tag is verified. If verification fails, the record is flagged for investigation.
6. Plaintext data is returned to the application layer. The DEK is not written to any persistent storage — it exists only in process memory.

Selecting which fields to encrypt

Not every column in a healthcare database needs to be encrypted at the application layer. Encrypting every field creates unnecessary complexity and makes database-level querying (for example, filtering patients by last visit date) impossible without decrypting first. The practical approach is to identify fields that contain PHI under HIPAA's Safe Harbor definition and encrypt those specifically:

• Always encrypt: names, dates of birth, addresses, phone numbers, email addresses, SSNs, medical record numbers, lab values, diagnosis codes, prescription details, clinical notes, and any free-text fields that could contain identifiable information.
• Generally encrypt: appointment timestamps associated with identified patients, payment information, insurance identifiers.
• May not require encryption: aggregate statistics, de-identified cohort metrics, internal system identifiers (UUIDs) that are not independently meaningful, schema version metadata.

The encryption layer in LUKE Health's platform uses a field-level annotation system where each model field is declared as encrypted or plaintext at the schema level. This means the encryption behavior is consistent across all code paths that touch a given field — there is no possibility of a code path that accidentally writes a PHI field without encrypting it.

Regulatory Advantage: How Per-Tenant Keys Change Your Breach Math

The HIPAA Breach Notification Rule creates a significant operational and financial distinction between a breach that is "unsecured PHI" and one where the Safe Harbor applies. Under 45 CFR §164.402, PHI that has been encrypted in accordance with guidance issued by the Secretary of HHS is excluded from the breach definition — provided the encryption key was not also acquired by the unauthorized person.

This provision rewards precisely the architecture described in this article. If an attacker exfiltrates encrypted rows from your database but does not also obtain the tenant-specific decryption key from your KMS, the HIPAA Safe Harbor applies. You have experienced a security incident but not a reportable breach. You are not required to notify the 500+ individuals whose encrypted records were taken, and you are not required to submit an HHS report that triggers public posting to the "Wall of Shame." For a broader guide to preventing breaches before they occur, see our article on the 7 technical controls every telehealth platform needs.

This regulatory isolation is also important for operational continuity. A shared-key breach effectively shuts down the platform while the incident is investigated, a replacement key is generated, all records are re-encrypted, and all tenants' patients are notified. A per-tenant key incident affects only the compromised tenant — the platform continues operating normally for every other clinic, and the re-encryption scope is limited to one tenant's data.

For multi-tenant telehealth SaaS companies, this isolation property is not just a compliance advantage — it is a commercial one. Tenants evaluating your platform for their clinic's sensitive patient data want assurance that a security incident at another clinic cannot affect their patients. Per-tenant encryption provides that assurance cryptographically, not just as a contractual promise.

Frequently Asked Questions