Trust Center

Security, Privacy & Compliance

Your firewall config contains the keys to your network. We know that. Here is exactly what happens when you upload one, the controls that protect it, and the compliance frameworks your audit maps to.

Compliance Coverage

Every finding in your CRWLR audit is mapped to the control frameworks your auditors and customers ask about. Filter findings by framework on any scan, and export a compliance-mapped report as evidence.

SOC 2 (Trust Services Criteria)	Findings map to the Common Criteria — CC6 logical access & boundary protection, CC7 system monitoring & change detection.
HIPAA Security Rule	Mapped to §164.312 technical safeguards: access control (a), audit controls (b), authentication (d), and transmission security (e).
PCI DSS 4.0	Network security controls — Requirement 1 and the related logging and cryptography requirements.
NIST 800-53	Control families AC, AU, SC and CM — access, audit, system & communications protection, configuration management.
CIS Benchmarks	Vendor-specific hardening references where applicable.
MITRE ATT&CK	Findings tagged with technique IDs (e.g. T1190, T1133) for threat-informed prioritization.

These mappings show which controls each finding supports — they are audit evidence, not a certification claim. For CRWLR's own security posture or a completed vendor security questionnaire, reach us at security@crwlr.io.

What We Read

We parse your config to extract network structure only — the minimum needed to identify security gaps. Nothing else.

✓Firewall policies — source/destination zones and addresses, services, action, logging, schedule
✓Zones, interfaces, and IP assignments
✓NAT rules and address translation mappings
✓VPN tunnel config — remote gateway, IKE version, encryption algorithms, DH groups, SA lifetimes
✓Security profile assignments — IPS, AV, web filter, SSL inspection profile names
✓Admin usernames, roles, trusted host restrictions, 2FA status
✓Certificate metadata — subject, issuer, key type, expiry status
✓Device identity — hostname, serial number, model, firmware version
✓Routing topology — static routes, BGP/OSPF neighbor IPs (not auth credentials)
✓HA cluster config — mode, priority, heartbeat interfaces

What We Never Touch

These fields exist in your config file. We never extract, store, or process them:

Passwords & hashes	Skipped entirely. FortiGate ENC blocks, PAN-OS phash elements, Sophos admin credentials — the parser ignores all of them.
VPN pre-shared keys	We record that PSK auth is in use. The actual key value is never read from the config.
RADIUS / LDAP secrets	We note the server exists and whether TLS is enabled. Shared secrets and bind passwords stay in your config.
SNMP community strings	Community label names are noted. The actual shared secret string is never extracted.
BGP / routing passwords	We record whether a neighbor password is set (true/false). The password itself is discarded.
Private keys & PEM data	Certificate subject and issuer are read. No private key material or certificate bodies are parsed.
API tokens & keys	Not extracted from any vendor format.

This is an architecture decision, not a policy. Our parser data types have no fields for secrets. There is nowhere to store them even if someone tried.

Don't take our word for it — sanitize first

Download our free one-file sanitizer and strip every secret from your config locally, before it ever leaves your machine. Audit results stay identical. Get the sanitizer →

Config File Lifecycle

Upload

Your file is sent directly to the scan engine. It is held in memory only — never written to disk or cloud storage.

Scan

We parse the structure in memory, run security checks, and save findings. The normalized policy structure (zones, object names, rules) and security findings are stored — no secrets, no raw file, no IP addresses.

Disposal

The raw config file is discarded from memory immediately after parsing. There is no retention setting because there is nothing to retain — the file never reaches storage.

This is an architecture decision. Our scan pipeline has no code path to persist raw config files. A SHA-256 hash of the original file is stored for audit verification.

What We Store

For transparency: while raw config files and secrets are never stored, the following network data IS retained in our database to power your security analysis:

Address object names	Firewall object names (e.g. "LAN_NET", "DMZ_SERVERS") are stored. Resolved IP addresses and subnets are never stored.
Zone names	Network zone labels (e.g. "lan", "wan", "dmz") are stored to map traffic flow and assess segmentation.
Hostnames & serials	Device hostname and serial number are stored to identify and track firewalls across scans.
Policy rules	Policy structure (object names, services, actions, logging) is stored for analysis. No resolved IPs.
Firmware version	Stored to match against known CVEs and recommend safe upgrade targets.

IP Addresses Are Never Stored

We reference your firewall's address object names and policy IDs — not the resolved IP addresses behind them. Your internal network topology stays on your firewall, not in our database. This is an architecture decision, not a setting.

Tenant Isolation

Every database query includes your account ID as a mandatory filter. Your data cannot appear in another customer's dashboard, API response, or background job.

✓Database — Row Level Security policies on every table
✓API — JWT verification scopes every request to your account
✓Storage — File paths include your account ID, validated on every operation
✓Background jobs — Alerts, scans, and cleanup run per-tenant, never cross boundaries

Encryption

✓In transit — TLS on all connections: API, dashboard, storage, webhooks
✓At rest — AES-256 encryption on database and storage
✓Encrypted backups — Sophos encrypted configs are decrypted in memory during the scan, never written to disk unencrypted. The password is not stored.

What Shows Up in Reports

Findings include enough context to act on them:

✓Policy name, source/destination zones, addresses, services
✓What is wrong and why it matters
✓Vendor-specific CLI commands to fix it
✓CIS benchmark references where applicable

If you enable IP obfuscation in account settings, traffic-related IP addresses are replaced with synthetic addresses. Policy structure remains readable — you need that to fix things.

Access Controls

✓10+ character passwords with complexity requirements and common password blocklist
✓Email verification required on signup
✓Short-lived JWT sessions with automatic expiry
✓Rate limiting on all endpoints, with stricter limits on auth routes
✓Generic error messages on login and signup to prevent account enumeration

Scan Isolation

Every scan runs in an isolated worker thread with hard resource limits. A malformed or malicious config cannot affect other customers or crash the platform.

✓Sandboxed worker threads with 512 MB memory cap and 5-minute timeout
✓XML configs pre-scanned for excessive nesting depth before parsing
✓Concurrent scan limits enforced globally and per-account
✓Worker crash marks the scan as failed — no impact on other operations

Infrastructure

API Hosting	Render (EU — Frankfurt)
Web Hosting	Vercel (Global edge CDN)
Database	Supabase (EU — Frankfurt, PostgreSQL with RLS)
Payments	Stripe (PCI Level 1 — we never see card numbers)
Email	Resend (transactional only — no marketing)
Analytics	None — no third-party tracking scripts
AI Summaries	Anthropic Claude API — your data is sent in a single request and not used for model training
CI/CD	Automated dependency audits, secret scanning, and type checking on every deploy

Responsible Disclosure

Found a security issue in CRWLR? We want to hear about it, and we'll work with you to fix it.

✓Email security@crwlr.io with details and reproduction steps. PGP key available on request.
✓We acknowledge reports promptly and keep you updated through to resolution.
✓Good-faith research is welcome — we won't pursue legal action for testing that respects customer data, avoids service disruption, and gives us reasonable time to remediate before public disclosure.

Please don't access or modify other tenants' data, run automated tests that degrade service for others, or disclose publicly before a fix ships. Test against your own account only.