Encryption & PKI

In one line

Encryption protects data from someone who has the bytes but not the key. Almost every real health breach involves someone who had a valid key — which is why "we encrypt everything" answers a question nobody was asking.

The three states, and what each buys

In transit — TLS. Non-negotiable, essentially solved, use TLS 1.3, and this genuinely protects you. Someone on the hospital wifi cannot read the FHIR call.

At rest — disk or database encryption. Protects against physical theft: a stolen laptop, a decommissioned drive sold on, a backup tape in a taxi. Real threats, and this is real protection.

But be precise about what it does not do. Your application connects to the database with valid credentials, so the database decrypts for it. An SQL injection, a compromised service account, an over-broad IAM role, or a curious employee all see plaintext. Encryption at rest was never in the path.

Which is why the sentence deserves saying plainly: encryption at rest protects against a stolen disk, not a stolen credential. Most health breaches are the second kind.

In use — the genuinely hard one, because data must be decrypted to be computed on. Homomorphic encryption and secure enclaves attack this and remain niche, slow, or both.

PKI, briefly

Public key infrastructure is the machinery of trust: certificates bind a public key to an identity, certificate authorities vouch for that binding, and a chain lets you verify someone you've never met.

Where it shows up in health:

• TLS certificates — every API call.
• Mutual TLS (mTLS) — both sides prove identity. Common in interface engines and system-to-system health exchange, where there's no user to authenticate.
• Digital signatures on documents — a signed CDA or prescription, where non-repudiation is the point.
• Device certificates — how a monitor proves it's the monitor.

The recurring operational failure is unglamorous: expiry. Certificates expire, and the outage lands at 2am on a public holiday because nobody owned the renewal. Automate it, monitor it, and know that this — not cryptanalysis — is how PKI actually fails.

Key management is the whole thing

The uncomfortable arithmetic: your data is exactly as safe as your keys.

• A key in the source repo is not a key. It's a public string with extra steps.
• A key in the same database it protects is decoration.
• Who can access the key? That list is your real access control, regardless of what your IAM says.
• Rotation — can you actually rotate without downtime? Most can't, discover it during an incident, and then don't.
• Backups — encrypted backups whose key is lost are just noise. Encrypted backups whose key sits beside them are unencrypted backups.

Use a KMS/HSM. Not because it's fashionable, but because it makes the key a thing with an owner, a policy, and an audit trail rather than a secret in an environment variable.

The health-specific reality

Column-level encryption for the most sensitive fields — psychiatric notes, HIV status, genetics — is worth the pain precisely because the threat is an insider with legitimate database access. It's the only encryption that sits between a curious employee and the data.

Encrypt everything at column level and you lose indexing, break search, and gain complexity that produces its own bugs. Choose the fields, deliberately.

And remember the boundary: as with residency, backups, replicas and logs are data too. Encrypting the primary and shipping plaintext logs to a third-party observability vendor is a common, entirely self-inflicted breach.

The honest summary

Encryption is table stakes and it is not a security strategy. It closes one door — the physical one — very well. Everything that actually goes wrong walks in through the front, holding a badge, which is why identity and audit matter more than your cipher suite.