A client rang me on a Thursday afternoon in late 2023 — fintech-turned-healthtech pivot, they'd just hired a compliance consultant who'd looked at their Next.js codebase and handed back a three-page list of problems. "We thought putting it on AWS was enough," the founder said. He genuinely believed that. And honestly? I'd heard that same sentence from probably six different teams before his.
HIPAA compliance is one of those areas where everyonethinksthey understand the surface — sign a BAA, pick a compliant cloud provider, done. But theHIPAA Security Ruledoesn't care about your hosting provider's marketing page. It cares about how your application handles, stores, transmits, and audits Protected Health Information (PHI). Next.js — as a framework — is neither compliant nor non-compliant out of the box. What you build on top of it is everything.
So let me walk you through what actually counts in 2026, based on real architectures I've built and real mistakes I've watched teams make.
---
What "HIPAA-Compliant Next.js" Actually Means
People confuse infrastructure compliance with application compliance. These are not the same thing.
Your cloud provider (AWS, GCP, Azure — pick one) can sign a Business Associate Agreement with you. That's a legal document establishing they'll protect PHI on their infrastructure according to HIPAA rules. AWS has aHIPAA-eligible services listthat's worth bookmarking. But a BAA from AWS doesn't mean your Next.js app is compliant. Not even close.
The application layer isyourresponsibility. Always. The framework is just a vehicle.
Here's the thing — Next.js 14+ (and into 2026, the App Router is fully mature) gives you server components, server actions, middleware, and edge functions. Every single one of those has different PHI-handling implications. A server component that queries a patient database and passes data down to a client component — where does that data live? How long? Does it end up in a browser cache? These aren't hypothetical concerns.
---
The PHI Surface Area Problem
Before writing a line of code, I make every health-tech client do one exercise: map every place PHI could possibly touch the application. Not where itshouldtouch it. Where itcould.
That includes:
- URL parameters (I've seen patient IDs in query strings — don't)
- Browser
localStorageandsessionStorage - Client-side state management (Zustand stores, Redux, even React context)
- Next.js fetch cache and the Data Cache layer
- Log output from
console.logduring development that sneaks into production - Error tracking tools like Sentry (more on this shortly)
- Analytics pipelines — GA4, Segment, Amplitude
The last two trip up more teams than almost anything else. Back in early 2024, Seahawk had a telehealth client who'd wired up Sentry for error monitoring. Standard move. Except their error boundaries were capturing the full props object on crash — which included appointment details and user health flags. Sentry wasn't covered under their BAA. That's a breach waiting to happen.
Sanitising Your Error Tracking
If you're using Sentry with PHI-adjacent code, use thebeforeSendhook to scrub sensitive fields before they leave the browser. Full stop. Something like this is non-negotiable:
``beforeSend(event) { if (event.user) { delete event.user.email; delete event.user.ip_address; } return event; }``
Sentry does have aHIPAA compliance path— they'll sign a BAA — but you still need to configure what data you send them. The BAA doesn't sanitise your payloads automatically.
---
Authentication and Session Handling
This is where I see the most shortcuts. Teams reach for NextAuth.js (now Auth.js), wire up a provider, and call it done. Auth.js is a solid library. But the defaults are not HIPAA defaults.
A few specifics:
- Session token storage— Auth.js defaults to a cookie-based session, which is fine, but you need
httpOnly,secure, andsameSite: 'strict'explicitly set. Don't assume. - Session expiry— HIPAA's Automatic Logoff standard (§164.312(a)(2)(iii)) requires that sessions terminate after a defined period of inactivity. The number isn't prescribed, but 15 minutes is the industry standard for clinical applications. Wire up an inactivity timer in your layout. I usually build this as a custom hook that fires a server action to invalidate the session.
- MFA— Not strictly mandated by HIPAA's text, but try explaining to an OCR auditor why you didn't implement it after a breach. Use TOTP via something like
otplibor lean on an identity provider like Auth0 or Clerk that has MFA baked in and will sign a BAA. - Audit logging of auth events— Every login, failed login, and logout needs to be logged with a timestamp and user identifier. Every single one.
I'm not going to tell you Auth.js is wrong for this use case — I've shipped it in production on HIPAA projects. But you have to layer the compliance requirements on top deliberately.
---
Data in Transit and at Rest
Transit is the easy part. TLS 1.2 minimum, TLS 1.3 preferred, everywhere. Not just your main domain — your API routes, your edge functions, any webhooks. If you're on Vercel, this is handled. If you're self-hosting on EC2 or running Next.js in a Docker container behind an NGINX reverse proxy, you need to configure this yourself. I've reviewed codebases where the internal service-to-service calls were still on HTTP because "it's inside the VPC." That's not an acceptable position.
At rest is harder. A few specifics that matter:
- Database encryption— AWS RDS with encryption enabled (uses AES-256 via AWS KMS). This is a checkbox, but you need to actually check it and document it.
- Field-level encryption for highly sensitive data— For things like SSNs, diagnoses, or medication lists, I often add a second layer of encryption at the application level using a library like
@aws-sdk/client-kmsto wrap/unwrap keys. Overhead is real, but so is the risk. - Next.js Data Cache— This one catches people out. The App Router caches fetch responses by default. If you're fetching patient data in a server component with
fetch(), you need{ cache: 'no-store' }unless you're very deliberately managing revalidation. A cached response containing PHI sitting in the server's memory or filesystem is a problem. - Backups— Encrypted. Tested. Documented. Obvious, but I've audited systems where the backups existed but had never been restored once.
---
Audit Logging: The Part Nobody Wants to Build
Here's something I'll say plainly — audit logging is the most boring and most important thing you'll build in a health-tech app. Every access to PHI needs to be recorded. Not just writes. Reads too.
TheHIPAA Audit Controls standard(§164.312(b)) requires "hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use ePHI." What that means practically: you need an append-only log of who accessed what patient data, when, and from where.
I build this as a middleware layer in Next.js. For App Router projects, I'll intercept inmiddleware.tsfor route-level logging and add a thin service wrapper around any database query function that touches PHI tables. The log records get written to a separate database table (or a service like AWS CloudTrail if you want immutability guarantees) — never the same table as the PHI itself.
A minimal audit record looks like this:
user_id— whoresource_type+resource_id— whataction— read / write / deleteip_address— where (anonymised at the network layer is fine)timestamp(UTC, always UTC)request_id— to correlate with your application logs
Do not let developers addconsole.log(patientRecord)and call it an audit trail. I've seen this. It's not.
---
Choosing Your Infrastructure Stack
The honest answer is that in 2026 there are a handful of stacks I'd actually recommend for a production HIPAA Next.js application.
Vercel + PlanetScale/Neon + Clerkis the developer-experience stack. Vercel will sign a BAA (enterprise plan — yes, it costs money). PlanetScale and Neon both have HIPAA-eligible tiers. Clerk handles auth and will sign a BAA. This is fast to ship and reasonable to operate. The tradeoff is cost at scale and some loss of infrastructure control.
AWS (ECS/EKS for the Next.js app) + RDS Aurora + Cognitois the enterprise stack. More operational overhead. Much more control. AWS's shared responsibility model is well-documented and the BAA coverage is broad. If your client is a hospital system or an insurer, they're probably going to ask about your AWS architecture in detail.
Render or Railway— I'd steer clear for anything seriously regulated. They're great tools, but their HIPAA compliance story is thin.
One thing I want to flag: Vercel's Edge Network and Edge Functions arenotHIPAA-covered under their BAA as of early 2026. If you're running logic that touches PHI in edge middleware, that's a gap. Run that logic in serverless functions (Node.js runtime) instead.
---
Third-Party Integrations: Where Compliance Goes to Die
Every third-party you integrate with that touches PHI needs a BAA. That sounds obvious. Here's the list that actually trips teams up:
- Customer support tools (Intercom, Zendesk) — if a patient messages about their health, that's PHI in your support platform
- Form tools (Typeform, Jotform) — patient intake forms are PHI
- Email providers (SendGrid, Postmark) — if the email body contains health info, BAA required
- Feature flag tools (LaunchDarkly, Statsig) — usually fine, but if you're passing user attributes that include health status to evaluate flags, that's PHI
- CRMs (HubSpot, Salesforce) — many healthtech teams sync patient data into these without thinking
Postmark will sign a BAA. SendGrid (via Twilio) will too, on paid plans. Twilio for SMS as well. LaunchDarkly has a BAA path. These aren't obscure options — the BAA process is usually a form submission and a few business days.
The ones that won't or can't sign a BAA? Don't integrate them anywhere near PHI. Simple as that.
---
FAQ
Does deploying on Vercel make my Next.js app HIPAA-compliant?
No. Vercel can sign a Business Associate Agreement on their enterprise plan, which means they take on certain HIPAA obligations for the infrastructure they control. But your application code, your database design, your logging, your third-party integrations — none of that is covered by Vercel's BAA. Compliance is shared across every layer of the stack, and the application layer is your responsibility.
Do I need to encrypt data in a Next.js API route before sending it to the client?
TLS handles encryption in transit, so you don't need to manually encrypt the HTTP response body. What you do need to do is make sure you're only returning the minimum necessary PHI for the operation — not full patient records when you only need a name, for instance. The "minimum necessary" principle is baked into HIPAA and it should shape your API response design from day one.
Is the Next.js App Router's built-in caching safe for PHI?
Not by default. The Data Cache and Full Route Cache in the App Router can cache responses that contain PHI, which is problematic. For any route or fetch call that touches patient data, use{ cache: 'no-store' }on fetch calls and addexport const dynamic = 'force-dynamic'to route segments. Review Vercel'scaching documentationcarefully — it's dense but important.
What's the minimum logging I need for a HIPAA audit trail?
At minimum: who accessed what, when, and from where. That's user ID, resource identifier, action type, timestamp, and IP address. Logs need to be tamper-evident (append-only, not editable by application code) and retained — most compliance frameworks suggest six years, which matches HIPAA's documentation retention requirement.
Can I use React Query or SWR for data fetching in a HIPAA app?
Yes, but with care. Both libraries cache responses client-side, which means PHI can sit in the browser's memory. SetstaleTime: 0andcacheTime: 0(React Query) ordedupingInterval: 0(SWR) for queries that return PHI. Also clear the query cache on logout explicitly — don't rely on component unmounting to handle this.
---
I want to be honest about something: HIPAA compliance is genuinely hard to get right, and no framework — Next.js or otherwise — makes it easy. The teams I've seen do it well are the ones who treat it as an architecture problem from day one, not a checklist to run through before launch. The framework is fine. The gaps are almost always in the decisions made around it.
Start with the PHI surface area mapping. Everything else follows from that.