HIPAA Secure Messaging: What Building It Ourselves Actually Cost, and What We Would Buy Instead

At a Glance

Every healthcare organization that needs HIPAA compliant messaging eventually hits the same question: pay a vendor per user, per month, forever, or build the encryption layer yourselves once. We didn't answer that question in the abstract. We built a working prototype, called Sealwax, to find out exactly what "build" actually takes, and we're publishing the honest result: what it cost us in engineering time, what it does well, what it's still missing, and a framework for which path makes sense for your organization.

The Decision Every Healthcare Organization Eventually Faces

Standard email was never built to carry Protected Health Information. Once a message reaches a recipient's inbox, it's stored in plaintext on at least two mail servers, forwarded without your knowledge, and indexed by whatever search tool the recipient's provider runs. For anything that identifies a patient alongside their treatment, that's a standing liability, not a hypothetical one.

Commercial platforms exist specifically to close that gap. Virtru, Paubox, Kiteworks, and Tresorit each offer encrypted email and file delivery with a HIPAA Business Associate Agreement included. They work. The question we wanted to answer honestly, rather than assume, is what it would take to build the same protection ourselves, and whether that's actually the better decision for an organization like ours.

What "Buy" Actually Costs

Commercial secure messaging pricing is genuinely competitive once you're past a few hundred seats. Enterprise buyers in the 100–500 user range typically pay in the region of $6 to $10 per user per month as of 2026, with published list pricing around $79 per user annually for mid-tier plans; volume discounts and multi-year terms often bring larger deployments below $8 per seat. For a 50-person billing or clinical operation, that's roughly $3,600–$6,000 a year, before you've written a line of code, and it comes with a signed BAA, a support contract, and someone else's engineers on call for the next zero-day.

What you're buying beyond the encryption itself: a maintained key infrastructure, a compliance certification you didn't have to earn, and a vendor whose entire business is not getting this wrong. That last part is worth pricing in explicitly , it's not "just" a subscription fee, it's an insurance policy against your own team getting a cryptographic detail wrong in a way that costs far more than a support contract.

The Commercial Field, Named

"Buy" isn't one option, it's several, and they solve slightly different problems:

• Paubox encrypts every outbound email automatically, with no portal login or passcode for the recipient, and falls back to a secure web page only if the recipient's mail server can't handle TLS. It's built for organizations that want encryption to be invisible to the sender and the recipient.
• LuxSci targets higher-volume PHI email, appointment reminders, lab results, and care coordination at scale, and connects via API into EHRs and revenue cycle systems so messages trigger automatically from events elsewhere.
• Virtru offers a private keystore option, letting a large organization host its own encryption keys rather than trusting the vendor with them, at a higher pricing tier.
• Kiteworks and Tresorit lean toward unified governance and audit trails across every channel an organization uses to move sensitive data, not just email.

The right "buy" choice depends on whether your real problem is one-to-one messages (closer to what Sealwax addresses), bulk automated notifications, or governance across many channels at once. Naming these matters because "just buy a secure email tool" isn't a single decision; it's a shortlist with real tradeoffs.

What "Build" Actually Takes

We built Sealwax to find out. It's a working system, not a whitepaper: a FastAPI application in Python, using PyNaCl (the audited binding to libsodium) for every cryptographic operation, with 82 automated tests covering the crypto layer, the data model, the HTTP API, and a full two-party integration scenario.

The architecture follows a pattern called envelope encryption, the same approach commercial platforms use:

• A unique key per message. Every message or file gets its own random 256-bit key. Compromising one key exposes exactly one message, never a mailbox.
• The key, sealed, not the file. That key is encrypted ("sealed") separately to each recipient's public key using Curve25519 and delivered alongside the ciphertext. Only the intended recipient's private key can open it.
• Link-only delivery. The email notification carries a random token, never the message. There's nothing in a forwarded or misdirected notification to expose.
• Deletion that means something. Deleting a message destroys every sealed copy of its key. Because the content only ever existed as ciphertext, destroying the key makes it permanently unreadable , a technique called crypto-shredding, and the only deletion method that survives the fact that overwritten data on modern SSDs isn't reliably gone, a limitation NIST SP 800-88 documents for exactly this reason.

