ctHelixOne

Security & sovereignty

Your data, your file, your call.

Operations data is sensitive, regulated, and increasingly hard to extract from vendor clouds. ctHelixOne™ takes the opposite stance: production-grade application security across every layer, your operational record encrypted at rest in a standard SQL database you control, and the decision to migrate, archive, or destroy yours alone.

Three sovereignty pillars

What we mean when we say ‘sovereign’.

Your data, your database, your file

Your full operational history sits in a standard SQL database you control — encrypted at rest, queryable with any standard SQL tool, exportable on your schedule. No proprietary format, no vendor cloud, no extraction fee.

Self-host or we host

Run it on your hardware, your VM, or your air-gapped network. Or let us run a hosted instance for you. Single-tenant either way — your instance, your database, your isolation.

No lock-in

Standard SQL. Standard schema. Standard tooling. You can walk away at any time and take everything with you, in a format anyone can read.

Application security across the suite

Defense in depth, applied at every layer.

Authentication, cryptography, application hardening, and audit are first-class concerns — engineered into the platform, not bolted on. Every primitive below is a vetted industry standard, configured with hardened defaults, and inherited consistently across every module of the ctHelixOne™ suite.

Authentication & authorization

  • Argon2id (memory-hard, side-channel resistant) hashing for operator passwords and field PINs.
  • Role-based access control with granular, agency-scopable permissions. License management gated to its own permission.
  • Independent authentication surfaces for the dispatcher console and the mobile companion — separate token shapes, lifetimes, and scopes.
  • Short-lived, sliding session tokens for mobile — never long-lived bearer tokens. Idle sessions age out automatically.
  • Idle timeouts on administrative and license-management surfaces.
  • Rate-limited authentication endpoints with progressive back-off on repeated failure.

Cryptography & data protection

  • AES-256 encryption at rest for the operational database, using vetted, industry-standard encryption primitives (engine-appropriate transparent or filesystem-level encryption).
  • TLS 1.2+ for every HTTP and Socket.IO connection; HSTS enforced; secure cookies only.
  • Backups inherit the at-rest encryption posture; backup artifacts are themselves encrypted.
  • Ed25519-signed license bundles bound to an install ID — a leaked license cannot run on a second host.
  • No custom cryptographic primitives. Every algorithm is a vetted, widely deployed industry standard.

Application & API hardening

  • Schema-validated input on every API surface — malformed or off-spec payloads are rejected before they reach business logic.
  • Secure-by-default HTTP response headers: Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy.
  • CSRF protection on state-changing routes; cross-origin requests denied by default.
  • XSS-resistant rendering throughout the React surface.
  • Least-privilege database role at runtime — DDL and superuser access are never reachable from the application.
  • Secrets stored outside the operational database — environment, OS keyring, or your secret-management system.

Auditability & operational posture

  • Audit log captures every mutation — status changes, assignments, notes, configuration edits, license-management actions — with user attribution and timestamps.
  • PHI tables (EMS Transport add-on) scoped to the transport module with a distinct PHI audit log.
  • Single-tenant by design — your instance, your database, your isolation. No shared multi-tenant surface to escape from.
  • Air-gap-friendly — the system operates without outbound calls between periodic license check-ins.
  • No telemetry on operational data. Crash and diagnostic reporting is opt-in and scrubbed.

CJIS-aware primitives for records data

  • Multi-factor authentication for accounts handling criminal-justice information.
  • Configurable password rotation cadence to the policy your agency operates under.
  • Per-query audit logging on sensitive lookups — the query and the reason given are recorded; the full sensitive response body never is.
  • Encrypted storage of sensitive identifiers with reveal-with-permission and a distinct audit trail for each reveal.
  • Granular role-based permissions on records-side actions: create, edit-own-draft, submit, read-own, read-agency, approve, reopen.

What we don’t do

As important as what we do.

No phone-home with operational data.

No telemetry on your incidents, your units, your roster, or your patients. Crash and diagnostic reporting is opt-in and scrubbed.

No internet requirement for normal operation between check-ins.

The system runs entirely on your network between periodic license check-ins. Update cadence is on your schedule, not ours. Air-gap-friendly.

No kill switch that erases your data. Your database is yours; you can read it without us.

Even in the Disabled license state, your data is untouched. The operational database stays exactly where it has always sat, in a standard, openly readable SQL format.

No direct NCIC / NLETS brokerage.

We don’t broker your federated-system access. Your existing terminal stays where it is; ctHelixOne™ logs the request and the outcome through per-query audit, not the response body.

No facial recognition or biometric matching.

Not v1, not roadmap. Smaller agencies rightly don’t want this inside their records system, and the legal posture is still in motion.

No intelligence or SAR-style analytics.

Records management is not an intelligence platform. 28 CFR Part 23 governs intelligence systems for a reason — we deliberately stay out of that scope.

For your security team

We’ll meet them where they are.

Want our architecture diagram, threat model summary, or auth-surface deep-dive for a review packet? Start with the tech page and reach out for anything that isn’t covered.

Need our architecture diagram for a review?

Tell us your framework. We’ll send the right packet, not a generic one.