Authio docs

Concepts

HIPAA

Authio supports HIPAA-grade authentication. We are a Business Associate when our customer is a Covered Entity. Here is exactly what we provide, what stays on your side, and how to engage.

Short version. Authio does not process clinical PHI. We process authentication metadata that may be classified as PHI when it is associated with PHI access. We safeguard that metadata to HIPAA Security Rule standards — AES-256 at rest, TLS 1.2+ in transit, immutable audit logging for 7 years, BAA-bound sub-processors only. Engage security@authio.com to request a BAA.

The split of responsibilities

HIPAA imposes obligations on Covered Entities (you, the provider, payer, or clearinghouse) and on Business Associates (Authio, when we handle PHI on your behalf). The Security Rule (45 CFR §§164.302-318) breaks the obligations into administrative, physical, and technical safeguards. Authio handles the technical safeguards within our authentication platform and passes through the physical safeguards inherited from AWS. You retain your obligations for the rest of your system.

What Authio provides

§164.312(a) Access Control

  • Unique user identification. Every user gets an opaque users.id; every API request is bound to an authenticated principal.
  • Emergency access. Break-glass procedure in the operator runbook; pre-configured emergency operators with passkeys + recovery codes.
  • Automatic logoff. Per-organization session timeout policy (org_policies.session_idle_timeout_min and session_absolute_max_min). For HIPAA we recommend 15-minute idle / 24-hour absolute timeouts; you configure these per organization via the dashboard.
  • Encryption / decryption. AES-256 at rest on managed Postgres; envelope encryption for high-blast secrets; KMS-managed signing keys.

§164.312(b) Audit Controls

  • Comprehensive audit log. Every consequential identity event lands in audit_events: logins, MFA challenges, session creation, organisation changes, impersonation, DSR fulfillment, admin operations.
  • Immutability. Audit-event mutation is denied at the database row-level via RLS policies. UPDATE / DELETE require a dedicated cleanup role that the regular application connection cannot enter.
  • 7-year tamper-evident archive. Every event is also written to an S3 bucket with Object Lock in COMPLIANCE mode. The retention is 2555 days (7 years) and cannot be shortened by anyone — including Authio's own root account.
  • Customer-side streaming. Forward your audit stream to your own SIEM via audit streams.

§164.312(c) Integrity

  • Audit-trail-based integrity controls. Every PHI-adjacent mutation produces an audit row with actor + before/after. The audit row is itself immutable (above), so tampering with application data is detectable.
  • Roadmap: per-row hash chain on the audit-events table is the Phase 2 strengthening of the integrity property (Q4 2026 target).

§164.312(d) Authentication

  • Passkey-first. WebAuthn / FIDO2 is the recommended primary credential — phishing-resistant by design.
  • SSO. SAML 2.0 and OIDC for enterprise IdP federation. SCIM 2.0 for directory-driven lifecycle.
  • Mandatory MFA. org_policies.require_mfa enforces step-up on every session-create. require_passkey raises the bar (TOTP and SMS do not satisfy).
  • Risk-based step-up. Adaptive risk engine scores every sign-in; high-risk attempts get step-up before the JWT is minted.

§164.312(e) Transmission Security

  • TLS 1.2+ at the edge with HSTS preload.
  • mTLS between internal Authio services.
  • DKIM + SPF + DMARC on all outbound email.
  • HMAC-signed webhooks (SHA-256) with rotating per-endpoint secrets.

What stays on your side

  • Your own HIPAA Risk Analysis. Authio's risk analysis covers Authio's scope. Your full system analysis is yours.
  • Your application data and clinical PHI. Authio does not ingest medical records, treatment notes, diagnoses, or any clinical data. Your EHR, your obligation.
  • BAAs with your other vendors. Each Business Associate you engage signs a separate BAA. Authio's BAA is one of them.
  • §164.404 patient and HHS notifications. If a breach occurs, Authio (as your BA) notifies you within 5 business days; you then notify the affected individuals and (where applicable, 500+ individuals) HHS and the media. Authio supplies the evidence for your filings.
  • Patient-facing DSR intake. Patients send their access / amendment / accounting requests to you. You forward the Authio-side portion to us via the admin API.
  • Workforce training. Your staff training, background checks, and sanction policies are yours.

Subject access requests (§164.524 / §164.526 / §164.528)

When a patient submits an access, amendment, or accounting request to your support team, you fulfill the Authio-side portion via the admin DSR endpoints (admin api-key required; the customer-facing DSR surface at /v1/compliance/dsr is the GDPR / CCPA / general intake).

§164.524 — access (export)