Building this took roughly the effort of one focused engineer-sprint to get the cryptography and core flow working, followed by a comparable amount of time writing the test suite that actually proves it. That ratio is the real lesson: the test suite is larger than the application it covers, and it should be. A security property nobody tested is just an intention.

A Concrete Walkthrough

Here's what actually happens when a clinician sends a patient a billing statement through Sealwax. The clinician composes the message and attaches a PDF. The system generates one random key for that message alone, encrypts the subject, body, and PDF with it, and seals a copy of that key to the patient's public key and a second copy to the clinician's own, so the sender can still re-read what they sent. The patient's email contains a link and nothing else, no visible subject line, no attachment. When the patient signs in, their password unlocks their private key, which unlocks the message key, which decrypts the content in memory for that one view. If the clinician later needs to revoke it, one action destroys every sealed copy of that key, and the ciphertext left behind, wherever it sits, becomes permanently unreadable.

That's the entire mechanism. It sounds involved described this way; to the two humans on either end, it's a compose form and a link.

Where We Landed, Honestly

Sealwax works. All 82 tests pass, including a scenario where two independent users, on separate sessions with separate keys, exchange a message, an attachment, and a reply, and one of them securely deletes it, wiping the sealed keys and confirming the file is gone from disk. That proves the core architecture is sound.

It is not, however, ready to replace a commercial platform today, and we think publishing the gap list is more useful than pretending it doesn't exist:

• No client-side (browser) encryption yet. The server currently handles plaintext briefly during each request. A genuinely "cannot be read by us" system needs that encryption to happen in the browser, using something like libsodium's JavaScript build, before anything reaches the server.
• Session security needs hardening. Our first pass stored a derived credential in a signed-but-not-encrypted session cookie , signed means it can't be tampered with, not that it's hidden from anyone holding the cookie. That's a known, fixable pattern (derive a session key once, discard the password, store the key server-side), but it has to be fixed before this touches real PHI.
• No enforced TLS in the local build, no multi-factor authentication, and no independent penetration test yet , all standard requirements before a HIPAA Security Rule assessment would pass.
• Recipients need a pre-created account. A patient can't yet open a message using just their email address; OAuth or a magic-link fallback is the natural next step.

None of these are architectural problems. They're the standard distance between "the core idea works" and "this is production-hardened," and closing them is a matter of months, not a redesign.

The Real Total Cost of Ownership

The sticker price of "buy" is easy to see. The full cost of "build" is easy to underestimate, and we'd rather show our own numbers than wave at the idea:

• Initial build: roughly 2,000 lines of application code and 1,200 lines of tests for a working MVP with one sender/recipient model, no client-side crypto, and no compliance certification.
• To reach what a commercial vendor already provides today, you're adding: client-side encryption, multi-factor authentication, TLS everywhere, an independent penetration test, a documented HIPAA risk analysis, and ongoing key-rotation and patch management , each with its own timeline and cost, and none of it optional if PHI is actually going to move through the system.
• The ongoing cost doesn't stop at launch. Every CVE in your dependency chain is now your team's problem to triage, not a vendor's. Healthcare is the costliest industry for data breaches globally, averaging $6.64 million per incident in 2026, and a breach that traces back to your own homegrown security layer is a materially worse conversation with a regulator than one traced to a certified vendor's platform.

That's not an argument against building. It's an argument for building with your eyes open about what "done" actually includes.

It's also worth pricing the alternative correctly. Healthcare data breaches average $6.64 million globally in 2026, but the more instructive number for a mid-sized organization is what IBM's research has found specifically about third-party involvement: a breach that originates with a vendor rather than the organization itself adds a substantial premium to the final cost, precisely because accountability and forensics get harder to untangle across two organizations instead of one. Building in-house doesn't remove that risk. It just means the accountability, and the premium if something goes wrong, stays entirely with you.

A Third Path: Custom Integration With Private AI

There's a middle option between "buy a certified platform" and "build the encryption layer from scratch," and it's the one getting real attention in 2026: keep a commercial or custom encrypted-delivery layer, but add intelligence around it using an AI model your organization hosts and controls, rather than a public API that sees your plaintext.

