Security & compliance
This page is for the security reviewer with a questionnaire, and for the workspace admin who has to fill it in.
Controls by plan
Section titled “Controls by plan”| Control | Plan |
|---|---|
| Two-factor sign-in, and a workspace setting to require it | Every plan |
| Workspace audit log, with CSV export | Team keeps 90 days, Enterprise keeps everything. Free and Pro see the last 7 days. |
| SAML single sign-on | Enterprise |
| Retention policies and legal hold | Enterprise |
| Every tracker write attributed to a named member | Every plan with tracker sync |
Two-factor sign-in
Section titled “Two-factor sign-in”Anyone who signs in with a password or with Google can turn on two-factor sign-in from Two-factor authentication in their account settings. It uses an authenticator app (any TOTP app) and gives you ten one-time recovery codes for when the phone isn’t around.
- Password and Google sign-ins both ask for the code. A hijacked Google account shouldn’t be a hijacked CardBoard account.
- SAML sign-ins skip it. Your identity provider owns that factor.
- A code works once. It can’t be replayed inside its 30-second window, and failed attempts are rate-limited.
- API keys and MCP tokens are unaffected. They’re issued from a session that already passed sign-in.
Require it for a workspace
Section titled “Require it for a workspace”A workspace admin can turn on Require two-factor in the workspace’s Security settings, on any plan.
| Topic | Details |
|---|---|
| Who it applies to | Admins and members. Guests are exempt, so an outside reviewer can open a shared board without an authenticator app. SAML members are exempt too. |
| What happens when you turn it on | Nobody is signed out. Each member without two-factor is sent to set it up on their next page load. |
| Before you can turn it on | Your own account needs two-factor first, so you can’t lock yourself out of the setting. |
Workspace audit log
Section titled “Workspace audit log”Admins find the audit log on the workspace’s Audit log page. It answers “who did what, from where” for the things that govern a workspace: who got in, who got access, and what left.
| Family | Events |
|---|---|
| Sign-in | Signed in (with the method, and whether a second factor was used), two-factor turned on or off, recovery code used |
| Membership | Member joined, removed, or changed role; invitation sent or revoked |
| Board access | Guest link turned on, off, or changed; collaborator added, removed, or changed role; board visibility changed |
| Boards | Board deleted, restored, or transferred |
| Trackers | A tracker connected or disconnected, for a board or for the workspace |
| Exports | Board PDF or CSV, member CSV, and audit log CSV |
| Settings | Security, SSO, and retention settings changed, with before and after values |
Each event records the person who acted and, when an AI agent acted, the member behind it, plus the IP address and browser. Filter by person, event family, or date range, and export to CSV. The export shows up in the log too.
Not in the audit log: card edits, comments, and reactions (those are in each board’s activity), and members connecting their personal tracker accounts, which belong to the person, not the workspace.
How much history you see:
| Plan | History |
|---|---|
| Free, Pro | The last 7 days |
| Team | 90 days |
| Enterprise | Everything, or the window your admin sets |
Events are recorded on every plan, so upgrading shows your history instead of an empty page.
Retention and legal hold
Section titled “Retention and legal hold”Enterprise admins set retention in the workspace’s Security settings. Each window is 30, 90, or 365 days, or keep forever.
| Setting | What it does |
|---|---|
| Deleted boards | Boards in the trash are permanently deleted after the window, along with their cards, links, and attachments. The default is to keep them. |
| Audit log | Events older than the window are removed. The Enterprise default is to keep everything. |
| Legal hold | Pauses every purge in the workspace, including deleted boards, audit events, and rejected agent proposals, until it’s lifted. You can record a reason. |
Purges run nightly. Every retention change is an audit event, and every purge records what it removed.
Two system defaults apply to every workspace: rejected agent proposals are removed after 90 days, and inactive temporary guest accounts after 30.
Single sign-on
Section titled “Single sign-on”SAML SSO is available on Enterprise and set up with us. Members who sign in through your identity provider get their CardBoard account on first sign-in, and SSO sign-ins are recorded in the audit log.
Authentication methods
Section titled “Authentication methods”| Method | Used for |
|---|---|
| Password | Standard email and password sign-in, with optional two-factor |
| Social sign-in, with optional two-factor | |
| Microsoft Entra ID (Azure AD) | Social and enterprise sign-in |
| SAML SSO | Enterprise single sign-on |
| HTTP Basic (email + API key) | REST API |
OAuth 2.0 (mcp scope) | MCP endpoint for AI agents |
Authorization
Section titled “Authorization”Layered permissions: workspace roles plus board roles, enforced on the server by policy classes on a least-privilege model. Every tracker write is attributed to the member who made it, and on Azure DevOps and Jira it’s made with their own tracker account. See Trackers.
Encryption
Section titled “Encryption”- In transit: TLS on every connection. Heroku negotiates TLS 1.2 or later.
- At rest: files on Amazon S3 with bucket-level encryption. Tracker access and refresh tokens, webhook secrets, and two-factor secrets are encrypted in the database with Active Record encryption. Recovery codes are stored only as bcrypt hashes.
Hosting and data
Section titled “Hosting and data”CardBoard runs on Heroku in the United States, with file storage on Amazon S3. Production and staging are separate environments. Your data is exportable (CSV), and backup and recovery details are available on request.