curl -X POST \
  -H "Authorization: Bearer sk_live_<admin_project_key>" \
  -H "Content-Type: application/json" \
  -d '{"requested_by": "alice@hospital.org",
       "notes": "Patient request 2026-05-21"}' \
  https://api.authio.com/v1/admin/users/<user_id>/dsr/export

Returns a JSON bundle of every Authio-side artifact tied to the user: account row, identities, memberships, sessions, audit events, risk decisions, recovery requests. Combine with your own clinical export and deliver to the patient.

§164.526 — amend

curl -X POST \
  -H "Authorization: Bearer sk_live_<admin_project_key>" \
  -H "Content-Type: application/json" \
  -d '{"field": "email",
       "new_value": "patient-new@example.com",
       "reason": "§164.526 patient request 2026-05-21"}' \
  https://api.authio.com/v1/admin/users/<user_id>/dsr/amend

We can amend email, name, and phone (phone goes via the identities surface). Historical audit rows are not amendable — per §164.526(d) we attach a statement of disagreement instead.

§164.528 — accounting of disclosures

curl -H "Authorization: Bearer sk_live_<admin_project_key>" \
  https://api.authio.com/v1/admin/users/<user_id>/dsr/accounting

Returns every audit event over the trailing 6 years that constitutes a disclosure under §164.528. The default disclosure action list excludes the patient's own access per §164.528(a)(1)(i). Customize via AUTHIO_HIPAA_DISCLOSURE_ACTIONS if your interpretation differs.

Breach response

If Authio detects (or you report to us) a credible breach signal affecting PHI, we follow our PHI breach-response runbook:

  1. Hour 0-4 — contain. Revoke compromised credentials, lock affected sessions, rotate signing keys if needed.
  2. Day 1-3 — scope. Reconstruct timeline from the immutable audit archive. Determine affected individuals. Perform the §164.402 four-factor risk assessment.
  3. Day 5 — notify. Customer notification with the §164.410 content elements: discovery date, PHI involved, affected individuals, containment actions, and next steps. Five business days is our internal SLA; the regulatory maximum is 60 days from discovery.
  4. You then notify the affected individuals, and (where applicable, 500+ individuals) HHS and the media. Authio supplies all reasonable assistance.
Authio does not notify HHS directly — the Covered Entity does. Our role under §164.410 is to inform you fast, with the evidence you need for your §164.404 filings.

Control matrix

Our HIPAA technical and administrative safeguards mapping is committed at hipaa/control-mapping.md. At the most recent ship (T4.5, 2026-05-21):

  • §164.312 Technical safeguards: 13 PASS / 1 PARTIAL / 0 GAP.
  • §164.308 Administrative safeguards (relevant subset): 16 PASS / 3 PARTIAL / 0 GAP.
  • §164.310 Physical safeguards: 1 PASS / 2 PARTIAL / 5 N/A (inherited from AWS / Railway).
  • §164.314 Organizational: 0 PASS / 1 PARTIAL / 1 N/A (BAA template requires legal review).
  • §164.316 Documentation: 3 PASS.

Sub-processors handling PHI

Authio uses several sub-processors. Those that handle PHI on your behalf operate under their own BAAs with Authio (or are replaced with HIPAA-aware alternatives for HIPAA-bound deployments — for example, dedicated Postgres on RDS instead of Railway-managed). The current list is at vendor-list.md.

Dedicated infrastructure tier

For HIPAA-bound customers who require infrastructure isolation, the Enterprise tier provisions a dedicated Postgres instance per tenant with a customer-isolated KMS CMK. No data crosses the tenant boundary. See the architecture doc for details.

How to engage

  1. Email security@authio.com with subject “BAA request” and include your legal entity name, the Authio project IDs involved, and a preferred Privacy Officer contact.
  2. We send the draft BAA. Counsel-reviewed; based on our public template.
  3. Sign. Authio enables the HIPAA preset on your project(s) and adds your Privacy Officer to the incident-notification channel.
  4. You enable require_mfa + require_passkey and set session timeouts on each HIPAA-scoped organization in your dashboard.
Want the full control matrix in a single PDF for your auditor? Email security@authio.com and reference your BAA effective date; we'll send the signed PDF under NDA along with the commit hash anchor so your auditor can compare to the public Git history.

What we're not

Authio is not a clinical system. We do not ingest medical records, treatment notes, diagnoses, lab results, claims data, or any clinical content. If your application needs to send clinical data to a third party, that third party is a separate Business Associate with its own BAA. The Authio BAA covers only the authentication-metadata scope documented in our PHI handling guide.

See also