Encrypted in transit, everywhere
Every connection to Curalis is served over TLS 1.3 only — our reverse proxy is configured to refuse older, weaker TLS versions outright. There is no unencrypted path into the application.
Security & Privacy
Curalis is built for organizations that handle protected health information every day. Here's the real architecture behind that — not badges, not attestations we haven't earned, just how the system works.
Every connection to Curalis is served over TLS 1.3 only — our reverse proxy is configured to refuse older, weaker TLS versions outright. There is no unencrypted path into the application.
Every agency, facility, and family account is a separate tenant, and tenant isolation is enforced by PostgreSQL row-level security policies — not just application code. The app itself connects as curalis_app, a non-superuser role subject to those policies, so a bug in application logic can't reach across tenants.
Two-factor authentication is available on every account — TOTP-based (the same standard used by authenticator apps like Google Authenticator or Authy), and once enabled it's required at every sign-in. Sessions also time out automatically after a period of inactivity.
Access to care records is tracked through a dedicated audit domain, so agencies and facilities can review who viewed or changed a recipient, medication, or schedule record.
Protected health information — medications, care plans, recipient details — is handled as a distinct, sensitive data category throughout the schema and API, not bundled in with general-purpose fields.
Our own development, test, and demo environments never contain real patient data. Automated checks scan the codebase for PHI fields passed into application logs, and every seed and fixture is synthetic.
We won't claim compliance badges we haven't earned. Curalis has not completed a SOC 2, HITRUST, or ISO 27001 audit, and we don't describe ourselves as "HIPAA certified" — because no such certification exists. What we do is build the underlying architecture — tenant-isolated data access, encrypted transport, available two-factor authentication, and audit logging — that supports your organization's own HIPAA compliance obligations, and we describe it to you plainly.
There's no such thing as official "HIPAA certification" — HIPAA does not have a certifying body, and no vendor can be legitimately "HIPAA certified" by a third party. What we can tell you honestly is how Curalis is built to support your HIPAA obligations: row-level tenant isolation at the database layer, TLS 1.3-only transport, available two-factor authentication, audit logging of data access, and a strict synthetic-data-only policy in every non-production environment. We have not undergone a SOC 2, HITRUST, or ISO 27001 audit, and we won't claim otherwise.
Curalis is multi-tenant by design, and tenant isolation is enforced at the database layer using PostgreSQL row-level security policies, not just filtering in application code. The API connects to Postgres as curalis_app, a role with no superuser privileges, so it is itself subject to those RLS policies on every query.
Yes — two-factor authentication via TOTP (time-based one-time codes from an authenticator app) is available on every account, and once you enable it, it's required at every sign-in. Sessions also expire automatically after inactivity.
Data access is recorded through Curalis's audit logging, giving agencies and facilities visibility into who viewed or modified a care recipient's records.
No. We maintain a strict synthetic-data-only policy — tests, fixtures, seeds, and demos never contain real protected health information, and this is checked with automated scans of our own code.
Reach out and we'll walk through the architecture in as much detail as you need.
Contact us