Amplitude Security: Secure roles, SSO, API keys and user data

Amplitude holds event streams and user properties for every tracked customer, so the people and keys that can read, export or change that data need the same care as any customer data store. Amplitude is a product analytics platform organised into organisations and projects, with Analytics, Experiment, Data and related products sharing one set of users and keys. This guide covers how roles work at organisation and project level, how to set up SAML SSO and SCIM, which API keys and tokens are secrets, how to classify personal data with Data Access Control, how to handle deletion requests and what the audit log records. It is written for Amplitude administrators, data and growth engineering teams, and the security and privacy teams that review them.

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

Key takeaways

• Keep Admins few. Amplitude has four roles (Viewer, Member, Manager, Admin) and itself recommends limiting the number of Admins; Managers can also add users and rotate keys, so review both.
• Require SSO once it works. SAML 2.0 SSO with JIT provisioning is on the Growth and Enterprise plans; requiring SSO stops email and password sign-in, so MFA is enforced at your identity provider.
• Know which keys are secret. Project API keys and client-side deployment keys are public by design; secret keys, server-side deployment keys, Management API keys, Data API tokens, SCIM keys and org-level keys are not.
• Classify personal data. Data Access Control lets you mark properties as PII, Revenue or Sensitive and allow or deny each class per group.
• Export the audit log. The audit log keeps up to 90 days and covers logins, role changes, SSO changes and data exports; pull it into your SIEM through the API.

How identity and access work in Amplitude

An Amplitude organisation contains projects, and each project receives event data through its own project API key. Users belong to the organisation and hold a role. By default the role applies at organisation level, so a user has the same access in every project. Amplitude documents three structures for narrowing that:

• Organisation-level roles (default): one role for all projects.
• Project-level permissions: a user can hold different roles in different projects, for example Manager in one and Viewer in another.
• Permission groups: Admins create groups for more targeted controls, and groups also carry Data Access Control settings (see below).

New invitees get the Viewer role by default. Each organisation needs at least one Admin, and only an existing Admin can grant or revoke the Admin role. Admins can also turn on Allow team members to request access under Advanced Settings; requests then wait for admin approval. Users cannot change their own role or remove themselves from the organisation, and email addresses cannot be edited by users or admins (a domain change goes through Amplitude Support, and SSO must be turned off and set up again around it).

SSO, JIT provisioning and SCIM

Amplitude supports any SAML 2.0 identity provider, with documented setups for Auth0, AWS IAM Identity Center, Google Workspace, Microsoft Entra ID (Azure AD), Okta and OneLogin. Points to plan for:

• Require SSO: once you require SSO, organisation members can no longer sign in with email and password. Amplitude advises confirming that SSO works before turning it on, so test with a pilot group and keep an admin session open while you switch.
• Email matching: Amplitude looks for the user's email in the SAML assertion subject, then the standard emailaddress claim, then attributes named emailaddress or email. If none holds a valid email, sign-in fails, so map the attribute deliberately.
• JIT provisioning: users who authenticate through your identity provider are added to the organisation automatically, and you then set their role. Enterprise customers with project permissions can choose the default projects JIT users get.
• MFA: with SSO required, the sign-in strength is whatever your identity provider enforces. Apply phishing-resistant MFA and conditional access there for every Amplitude user, and especially for Admins and Managers. See the Phishing-Resistant MFA Guide.
• SCIM 2.0: under Access and SSO Settings, Provisioning Settings, set Enable SCIM Provisioning to Enabled and select Generate SCIM Key. The User Management API can create, read, update and delete users, pending users and permission groups, and Okta's Push Groups can link identity provider groups to Amplitude groups. Removing a user's assignment in the identity provider removes them from the organisation.

JIT adds users but does not remove them, so pair SSO with SCIM or a leaver process. See the SCIM Provisioning Guide and the Identity Provider and SSO Security Guide.

Availability: Amplitude's docs list SSO for the Growth and Enterprise plans, project-level permissions for Growth and Enterprise, permission groups for Enterprise and the SCIM key for Enterprise. Data Access Control varies by plan and is enabled through Amplitude Support. Confirm your entitlements with Amplitude.

Admin roles and privileged access

The table summarises what each role can do that matters for security, from Amplitude's roles and permissions page.

