Security Practices
Security Practices
Here's how we protect your data — both in the desktop app and the online invoicing portal.
Desktop app
Your data stays on your machine
Solid Accounting stores everything locally. Nothing leaves your computer unless you explicitly use an online feature like the invoicing portal.
Your files are encrypted
Company files are encrypted using SQLCipher (AES-256). Your password unlocks them. Without your password, the file is unreadable — even to us.
You can take your data anywhere
Company files use the .solid format. Backups are standard ZIP files. You can export to CSV, PDF, TXF, or OFX anytime.
No "phoning home"
Solid Accounting doesn't secretly talk to our servers. The only times it connects to the internet:
- License activation and checks — when you enter your key, then periodically
- Update checks — periodic
- Usage data and error reports — only if you said yes to the first-launch question (nothing is sent until you answer)
- Invoicing portal — only when you sync an invoice
Bank feeds (add-on)
Your bank credentials never touch our servers
When you connect a bank account, you authenticate directly with the aggregator (Plaid or Yodlee) through their hosted, sandboxed widget. Your bank username and password go straight to them over an encrypted HTTPS connection — our servers never see, store, or proxy those credentials.
Transaction data in transit and at rest
- Transaction data from the aggregator to our server: HTTPS, TLS 1.2 or newer
- Transaction cache on our server: AES-256-GCM at rest, stored in an isolated database with access restricted to the bank feed service
- Transaction data from our server to your desktop: HTTPS, TLS 1.2 or newer
- Cache retention: 7 days maximum, then automatically purged. The cache exists solely to handle sync retries and temporary connectivity failures.
Aggregator tokens
When you connect a bank, the aggregator issues an access token. We store this token encrypted at rest (AES-256-GCM) and use it only to fetch updated transactions on your behalf. If you disconnect the bank, the token is revoked with the aggregator and deleted from our servers.
What the aggregators see
Plaid and Yodlee are SOC 2 Type II certified and comply with financial data regulations. They see your bank login credentials (through their widget) and your transaction data. Their handling of that data is governed by their own privacy policies and security practices. See the Subprocessor List for details.
Cloud backup (add-on)
Cloud backup is a one-way, off-site backup of your company file. It uses a client-side, zero-knowledge encryption approach.
End-to-end encryption (zero knowledge)
- Client-side encryption: your company file is snapshotted, split into chunks, compressed, and encrypted on your device with AES-256-GCM before upload.
- Key management: from version 26.10, the backup key is derived (BLAKE3) from a 12-word recovery phrase (128 bits) generated at setup; backups set up before 26.10 keep a randomly generated key shown as a 24-word BIP39 phrase. Either way, the key is also wrapped by a key derived from your file password using Argon2id, so your password or the phrase alone can unlock backups. Rotating your password re-wraps the backup key without re-encrypting stored data.
- Recovery phrase: the phrase is your fallback if you forget your password. If you lose both the password and the recovery phrase, the data is unrecoverable — we have no reset mechanism and cannot decrypt your backups.
- In transit: TLS.
- We cannot read your backups. We (and the storage provider) only ever hold ciphertext.
Where backups are stored
- Managed (default): encrypted backups go to Backblaze B2 storage we provision, scoped per-license so one customer's storage credentials cannot reach another's data. US by default; EU-region storage available for EU customers.
- Your own folder or your own S3-compatible credentials: encrypted backups go where you direct them; no Solid Accounting infrastructure is involved.
Integrity
Stored backup chunks are content-addressed by hash and can be verified against their recorded hashes to detect corruption or tampering.
Online invoicing portal
What is encrypted
- Your customers' names and email addresses, and invoice contents (descriptions, line items, the copy of each invoice we keep, and the invoice emails we send, with their PDFs): encrypted at rest with AES-256-GCM
- Payment-provider tokens: encrypted at rest with AES-256-GCM
- Invoice amounts, dates, numbers and payment status are stored unencrypted, because the service uses them to track payments
- Data in transit: HTTPS with TLS 1.2 or newer
Your data is isolated
Every server-side query is scoped to the authenticated account, so one customer's records can't be returned to another. API tokens are scoped and revocable, and we throttle failed login attempts.
Where it's hosted
- Website, license server, payment endpoints and bank feed service: a single virtual private server at OVH (United States), which we administer ourselves. There is no separate payment platform.
- Each service runs as its own process under a dedicated, non-privileged system user
- Connections from the internet end at the server's web front end, which accepts HTTPS with TLS 1.3 or TLS 1.2 and refuses older versions. Your connection uses TLS 1.3 whenever your browser or computer supports it. The front end passes each request on to the service that handles it over plain HTTP inside the same server; that traffic does not leave the machine.
- Off-site backups: nightly encrypted archives to a Hetzner Storage Box (Germany), over SSH
- Managed cloud backup storage (opt-in add-on): Backblaze B2 (encrypted backup data only)
We don't handle your money
Payments flow directly from your customer to your Stripe, PayPal, or Square account. We never see credit card numbers, bank accounts, or payment credentials. PCI compliance is handled by Stripe, PayPal, and Square (all PCI DSS Level 1 certified).
On-device AI
Not currently enabled. On-device AI is coming soon. In the current version of Solid Accounting it is switched off and shown as "Coming soon", and no model is downloaded. When it is enabled, it will run on your computer and the protections in this section will apply.
Our AI features are designed to keep your data on your machine by default:
- Local inference: The AI model (Qwen3.5, Apache 2.0 licensed) runs on your computer. PDF extraction, corrections, and review all happen locally.
- Downloaded models are integrity-checked: the base model and every LoRA adapter is fetched over HTTPS from our CDN. Adapters are additionally signed with our Ed25519 keypair; the client verifies the signature before installation and refuses any bundle that fails.
- Tampered or unauthorized adapters are rejected: we embed the Ed25519 public key in the shipped binary. An attacker who replaces the CDN manifest cannot install adapters without our private key (stored in an HSM-backed vault with access limited to 2 named engineers).
- Staged rollouts contain bad releases: new adapter versions ship to a small cohort (5% of users) first and expand over a week. A regression detected in the early cohort halts the rollout before it reaches most users.
- Training Contribution data is anonymized before it leaves your device: HMAC-SHA256 tokenization of names, regex stripping of emails/phones/SSNs/EINs, per-company salt that never leaves your machine. See Data Processing Agreement for the full list.
Usage data and error reports (if you say yes)
- Off until you answer — nothing optional is sent until you answer the first-launch question, and "Don't send" sends nothing.
- Tied to an install ID — each report carries a random install ID, the same one sent at license activation. Paid-feature use events are also sent with the license's activation ID. They don't contain your name or email.
- No books — no transactions, amounts or balances. Error messages are shortened, not filtered, so one can occasionally include a name or file path from what you were doing.
- Kept 90 days — then deleted.
- Encrypted — sent over HTTPS.
- Transparent — Settings → Privacy shows what's been sent and can delete it. See the Privacy Policy.
People security
- Background checks: All employees and contractors with access to production systems or user data undergo background checks
- Security training: Team members complete security awareness training annually, covering phishing, social engineering, and secure coding practices
- Least privilege: System access follows the principle of least privilege — each person has only the access required for their role, reviewed quarterly
Secure development
- Code review: All code changes are reviewed by at least one other developer before merging
- Dependency scanning: We monitor dependencies for known vulnerabilities using automated tools and apply patches promptly
- Signed releases: All desktop application releases are code-signed (Windows and macOS) so you can verify they haven't been tampered with
- No secrets in code: API keys, credentials, and secrets are stored in environment variables and secret management systems, never in source code
Logging and monitoring
- Server access logs: All API requests to the payment service and license server are logged with timestamps, request paths, and response codes (never request bodies containing financial data)
- Authentication events: Login attempts (success and failure), password changes, and session activity are logged
- Log retention: Server logs are retained for 90 days, security-relevant logs for 1 year
- Alerting: Automated alerts for anomalous patterns (spike in failed logins, unusual API usage, error rate increases)
Physical security
We do not own or operate any data centers. Our production server is a virtual private server rented from OVH, and our off-site backup archives live on a Hetzner Storage Box. Physical security at those facilities — access control, surveillance, power and environmental protection — is the hosting provider's responsibility and is described in their own documentation.
To be clear about what that does and doesn't mean: Solid Accounting does not hold a SOC 2, ISO 27001, or any comparable certification, and we do not claim one by way of our vendors. A provider's certification covers that provider's facilities and operations, not our software or our administration of the server. What we can tell you about is the controls we actually run ourselves — described elsewhere on this page: HTTPS with TLS 1.2 or newer for every connection from the internet, encrypted backup archives at rest, per-service system accounts with least-privilege credentials, a default-deny host firewall, and encryption of your company file on your own machine under a key we never receive.
Penetration testing
We conduct periodic security assessments of our infrastructure and applications. We plan to engage third-party penetration testing firms for annual assessments beginning in 2026. Results inform our security roadmap and are addressed by severity.
Key rotation
- API keys: Automatically rotated on a regular schedule
- Encryption keys: Rotated on major version upgrades
- Session tokens: Short-lived with automatic refresh
- Database credentials: Rotated when team membership changes and on a scheduled basis
- AI adapter signing key (Ed25519): Stored in an HSM-backed vault; access limited to 2 named engineers. Rotated if the key is suspected compromised or on major-version boundaries. A new public key in the client binary is shipped as part of the next update; old-key adapters remain installable on clients running the prior version.
- Per-company Training Contribution salt: HMAC-SHA256 salt for name tokenization, generated on first opt-in, stored on device only (never transmitted). Rotated annually to bound the window for any future re-identification attempts; old tokens remain valid in already-contributed data.
Data classification
We classify data into three tiers:
| Classification | Examples | Controls |
|---|---|---|
| Public | Website content, documentation, pricing | No special controls |
| Confidential | License data, support correspondence, telemetry | Encrypted in transit, access-controlled |
| Restricted | Payment credentials, encryption keys, API secrets | Encrypted at rest and in transit, strict access controls, audit logging |
Disaster recovery
- Recovery Point Objective (RPO): 24 hours — in a disaster, we may lose up to 24 hours of data for server-side services
- Recovery Time Objective (RTO): 4 hours for the payment service, 24 hours for the license server and website
- Desktop data: Your local data is not affected by our server outages. Your backups are your disaster recovery plan for desktop data
- Backup testing: We periodically test backup restoration to verify recoverability
Breach history
As of March 2026, Solid Accounting has not experienced a security breach, data incident, or unauthorized access to user data. If this changes, we'll disclose it here and follow the incident response process described above.
Found a security bug?
We'd genuinely like to know. Email security@solidaccounting.com with:
- What you found
- How to reproduce it
- Your contact info
What we promise
- We'll acknowledge your report within 48 hours
- We'll assess severity within 5 business days
- Critical issues get patched within 7 days
- We'll credit you in release notes (with your permission)
- We won't sue you for responsible security research
What's in scope
- Solid Accounting desktop app
- solidaccounting.com
- The payment service and API
- License server
What's not
- Third-party providers (report to Stripe/PayPal/Square directly)
- Social engineering our team
- Denial of service attacks
Incident severity classification
| Severity | Definition | Response time | Example |
|---|---|---|---|
| Critical | Active data breach or unauthorized access to user data | Immediate containment, 72-hour user notification | Database exfiltration, credential compromise |
| High | Vulnerability that could lead to data breach if exploited | Patched within 7 days | SQL injection, authentication bypass |
| Medium | Vulnerability with limited impact or requiring unlikely conditions | Patched within 30 days | Information disclosure, CSRF |
| Low | Minor issue with minimal security impact | Addressed in next release | Missing security headers, verbose error messages |
If something goes wrong
If there's a data breach:
- We contain the problem immediately
- We investigate what happened and who's affected
- We notify affected users within 72 hours (as required by GDPR Art. 33 and our Data Processing Agreement)
- We fix the vulnerability
- We publish a transparency report explaining what happened and what we've done to prevent it from happening again
Software updates
Security patches go out as fast as we can ship them. Critical security fixes are pushed to everyone with active maintenance. For users without active maintenance, we'll publish security advisories and make critical patches available for the current major version for at least 12 months after the next major version ships. All updates are signed so you know they're really from us.