The distinction matters more here than almost anywhere else. The entire point of encrypting a patient statement is that nobody outside the intended recipient can read it. Piping that same document's content through a public AI API for "smart" classification or summarization defeats that guarantee just as thoroughly as sending it over unencrypted email, since the plaintext now sits on a third party's servers regardless of what happens to the message afterward. Enterprise AI redaction and classification tools have converged on the same answer: run the model in a private cloud, on-premises, or air-gapped deployment so PHI never leaves your infrastructure by design, rather than trusting a vendor's data-handling policy after the fact.

Concretely, for a healthcare organization, this looks like:

• AI-assisted PHI detection before encryption. Automated tools can now flag over 50 types of PHI, names, diagnoses, addresses, Social Security numbers, in an uploaded document before it's encrypted and sent, catching content a human reviewer might miss in a large attachment.
• Anomaly detection on the access log. Because every view and download is already logged, a model trained on normal access patterns can flag the unusual one, an account downloading every attachment in an inbox at 3 a.m., for instance, far faster than a human reviewing logs manually.
• A self-hosted model, not a SaaS subscription to a public one. The hardware requirement is smaller than the phrase suggests. From our directory of 24 openly licensed models, with VRAM measured at 4-bit and 8-bit quantisation, PHI detection and retrieval over your own documents runs in about 0.5 GB, a guardrail model in about 2 GB, and a provenance-focused model such as IBM Granite 4.2 8B in about 5 GB. Rented, that whole stack is one 24 GB instance at roughly $0.71 an hour on a Google Cloud g2-standard-4, or about EUR 214 a month for a dedicated Hetzner GEX45 in EU datacentres, which is the cheaper shape once utilisation passes roughly 30%.

This path doesn't replace the buy-vs-build decision above; it sits on top of either one. A commercial platform with this layer added gets smarter without changing your compliance posture. A custom build like Sealwax gets the same benefit, and because every cryptographic operation already lives in one small, auditable module, adding an AI layer that only ever touches ciphertext until the moment of authorized decryption is a contained change, not a redesign.

How This Sits Against Our Other Healthcare Work

The same architecture turned out to apply well beyond healthcare, which we worked through separately in secure document delivery software across six regulated industries: law, accounting, title and escrow, wealth management and HR all converge on the identical four properties, each for a different regulator.

This prototype is also one half of a pattern we have now built both sides of. The harder half, getting data out of a system that was never designed to release it, is documented in our legacy EHR extraction case study, where a full patient registry came out of a clinical system with no export function, no API and no data portability menu, against an industry backdrop where roughly 75% of data migration projects fail outright (Bloor Research).

For the private-model side of this decision, our directory of 24 openly licensed models records VRAM measured at 4-bit and 8-bit quantisation alongside named cloud instances and their memory bandwidth. A practice-scale stack is smaller than most expect: retrieval over your own clinical documents in about 0.5 GB, transcription in about 1 GB, a guardrail model in about 2 GB, and a provenance-focused model such as IBM Granite 4.2 8B in about 5 GB. One 24 GB instance covers all of it, at roughly $0.71/hr on Google Cloud or EUR 214/month on a dedicated Hetzner box in EU datacentres.

The wider comparison is in private AI for medical practices and cloud AI vs local AI for medical practices. For what a regulator actually expects around the software, see AI automation under UK GDPR and HIPAA.

A Framework: When Build Wins, When Buy Wins, When to Add AI

Buy makes more sense when:

• You need a signed BAA and SOC 2 attestation now, not in six months
• Your team doesn't have dedicated security engineering capacity to maintain a custom system indefinitely
• Your volume is small enough that per-seat pricing is genuinely cheaper than the engineering time to build and maintain an equivalent

Build makes more sense when:

• You're operating at a scale where per-seat SaaS pricing compounds into a real budget line, and you have engineers who can own it long-term
• You need deployment flexibility a commercial platform doesn't offer, such as on-premises key custody or integration deep inside a proprietary EHR workflow
• Understanding exactly where every key lives is itself a requirement, not a nice-to-have, for your specific regulatory posture

Adding a private AI layer makes sense when:

• You're already processing enough volume, roughly 50,000+ monthly queries or 2 million-plus tokens a day, that self-hosting reaches cost parity with API calls within a few months
• Manual review of attachments or access logs has become the actual bottleneck, not the encryption itself
• Sending document content to any third-party AI service, even a compliant one, is a non-starter for your risk tolerance