Amplitude Experiment adds its own Viewer, Member, Manager and Admin roles alongside the organisation role. Experiment Admins can edit restricted flags and experiments even when not listed as editors, and Experiment Managers can add users to projects, so include Experiment roles in reviews.

1. Name the admin tier: list every Admin and Manager with a reason. Managers can add users and rotate secret keys, so they are privileged even though the role name sounds modest.
2. Use project-level permissions where available: give data owners Manager only on the projects they own, and Viewer elsewhere.
3. Govern destinations: Managers can add data sources and destinations, which send event data to other systems. Treat a new destination as a data transfer that needs approval.
4. Review shared links: Members and above can create shareable links to charts and dashboards; Admins can remove them. Review public links on the same cycle as access.
5. Handle leavers cleanly: when an Admin or Manager removes a user, their charts, dashboards and cohorts become unassigned. Transfer content during removal in the Remove Members modal; the recipient must have logged in within the last 30 days.
6. Review quarterly (our recommendation), and after any reorganisation or agency engagement. See the Access Reviews Guide.

Integrations, API tokens and service accounts

Amplitude's keys are the platform's non-human identities. Some are public identifiers that ship in apps and web pages; others grant read or write access to data and must be handled as secrets.

Server-side APIs such as the User Privacy API use HTTP Basic authentication with the API key and secret key, so a leaked secret key gives direct API access. Amplitude's response steps by key type:

• Secret key exposed: delete it and generate a new one.
• Server-side deployment key exposed: create a new key, swap it into every flag and experiment, then delete the old one.
• Management API key exposed: create a new key and delete the old one.
• SCIM key exposed: select Regenerate SCIM Key. The old key is rejected immediately, so update the identity provider straight away.
• Org-level key exposed: contact Amplitude Support.

Keep secret keys out of mobile apps, front-end bundles and notebooks, scan repositories for them, and record an owner and purpose for each. Warehouse and reverse ETL sources and destinations hold credentials for your data platforms too, so include them in the same inventory. See the API Key Management Guide, the Secrets Management Guide and the Non-Human Identity (NHI) Guide.

Personal data controls and deletion

Data Access Control

Data Access Control (DAC) restricts who can see sensitive property values. It applies to properties, not to event definitions or metadata.

1. Classify properties: in Amplitude Data, Properties, open a user, event or group property and choose PII, Revenue or Sensitive from the Classification drop-down. Derived properties inherit their parent's classification, and the Taxonomy API can classify at scale.
2. Set group permissions: in Settings, Organization settings, Groups, open the Data Access tab and choose Yes or No for each classification.
3. Check the effect: users without access cannot open charts, cohorts, dashboards, notebooks or sessions that use restricted data, and see [DAC Restricted] in the Event Stream and user lookup. CSV exports omit inaccessible properties and PDF or PNG exports obscure inaccessible charts.

Organisation Admins always see every classification, which is one more reason to keep the Admin role small. Classifying user_id stops users without access from using Event Explorer, so test with a pilot group first.

Deletion requests

The User Privacy API handles data subject deletion. Amplitude recommends version 2 at privacy.amplitude.com for new integrations. Facts from the version 1 documentation that shape your process:

• Scope: a job deletes all events and user properties recorded up to its run time for each Amplitude ID, including from recovery and backup systems. With delete_from_org set to true it creates jobs in every project holding the user's data.
• Timing: Amplitude processes deletion requests within 30 days. Jobs can be edited while staging and revoked until three days before the run; a submitted job cannot be stopped, and it shows done after a five day wait for backups.
• Audit: the requester field records who asked, and account admins receive an email with the deletion details.
• Re-ingestion: deletion does not stop new events; a returning user is treated as a new user. Use the SDK's setOptOut() to stop tracking, and delete at the warehouse source too, because warehouse ingestion can bring deleted data back on the next sync.

The best control is not sending personal data you do not need: avoid email addresses or names as user IDs and keep free-text properties out of the tracking plan. See the Data Minimisation guide, the Consent Management Guide: Cookies, CMPs and GPC and the Data Retention and Secure Deletion Guide.

Logging and detection

Only organisation Admins can open the audit log, under Organization Settings, Audit Logs. It holds up to 90 days and records who acted, when and from which IP address, grouped by Amplitude into risk levels:

