Mixpanel Security: Roles, Service Accounts, SSO, Audit

Mixpanel holds detailed behavioural data about your users, often joined to profiles, emails and account identifiers, so the people and service accounts that can export reports, cohorts and profiles need careful control. Mixpanel separates organisation roles from project roles, adds teams, custom roles and classified data controls, and gives back-end integrations their own service accounts. This guide explains how those layers combine, how to limit Owner and Admin, how to run service accounts and tokens as non-human identities, what the Audit Log records, and a governance baseline that covers SSO, 2FA, classified data and end-user deletion. It is written for Mixpanel organisation owners, data and product analytics teams, and the security and privacy staff who support them.

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

Key takeaways

Two role layers, additive. Organisation roles (Owner, Admin, Billing Admin, Member) control management; project roles (Owner, Admin, Analyst, Consumer) control data. A user's rights are the combined set of every grant they hold.
Consumer is the safe default. Consumers can build reports and boards but cannot download reports, export users or cohorts, or edit profiles; give Analyst only to people who need exports.
Service accounts are the API identity. Mixpanel recommends service accounts for most APIs; the secret is shown once and accounts do not expire unless you set an expiration date, so always set one.
Classified data is opt-in to see. No default role, including Owner and Admin, can view classified properties; access comes only from a custom role or a team's Classified Data setting.
Use the Audit Log on every plan. It records authentication, service account changes, report creation and data exports, kept 90 days on Free and Growth and two years on Enterprise; export it as NDJSON to your SIEM.

How identity and access work in Mixpanel

A Mixpanel organisation contains projects; a project receives events and holds reports, boards, cohorts and user profiles. Users must first be added to the organisation as a Member before they can be added to projects or teams. Teams grant a project role to every member at once, which makes them the natural link to identity provider groups.

Organisation roles

Capability	Owner	Admin	Billing Admin	Member
Add, invite and remove users	Yes	Yes	No	No
Manage service accounts	Yes	Yes	No	No
Modify 2FA and SSO	Yes	Yes	No	No
Modify organisation, project and team roles	Yes	Yes (up to Admin)	No	No
Delete or transfer projects, request organisation deletion	Yes	No	No	No
Manage billing	Yes	No	Yes	No

Enterprise and Growth plans have all four roles; Free plans have Owner and Billing Admin. Mixpanel recommends at least two Owners.

Authentication

SSO: available on Growth and above with any SAML 2.0 identity provider. Claim your domain in Organization Settings with a mixpanel-domain-verify DNS TXT record and leave the record in place permanently, since Mixpanel marks the domain unverified a week after it disappears. Upload the signing certificate as a .cert or .pem X509 file and track its expiry yourself, because Mixpanel does not send expiry notices.
Require Single Sign-On: blocks password sign-in for users while Owners and Admins keep a password fallback. Require Single Sign-On for administrators removes that fallback; Mixpanel warns that a misconfiguration then locks every administrator out, so test SSO thoroughly first and keep a recovery route agreed with your identity team.
IDP Managed Access and SCIM: IDP Managed Access routes users on your claimed domains to SSO and adds them on first sign-in with no extra permissions. SCIM, on Enterprise, provisions and deprovisions users at https://mixpanel.com/api/app/scim/v2 with a Bearer token that is shown once; generating a new token revokes the previous one. See the SCIM Provisioning Guide.
Two-factor authentication: organisation admins turn on the requirement in Organization Settings > Access Security; it covers password and Google sign-in, and users set up an authenticator app at next login. Users required to use SSO are exempt because the identity provider handles MFA. Recovery codes can only be saved at setup, and admins can reset 2FA for a user from the 2FA tab. See the Phishing-Resistant MFA Guide.

Admin roles and privileged access

Project roles

Capability	Owner	Admin	Analyst	Consumer
View access keys, change settings, invite users, change roles	Yes	Yes	No	No
Create service accounts	Yes	Yes	No	No
Create and edit user profiles, delete profiles	Yes	Yes	No	No
Download reports, export users report and cohorts, download Lexicon CSV	Yes	Yes	Yes	No
Create and view reports, boards and cohorts	Yes	Yes	Yes	Yes
Transfer, reset or delete project; merge or drop Lexicon data	Yes	No	No	No

