SECURITY

Security Built for Protected Health Information

OpenCryo stores specimen records that identify patients. This page describes how we protect them now and in the future.

At a Glance

The summary to review against your security checklist.

Sign-in
Application users (clinic and lab staff, storage technicians, couriers) cannot sign in with a password: access is by passkey (FIDO2 and WebAuthn) or emailed magic link only, on desktop and mobile. Portal clients, who see only their own records, may use a password for convenience.
Sessions
Signed, time-limited tokens. A user can sign out of every session at once, and deactivating a user blocks them on their next request.
Access control
Instance admin, organization admin, staff, and viewer roles, checked on the server for every request, with a separate per-user, per-organization grant for protected health information.
Audit log
Append-only by design: the application adds events and never edits or removes one in production. Every event is timestamped and records the acting account. Exportable to CSV.
Encryption
TLS 1.2 or 1.3 in transit. AES-256-GCM for stored credentials. AES-256 for database backups.
Hosting
OpenCryo Cloud runs on servers in the United States. Hosting locations outside of the United States are available.
Backups
Encrypted, taken automatically before every deploy and daily. The daily backup is stored on separate and distinct, and geographically distanced, infrastructure.
HIPAA
HIPAA-aligned controls throughout. A Business Associate Agreement is available and is executed before any PHI is stored.
Certifications
A SOC 2 Type 1 audit is planned for Q3 2027.
Source code
Available for inspection by your team, your auditors, and your regulators under the Business Source License.

How It Is Built

Robust security and data protections are core to the system.

Phishing-Resistant Sign-In

Application access is locked to the current industry best-practice standard. Staff sign in with a passkey, a public-key credential (FIDO2 and WebAuthn) bound to the sign-in domain, kept in the device or platform keychain, and unlocked by the device's own biometrics or PIN, or with an emailed magic link. No staff account has a password, so there is nothing to phish, guess, reuse, or leak, and the private key is never sent to us. Portal clients, who can see only their own records, may sign in with a password for their own convenience; passkeys and magic links are available to them as well.

  • User verification is required on every passkey sign-in, never optional.
  • Staff sign-ins are written to the audit log with their method and source IP, and so are rejected passkey attempts. Failed attempts never record the email that was tried.
  • Sessions are signed, time-limited tokens. A user can sign out of every session at once, and deactivating a user blocks them on their next request.
  • Sign-in, session, magic-link, and passkey routes carry tighter rate limits than the rest of the API.

Roles, Permissions, and PHI Gating

Four roles (instance admin, organization admin, staff, viewer) map to granular permissions that the server checks on every request. Access to protected health information is a separate grant, made per user and per organization: defaulted by role when a user is invited, changed only through its own audited action, and never altered by a later role change. A user without it sees redacted identifiers.

  • Changes to a user's PHI access are audited as their own event.
  • Regulated operations are gated by qualifications: staff must hold the matching qualification to perform or review validations, destructions, and intake, or to see financial data.
  • Role changes take effect on the user's next request. Deactivating a user blocks them immediately.
  • Permission checks fail closed: anything not explicitly granted is denied.

An Append-Only Audit Trail

Every significant action writes an audit event: who, what, when, and the specimen, container, or location it touched. Events are written once. In production nothing in the application edits or removes one, so history is appended, never rewritten; enforcing that at the database layer is on the roadmap below.

  • Specimen movements, custody changes, client changes, agreement signings, sign-ins, and PHI access changes are all recorded.
  • Audit metadata references clients by ID, never by name or email.
  • Viewing the full log takes an administrator permission. Export it to CSV for archival or an external review.
  • Every role that can view a container can see that container's own custody history.

Organization Isolation

