Steadfast HSA is designed for one purpose: to be the long-term vault for your HSA documentation. You may store receipts for 20–30 years before you ever need them. That timeline demands infrastructure and security practices built to last — not corners cut to ship faster.

This page describes our security posture in plain terms. We name our infrastructure providers, describe our controls, and are honest about where we are on the security maturity roadmap.

1. Data in Transit

All communication between your browser, our application, and our infrastructure is encrypted using TLS 1.2 or higher. We enforce HTTPS across all endpoints — there is no unencrypted fallback. HTTP requests are automatically redirected to HTTPS.

Our frontend is served through Cloudflare's global network, which terminates TLS at the edge, providing both encryption and DDoS mitigation. The HTTP Strict Transport Security (HSTS) header is set on all responses with a two-year max-age and preload registration, instructing browsers to never attempt an unencrypted connection to our domains.

2. Data at Rest

Expense Records & Account Data

All structured data — your expense records, account metadata, and family member information — is stored in a managed PostgreSQL database hosted by Neon. Neon encrypts all data at rest and maintains SOC 2 Type II compliance. Backups are encrypted and retained for 30 days.

Receipt Files & Documents

Your uploaded files (receipt images, PDFs, and exported archives) are stored in Cloudflare R2, Cloudflare's object storage product. R2 encrypts all objects at rest using AES-256. Files are accessed only through short-lived, signed URLs generated on demand — there are no permanent public links to your documents. Cloudflare's zero-egress architecture means your files do not traverse third-party networks for delivery.

File storage paths include your account identifier but not personally identifiable information. Even if a storage path were exposed, it would not be directly usable without a valid signed URL.

3. Authentication & Account Security

Authentication is handled entirely by Clerk, a dedicated identity and authentication platform. We do not store passwords. We never see your password — it is handled, hashed, and stored by Clerk using industry-standard practices.

Clerk provides:

• Multi-factor authentication (MFA): TOTP authenticator app support. We strongly recommend enabling MFA on your account.
• Social sign-on: Optional sign-in via Google and Apple, using those providers' authentication flows.
• Session management: Active sessions are listed in your account settings. You can revoke any session remotely at any time.
• Credential breach detection: Clerk monitors for compromised credentials and flags accounts accordingly.

All API requests from the frontend include a short-lived JSON Web Token (JWT) issued by Clerk. Our backend validates the token signature on every request. Tokens are never stored in our database.

4. Data Isolation

Every database query in the application is scoped to the authenticated user's account ID. It is not possible for one user to retrieve, modify, or delete another user's expenses, receipts, or account data — this is enforced at the application layer, not just the UI layer.

Receipt files in storage are namespaced by account identifier. Access to files requires both a valid authenticated session and ownership of the associated account.

5. Browser & Transport Security Headers

Every response from our application includes security headers designed to protect against common browser-based attacks:

6. Infrastructure & Hosting

We deliberately chose infrastructure providers with strong, independently verified security postures. We do not run our own physical servers.

Our backend API is not directly exposed to the public internet on a database port. The database accepts connections only from the application server's private network. There is no direct external database access.

7. Internal Access Controls

Access to production systems is restricted to authorized personnel only. We apply a principle of least privilege — individuals have access only to the systems required for their role. Production database access is not a routine developer privilege.

We do not have a large team with complex access sprawl. As a small, bootstrapped company, the surface area for insider risk is limited. As we grow, we will implement formal access review processes and maintain an audit log of production access.

8. Incident Response

In the event of a confirmed security incident affecting your data, we will:

• Notify affected users by email within 72 hours of confirming a breach that affects their data.
• Describe what data was affected, the scope of the incident, and the steps we are taking to contain and remediate it.
• Comply with applicable breach notification requirements, including the FTC Health Breach Notification Rule, which we believe applies to our handling of health-adjacent receipt data.
• Publish a post-incident summary for material incidents once the situation is resolved.

To report a suspected security vulnerability, please contact us at security@steadfasthsa.com. We take all reports seriously and will respond within 2 business days. We ask that you give us reasonable time to investigate and remediate before public disclosure.

9. Where We Are on the Security Roadmap

We believe in being honest about what we have done and what we have not yet done. The following items are on our security roadmap but are not yet complete:

• SOC 2 Type II (Steadfast HSA): We rely on our infrastructure providers' SOC 2 certifications today. Our own SOC 2 audit is a planned milestone as the business scales.
• Bug bounty program: Planned. In the interim, we accept responsible disclosures at security@steadfasthsa.com.

We will update this page as these milestones are reached.

10. Contact

For security inquiries, vulnerability reports, or questions about our security practices: