Twilio Segment sits in the middle of your customer data flows, collecting events from every website, app and server and forwarding them to analytics, advertising and warehouse destinations, so a mis-scoped role or token in Segment reaches every downstream system at once. Segment's security controls are mostly customer-side: workspace roles and resource scoping, PII Access, SSO and MFA enforcement, Public API tokens, source write keys, the Privacy Portal and end-user deletion. This guide explains how those controls fit together, how to keep Workspace Owner small, how to manage tokens and write keys as non-human identities, what Audit Trail records and how to forward it, and a privacy-focused hardening baseline. It is written for Segment workspace owners, data engineers, and the security and privacy teams who govern customer data.
This is an independent guide from NHI Mgmt Group, based on Twilio's public Segment documentation as of November 2026. It is not sponsored or reviewed by Twilio. Product features change, so confirm settings against Twilio's current documentation.
Key takeaways
- Workspace Owner is the master key. Owners hold full edit rights, PII Access by default, sole access to the Privacy Portal and Audit Trail, and are the only people who can create Public API tokens.
- Build access from scoped roles. Make people Workspace Members and add Source, Unify and Engage, Warehouse or Tracking Plan roles scoped to specific resources or Labels.
- PII Access is a separate grant. Without it, fields classified Red or Yellow are masked; it never widens a user's resource scope, so grant it only where people need to see raw values.
- Require SSO and MFA. Both are off until an owner turns them on in Advanced Settings; Segment recommends requiring SSO for most customers.
- Forward the Audit Trail. It keeps 90 days in the app; Audit Forwarding sends events to a dedicated source so you can alert and retain them in your own systems.
How identity and access work in Twilio Segment
Segment organises everything in a workspace: sources that collect data, destinations that receive it, warehouses, Unify spaces for identity resolution, Engage audiences and journeys, Protocols tracking plans and functions. Users and groups are granted roles that apply to the whole workspace or to specific resources. When a user holds both user-level and group-level permissions, they receive the higher of the two.
Authentication
- SSO: Segment supports SAML 2.0 with any SAML identity provider and has prebuilt connections for Okta, OneLogin and Microsoft Entra ID. SSO is on the Business tier. Verify your domain under Authentication > Domains with a DNS TXT record or meta tag; a domain can be claimed by only one workspace.
- Require SSO: off by default. Turn it on in Workspace Settings > Authentication > Advanced Settings after signing in through SSO yourself, and grant exemptions only to named accounts that cannot use it.
- Just-in-time and SCIM: users who arrive through the identity provider are created as minimal-access, read-only members. Use SCIM with role mapping to assign roles from identity provider groups. See the SCIM Provisioning Guide.
- MFA: for password sign-in, users enrol an authenticator app or SMS (US and Canada only), and workspace owners can turn on Require MFA in Advanced Settings. SSO users get MFA from the identity provider, and Twilio Unified Login users configure it in their Twilio account. Segment also advises protecting the email account used for Segment, since email access can lead to account access.
Admin roles and privileged access
| Role | What it grants (per Twilio) | Scope options | Use for |
|---|---|---|---|
| Workspace Owner | Full read and edit of everything, including team permissions | Whole workspace | Two to four platform owners |
| Workspace Member | Nothing by itself; access comes from assigned roles | None | Everyone else, as the base |
| Source Admin | Edit sources, settings, connected streaming destinations, schema, write key and debugger | All current and future, a list, or a Label | Engineers owning specific sources |
| Source read-only | Read sources, schema, transformations and debugger | As above | Analysts and support |
| Unify and Engage admin / read-only | Edit or read Unify settings and Engage audiences, traits, journeys | All, a list, or Label-based spaces | Marketing operations |
| Warehouse destination admin / read-only | Edit or read warehouse destinations | All warehouses | Data platform team |
| Tracking Plan admin / read-only | Edit or read Protocols tracking plans | All tracking plans | Data governance |
| End User Privacy admin | Edit End User Privacy settings, suppression and deletion workflows | Privacy settings only | Privacy operations |
| Observability admin / read-only | Failure log collection data, including PII collections; requires PII Access | All data | Small on-call group |
- Keep Owners few: owners are the only people who can create Public API tokens, view the Audit Trail and use the Privacy Portal, and they hold PII Access by default. Two to four named people is a workable range; avoid giving it to agencies.
- Scope with Labels: on Business, label sources and spaces by environment or region (for example production and EU) and scope roles to the label so new sources inherit the right access.
- Watch cross-resource rights: connecting a source to a warehouse needs Source Admin and Warehouse destination admin; connecting destinations to an Engage space needs Unify and Engage admin plus Source Admin on the linked source. Combining these on one person lets them send a source's data anywhere.
- Grant PII Access deliberately: it applies only within a user's existing scope, does not give Privacy Portal access, and is required for Observability roles. Review the list quarterly. See the Access Reviews Guide.
Integrations, API tokens and service accounts
Segment has three main kinds of machine credential. Each is a non-human identity with an owner, a purpose and a rotation plan.
| Credential | Created where | What it can do | Key controls |
|---|---|---|---|
| Public API token | Settings > Workspace settings > Access Management > Tokens (Workspace Owner only) | Workspace Owner or Workspace Member access through the Public API | Choose Member where possible, server-side only, Bearer header, store in a secrets manager |
| Source write key | Source > Settings > API Keys | Send events into that source | Generate New Key adds a second active key; delete the old one after cut-over |
| Destination and warehouse credentials | Destination or warehouse settings | Segment writes into your tools or warehouse | Dedicated least-privilege accounts on the receiving side |
Public API tokens
- Pick the access level: a token is created with Workspace Owner or Workspace Member access. Use Member for automation that does not need full control.
- Describe it: the description should name the pipeline, owner and ticket so tokens in the Audit Trail actor filter are recognisable.
- Keep it server-side: Twilio states the Public API is for server-side use only, with the token in the
Authorizationheader as a Bearer token. - Store it in a vault: Twilio notes tokens are often exposed through commits to public repositories. Segment works with GitHub secret scanning and revokes valid tokens found in public repositories, notifying owners; on such a notice, review the Audit Trail for that token's actions. See the Secrets Management Guide.
Write keys
A write key identifies a source and tells Segment where events belong. Keys used in browser or mobile sources are visible to anyone who inspects the page, so treat them as identifiers rather than secrets and protect data quality with Protocols tracking plans that define the events you expect. Keys used by server sources should be kept in a secrets manager. To rotate, open the source, go to Settings > API Keys and choose Generate New Key: the original stays active until you delete it, so deploy the new key, confirm events arrive in the debugger, then delete the old one. This needs Source Admin or Workspace Owner.
Destinations, functions and Twilio credentials
- Destination credentials: give each destination a dedicated account or key in the receiving tool with only the write rights it needs, and record it in your non-human identity inventory. See the Service Account Security Guide.
- Warehouse users: create a dedicated warehouse user for Segment limited to its schema.
- Functions: Function Admin can change code that processes every event; keep it to engineers and review function settings that hold secrets.
- Twilio account credentials: if you also use Twilio messaging, manage those API keys separately. See the Twilio Credentials Security Guide.
Logging and detection
The Audit Trail shows the last 90 days of user and system activity across sources, destinations, warehouses, tracking plans, audiences, journeys, users and workspace settings. It is available on Business to Workspace Owners at Settings > Admin, filterable by action and by actor (users and access tokens), and exportable to CSV.
Audit Forwarding
Turn on Settings > Workspace Settings > Audit Forwarding and select a dedicated HTTP API source, which Twilio recommends. Forwarded events go through the normal pipeline, so you can route them to your SIEM or warehouse, apply filters and keep them beyond 90 days.
| Event area | Example detections | ATT&CK mapping |
|---|---|---|
| Users and workspace | New Workspace Owner, PII Access granted, Require SSO or Require MFA turned off | T1098 Account Manipulation |
| Access tokens | Token created, token acting outside its normal pattern | T1528 Steal Application Access Token |
| Destinations and warehouses | New destination connected to a production source, warehouse settings changed | T1537 Transfer Data to Cloud Account |
| Sources | New write key generated, source deleted or disabled | T1078.004 Cloud Accounts (when actor is unexpected) |
Metrics
- Workspace Owner count: target two to four.
- Users with PII Access: trend down to those with a documented need.
- Public API tokens at Owner level: target zero or a documented few.
- Write keys older than policy: server-side keys past your rotation interval.
- Audit Forwarding health: forwarded events received each day, target no gaps.
- Deletion requests completed within SLA: share finished inside 30 days.
Hardening baseline
Privacy controls
- Privacy Portal: the Inbox shows properties seen in the last 7 days from web, mobile, server and cloud event sources, pre-classified Red, Yellow or Green by default matchers. Review it weekly, add fields to the Inventory, and write custom matchers (up to 100) for your own identifiers. Red and Yellow fields are masked for anyone without PII Access.
- End-user deletion and suppression: issue regulations from Settings > End User Privacy or the Public API (up to 5,000 userIds per call).
SUPPRESS_WITH_DELETEandDELETE_ONLYalso forward deletions to destinations that support programmatic deletion; contact the others directly. Segment's SLA is 30 days for its internal stores, not your warehouse, S3 or destinations. - Device-mode destinations: data sent directly from the device bypasses Segment's suppression point, so prefer cloud-mode destinations where you need suppression to apply.
- Consent: Twilio states suppression is not a substitute for obtaining consent before collecting data. See the Consent Management Guide.
Phased rollout
- Inventory (week 1): export users, groups, roles and PII Access holders; list tokens, sources, destinations and warehouses; export the Audit Trail to CSV as a baseline.
- Identity (weeks 1 to 3): configure SAML SSO, verify domains, connect SCIM with role mapping, test with a pilot group, then turn on Require SSO with documented exemptions. Turn on Require MFA for any remaining password users.
- Roles (weeks 3 to 5): move people from Owner to Member plus scoped roles; apply Labels; record previous assignments so you can restore access if a pipeline owner is blocked.
- Credentials (weeks 4 to 6): recreate Owner tokens as Member tokens where possible, rotate server write keys with the two-key method, and move all secrets into a vault.
- Monitoring and privacy (weeks 5 to 8): enable Audit Forwarding, build alerts, set up Privacy Portal reviews and a tested deletion workflow.
Choosing between options
- Labels versus resource lists: labels suit growing workspaces where new sources appear often; explicit lists suit small, stable estates.
- Owner versus Member tokens: Member tokens fit most automation; reserve Owner tokens for provisioning tooling that manages users or settings.
- Small teams: without Business features, focus on few owners, Require MFA, careful token handling and CSV exports of what is available.
Common misconfigurations
- Everyone is Workspace Owner: gives every user PII Access, token creation and the Privacy Portal.
- Require SSO left off after SSO setup: users keep password sign-in alongside SSO.
- Owner-level tokens in CI pipelines: a leaked token then controls the whole workspace.
- Old write keys never deleted: the second key is added, but the first stays active indefinitely.
- Audit Trail never forwarded: evidence older than 90 days is gone when an investigation needs it.
- Deletion assumed complete everywhere: warehouse, S3 and destinations without programmatic deletion need their own process.
Framework mapping
| Control area | Segment setting | NIST SP 800-53 Rev 5 | NIST CSF 2.0 |
|---|---|---|---|
| Account management | SSO, SCIM, JIT, user and group roles | AC-2 | PR.AA-01 |
| Least privilege | Member base role, scoped roles, Labels, PII Access | AC-6 | PR.AA-05 |
| Authentication | Require SSO, Require MFA | IA-2 | PR.AA-01 |
| Authenticator management | Public API tokens, write key rotation | IA-5 | PR.AA-01 |
| Audit logging | Audit Trail, Audit Forwarding | AU-2, AU-6, AU-11 | PR.PS-04, DE.CM-03 |
| Data protection | Privacy Portal classification, deletion and suppression | SC-28 | PR.DS-01 |
Practitioner checklist
- Limit Workspace Owner to two to four named people and make everyone else a Workspace Member with scoped roles.
- Configure SAML SSO, verify domains, map roles through SCIM and turn on Require SSO.
- Turn on Require MFA for any users who still sign in with a password.
- Grant PII Access only where raw values are needed, and review it quarterly.
- Create Public API tokens at Member level where possible, describe each one, and store them in a vault.
- Rotate server write keys with Generate New Key and delete the old key after cut-over.
- Enable Audit Forwarding to a dedicated HTTP API source and alert on owner, token and destination changes.
- Review the Privacy Portal Inbox weekly and run deletion requests through a tracked workflow.
Standards and references
- Twilio Segment: Roles
- Twilio Segment: Single Sign-On
- Twilio Segment: Multi-Factor Authentication
- Twilio Segment: Audit Trail
- Twilio Segment: Public API
- Twilio Segment: User Deletion and Suppression
- Twilio Segment: Privacy Portal
- Twilio Support: How to Generate a New Write Key for Your Segment Source
Related NHI Mgmt Group resources: SaaS Security Guide · Data Minimisation · GDPR Compliance Guide for Security Teams · API Key Management Guide