Most organizations land somewhere in between: buy the certified platform for now, treat a project like Sealwax as a way to genuinely understand what you're buying, and add a private AI layer only once volume justifies the infrastructure it requires.

Compliance Snapshot

We mapped Sealwax against both the HIPAA Security Rule and GDPR before drawing any conclusions about where it stands.

Already provided by the architecture:

• Encryption at rest for all message content, with private keys never stored in plaintext
• Unique user identification and authenticated encryption (tampering is detected, not silently accepted)
• An audit log of every send, view, and download
• Data minimisation , only an email address, a password hash, and a keypair per user

Still required before a real compliance assessment would pass: TLS enforcement, multi-factor authentication, a documented risk analysis, a Business Associate Agreement template, breach notification procedures, and an independent security audit. Both frameworks are explicit that compliance is never a property of code alone , it also requires the organisational safeguards that sit around the software.

If You're Facing This Decision Yourself

If your organization is weighing the same build-vs-buy question, five questions are worth answering before you commit either way:

1. Does your volume actually justify the engineering cost of building? Run the real numbers, not just the sticker price of a subscription.
2. Do you have engineers who'll still be maintaining this in three years? A security system with no owner degrades faster than one that was never built.
3. What does your BAA and audit timeline actually require, and by when? Buying gets you there faster if a deadline is close.
4. Where do you need the keys to live? If deployment flexibility or key custody is a hard requirement, that tilts toward building.
5. What would an independent auditor say about what you have today? Get that answer before you decide, not after.

If you're evaluating this build-vs-buy decision for your own organization, or want a second opinion on a system you're already building, we'd welcome the conversation.

If You Want This Built Rather Than Prototyped

A scoped secure-delivery workflow into an EHR or practice management system with a documented API runs $5,000 to $15,000. A multi-system build, including the identity and access work a HIPAA assessment expects around it, runs $15,000 to $50,000. The full pricing logic is in our AI automation cost guide, and the entry tier in what $5,000 actually buys.

Delivery sits under our healthcare AI development service, with AI consulting for the build-versus-buy decision itself. Tiers are on the pricing page.

If the honest answer is that you should buy rather than build, we will say so on the first call. The AI readiness score gives you that read in ten questions before any conversation, and the automation quote generator prices the build if you decide to go ahead.

Frequently Asked Questions

Is Sealwax ready to handle real patient data today?

No. It's a working proof of concept that passes 82 automated tests, but it hasn't been through an independent security audit, doesn't yet enforce TLS, and doesn't have multi-factor authentication. We're publishing exactly where it stands, gaps included, rather than overstating it.

How does Sealwax compare to Virtru or similar platforms?

The core architecture is the same idea: encrypt once, deliver a link instead of the file, and give the sender control after sending. Commercial platforms add years of hardening, a signed BAA, SOC 2 certification, and a support organization on top of that same core idea , which is exactly what "build" has to account for before it's a fair comparison.

What does it actually cost to build something like this?

For us, roughly one engineering sprint for the core encryption flow and comparable time again for a genuine test suite. Reaching commercial-grade readiness, meaning client-side encryption, MFA, TLS, an audit, and compliance documentation, is a materially larger and ongoing investment, not a one-time cost.

Why does the test suite matter this much?

Because an untested security property is only an intention. Our tests inspect what's actually stored on disk and in the database, not just what the code claims to do, including scenarios where a third party tries to access a message they were never sent.

What's the single biggest risk in building this yourself?

Underestimating everything outside the cryptography itself: session handling, key recovery, account onboarding, and the administrative controls a regulator expects. The encryption is the well-understood part. Everything around it is where projects like this usually go wrong.

Does building in-house mean you avoid compliance costs entirely?

No. It shifts who owns them. A commercial vendor's subscription bundles their compliance certification into the price. Building means you own the risk analysis, the BAA process, and the audit, on your own timeline and budget.

Is it safe to use AI to help manage encrypted patient documents?

Only if the model runs somewhere the plaintext never leaves your control, a private cloud, on-premises, or air-gapped deployment. Sending document content to a public AI API defeats the purpose of encrypting it in the first place, regardless of what happens to the message afterward. Self-hosted, open-weight models have matured enough by 2026 to make this a realistic option rather than a research project.