Security at PathFacts
Updated October 2026
Carriers and utilities trust PathFacts with the shape of their microwave networks. This page describes how we protect that data. For our security documentation, a completed questionnaire or a data processing agreement, write to security@pathfacts.com.
Infrastructure
The application and its databases run on Railway in the United States; Railway holds a SOC 2 Type II report. Production and development are separate environments with separate databases and keys. The development environment holds a scrubbed copy of production data: no passwords, sessions, secrets or customer email addresses.
Encryption
- All traffic uses TLS, with HTTP Strict Transport Security.
- Credentials for customer integrations (single sign-on client secrets, webhook signing secrets) are encrypted in the database with a key held outside it.
- Backups are encrypted before they leave our hosting provider and stored in AWS S3 with Object Lock, so they cannot be altered or deleted early.
- Passwords are stored only as salted scrypt hashes.
Access control
- Every PathFacts staff account must sign in with a second factor (an authenticator app or a passkey). Customers can turn on two-factor sign-in, or sign in through their own identity provider with SAML 2.0 or OpenID Connect. A company can require single sign-on or two-factor sign-in for all its people, set its own session length, and provision and deactivate accounts through SCIM.
- Each customer account sees only its company's access scope and the paths it has bought; the same rule is applied to the map, the API and every report.
- Every time a PathFacts staff member opens a customer's account, order, monitor or deliverable, or builds a report, it is logged. A company's administrators can read that record, with their own people's sign-ins and changes, and download it.
- Administrative access to our hosting, code and cloud accounts uses named accounts with two-factor authentication, reviewed every quarter.
- Accounts lock after repeated failed sign-ins, and the API is rate limited.
Application security
- Every change passes automated dependency auditing, static security analysis and tests, and runs on a staging environment before it reaches production.
- Dependencies are updated through automated weekly pull requests.
- The application enforces a content security policy that allows no inline script, sends the standard security headers, and protects every form against cross-site request forgery.
- Outbound webhooks and single sign-on discovery refuse private and internal network addresses.
Monitoring and incident response
Sign-ins, account changes and every request are logged in structured form, and a failed backup alerts us immediately. We follow a written incident response plan and notify affected customers of a breach of their data within 48 hours of becoming aware of it.
Backups and continuity
Production databases are archived continuously for point-in-time recovery, and backed up nightly to a separate cloud provider and kept for up to twelve months. Our targets are to lose no more than one hour of data and to be back in service within 4 hours. Restores are tested every month by rebuilding the staging environment from the latest production backup.
Policies and compliance
We maintain written policies for information security, access control, change management, incident response, business continuity, vendor management, data retention and acceptable use. We are working toward a SOC 2 Type I report; until it is issued we answer security questionnaires (SIG Lite, CAIQ or your own) on request.
Subprocessors
Companies that process customer data on our behalf. Customers with a data processing agreement are told 30 days before a new one is added.
| Company | Purpose | Location |
|---|---|---|
| Railway | Application hosting and databases | United States |
| Amazon Web Services | Encrypted backups, secrets storage; AI (Claude on Amazon Bedrock) for news and public documents (no customer data) | United States |
| Resend | Transactional email (sign-in, alerts) | United States |
| Stripe | Card payments | United States |
| Google Workspace | Staff email | United States |
| Vercel | Hosting for this website | United States |
| GitHub | Source code and automated testing (no customer data) | United States |
| CARTO, Esri | Map tiles requested by your browser | United States |
| Tavily | Web search for industry research (no customer data) | United States |
| OpenAI | Illustrations for news stories (no customer data) | United States |
| Google (Gemini API) | Illustrations for news stories (no customer data) | United States |
Reporting a vulnerability
If you believe you have found a security problem, email security@pathfacts.com with the details and steps to reproduce. We acknowledge reports within two business days, keep you informed while we fix it, and will not pursue good-faith research that avoids privacy violations, data destruction and service disruption. Please do not test against other customers' accounts; we can provide a test account on request. Our security.txt has the same contact.