Default to Consumer: it lets people explore and share insight while keeping raw exports with Analysts. Consumers create custom events and properties only for themselves and cannot create public boards.
Keep project Admin small: project Admins can view access keys, create service accounts and delete profiles. Two or three per project is usually enough.
Grant through teams: map identity provider groups to Mixpanel teams, each with a project role, so joiners and leavers flow from the directory. Deleting a team removes only the access it granted, so check for direct grants in reviews.
Use custom roles for edge cases: Enterprise allows up to five custom roles per project, created by project Owners and Admins; default roles cannot be edited.
Review quarterly: because roles are additive, review each user's combined grants across organisation, project and team. See the Access Reviews Guide.

Integrations, API tokens and service accounts

Credential	Used for	Handling
Service account (username and secret)	Query, export and management APIs via HTTP Basic Auth; Mixpanel's recommended method	Secret shown once; set an expiration date; per-project role
Project token	Ingestion APIs (track, import, profiles), often from client-side SDKs	Identifies the project; treat as public in browser and app code
GDPR OAuth token	GDPR deletion and retrieval APIs	Generated in Personal Settings > Data & Privacy; expires after one year
SCIM token	Identity provider provisioning	Shown once; regenerating revokes the old token

Running service accounts well

Choose where to create it: a service account created in Organization Settings can be given roles in several projects, and deleting it removes access everywhere. One created in Project Settings is limited to that project and deleting it removes only that access. Prefer project-level accounts for single-project pipelines.
Assign the lowest project role: each project has its own role assignment. An export job may need Analyst; a profile sync that edits or deletes profiles needs Admin. Do not give Owner.
Set an expiration date: accounts do not expire by default. Mixpanel lets you set an expiry at creation to enforce rotation; after it passes, requests are rejected. Track expiry dates so pipelines are rotated before they fail.
Store the secret once: the secret cannot be retrieved after creation. Place it in a secrets manager straight away. See the Secrets Management Guide.
Name and own it: name each account after its pipeline and record an owner, so Audit Log entries for service account activity are traceable. See the Service Account Security Guide.

All Mixpanel APIs reject plain HTTP, so integrations must use HTTPS. Treat the project token in front-end code as an identifier and protect data quality with Lexicon governance rather than secrecy.

AI assistants and MCP

Mixpanel's Audit Log records MCP tool calls, with entries kept 90 days on all plans. Mixpanel notes that MCP entries show the AI provider's server IP rather than the user's, so identify the actor from the user field, and that some object changes (tags, metrics, custom properties, lookup tables) are logged only when made through MCP. Treat AI clients connected to Mixpanel as integrations with an owner and review them with your other non-human identities. See the OAuth Scope Design Guide.

Logging and detection

The Audit Log is available on all plans. Organisation-level logs sit in Organization Settings and project-level logs in Project Settings; Owners and Admins can view them, and custom roles can be granted access. Login, logout and two-factor events appear only at organisation level. Read-only actions such as viewing or querying are not logged.

Event area	What to alert on	ATT&CK mapping
Authentication and 2FA	2FA reset for a user, failed sign-in bursts, SSO requirement turned off	T1078.004 Cloud Accounts
User and role changes	New Owner or Admin, Classified Data Access granted	T1098 Account Manipulation
Service account management	Service account created without an expiry, new project role on an existing account	T1098 Account Manipulation
Data exports	Large or out-of-hours exports, exports by new users	T1530 Data from Cloud Storage

Retention is 90 days on Free and Growth and two years on Enterprise. Export the current view as CSV or NDJSON; NDJSON keeps nested structure for SIEM ingestion. Schedule a regular export so evidence outlives the retention window on shorter plans.

Metrics