One OpenCryo instance can host many organizations: clinics, storage providers, couriers, collection services. Each is isolated by default and shares data only through orders, the one explicit, audited path for cross-organization work.

  • Every query the application makes for organization-scoped data carries the organization filter, on every table: containers, specimens, clients, orders, portals, users, and audit events. That scoping is the isolation layer enforced today.
  • Database-enforced row-level security with a dedicated non-owner database role is on the roadmap below.
  • Cross-organization isolation is covered by integration tests that run against the live API.
  • Records are archived rather than deleted, so custody history stays intact. Permanent deletion is reserved for formal data-removal requests.

Encryption and Infrastructure

Everything travels over TLS 1.2 or 1.3; older protocols are refused. Stored credentials (SMTP passwords, payment keys, OAuth tokens) are encrypted with AES-256-GCM before they reach the database. Certificates, including those for your custom portal domain, are issued and renewed automatically.

  • HTTP Strict Transport Security, a Content Security Policy, frame denial, and content-type sniffing protection on the API.
  • Rate limiting on every endpoint, with tighter tiers on the authentication routes.
  • Every database query is parameterized. No SQL is assembled from user input.
  • Third-party keys can be rotated without downtime.

Backups and Change Control

Every deploy takes an encrypted database backup first and checks the API's health endpoint afterwards, and every change reaches staging before production. A daily backup, encrypted the same way, is copied to a second server over SSH, and the restore procedure is documented step by step.

  • Pre-deploy and daily backups are encrypted with AES-256; pre-deploy backups are stored with the matching commit, so code and data roll back together.
  • The post-deploy health check reports the database connection, the running version, and the deployed commit.
  • Your data is exportable at any time: the audit log to CSV, agreements and receipts as PDF, and the data model is published.
  • If you leave, your administrators keep a 30-day window to sign in and export the organization's data.

HIPAA and Your Compliance Program

OpenCryo is built with HIPAA-aligned technical safeguards: role-based access with a separate PHI grant, audit logging of data access and changes, encryption in transit and of sensitive data at rest, and authentication without shared credentials. For organizations that are covered entities or business associates, Improbability Works executes a Business Associate Agreement before any protected health information is stored on OpenCryo Cloud.

Technical controls support compliance; they do not constitute it on their own. Your policies, your workforce training, and the executed BAA together with these controls form the compliance framework. Self-hosted instances run outside the scope of our BAA, and organizations that self-host are responsible for their own HIPAA compliance.

Specimen tracking data, custody audit events, and signed agreements are retained for as long as your account is active, consistent with the long-term nature of cryogenic storage and healthcare record-keeping obligations. OpenCryo Cloud data is stored on servers in the United States but can be hosted on servers in other countries as per your location's needs. The Privacy Policy sets out the full retention and data-rights terms.

Certifications and Roadmap

OpenCryo holds no third-party certifications yet, but we are working towards receiving them. In March 2026 the platform was reviewed against an internal control framework drawn from SOC 2 and ISO 27001, with the goal of achieving SOC 2 certification in 2027.

  • Completed Passkey sign-in with required user verification, sign-out from every session at once, sign-in audit events, encrypted pre-deploy and daily backups, TLS 1.2 and 1.3 only, and security headers on the API.
  • Underway Ongoing security audits and code reviews with every update.
  • Planned A dedicated non-owner database role with forced row-level security on every organization-scoped table, which also enforces the append-only audit log at the database layer; then a SOC 2 Type 1 audit targeted for Q3 2027.

Dates are targets, not commitments. This page is updated when a milestone lands.

Verify It Yourself

Closed systems ask you to trust a vendor. OpenCryo's complete source code is available for inspection under the Business Source License, so your team, your auditors, and your regulators can check how every control on this page is implemented rather than take our word for it. Ask and we will arrange access.

If you have a security questionnaire, send it to hello@opencryo.io. We answer every question with what the shipped product does today, and we share the control review summary and the BAA on request. If you believe you have found a vulnerability, email the same address and we will respond promptly.

Ready to See It in Action?

Book a 15-minute demo, or send us your security questionnaire.

Book a Demo