Anaplan Security: Govern tenant admins, SSO, integrations and model access

Anaplan holds an organisation's plans, forecasts, headcount and often payroll and supplier spend models, so the people and integrations that can administer the tenant, bypass single sign-on or run model actions hold some of the most sensitive data in the business. Anaplan runs the platform, and the customer decides who holds each administration role, how users sign in, which integration users and certificates exist, what each model role can see, and who reads the audit trail. This guide covers those customer-side controls: the administration roles in the Administration console, SAML single sign-on and exception users, Integration API authentication with basic credentials and CA certificates, the Restricted Integration User role, model roles and Selective Access, Bring Your Own Key, and audit events. It is written for Anaplan tenant administrators, Centre of Excellence leads, integration engineers and the security teams who review them.

This is an independent guide from NHI Mgmt Group, based on Anaplan's public documentation as of November 2026. It is not sponsored or reviewed by Anaplan. Product features change, so confirm settings against Anaplan's current documentation.

Key takeaways

• Split the administration roles. Anaplan separates Tenant administrator, Tenant security administrator, User administrator, Tenant auditor, Encryption administrator and integration roles; assign each to different people rather than one super-admin group.
• Exception users are your SSO bypass list. Integrations using basic authentication in SSO workspaces need an exception user; keep that list short, owned and reviewed, and prefer CA certificate authentication for integrations.
• The API grants no extra access. An integration can do only what its Anaplan user can do, so a dedicated integration user with a narrow model role is the main control; Workspace Administrator authority runs any model action.
• Use the Restricted Integration User role. It lets a person manage connections and integrations in assigned workspaces without gaining access to the workspaces or models themselves.
• Turn on audit and give someone the Tenant Auditor role. Audit events cover access control, SAML connections, encryption, integrations and user activity, and they are only useful if someone reviews them.

How identity and access work in Anaplan

Anaplan evaluates access in layers. The Integration API documentation lists them in order: tenant and workspace access, Workspace Administrator authority, model role, object-level permissions (such as Selective Access and Dynamic Cell Access), and file access. The same layers apply whether a person uses the interface or an integration calls the API.

Single sign-on

SSO is configured in the Administration console under Security, then Single Sign-On, by a Tenant security administrator. Anaplan's documented steps are: select New, set the identity provider metadata (upload XML or enter manually), configure the connection details, optionally configure advanced SAML settings, assign workspaces to the connection, and give your Anaplan configuration details to your identity provider. Assigning workspaces is what turns SSO on for them, so plan the assignment workspace by workspace and test with a pilot workspace first. Once users sign in through your identity provider, MFA, conditional access and leaver disablement there apply to Anaplan. See the SAML Security Guide and the How Single Sign On Works guide.

Exception users

An exception user can authenticate outside the enforced SSO flow for supported integration scenarios. Anaplan's API documentation states that if a workspace uses SSO and an integration uses basic authentication, the integration user must be an exception user. Exception users are assigned by Tenant security administrators, separately from model roles, and need an active mailbox to receive password reset emails. Because each exception user signs in with a password instead of your identity provider, treat the list as privileged:

• Integration accounts only: no named people on the exception list except a documented break-glass account (ours).
• Team mailbox: point the password reset address at a mailbox owned by the integration team, not an individual.
• Move to certificates: where an integration can use CA certificate authentication, use it and take the account off the exception list.

Admin roles and privileged access

Anaplan's administration roles are assigned in the Administration console under Access Control. Each one opens a different part of the tenant. Our suggested owners are shown alongside what Anaplan documents.

Anaplan's role list also includes Workflow owner, Page builder, View administrator, Application owner and AI administrator; review those holders in the same cycle. Anaplan notes that tenant administrators cannot access other tenants or their data, and that a sole tenant administrator cannot remove their own permissions through Assignments and must raise a Support case. Keeping two tenant administrators avoids that dependency.

Segregation of duties for planning data

The roles are designed so no single administrator controls everything. A practical split: tenant administrators do not hold Encryption administrator, Tenant security administrators do not build models, and the Tenant auditor is outside the platform team. Anaplan's BYOK documentation makes the same point about the Encryption Administrator, describing it as separated from other administrative roles so no single administrator controls data protection. Document the split in a matrix; see the Segregation of Duties Matrix Template.

Workspace administrators and model roles

Workspace Administrator is the most powerful authority inside a workspace: Anaplan's API documentation says it can run any model action regardless of model role. Limit it to model builders who need it, and give business users model roles that grant only the actions, modules and views they use. Use Selective Access on sensitive lists (cost centres, employees, suppliers) and Dynamic Cell Access where cell-level rules are needed, so a model role does not expose salary or supplier lines to every planner.

Integrations, API tokens and service accounts

Anaplan's Integration API v2.0 documentation is explicit that the API uses the permissions of the authenticated Anaplan user and does not grant extra access. The integration's Anaplan user is therefore its security boundary.

Authentication options

Anaplan auth tokens are used in the Authorization header with the AnaplanAuthToken scheme. Anaplan's documentation describes a 35-minute session: reuse one token per session and refresh it with POST auth.anaplan.com/token/refresh, rather than authenticating on every call. Anaplan also documents other authentication options for integrations; check its current documentation for the methods available to your tenant.

Certificate handling

Anaplan's support article on CA certificates says the uploaded public certificate must contain a single encoded string and be an S/MIME type certificate with an email address attribute, obtained from a supported CA provider. Private keys can be encrypted with a passphrase, supplied after a colon in the key path. Good practice (ours):