• High risk: project creation, updates and deletion; project data export.
• Medium risk: user invitations, role and permission changes, group changes, user deletions, SSO configuration changes.
• Low risk: logins by SSO, magic link, password or Google, registrations, password reset attempts, chart, dashboard and notebook deletion and export, cohort exports, user profile and timeline views.

The UI exports CSV, but IP address, organisation ID, user agent and error fields are only in the API. The API is a POST to https://amplitude.com/api/2/audit-logs/<ORG_ID> with an org secret key from Amplitude Support, ISO 8601 start_date and end_date, up to 30 days per query, and filters on domain, feature and action. Pull it at least daily so you keep more than 90 days.

Correlate Amplitude logins with your identity provider's sign-in logs, which carry the MFA and device context. Key creation and rotation should also match a change ticket.

Metrics: number of Admins and Managers (target: a short named list); percentage of users signing in through required SSO (target 100%); users removed within one day of leaving; secret keys and tokens with a named owner; PII properties classified under DAC; days of audit log held in your SIEM.

Hardening baseline

A phased rollout we recommend:

1. Inventory: export users and roles, list projects, secret keys, Data API tokens, deployment keys, sources and destinations, and name an owner for each.
2. Connect SSO: configure SAML with your identity provider, map the email attribute, and test with a pilot group while password sign-in still works.
3. Require SSO: turn it on once every active user has signed in through SSO; enforce phishing-resistant MFA at the identity provider. Roll back by turning the requirement off from an Admin session if sign-in fails.
4. Turn on SCIM where your plan includes it, so leavers lose access when the identity provider assignment goes.
5. Cut privileged roles: reduce Admins to two or three, move data owners to project-level Manager, and set Viewer as the norm.
6. Rotate and scope keys: issue one secret key per integration, delete unused ones, restrict who creates Data API tokens and move every secret into a vault.
7. Classify data: mark PII, Revenue and Sensitive properties and set group access under DAC; pilot on one project first.
8. Stream the audit log to your SIEM daily with alerts on the signals above.
9. Wire deletion into your data subject request process through the User Privacy API, with warehouse deletion alongside.

Common misconfigurations

• Manager treated as a routine role: Managers can add users, change roles and rotate secret keys, so a long Manager list is a long admin list.
• SSO configured but not required: email and password sign-in stays available, so some sign-ins happen outside identity provider MFA and conditional access. Turn on Require SSO.
• JIT without deprovisioning: JIT adds users on sign-in, but leavers stay in the organisation unless SCIM or a leaver process removes them.
• Secret keys in client code: project API keys are public by design, but secret keys and server-side deployment keys placed in apps or notebooks give direct API access.
• Shared Data API tokens: one token with account-wide permissions used by several tools, with no owner and no rotation.
• Personal data as identifiers: email addresses as user IDs or in unclassified properties, visible to every Viewer.
• Audit log left in place: the 90 day window passes before anyone looks.

Framework mapping

Practitioner checklist

• SAML SSO configured with a mapped email attribute, and Require SSO turned on.
• Phishing-resistant MFA enforced at the identity provider for all Amplitude users.
• SCIM provisioning enabled where available, or a tested leaver process.
• Two or three named Admins; Managers listed with a reason; project-level roles in use where available.
• Experiment roles reviewed alongside organisation roles.
• One secret key per integration, each vaulted with a named owner; unused keys deleted.
• Data API token creation restricted and every token inventoried.
• PII, Revenue and Sensitive properties classified under Data Access Control.
• Deletion requests run through the User Privacy API, with warehouse deletion and SDK opt-out.
• Audit log pulled into the SIEM daily, with alerts on role, SSO and export events.

Standards and references

• Amplitude: User roles and permissions
• Amplitude: Single sign-on (SSO) in Amplitude
• Amplitude: SCIM provisioning
• Amplitude: API keys and tokens
• Amplitude: Data Access Control
• Amplitude: User Privacy API
• Amplitude: Audit log
• NIST: SP 800-53 Rev 5 Security and Privacy Controls

Related NHI Mgmt Group resources: SaaS Security Guide · SCIM Provisioning Guide · API Key Management Guide · GDPR Compliance Guide for Security Teams