Asana holds project plans, launch dates, customer requests and internal decisions, and access to it is shaped by a handful of admin console settings that many organisations never revisit after rollout. The settings that matter most are sign-in method, guest rules, which apps and tokens can reach the API, and how AI features use workspace content. This guide explains how to secure Asana from the customer side: SAML and Google sign-in, two-factor authentication, super admin and admin roles, guest and sharing controls, app approval mode, personal access tokens and service accounts, the Audit Log API, and Asana AI controls. It is written for Asana super admins, collaboration platform owners and SaaS security teams. If a token has already leaked, use the Work SaaS API tokens response guide; this page covers prevention and configuration.
This is an independent guide from NHI Mgmt Group, based on Asana's public documentation as of November 2026. It is not sponsored or reviewed by Asana. Product features change, so confirm settings against Asana's current documentation.
Key takeaways
- Require SAML, but test it first. Set SAML to optional, confirm a super admin can sign in, then switch to "Required for all members, except guest accounts". Saving SAML signs everyone out.
- Guests need their own controls. SAML and Google sign-in apply to members only, so require 2FA (which covers members and guests) and restrict who can invite guests.
- Turn on app approval mode. The default "Allow all apps" uses a blocklist; "Require app approval" turns the Apps tab into an allowlist with a request workflow.
- Shorten token life. Personal access tokens last 10 years by default; set Token expiration to 30, 60 or 90 days and use scoped service accounts for organisation automation.
- Stream audit events. Enterprise+ (or Enterprise with the Compliance Management add-on) gives the Audit Log API through a service account, including failed SAML sign-ins.
How identity and access work in Asana
An Asana organisation is tied to verified email domains. People on those domains are members; everyone else invited in is a guest. This split matters because Asana's global authentication settings apply to members only. Guests are not affected by required SAML or Google sign-in, so they need separate controls.
| Sign-in control | Availability (Asana docs) | What it does | Recommended use (NHI Mgmt Group recommendation) |
|---|---|---|---|
| SAML authentication | Enterprise, Enterprise+ and Legacy Enterprise organisations or divisions; super admin | Optional or "Required for all members, except guest accounts"; can be limited to identity provider groups | Required for all members, after testing in optional mode |
| Google sign-in | Paid plans with Google Workspace; not on Division Plans | "Required for all members, except guests"; disables existing member passwords | Use where SAML is not licensed and Google Workspace is the identity source |
| Two-factor authentication | All paid plans | Optional, or required for all members and guests; does not apply to Microsoft SSO, Google SSO or SAML sign-ins | Required, so guests and any password users are covered |
| Password controls | Paid plans; super admin | Default minimum 8 characters with a "fair" entropy score; minimum can be raised to 20; forced reset for all members | Raise the minimum for any remaining password users (our recommendation: 14 or more) |
| SAML session timeout | With SAML | 1 hour to 30 days; separate mobile session timeout, disabled by default | Our view: 12 to 24 hours on web, and set the mobile timeout |
SAML setup details: the path is Admin console > Security > Global authentication settings > SAML authentication. Asana needs the identity provider sign-in URL and X.509 certificate, uses entity ID https://app.asana.com/ and ACS URL https://app.asana.com/-/saml/consume with the emailAddress NameID format, requires HTTP POST binding, and requires the assertion or full response to be signed. Asana does not sign authentication requests, so set request signing off on the identity provider side. Plan the change for a quiet period, because saving SAML logs out every user, including the admin making the change. See the SAML Security Guide.
Mobile: Asana's mobile apps support biometric unlock, and admins can set app permissions that restrict screen captures, attachments and copy and paste. Use these for organisations where phones are not fully managed.
Guests and sharing
| Setting | Options (Asana docs) | Recommended baseline (NHI Mgmt Group recommendation) |
|---|---|---|
| Guest access management | Admins only; admins and members; anyone, including guests | Admins only, or admins and members with a quarterly guest review |
| Read-only link sharing | Public sharing allowed; organisation sharing only; turned off | Organisation sharing only |
| Team and project privacy defaults | "Public to organization" or "Membership by request" | "Membership by request" where teams handle confidential work |
| File attachment controls | Disable specific attachment methods or all attachments | Turn off attachment sources outside your approved storage |
| Guest API use (Enterprise+) | Admin console > Apps > App settings > User permissions: API access for apps and for PATs, toggled separately | Off for guests unless a partner integration needs it |
For joiners and leavers, connect SCIM provisioning, which super admins manage, so deactivation in the identity provider removes Asana access. See the SCIM Provisioning Guide and SaaS deprovisioning.
Admin roles and privileged access
Asana has two organisation-wide admin roles, plus division and team-level roles with narrower scope. Only members can hold admin roles; guests cannot.
| Role | Privileges (Asana docs) | Least-privilege guidance |
|---|---|---|
| Super admin | Full admin feature set: SCIM, organisation-wide password resets and security settings, domain data export, service accounts, Google sign-in requirement, password strength, app management; can add other super admins | Two or three named people in IT or security; review quarterly (our cadence) |
| Admin | User and team management, individual password resets, branding, announcements, associated email domains | IT help desk and business owners who need user management only |
| Division super admin and division admin | View and manage members within their paid division only | Use for business units with separate administration |
| Team admin | Team-level control, no organisation-wide settings | Delegate to team leads |
The first super admin completes DNS TXT verification; verified super admins can then add others. Because super admins hold domain export, service account and app controls, treat the role as privileged access: sign-in through SAML, monitored role changes, and removal on role change. Admins of an organisation without a super admin can disable Asana AI but not enable it. See the SaaS Admin Account Protection guide.
Integrations, API tokens and service accounts
Every connected app, personal access token (PAT) and service account is a non-human identity with access to Asana data. The Apps tab of the admin console, open to organisation super admins on Starter and above, is where these are governed.
App management
- Connected apps: Manage apps > Connected apps shows each app's last activity, active members and granted permissions. Export CSV emails user-level usage for the last 90 days.
- Approval mode: under Global app settings, switch from Allow all apps (default, blocklist) to Require app approval (allowlist). Unlisted apps stop working, so export usage first and pre-approve the apps in active use.
- Request workflow: users can send an approval request; requests go to the addresses set in global app settings (all super admins by default) and appear under Manage apps > Approval requests.
- Block app: blocks an app for all members and guests in the domain.
- External automation permissions: allow or disallow rules triggered by web requests from external services.
- Approved workspaces (Enterprise+ and Legacy Enterprise): a proxy or CASB adds the
Asana-Allowed-Domains-Requester-IdandAsana-Allowed-Domain-Idsheaders so managed devices reach only your approved Asana organisations. This applies to web, desktop and mobile apps, not the API.
Tokens and service accounts
| Credential | Access (Asana docs) | Controls |
|---|---|---|
| Personal access token | Same access as its creator | Token list with creator and last use; Revoke; turn PATs off globally (revokes all); Token expiration 30, 60 or 90 days instead of the 10-year default |
| Service account, full permissions | All organisation data through the API; cannot sign in to the UI | Enterprise and above; avoid unless no scoped option fits |
| Service account, scoped | User provisioning (SCIM), audit logs, exporting, Workspace Events, AI Studio Usage API (read-only) | One account per purpose, named owner, review and deauthorise unused ones |
| OAuth apps | Permissions granted at connection, shown per app | Approval mode and per-app review |
Token expiration applies to existing tokens from the moment the policy is set, and the strictest policy wins. Developers get a warning seven days before expiry. Asana advises against hardcoding service account tokens: keep them in a secrets manager with a named owner. See the SaaS API Token Security Guide and the SaaS and OAuth App Governance Guide.
Asana AI and AI Studio data controls
The Enable Asana AI control in Admin console > Asana AI > Settings turns AI features on or off for the domain, and Advanced > Providers and APIs holds provider checkboxes. Asana states that it and its AI partners do not use customer data to train models. AI Studio workflows act with the builder's access: they reach only projects and tasks the builder can see, by default the triggering task and its project. Builders widen scope with @mentions, attachments (the "Include attachments added to tasks" checkbox), comments and linked tasks. Guests cannot build workflows. Web access for AI Studio is enabled by admins in the Asana AI section. For governance, decide which providers to allow, brief builders on scope, and monitor usage through a service account scoped to the AI Studio Usage API.
Logging and detection
The Audit Log API is available to service accounts in organisations on Enterprise+, Legacy Enterprise, or Enterprise with the Compliance Management add-on. It is read-only and authenticates with a service account token. Create a service account scoped to audit logs only, and pull events into your SIEM on a schedule.
| Event or source | Example (Asana docs) | What to watch for |
|---|---|---|
| Sign-in | user_login_failed, user_login_succeeded (with SAML response details) | Repeated failures, sign-ins from unusual locations, SAML errors after certificate changes |
| Role changes | user_division_admin_role_changed and admin role events | New super admins or admins outside change records |
| Deletion | task_deleted (deletion category) | Bulk deletion by one user |
| Apps and tokens | Connected apps page, PAT list with last use, CSV export | New apps with broad permissions; PATs unused for 90 days |
| Workspace Events | Scoped service account (Enterprise+ or Compliance Management add-on) | Activity feeds for SIEM correlation |
Retention for collected events is your choice once they are in your SIEM; confirm Asana's own retention period in the current audit log events documentation. See the SaaS Audit Log Retention and Licensing Guide.
Metrics that show it is working:
- Share of members signing in through SAML or Google sign-in (target 100%).
- Share of guests with 2FA, and guests with no activity in 90 days.
- Connected apps approved versus in use, and apps with a named owner.
- Active PATs, and PATs older than the expiration policy (target zero).
- Number of super admins (trend down) and service accounts with full permissions (target zero where scoped access fits).
- Hours of lag between Asana events and SIEM ingestion.
Hardening baseline
A phased rollout. Most settings revert by changing the same control, but two changes are disruptive: saving SAML signs everyone out, and turning PATs off revokes every existing token. Announce both.
- Inventory: export connected apps usage, list PATs and service accounts, list super admins and admins, and count guests.
- Verify domains and confirm at least two verified super admins.
- Configure SAML in optional mode, test with a super admin, then set it to required. Set web and mobile session timeouts.
- Require 2FA so guests and any password users are covered; raise the password minimum.
- Connect SCIM through a service account scoped to user provisioning.
- Set guest and sharing policy: who can invite guests, read-only link sharing, privacy defaults, attachment sources, guest API access.
- Turn on app approval mode, pre-approving apps in active use, and set external automation permissions.
- Set Token expiration to 90 days or less and replace shared PATs with scoped service accounts.
- Set Asana AI providers and brief AI Studio builders on data scope.
- Connect the Audit Log API and schedule quarterly admin, app and token reviews (our cadence).
| Organisation profile | Priority choices |
|---|---|
| Starter or Advanced | Google sign-in where available, required 2FA, guest invitation limits, app approval mode, token expiration |
| Enterprise | SAML required, SCIM, scoped service accounts, sharing policy; add the Compliance Management add-on for audit events |
| Enterprise+ | All of the above plus Audit Log API, guest API restriction, approved workspaces through your proxy |
Common misconfigurations
- Assuming SAML covers guests: it applies to members only. Require 2FA and govern guest invitations.
- Long-lived PATs: the 10-year default stays unless you set Token expiration.
- Full-permission service accounts for single jobs: use scoped permissions for SCIM, audit logs or exports.
- Approval mode switched on without an inventory: unlisted apps stop working. Export usage and pre-approve first.
- Public read-only links left on: set read-only link sharing to organisation only.
- SAML enforced untested: test in optional mode so admins are not locked out.
Apply Asana's product updates and security notices as published.
Framework mapping
| Asana control | NIST SP 800-53 Rev 5 | NIST CSF 2.0 | ATT&CK technique it helps address |
|---|---|---|---|
| SAML, 2FA, session timeout | IA-2, AC-12 | PR.AA-01 | T1078.004 Cloud Accounts |
| SCIM and guest controls | AC-2 | PR.AA-01 | T1078.004 Cloud Accounts |
| Admin roles, sharing defaults | AC-6, AC-3 | PR.AA-05 | T1213 Data from Information Repositories |
| App approval, token expiration, scoped service accounts | SA-9, CM-7 | GV.SC-07 | T1528 Steal Application Access Token |
| Audit Log API to SIEM | AU-6 | DE.CM-03, PR.PS-04 | T1098 Account Manipulation |
Practitioner checklist
- SAML required for members after testing in optional mode; web and mobile session timeouts set.
- 2FA required for members and guests.
- Two or three verified super admins; admin roles reviewed quarterly.
- SCIM connected through a scoped service account.
- Guest invitations limited; read-only link sharing set to organisation only.
- App approval mode on, with every approved app owned.
- Token expiration at 90 days or less; unused PATs revoked.
- Service accounts scoped per purpose, tokens in a secrets manager.
- Asana AI providers chosen deliberately and AI Studio builders briefed.
- Audit Log API events flowing to the SIEM, with alerts on admin role changes.
Standards and references
- Asana: Security controls in Asana
- Asana: Authentication and access management options for paid plans
- Asana: Admin and super admin roles in Asana
- Asana: App management and integrations
- Asana: Service accounts
- Asana Developers: Audit log API
- Asana: Asana AI features and admin controls
- Asana: AI Studio FAQ
Related NHI Mgmt Group resources: Work SaaS API tokens, SaaS and OAuth App Governance Guide, SaaS API Token Security Guide, SCIM Provisioning Guide, SaaS Security Guide.