Braze Security: Secure dashboard users, REST API keys and PII

Braze holds customer profiles, contact details and engagement history, and it can send email, SMS and push messages to your whole audience, so its dashboard users and REST API keys deserve the same protection as any system that holds personal data and speaks in your brand's name. Braze is a customer engagement platform organised into a company with one or more workspaces. This guide explains how to set up sign-in rules, SAML SSO and SCIM, how to design permission sets, roles and teams, how to scope REST API keys, how to limit who sees PII, and how to use the security event report. It is written for Braze company admins, CRM and lifecycle marketing operations teams, and the security and privacy teams that review them.

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

Key takeaways

• Set sign-in rules first. Security Settings controls password rules, session duration, 2FA, SSO enforcement, a dashboard IP allowlist and Elevated Access.
• Enforce one sign-in method. Use "Enforce custom SAML SSO only login" (or Google SSO) once SSO works, and put MFA in your identity provider; plan for the fact that there is no password fallback.
• Build access from permission sets and roles. Company admins can do everything, and a limited user with every permission except Workspace Admin can do nearly everything a workspace admin can, so grant narrowly.
• Scope every REST API key. Give each key only the permissions it needs and an IP allowlist; permissions cannot be edited later, so rotate by creating a new key.
• Mark PII and collect the security event report. Choose PII fields in Security Settings, keep View PII narrow, and export security events to Amazon S3 for full history.

How identity and access work in Braze

A Braze company contains workspaces, and dashboard users are either company admins or limited users whose access comes from permissions. Sign-in policy for every user sits in one place: Settings > Company Settings > Admin Settings > Security Settings.

SAML SSO, JIT and SCIM

• Setup: Braze supports SAML 2.0 with guides for Microsoft Entra ID, Okta and OneLogin. Register Braze in your identity provider with the ACS URL https://<SUBDOMAIN>.braze.com/auth/saml/callback (.braze.eu for EU) and the default Entity ID braze_dashboard. Only the email attribute is required.
• Turn on: after your account manager enables SAML, toggle SAML SSO on in Security Settings and enter the SAML Name, Target URL and x.509 certificate from your identity provider. An optional Custom Entity ID (braze_dashboard_<companyID>) must match the identity provider exactly.
• RelayState key: IdP-initiated login needs a REST API key with the sso.saml.login permission pasted into the RelayState field. Give that key no other permissions.
• Enforce: once enforced, users cannot sign in with a password, and Braze warns there is no fallback if SSO fails. Test with a pilot group and agree a recovery route with Braze Support before enforcing.
• MFA: Braze's 2FA setting applies only where SSO is not enabled, so with SSO enforced, MFA and conditional access live in your identity provider. Use phishing-resistant MFA there. See the Phishing-Resistant MFA Guide.
• SCIM: under Admin Settings, SCIM Provisioning, select Configure SCIM integration. Braze supports Okta, Entra ID and custom SCIM, one integration per company. Okta and Entra ID integrations create, update and deactivate users; new users get the default permission set on the default workspace, and roles and workspaces are assigned through SCIM group role mapping. userName must match the Braze email exactly, and users created before SCIM keep their manual provisioning, so clean them up separately.

See the SCIM Provisioning Guide and the Identity Provider and SSO Security Guide.

Availability: Braze documents Google SSO and SAML SSO for Pro and Enterprise customers, and SCIM provisioning depends on platform edition. Confirm entitlements with your Braze account manager.

Admin roles and privileged access

Braze offers three building blocks for limited users, under Settings, User Management:

