Security at LockIn90

01 — Our approach

LockIn90 exists to turn raw wearable signals into one honest answer about your energy. To do that we hold deeply personal data: sleep stages, heart-rate variability, resting heart rate, training load, logged caffeine and food, mood, menstrual cycle, and — for some members — genetic markers. We design every system around a simple principle: collect the minimum, protect it like it's our own, and never monetize it.

Security is not a feature we bolt on at the end. It is part of how the product is built — from the encryption defaults in our database, to the least-privilege roles our own engineers run under, to the end-to-end encryption that keeps your coach conversations off our servers in readable form.

• Defense in depth. No single control is trusted alone — encryption, network isolation, scoped access and audit logging each assume the others might fail.
• Data minimization. We pull only the wearable fields the energy model actually uses, and you control which sources are connected at any time.
• Your data is never sold. Cohort comparisons are opt-in and k-anonymized; we have no advertising business and no data-broker relationships.

This document describes the controls in place today. Where something is still in progress (for example, our SOC 2 Type II examination), we say so plainly rather than implying it's done.

02 — Encryption

All of your data is encrypted both while it travels between your device and our servers, and while it sits at rest in our databases and backups. We use modern, audited primitives and rotate keys on a regular schedule.

In transit

Every connection to LockIn90 — web, mobile and our public API — is served exclusively over TLS 1.3 with strong forward-secret cipher suites. Plaintext HTTP is redirected and refused. We send HSTS with a long max-age and preload, so browsers will only ever reach us over HTTPS.

At rest

Data at rest is encrypted with AES-256-GCM. Database volumes, object storage and automated backups are all encrypted, and encryption keys are managed in a dedicated key management service with strict access controls and audit logging.

Field-level encryption for the most sensitive data

On top of full-disk encryption, the most sensitive categories get an additional layer of application-level field encryption before they ever reach the database — so a stolen disk image alone reveals nothing useful for those fields.

Genetic & cycle data are field-level encrypted. Genetic markers and menstrual-cycle records are encrypted per-field with AES-256-GCM and a separate key class, decrypted only in-memory for the moment the energy model needs them, and never written to logs.

03 — End-to-end encrypted coach messaging

When you share progress with a coach, the conversation is end-to-end encrypted. Messages are encrypted on your device and only decrypted on your coach’s device. Our servers relay and store the ciphertext only — we cannot read your coaching messages, and neither can anyone who compromises our infrastructure.

We implement the Signal protocol with PQXDH — a post-quantum-augmented key agreement — so that conversations stay confidential even against a future adversary who records traffic today and attacks it with a quantum computer later. Each message uses a fresh key (the Double Ratchet), giving forward secrecy and post-compromise recovery.

• Your device encrypts the message.
• LockIn90 server relays ciphertext only — it sees only: 9f2c-a81e-…-3b07 (ciphertext).
• Coach device decrypts the message.

Device identity keys are pinned and you can verify a coach’s safety number out of band. Because decryption keys live only on endpoints, features that would require the server to read message contents (such as server-side search of message bodies) are deliberately unavailable — a trade-off we make on purpose.

04 — Authentication & sessions

Account access is protected by a session design that resists the most common attacks — token theft, replay and cross-site scripting.

• httpOnly cookie sessions. The web session lives in a Secure, httpOnly, SameSite cookie that JavaScript can't read — so an XSS bug can't exfiltrate your session.
• Refresh-token rotation with theft detection. Refresh tokens are single-use and rotated on every use. If an old token is ever replayed, we treat it as a compromise and revoke the entire token family, ending the attacker's access.
• Re-authentication for sensitive actions. Exporting your data, deleting your account, or changing security settings requires a fresh step-up — even within an active session.
• OAuth where you want it. Sign in with Google or Apple is supported; passwords (when used) are hashed with argon2id and checked against known-breach lists.
• MFA is mandatory for operators. Every LockIn90 employee with production access authenticates with multi-factor — hardware security keys (WebAuthn/FIDO2) preferred, TOTP as fallback. There is no password-only path into production.

05 — Infrastructure & hosting

LockIn90 runs on hardened, container-based infrastructure with a reverse proxy terminating TLS and a private network between services. Application services hold no long-lived secrets on disk; configuration and credentials are injected at runtime from a secrets manager.