• Keep private keys and keystore passwords in a secrets manager, never in batch scripts or shared drives.
• Encrypt every private key with a passphrase.
• Track each certificate's expiry and owner, and register the replacement before the old one expires; disable or delete retired certificates in Administration.
• Test new authentication with -debug and an import that does not change production models, as Anaplan's article suggests testing without affecting models.

See the Machine Identity, PKI and Certificate Lifecycle Guide.

Designing integration users

• One integration user per integration: Anaplan's own best practice is a dedicated integration user with only the permissions it needs.
• Model role over Workspace Administrator: grant Workspace Administrator only when administrative endpoints are needed or the integration must run actions regardless of model role; otherwise use a model role scoped to the specific imports, exports, deletes or processes.
• Restricted Integration User for people: engineers who manage connections and integrations can hold this role for assigned workspaces without access to the workspaces or models. The model role used by the integration must include the right action permissions and read or write access to Selective Access lists.
• Transport: API traffic uses HTTPS; TLS 1.3 is used and TLS 1.2 still supported, so build clients for TLS 1.3.

Each integration user and certificate is a non-human identity. Inventory them with owners and review dates; see NHI Discovery Across Cloud, SaaS, CI/CD and On-Premises Environments and the NHI Authentication Guide.

Encryption keys and Bring Your Own Key

With Bring Your Own Key, the customer's Encryption Administrator manages the keys that protect workspace data. Anaplan's documentation describes the key manager as FIPS 140-2 Level 3 certified with an embedded HSM providing the roots of trust, and compliance reporting that records encryption, key management and access policy actions by user and time, including failed access attempts. Anaplan documents key rotation and disabling an encryption key in separate articles; read them before changing a production key, because disabling a key affects access to the data it protects. Assign the Encryption administrator role to a key custodian who is not a tenant administrator, set a rotation schedule (ours: annually and on custodian change), and rehearse key operations in a non-production workspace. See the BYOK, HYOK and External Key Management Guide.

Logging and detection

Audit events are viewed in the Administration console under Audit by users with the Tenant Auditor role, once audit is enabled for the organisation. Anaplan documents event categories for access control, SAML connection management, encryption activity, integrations, user activity, workflow, comments and Forecaster. Each event shows an ID, Type (the Anaplan event code), Message, User, Tenant ID, Object ID and Event Date in UTC, with filters by application and time period, and audit events can be exported.

Detections worth building (ours), in Anaplan or after exporting to your SIEM:

Metrics (ours): number of Tenant administrators (two or three); exception users with a named owner (100 percent); integrations using CA certificates rather than passwords (rising each quarter); certificates expiring within 30 days without a replacement registered (zero); audit events reviewed weekly (yes). See the SIEM Log Source Onboarding Checklist.

Hardening baseline

The steps below are NHI Mgmt Group recommendations, built on the vendor settings described above.

1. Map current role holders: list every administration role assignment and workspace administrator; remove anyone without a current need.
2. Separate the roles: two Tenant administrators, a distinct Tenant security administrator, a Tenant auditor outside the platform team, and an Encryption administrator who is not a tenant administrator.
3. Enable SSO workspace by workspace: pilot on one workspace, then assign the rest. Roll back by unassigning the workspace from the connection.
4. Clean the exception list: integration accounts and one documented break-glass account only, each with a team mailbox.
5. Move integrations to CA certificates with Anaplan Connect 1.4 or higher, keys in a vault, and expiry tracked.
6. Narrow integration users: one per integration, model roles scoped to specific actions, Workspace Administrator only where needed, Restricted Integration User for engineers.
7. Apply Selective Access to lists holding people, cost and supplier data.
8. Turn on audit and schedule a weekly review and export.
9. Use provisioning for joiners and leavers so a user removed in your identity provider loses Anaplan access too; confirm the supported method in Anaplan's documentation.

Common misconfigurations

• Everyone in the CoE is a Tenant administrator: it collapses the role separation Anaplan provides. Use the scoped roles.
• A single Tenant administrator: that person cannot remove their own permissions and becomes a dependency. Keep two.
• Named people as exception users: they skip your identity provider's MFA and leaver controls. Keep the list to integration and break-glass accounts.
• Integrations running as a model builder: the integration inherits Workspace Administrator and can run any action. Use a dedicated integration user with a narrow model role.
• New auth token on every call: Anaplan notes requests may fail; reuse one token per 35-minute session and refresh it.
• Audit enabled but no Tenant auditor: events are recorded and never read. Assign the role and a review schedule.

Framework mapping

Practitioner checklist

• Two named Tenant administrators; no one holds both Tenant administrator and Encryption administrator.
• Tenant security administrator, User administrator and Tenant auditor held by separate teams.
• SSO connection assigned to every production workspace.
• Exception users limited to integration and break-glass accounts, each with an owner and team mailbox.
• Unattended integrations on CA certificates, private keys encrypted and vaulted, expiry tracked.
• One integration user per integration, with a scoped model role and Workspace Administrator only where required.
• Selective Access applied to people, cost and supplier lists.
• Audit enabled, events reviewed weekly and exported to the SIEM.
• BYOK key rotation and disable procedures rehearsed outside production.

Standards and references

• Anaplan: Tenant administrator
• Anaplan: Integration API authentication, access and permissions
• Anaplan: Add a new identity provider connection
• Anaplan Support: Implement your CA certificate in API integrations
• Anaplan: Assign Restricted Integration User role and workspaces
• Anaplan: View audit events
• Anaplan: Bring Your Own Key
• NIST: SP 800-53 Rev 5 Security and Privacy Controls

Related NHI Mgmt Group resources: SaaS Security Guide · SAML Security Guide · Machine Identity, PKI and Certificate Lifecycle Guide · Segregation of Duties Guide