• Permission sets: bundles of permissions by subject or action, applied company-wide (Braze's examples are Developers, Marketers and User Management).
• Roles: permissions or permission sets combined with access to selected workspaces, for example a marketer role limited to one brand's workspaces.
• Teams: restrict which audiences a user can message, based on attributes such as location or language.

1. Keep company admins few: a company admin cannot delete their own account, so another admin must remove them. Have at least two, and no more than you need.
2. Prefer roles over broad permission sets: scope people to the workspaces they work in.
3. Watch near-admin users: Braze notes that a limited user with every permission except Workspace Admin has access to nearly everything a workspace admin can do. Review anyone with a long permission list.
4. Separate user management: Edit Dashboard Users and Delete Dashboard Users are separate permissions; assign them deliberately.
5. Review quarterly: export users and their permissions from Company Users, Export Users (Braze emails a CSV) and review it (our cadence). See the Access Reviews Guide.

Integrations, API tokens and service accounts

Braze REST API keys are bearer credentials sent as Authorization: Bearer <key> to your instance's REST endpoint (for example rest.iad-01.braze.com or rest.fra-01.braze.eu). Braze checks that the key exists, is active and has permission for the endpoint, returning 401 or 403 if not. They are the main non-human identities in a Braze company.

• Create: Settings, APIs and Identifiers, Create API Key. Name it, add allowlisted IPs and subnets, and select permissions such as users.track, users.delete, messages.send, campaigns.list or canvas.list.
• Scope: grant only the endpoints the integration calls. A key used only to record events needs users.track, not messages.send.
• IP allowlist: without one, requests can come from any IP address. Add the integration's egress ranges.
• Rotate by replacement: permissions and allowlisted IPs cannot be edited after creation. Create a new key, switch the integration, then delete the old key from the API Keys tab.
• Ownership: deleting a dashboard user does not delete the API keys they created, so record an owner for every key and review keys when people leave.
• Exposure: Braze advises never placing REST keys in client-side code, AJAX calls, public repositories or user-facing apps, and revoking and replacing a key straight away if it is exposed.

Partner integrations, Currents data exports and Cloud Data Ingestion connections link Braze to other systems; record any credentials they use in the same inventory. See the API Key Management Guide, the Secrets Management Guide and the Non-Human Identity (NHI) Guide.

PII visibility and user deletion

Designate PII fields

In Security Settings, choose which fields your company treats as PII. Braze lists standard attributes that can be marked (email address, phone number, first name, last name, gender, birthday, device IDs, LINE ID and most recent location) and lets you mark all custom attributes or individual ones. Users without the View PII permission cannot see those attributes. Admins have View PII by default.

PII designation only controls what dashboard users can see; it does not change how Braze handles the end-user data. Braze points customers to its data retention documentation and advises consulting your legal team, so treat retention as a separate decision.

Delete user profiles

• Endpoint: POST /users/delete deletes profiles by external ID, user alias, Braze ID, email address or phone number, one identifier type per request and up to 50 identifiers per request.
• Irreversible: Braze states that deleting user profiles cannot be undone and may cause discrepancies in your data. Use a dedicated key with only users.delete for your data subject request workflow.
• Bulk: for cases bulk API deletion cannot cover, Braze directs customers to Support.
• Evidence: user deletions appear in the security event report, which gives you an audit trail for requests.

Collect only the attributes campaigns need, and avoid free-text custom attributes that may capture sensitive data. See the Data Minimisation guide, the GDPR Compliance Guide for Security Teams and the Data Retention and Secure Deletion Guide.

Logging and detection

The security event report is in Security Settings under Security Event Download. It is a CSV with CreatedAt (UTC), EmailAtTimeOfEvent, CurrentEmail, EventName, OtherAccount and JsonProperties columns. It records account invitations and removals, sign-in attempts, 2FA events, Elevated Access events and changes to campaigns, Canvases, segments, REST API keys, Basic Auth credentials, permissions, company settings, email templates, users, catalogs, Cloud Data Ingestion syncs and Braze Agents. Users Viewed and User Updated events are added on request.

The manual download includes only the most recent 10,000 events. Set up the security events export to Amazon S3 to remove that limit, and load it into your SIEM.

Correlate with your identity provider's sign-in logs and with campaign approvals, because an unexpected send is often the first visible sign of a misused account.

Metrics: number of company admins; percentage of users on enforced SSO; REST API keys with an IP allowlist and a named owner; users holding View PII; days of security events held in the SIEM; leavers removed within one day.

Hardening baseline

1. Inventory: export users and permissions, list every REST API key with its permissions and allowlist, and name an owner for each.
2. Tighten sign-in: enforce 2FA now, set session duration and password rules, and turn on Elevated Access.
3. Connect SAML: configure the identity provider, test with a pilot group, then select "Enforce custom SAML SSO only login". Agree a recovery path with Braze Support first, since there is no password fallback.
4. Turn on SCIM where your edition includes it, and map groups to roles.
5. Restructure access: move people onto roles scoped to their workspaces, cut company admins to two or three, and limit View PII and export permissions.
6. Replace broad API keys: create scoped, allowlisted keys per integration, switch over, then delete the old ones.
7. Mark PII fields in Security Settings and check what limited users now see.
8. Add the dashboard IP allowlist where your network allows, testing with one admin before saving.
9. Export security events to S3 and alert on the signals above.

Common misconfigurations

• All-permission keys: one REST API key with every permission, shared across several tools, with no IP allowlist.
• Orphaned keys: keys left active after their creator leaves, because deleting a user does not delete their keys.
• SSO enforced without a recovery plan: an identity provider certificate change locks everyone out because there is no password fallback.
• 2FA assumed under SSO: MFA is expected from Braze's 2FA setting, but it applies only when SSO is not enabled, so the identity provider policy is what counts.
• Near-admin limited users: users given every permission except Workspace Admin for convenience.
• PII not designated: contact fields visible to every dashboard user, and View PII granted widely.
• Report capped at 10,000 events: relying on manual downloads, so older events drop out.

Framework mapping

Practitioner checklist

• SAML SSO configured and "Enforce custom SAML SSO only login" selected, with a documented recovery path.
• Phishing-resistant MFA enforced at the identity provider; Braze 2FA enforced for any non-SSO access.
• Session duration, password rules and Elevated Access set in Security Settings.
• Dashboard IP allowlist in place where practical.
• Two or three company admins; everyone else on roles scoped to their workspaces.
• View PII and export permissions held by a small, reviewed group.
• Every REST API key scoped to minimum permissions, IP allowlisted, owned and vaulted.
• PII fields designated in Security Settings.
• Deletion requests run through POST /users/delete with a dedicated key.
• Security events exported to S3 and monitored in the SIEM.

Standards and references

• Braze: Security settings
• Braze: SAML SSO setup
• Braze: Automated user provisioning
• Braze: User permissions
• Braze: API basics
• Braze: Delete users endpoint
• NIST: SP 800-53 Rev 5 Security and Privacy Controls
• CIS: Critical Security Controls v8.1

Related NHI Mgmt Group resources: SaaS Security Guide · SCIM Provisioning Guide · API Key Management Guide · Consent Management Guide: Cookies, CMPs and GPC