NexLifeNexLife
Legal · NexLife

Security Overview

Last updated · July 12, 2026

This page describes the security controls that are actually implemented in the NexLife platform today. We do not claim any certification (HIPAA, SOC 2, ISO 27001, PCI-DSS, FINRA) that we have not undergone. If a control is not listed here, assume it is not in place.

1. Transport & Storage Encryption

  • TLS 1.2+ in transit: all traffic to nexlifecrm.org and API endpoints is served over HTTPS.
  • HSTS enforced: browsers are instructed to only connect over HTTPS for two years, with subdomains and preload.
  • Encryption at rest: the managed Postgres database and object storage encrypt data on disk using AES-256.
  • Additional field-level encryption: sensitive intake fields (SSN, driver's license, bank account and routing numbers, beneficiary DOB, health details) are encrypted with AES-256-GCM before they hit the database, using a server-only key.

2. Sensitive-Data Vault & Short Retention

When a client submits an intake, encrypted PII is written to a short-lived intake vault. The vault is automatically purged shortly after delivery to the carrier (or on scheduled expiry, whichever comes first). Every purge is recorded in a deletion log so we can prove the row is gone.

3. Authentication

  • Passwords are stored as one-way cryptographic hashes by our managed auth provider. NexLife never sees or logs plaintext passwords.
  • Sessions are bound to a single active IP per account. If the account is opened from a new location, the older browser is signed out on its next protected request.
  • Sign-in and session-conflict events are recorded with IP, coarse geolocation, and user-agent, and pushed to an internal monitoring channel.
  • Password reset uses a signed, expiring link delivered by the auth provider.

4. Authorization & Tenant Isolation

  • Row-Level Security is enabled on every user-data table. Policies are scoped to auth.uid() so agents can only read and modify rows they own.
  • Roles (agent, admin) live in a separate user_roles table checked by a SECURITY DEFINER function; roles cannot be self-granted from client code.
  • Privileged server functions verify the caller's role before doing anything with elevated privileges.

5. HTTP Response Hardening

Every server response includes:

  • Strict-Transport-Security (2 years, includeSubDomains, preload)
  • X-Content-Type-Options: nosniff
  • Referrer-Policy: strict-origin-when-cross-origin
  • Permissions-Policy disabling camera, microphone, geolocation, USB, and motion sensors
  • Cross-Origin-Opener-Policy: same-origin-allow-popups

React automatically escapes rendered content, providing baseline XSS protection. Parameterized queries and the managed Postgres client remove classic SQL-injection surface. State-changing requests use the framework's typed RPC transport, which is same-origin and requires the session bearer token.

6. Webhook & Integration Security

  • Stripe webhooks are verified against the Stripe-Signature header with a timing-safe comparison before any state change.
  • Inbound optin webhooks require a shared secret in the request header.
  • Outbound webhooks (e.g., GoHighLevel) are configured per agent and only fired after the agent authorizes them in Settings.

7. Logging & Monitoring

  • Sign-in events, session conflicts, Stripe payment events, and NDA/SSN disclosure signatures are recorded server-side.
  • Errors from the running app are captured for triage; we scrub obvious secrets from error payloads.
  • We are actively expanding the audit-log surface, see the "Gaps" section below.

8. Backups

Backups are managed by our hosting provider (managed Postgres). Point-in-time recovery is available for a rolling window. NexLife does not currently perform independent, out-of-region backups; that is a known gap.

9. Vulnerability Reporting

If you believe you have found a security issue, email security@nexlifecrm.orgwith a description and reproduction steps. Please do not publicly disclose the issue until we have had a reasonable opportunity to investigate. We will acknowledge good-faith reports and will not pursue legal action against researchers who follow responsible disclosure. See our Security Contact page for details.

10. What We Do Not Claim

NexLife is a software platform. We are not certified under, and we do not claim compliance with:

  • HIPAA, HITECH, or any BAA-required framework
  • SOC 2 (Type I or Type II), ISO 27001, PCI-DSS (beyond the fact that Stripe handles card data)
  • FINRA, NAIC model regulations, or any carrier's specific security requirements
  • State insurance data-security acts (e.g., NY DFS 500, NAIC Insurance Data Security Model Law), agents remain responsible for their own compliance obligations

11. Known Gaps We Are Working On

  • Multi-factor authentication for agent accounts (planned, not shipped)
  • Full application-level audit log across all sensitive-data reads (in progress)
  • Formal third-party penetration testing
  • Written incident-response tabletop exercises

Questions? Email security@nexlifecrm.org.