A Trello board set to Public is visible to anyone on the internet who has its link, and boards often carry roadmaps, hiring pipelines, customer names and even credentials pasted into cards. Visibility is chosen by board admins one board at a time, so the organisation-wide answer is a mix of Enterprise-wide permissions, Power-Up administration, and identity controls that come from linking Trello to an Atlassian organisation. This guide explains how to secure Trello from the customer side: board and Workspace visibility, public board management, Enterprise-wide permissions, Power-Up administration, API keys and tokens, managed accounts, SAML SSO through Atlassian Guard, and shadow IT request controls. It is written for Trello Enterprise admins, Atlassian organisation admins and data security teams. For organisation-level Atlassian controls shared with Jira and Confluence, see the Atlassian Cloud Security Guide; this page stays specific to Trello.
This is an independent guide from NHI Mgmt Group, based on Atlassian's public Trello documentation as of November 2026. It is not sponsored or reviewed by Atlassian. Product features change, so confirm settings against Atlassian's current documentation.
Key takeaways
- Know the four visibility levels. Private, Workspace, Organization (Enterprise) and Public; Public boards can be viewed by anyone with the link, though only members can edit.
- Review public boards centrally. The Enterprise Dashboard "Public boards" page lets admins move one or many public boards to "Workspace Visible" in bulk.
- Turn on Power-Up Administration. It is off by default; once on, Power-Ups not in use become disallowed and admins allow or disallow each one.
- Use Enterprise-wide permissions. Workspace Visibility set to Private, a membership domain allowlist, board creation limits and attachment source restrictions apply across every Enterprise Workspace.
- Bring identity under your organisation. Verify domains, claim accounts and use Atlassian Guard Standard for SAML SSO and authentication policies on managed Trello accounts.
How identity and access work in Trello
Trello users have Atlassian accounts. Boards live in Workspaces, and a Trello Enterprise groups many Workspaces under Enterprise admins. Identity policy comes from the Atlassian organisation: when you verify a domain and claim accounts, those accounts become managed accounts and follow the organisation's authentication policies.
Board visibility
| Visibility | Who can see the board (Atlassian docs) | Recommended use (NHI Mgmt Group recommendation) |
|---|---|---|
| Private | Board members, plus Workspace admins in paid Workspaces | Confidential work: HR, finance, security, customer data |
| Workspace | Workspace members can view and edit by default; board admins can stop members joining or editing | Default for team boards |
| Organization (Enterprise) | Anyone in at least one Workspace in the Enterprise | Company-wide reference boards |
| Public | Anyone with the link can view; only board members can edit; not indexed by search engines; board settings control voting and commenting by any Trello account | Published roadmaps or community boards only, with an owner and review date |
Board admins change visibility from the board menu under Visibility. Not being indexed by search engines does not make a public board private: anyone who obtains the link can view it, so treat Public as publication.
Choosing a visibility level
Our recommended decision rule for board owners, which you can publish internally as a one-page standard:
- Private: any board holding personal data, contracts, pricing, incident notes, hiring decisions or security work. Remember that Workspace admins in paid Workspaces can still see private boards, which helps recovery when an owner leaves.
- Workspace: routine team work where everyone in the Workspace already shares context. Ask board admins to turn off joining or editing by Workspace members where only a few people should change cards.
- Organization: reference boards meant for everyone in the Enterprise, such as office information or company calendars, with nothing sensitive on cards or attachments.
- Public: only content you would put on your website. Assign an owner, set a review date, and decide whether any Trello account may vote or comment.
Smaller organisations without Enterprise rely on board admins applying this rule; Enterprise customers can back it with the Enterprise-wide permissions below and the Public boards review.
Sign-in and provisioning
| Control | Requirement (Atlassian docs) | Effect |
|---|---|---|
| Verified domain | Atlassian organisation; DNS TXT record or HTML file; a domain can be verified by one organisation only | Lets you claim accounts on that domain |
| Claimed (managed) accounts | Verified domain | Accounts join the default authentication policy (with Guard) and meet its requirements at next login |
| SAML SSO | Atlassian Guard Standard and the Atlassian Cloud app in your identity provider; legacy Trello SSO apps do not work with Guard Standard | Managed users sign in through your identity provider |
| Provisioning | Atlassian SCIM API or identity provider integration (Trello's own SCIM API is being retired) | Creates accounts; invite users to an Enterprise Workspace to grant a licence |
| Link Enterprise to organisation | Enterprise subscription; admin in both | Managed-user security features, Organization visible boards, claiming non-Enterprise Workspaces, Enterprise data restrictions |
Atlassian's suggested safe rollout is a default authentication policy that does not enforce SSO, then a second policy with SSO for one test user, before moving everyone across. Users are not logged out when accounts are claimed; the policy applies at their next login. Two-factor authentication can be enforced through an authentication policy for managed accounts. See the SAML Security Guide and the SCIM Provisioning Guide.
Admin roles and privileged access
| Role | Scope (Atlassian docs) | Least-privilege guidance |
|---|---|---|
| Atlassian organisation admin | Domains, claimed accounts, authentication policies, SSO, app request settings | Shared with Jira and Confluence administration; two or three named people |
| Enterprise admin | Enterprise Dashboard: members, Workspaces, public boards, Enterprise-wide permissions, Power-Up administration, seat assignment rules | Small named group, reviewed quarterly (our cadence) |
| Workspace admin | Workspace settings and visibility, members, private boards in paid Workspaces | Team leads; recover orphaned Workspaces when an admin leaves |
| Board admin | Board visibility, membership and editing rights | Brief board admins on when Public is acceptable |
The Enterprise setting for who can give Enterprise seats to users is worth restricting, because a seat brings a user under Enterprise policy and billing. See the SaaS Admin Account Protection guide.
Enterprise-wide permissions
Set from the Enterprise User Management Dashboard under the Workspace Settings tab, these apply to every Enterprise Workspace.
| Setting | Default and options (Atlassian docs) | Recommended baseline (NHI Mgmt Group recommendation) |
|---|---|---|
| Workspace Visibility | Workspace admins decide by default; Private overrides every Workspace, hiding them from non-members | Private |
| Workspace Membership Restrictions | Email domain allowlist for Workspace members | Your domains plus approved partner domains |
| Workspace Board Creation Restrictions | Any Workspace member, Workspace admins only, or Nobody, per board type | Restrict creation of public boards to Workspace admins, or Nobody |
| Workspace Board Invitation Restrictions | Controls who can be added to Workspace boards | Limit to Workspace members or allowed domains |
| Attachment Restrictions | All sources allowed by default; each source on or off; Trello links always allowed | Allow only your approved storage services and local upload |
Organisation admins with a Jira, Jira Service Management or Confluence Enterprise plan can also turn on Require admin review under Security > App requests in Atlassian Administration, so managed accounts must request access before signing up for Trello. Marking a request Resolved does not grant access by itself.
Integrations, API tokens and service accounts
Power-Ups and API tokens are the non-human identities in Trello. Each API key belongs to a Power-Up and is generated in the Trello Auth tab at trello.com/apps/admin. A user token acts on behalf of the user who granted it.
Power-Up administration
- Turn it on: Enterprise Dashboard > Power-Ups tab > Turn on Power-Up Administration. Power-Ups in use stay allowed; others become disallowed.
- Allow or disallow: per Power-Up through Allow Power-Up or Disallow Power-Up, or in bulk with Change Permissions.
- Review usage: the page shows which Power-Ups are in use and on how many boards; use this to retire unused ones.
- Keep it on: turning administration off lets members enable any Power-Up again and removes the in-use view.
API tokens
| Parameter (Trello REST API) | Values | Guidance |
|---|---|---|
scope | read, write, account | Request read only where the integration does not change boards; account only where member email is needed |
expiration | 1hour, 1day, 30days, never | Our recommendation: 30days or shorter for scripts, never never for shared automations |
| Allowed origins | Must match the return_url; wildcards supported | List exact origins in production; drop localhost after development |
| Revocation | Account settings > Applications, or DELETE on /1/tokens | Revoke on owner departure and on any exposure |
Atlassian states that the API key can be public but tokens grant access to the user's whole account and must be stored securely. Run automations from a dedicated account owned by the platform team (our recommendation), keep tokens in a secrets manager, and see the SaaS API Token Security Guide. If a token is exposed, follow the Work SaaS API tokens response guide.
Logging and detection
Trello's detection signals come from the Enterprise Dashboard and from the Atlassian organisation. Build a routine around them rather than waiting for a public board to be reported.
| Source | What it shows | What to watch for |
|---|---|---|
| Enterprise Dashboard: Public boards | Public boards in Enterprise Workspaces (not personal spaces) | New public boards since the last review |
| Enterprise Dashboard: Power-Ups | Power-Ups in use and board counts | New Power-Ups on many boards; disallowed ones requested |
| Atlassian Administration: App requests | Requests from managed accounts to use Trello | Teams adopting Trello outside the Enterprise |
| Atlassian Administration: managed accounts | Claimed accounts and authentication policy membership | Accounts outside the SSO policy |
| User Applications page | Tokens each user has granted | Tokens with never expiry or unknown apps |
Confirm in Atlassian Administration which Trello events your Guard tier records in the organisation audit log, and forward it to your SIEM where available. See the SaaS Audit Log Retention and Licensing Guide.
Metrics that show it is working:
- Public boards in Enterprise Workspaces, each with an owner and review date.
- Share of Trello users who are managed accounts in an SSO policy (target 100% for corporate domains).
- Allowed Power-Ups versus in use, and Power-Ups with an internal owner.
- Workspaces outside the Enterprise claimed or closed per quarter.
- Integration tokens with an expiry of 30 days or less.
Hardening baseline
A phased rollout. Changing visibility and disallowing Power-Ups take effect at once and can be reversed by an admin, so announce changes to board owners first. SSO enforcement applies at each user's next login.
- Inventory: export the Public boards list, Power-Ups in use, Enterprise admins and Workspace admins.
- Verify domains and claim accounts in the Atlassian organisation.
- Configure SAML SSO with Atlassian Guard Standard, test with one user in a separate policy, then enforce. Enforce 2FA through policy for any non-SSO accounts.
- Link the Enterprise to the organisation and provision through Atlassian SCIM.
- Set Enterprise-wide permissions: Workspace Visibility Private, membership domain allowlist, board creation and invitation limits, attachment sources.
- Review public boards and move unjustified ones to Workspace Visible in bulk.
- Turn on Power-Up Administration and disallow unused Power-Ups.
- Turn on app request review for managed accounts where your Atlassian plan includes it.
- Set token practice: short expirations, minimal scopes, dedicated automation account.
- Schedule reviews: monthly public board review, quarterly admin and Power-Up reviews (our cadence).
| Organisation profile | Priority choices |
|---|---|
| Standard or Premium Workspaces | Private Workspace visibility, board admin briefings, 2FA on accounts, token hygiene |
| Enterprise | Enterprise-wide permissions, public board review, Power-Up Administration, seat assignment rules |
| Enterprise with Atlassian Guard | All of the above plus SAML SSO, authentication policies, claimed accounts, Enterprise data restrictions |
Common misconfigurations
- Treating "not indexed" as private: anyone with a public board's link can view it.
- Public boards in personal spaces: they do not appear on the Enterprise Public boards page. Move work boards into Enterprise Workspaces.
- Power-Up Administration left off: members can add any Power-Up to any board.
- SSO configured with a legacy Trello SSO app: use the Atlassian Cloud app with Guard Standard.
- Tokens with
neverexpiry on personal accounts: use short expiry and a dedicated account. - Credentials pasted into cards: store secrets in a secrets manager and link to it instead.
Apply Atlassian's product updates and security advisories as published.
Framework mapping
| Trello control | NIST SP 800-53 Rev 5 | NIST CSF 2.0 | ATT&CK technique it helps address |
|---|---|---|---|
| Managed accounts, SAML SSO, authentication policies | IA-2, AC-2 | PR.AA-01 | T1078.004 Cloud Accounts |
| Board visibility, Enterprise-wide permissions | AC-3, AC-6 | PR.AA-05, PR.DS-01 | T1213 Data from Information Repositories |
| Power-Up Administration, token scope and expiry | CM-7, SA-9 | GV.SC-07 | T1528 Steal Application Access Token |
| Public board and app request reviews | AU-6 | DE.CM-03 | T1567 Exfiltration Over Web Service |
Practitioner checklist
- Domains verified and accounts claimed in the Atlassian organisation.
- SAML SSO through Atlassian Guard Standard enforced by authentication policy.
- Enterprise linked to the organisation and provisioning through Atlassian SCIM.
- Workspace Visibility set to Private with a membership domain allowlist.
- Public board creation limited and existing public boards reviewed monthly.
- Power-Up Administration on, with unused Power-Ups disallowed.
- Attachment sources limited to approved storage.
- Integration tokens scoped minimally, short expiry, held by a dedicated account.
- Enterprise admins and seat assignment rights limited to named people.
Standards and references
- Atlassian: Change the visibility of a board
- Atlassian: Manage public boards in an Enterprise
- Atlassian: Enterprise wide permissions
- Atlassian: Enterprise Power-Up administration
- Atlassian: Configure SSO for Trello with Atlassian Guard
- Atlassian: Manage Shadow IT in Trello
- Atlassian Developer: Trello REST API authorization
Related NHI Mgmt Group resources: Atlassian Cloud Security Guide, Secure File Sharing Guide, SaaS and OAuth App Governance Guide, Shadow SaaS and Unsanctioned App Discovery Guide, SaaS Security Guide.