foxxcyber/docsData Handling & Access
What data our Railway-hosted products store, how it's protected in transit and at rest, and how authentication and authorization work.
Draft — verify before publishing. Confirm the data categories, encryption, backup, and retention specifics for each product before this page is published. Do not state a protection that isn't actually in place.
What data these products store
Each product stores the operational data its features require:
- Praevio — coaching data: athlete profiles, self-reported health and fitness information, and minors' data (with parental-consent tracking). This is sensitive personal data, though not CUI.
- RailCompliant — FRA locomotive maintenance, inspection, and compliance records. Not CUI.
- Bedrock AFT — transfer-request records, the approval/audit trail, and classification labels/descriptions — not the transferred file contents.
- Bedrock RMF — RMF authorization artifacts (SSP, POA&M, control implementations) and customer-uploaded evidence, which may contain CUI.
Only the two commercial-SaaS products (Praevio, RailCompliant) can be described as free of CUI. Bedrock RMF may hold CUI in its packages and evidence; Bedrock AFT holds classification metadata. None are in scope of the Bedrock platform SSP, but that is not the same as "no sensitive data."
Card and payment details are not stored by our applications; see Payments.
Protection in transit and at rest
- In transit: all traffic is served over HTTPS with TLS terminated at the platform edge.
- At rest: application data lives in a managed PostgreSQL database. Encryption-at-rest and backup specifics are provided by the managed database and should be confirmed per product before this page publishes.
- Secrets: credentials and API keys are stored as platform environment variables, never in source or in the container image.
Every product hashes passwords with a modern, deliberately slow algorithm;
plaintext passwords are never stored or logged. Sessions are carried in
HttpOnly cookies over HTTPS. Administrative capabilities are gated behind
explicit role checks under the auth-gate-first
invariant. The specifics differ by
product:
| Product | Password hashing | Session | Additional factor |
|---|---|---|---|
| Praevio | bcrypt (cost 12) | JWT | Optional TOTP 2FA |
| RailCompliant | argon2id | Server-side DB session (256-bit token) | — |
| Bedrock RMF | scrypt | Server-side DB session | TOTP 2FA; public sign-up disabled |
| Bedrock AFT | bcrypt (cost 12) | Server-side session (HttpOnly, Secure, SameSite=Strict) | CAC / client-certificate authentication |
Bedrock AFT authenticates with a CAC (client certificate) verified against the DoD CA at the edge. Note that when it runs behind a TLS-terminating edge (such as Railway's), the client certificate does not reach the app, so that deployment uses password login. AFT's in-app digital-signature capture is a workflow record, not a cryptographic signature made with the card's private key — describe it as a recorded approval, not a CAC-signed artifact.
Authorization and tenant isolation
Within each product, users only reach data they're entitled to. Tenant isolation is enforced in the application: every scoped query carries a server-derived tenant identifier, and that identifier is never taken from the client. This is the same invariant — and the same class of regression test — that governs the Bedrock platform and HLE-AIO.
Retention and deletion
Data retention and deletion follow each product's terms and any applicable customer agreement. For the current company-wide policy and how to request deletion, see Data Retention & Deletion.
Because these are commercial SaaS products rather than a CUI platform, the controlling document for data handling is the product's terms and your agreement with us — not a NIST SP 800-171 SSP. Where you need contractual data commitments, they belong in that agreement.