Security at Cardboard

Cardboard handles your company's payments, so we design the system so that we are never the single point of failure for them. This page answers the security questions we get most often. If yours is not here, email hello@cardboard.inc and we will add it. If you have found a vulnerability, see how to report it at the end of this page.

Payment cards

• Our cards are issued by Adyen, a licensed bank and PCI DSS Level 1 certified payment provider. See Adyen security.
• We never store card numbers. When you reveal a card in the app, the card details are encrypted from Adyen all the way to your device with keys we do not have access to.
• Your cards do not depend on Cardboard being online. Authorizations are handled by Adyen, so payments continue to work even if our service is down.

Authentication

• We do not store passwords, and there are no passwords to steal. You sign in with your Google or Microsoft work account, or with a one-time sign-in link sent to your work email.
• One-time sign-in links expire after one hour, and we limit how many links can be requested and how many sign-in attempts can be made per hour.
• Sensitive actions, such as revealing card details, require that you authenticated recently. If your session is older than three hours, we ask you to sign in again before proceeding.
• Our API and MCP server use OAuth 2 with PKCE and short-lived access tokens. Our mobile app binds its tokens to a key in the phone's secure hardware with DPoP, so a leaked token cannot be used from another device.

Authorization and data isolation

• Every request is scoped to one organization. Data from one organization is never visible to another, and every view checks that the signed-in user is a member of the organization it is serving.
• Access within an organization is role-based. Members see and manage only their own subscriptions, cards, and receipts. Leads see everything in the organization but manage only their own. Accountants also manage the accounting settings. Admins have full access, including inviting members, creating cards, and reviewing access requests.
• A card's details can only be revealed by its owner or by members an admin has explicitly granted access, and only after re-authenticating.
• Access changes are recorded. Role assignments, card access grants and removals, team changes, and sign-ins all go into an audit log.

Encryption

• All traffic between your browser, our services, and our partners is encrypted with TLS.
• All data is encrypted at rest with AES-256 by Google Cloud, including databases, file storage, and backups.
• Credentials for third-party systems, such as the tokens that connect your accounting system, are encrypted at the application level before they are stored in the database.
• Identity documents uploaded for know-your-customer checks are encrypted with a key that is unique to your organization and managed in Google Cloud KMS. Every access to such a document is logged.

Infrastructure

• Everything we run ourselves runs on Google Cloud in the Netherlands (region europe-west4), and our databases and backups stay in the European Union.
• We use AI models from Anthropic, Google, and OpenAI to read receipts and other documents you send us. That processing can happen outside the European Union, under each provider's data processing addendum, and none of the providers use your data to train their models.
• We prefer third-party services with strong security and privacy practices, and we keep the list of services that see customer data short. The current list of sub-processors and their locations is in our data processing agreement.
• Databases, caches, and internal services live on a private network with no public IP addresses. Only the web front end is reachable from the internet. Our engineers reach the private network only through Tailscale.
• All web traffic passes through Google Cloud Armor, a web application firewall configured with the OWASP Core Rule Set, before it reaches our application.
• Our production database runs in a regional high-availability configuration with automatic failover to a second zone.
• All infrastructure is defined in code and reviewed and deployed the same way as application code. Nothing is configured by hand.
• Google Cloud undergoes regular independent audits, including ISO 27001, SOC 1, SOC 2, SOC 3, and PCI DSS. See Google Cloud compliance.

Backups and recovery

• The production database is backed up automatically every day, and we keep the last 30 daily backups.
• Point-in-time recovery lets us restore the database to any moment within the last seven days.
• Database instances have deletion protection enabled, and backups are retained even if an instance is deleted.

Team and access

• Every account our team uses is personal. We sign in to all our own tools and third-party services with single sign-on through our Google Workspace accounts, with two-factor authentication required.
• Access to production systems is limited to the few engineers who operate them, and Tailscale requires an enrolled device and the engineer's own single sign-on identity.
• Changes our staff make through our internal admin tools are logged.
• When our staff need to access your account to help you, they sign in through a support session that expires after 20 minutes. Every such access is recorded in our audit log.

Browser extension

• Our browser extension is optional, and each of your employees installs and enrolls it themselves.
• Pulse, the usage part of the extension, decides in the browser whether a visited site is one of the services your organization pays for, and sends us only that a service was used on a given day. It sends nothing about which pages were visited, no timestamps or durations, and nothing about any other site.
• The list of services we match against is curated by us. We exclude services where usage would reveal something personal, such as occupational healthcare, personal-use services, and travel bookings.
• Employees see exactly what their organization sees about them. Our CTO published his own profile as an example at cardboard.inc/pulse/cto, and explains the design in Usage insights without the surveillance.
• Fetcher, the receipt part of the extension, uses the sessions you are already signed in to in your own browser to download receipts for payments that are missing one. Only the receipt and payment metadata is uploaded, never your credentials.

Development and operations

• Every code change goes through a pull request that another engineer approves and that must pass our automated tests, type checking, and linters before it can be merged. Branch protection enforces this.
• GitHub security advisories alert us about known vulnerabilities in our dependencies, and Renovate proposes updates as soon as they are released. We apply them continuously and deploy small changes many times a week.
• Codex Security scans our code base for vulnerabilities, and we act on what it finds.
• Application errors are reported to us automatically, and our engineers look at them as they come in.
• If we discover a breach that affects your data, we notify you without undue delay, as our data processing agreement requires.

Frequently asked questions

Do you hold SOC 2, ISO 27001, or similar certifications?

No. We have chosen to spend our time on the practices above rather than on certification. Our engineering team is all senior and includes former database administrators and DevOps engineers from some of Norway's largest companies. The practices on this page are the ones they brought with them. We build on providers that are certified, Google Cloud and Adyen, and we design Cardboard so that it is never in the critical path for your payments. If a certification is a hard requirement for you, let us know.

Do you do penetration tests?

We have not commissioned an external penetration test yet. Instead we layer the controls described under development and operations and infrastructure: review of every change, scanning of our code and dependencies, a web application firewall, and a private network for everything but the web front end. If you find a vulnerability despite this, we want to hear about it.

Where is my data stored?

In Google Cloud in the Netherlands, with backups in the European Union. Documents you send us can be read by AI models outside the European Union. See infrastructure for details and for the list of every sub-processor.

What usage data do you collect?

We collect product usage events and application errors so that we can improve the product and help you faster when something goes wrong. We do not sell data. Our privacy policy describes what we collect and why.

How long do you keep my data, and can I have it deleted?

We keep your data for as long as you have an account with us, as described in our privacy policy. When you ask us to close your account, we delete your data.

We are a financial entity subject to DORA. Can you support us?

Yes. We offer a DORA addendum to our service agreement.

How do I report a vulnerability?

Email security@cardboard.inc with enough detail for us to verify the finding: the affected URL or endpoint, the steps to reproduce, and what you observed. We practice responsible disclosure and will confirm the finding and tell you when it is fixed. We do not respond to reports that arrive without verifiable details, and we do not run a bug bounty program.