Organisation Owners and Admins: at least two Owners, total administrators kept to a small named group.
2FA or SSO coverage: 100% of human users.
Service accounts with an expiry date and owner: target 100%.
Users with Analyst or higher: share of users who can export, trending to documented need.
Classified Data Access holders: reviewed quarterly.
Audit Log export cadence: days since last successful export.

Hardening baseline

Data governance

Classify sensitive properties: users with the Mark Classified Data permission can classify properties without seeing them. Viewing then needs Classified Data Access through a custom role, or the Classified Data checkbox on a team's project assignment. Classify emails, phone numbers and any free-text properties that may hold personal data.
Use data views: adding a team to a data view filters that team's data access, which suits regional or business-unit separation inside one project.
Minimise what you send: avoid sending personal data in event properties you do not analyse. See Data Minimisation.
End-user deletion: the GDPR API accepts up to 2,000 distinct IDs per deletion or retrieval request, authenticated with an OAuth token from Personal Settings > Data & Privacy that expires after a year. Requests can take weeks to process. Deletion removes data for the distinct_id permanently but does not stop future collection, so also opt the user out in your SDK. See the GDPR Compliance Guide for Security Teams.

Phased rollout

Inventory (week 1): list organisation and project roles, teams, custom roles, service accounts and Classified Data Access holders; export the Audit Log.
Authentication (weeks 1 to 3): claim domains, configure SAML, enable IDP Managed Access and, on Enterprise, SCIM. Turn on Require Single Sign-On for users; require 2FA for anyone not on SSO. Leave the administrator fallback until SSO has run cleanly for several weeks.
Roles (weeks 3 to 5): move people to Consumer by default through teams, keep Analyst for exporters, and reduce project Admins. Record old roles for quick rollback.
Service accounts (weeks 4 to 6): recreate accounts at project level with expiry dates and the lowest role, cut pipelines over, then delete the old accounts.
Governance (ongoing): classify properties, schedule Audit Log exports, and test a deletion request end to end.

Choosing between options

Organisation versus project service accounts: organisation-level for a central pipeline that spans projects; project-level for everything else.
Require SSO for administrators: turn it on once you have a tested identity provider recovery process; until then the administrator password fallback, protected by 2FA, is the safety net.
Small teams: on Free, focus on two Owners, 2FA for everyone, expiring service accounts and regular Audit Log exports.

Common misconfigurations

Everyone is project Admin: every user can view access keys, create service accounts and delete profiles.
Analyst as the default role: everyone can download reports and export cohorts. Make Consumer the default.
Service accounts with no expiry: credentials live for years after a pipeline is retired.
One organisation-level service account for every pipeline: one secret then unlocks every project.
SSO certificate expiry unmonitored: sign-in breaks without warning. Track the date yourself.
Personal data left unclassified: everyone with project access sees raw emails or identifiers in reports.

Framework mapping

Control area	Mixpanel setting	NIST SP 800-53 Rev 5	NIST CSF 2.0
Account management	Organisation membership, teams, SCIM, IDP Managed Access	AC-2	PR.AA-01
Least privilege	Consumer default, custom roles, data views	AC-6	PR.AA-05
Authentication	Require Single Sign-On, required 2FA	IA-2	PR.AA-01
Authenticator management	Service account expiry, secret storage, token renewal	IA-5	PR.AA-01
Audit logging	Audit Log, NDJSON export	AU-2, AU-6, AU-11	PR.PS-04, DE.CM-03
Data protection	Classified data, GDPR API deletion	SC-28	PR.DS-01

Practitioner checklist

Keep at least two organisation Owners and a small, named set of Admins.
Claim domains, configure SAML SSO and turn on Require Single Sign-On; track the SSO certificate expiry.
Require 2FA for every user not covered by required SSO.
Make Consumer the default project role through teams and reserve Analyst for people who export.
Create service accounts at project level with the lowest role and an expiration date, and store secrets in a vault.
Classify personal data properties and grant Classified Data Access only through reviewed roles or teams.
Export the Audit Log regularly as NDJSON and alert on role, service account and export events.
Run GDPR deletion requests through a tracked workflow and opt users out in the SDK.

Mixpanel Security: Roles, Service Accounts and Data Governance