• Network isolation. Databases and internal services are not reachable from the public internet — only the proxy is exposed, and it speaks to services over a private network.
• Self-hosted, encrypted database. We run our own Postgres with encrypted volumes and least-privilege roles, rather than handing your raw health data to a third-party analytics warehouse.
• Reproducible, scanned images. Service images are built in CI, scanned for known vulnerabilities, and deployed immutably — no hand-editing of running servers.
• Rate limiting & abuse controls. A network-level flood guard and per-tier usage quotas protect the platform from credential-stuffing and abuse without slowing legitimate use.

06 — Access control & least privilege

Access to production data is restricted to the smallest possible set of people and processes, and every grant is scoped to exactly what the role needs — nothing more. At the database level we use distinct, least-privilege roles so that no single credential can do everything.

• Need-to-know. Engineers do not have standing access to member health data. Access is requested for a task, approved, granted for a limited window, and recorded.
• Privacy-gated coach views. Even with consent, a coach sees trends and shared metrics — never your raw private logs. Cohort aggregation is fail-closed and enforces a minimum group size.
• Tamper-evident audit log. Administrative and data-access actions are written to an append-only audit trail used for security review and incident investigation.

07 — Data isolation & backups

Member data is logically isolated per account and protected against loss with regular, encrypted backups that we actually test by restoring.

• Encrypted, automated backups. Backups are encrypted with AES-256 and retained on a defined schedule. We periodically run restore drills so a backup is never a backup we can't recover from.
• Separation of the public surface. The public marketing & pricing service runs on its own database with a one-way, read-only sync — your private health data lives nowhere near the public site.
• Deletion that means deletion. When you delete your account, your data is removed from production systems and rolls out of backups as they age out of their retention window. The deletion request is re-authenticated.

Retention is matched to purpose: connected-source data lives only as long as your connection and energy history are useful to you. You can export everything or delete your account at any time.

08 — Sub-processors

We use a small, vetted set of sub-processors to operate the service. Each is bound by a data processing agreement, and we share only the data necessary for that processor’s function. Wearable sources you connect (Oura, WHOOP, Garmin, Apple Health, Health Connect) are data sources you authorize, not sub-processors we hand your data to.

We maintain a current sub-processor list and will give notice of material changes. To be notified of updates, contact privacy@lockin90.com.

09 — Responsible disclosure & bug bounty

We welcome reports from security researchers and we will not pursue legal action against good-faith research conducted within the scope below. Please give us a reasonable window to fix an issue before any public disclosure, and never access, modify or destroy data that isn't yours.

In scope

• The web app, public API and our domains
• The iOS & Android apps
• Authentication, session and authorization flaws
• Data exposure, injection, RCE, IDOR / access-control bugs

Out of scope

• Volumetric DoS / DDoS & brute-force without a bypass
• Social engineering of staff or members
• Reports from automated scanners with no demonstrated impact
• Third-party services & the wearables you connect

How to report

Email security@lockin90.com with steps to reproduce and impact. We acknowledge within 2 business days, triage promptly, and recognize valid reports in our hall of fame. Encrypt sensitive details with our published PGP key.

10 — Compliance & certifications

We hold ourselves to recognized privacy and security frameworks and are transparent about where we are on each. We'd rather tell you something is in progress than imply it's finished.

Note: LockIn90 is a performance & recovery insights tool, not a medical device, and does not provide HIPAA-covered services. Enterprise customers can request our latest reports and questionnaire under NDA.

11 — Incident response

We maintain an incident-response plan with defined roles, severity levels and communication steps. Alerts route to an on-call engineer, and security-relevant events escalate to a small response team.

• Detect & contain. Centralized logging and alerting help us spot anomalies; the first priority in any incident is to contain it and protect member data.
• Notify. If an incident affects your personal data, we will notify affected members and the relevant authorities within the timelines required by law (GDPR: within 72 hours of becoming aware).
• Learn. Every incident gets a blameless post-mortem and concrete follow-up actions, tracked to completion.

12 — Contact

Questions about our security or privacy practices, or want to report something? We read every message.

• Security reports — security@lockin90.com
• Privacy / DPO — privacy@lockin90.com
• General support — Contact form
• PGP key — Request public key