Security

QIF Importer Pro holds a standing grant to a customer’s accounting records. This page describes how that grant is protected, and is the summary Intuit’s annual security assessment draws on.

Credentials

• Refresh tokens are stored as AES-256-GCM envelopes. The key comes from the process environment, never from the database, and never reaches a client bundle.
• Each envelope names the key that wrote it, so a key can be rotated by adding a new one and leaving the old one listed. Existing rows continue to decrypt and are re-wrapped as they are used.
• Ciphertexts are bound to the connection row they belong to, so one copied into another row fails to decrypt rather than silently working.
• Intuit rotates refresh tokens on refresh. We persist the rotation in the same transaction that uses it, so a crash cannot leave us holding an invalidated token.

Access

• Sign in is Intuit’s OpenID Connect. We never see or store a password.
• Accounts whose Intuit email is unverified cannot reach the application.
• Sessions are httpOnly, SameSite cookies signed with HMAC-SHA256 and valid for fourteen days.
• Every data query is scoped to the organizations you are a member of.

Data handling

• Uploads live in object storage under a per-organization prefix and are deleted on a schedule, not on request.
• Webhook deliveries from Intuit are verified with an HMAC-SHA256 signature over the raw request body before anything is parsed.
• Significant actions — connect, push, disconnect, purge — are written to an append-only audit log.

Writing to your books

• Nothing is created until you approve a plan whose contents you can read in full.
• Every created entity carries a key derived from the source line, and the database enforces uniqueness on it per company. A repeated or resumed push cannot duplicate a transaction.
• We create records. We do not modify or delete records we did not create.

Reporting a problem

Email support@example.com. We aim to acknowledge security reports within one business day.