Marketing Cloud Engagement holds subscriber lists, behavioural tracking and the ability to send messages in your brand's name to millions of people, so its roles, installed packages and file transfer accounts deserve the same care as any customer data platform. Marketing Cloud Engagement runs on a separate stack from core Salesforce, with its own users, roles, business units, security settings and API model, which means controls set in a Salesforce org do not carry across. This guide explains how users, roles and business units fit together, how to control administrators, how to scope installed package API integrations, what Audit Trail and send logging record, and a hardening baseline built on Salesforce's recommended settings. It is written for Marketing Cloud administrators, marketing operations and integration engineers, and the security teams that review them. For the core Salesforce platform, see the Salesforce Security Guide.
This is an independent guide from NHI Mgmt Group, based on Salesforce's public documentation as of November 2026. It is not sponsored or reviewed by Salesforce. Product features change, so confirm settings against Salesforce's current documentation.
Key takeaways
- It is its own identity island. Marketing Cloud Engagement users, roles and security settings are managed inside the account, so connect it to your identity provider with SAML 2.0 and apply MFA there or in the account itself.
- The Security Administrator role owns access. Salesforce designed Marketing Cloud Security Administrator for whoever decides user access; keep it apart from the people who build and send campaigns.
- Installed packages are the main non-human identities. A server-to-server API integration can do everything its scopes allow in every business unit it is enabled for, so assign only the scopes and business units it needs.
- File transfer accounts need attention. Salesforce notes the FTP password is shared across the account, so rotate it on a schedule and update every dependent automation.
- Basic Audit Trail keeps 30 days. Extract it regularly through Automation Studio or the REST API into your own retention, and consider the advanced version for business unit and content changes.
How identity and access work in Marketing Cloud Engagement
An Enterprise account is organised as a top-level account with business units beneath it, typically one per brand, region or regulated audience. Users belong to one or more business units, and data, content and sends are separated by business unit, which makes business unit design the first access boundary.
Roles
Each user can have one standard Marketing Cloud Engagement role and one standard Email Studio role. Where neither fits, create a custom role or assign individual permissions. Custom roles work in the top-level account and in business units.
| Role | Purpose (per Salesforce) | Typical holder |
|---|---|---|
| Marketing Cloud Administrator | Assigns roles and manages channels, apps and tools across most functionality except Email Studio | Platform owner |
| Marketing Cloud Security Administrator | Maintains security settings and manages user activity and alerts | Person who decides user access |
| Marketing Cloud Channel Manager | Creates and runs cross-channel campaigns, administers specific channels, sends and monitors journeys | Senior marketing operations |
| Marketing Cloud Content Editor/Publisher | Creates and delivers messages and journeys, with limited reporting | Campaign builders |
| Marketing Cloud Viewer | Read-only view of activity; no creating, sending or reporting | Stakeholders and reviewers |
| Email Studio Administrator, Data Manager, Content Creator, Analyst | Full Email Studio access; data without content; content without data; tracking only | Email specialists by task |
Salesforce advises giving each person only the roles their job needs and not assigning every role to one user. Pair Content Creator with Data Manager responsibilities only where one person genuinely does both, since that combination joins subscriber data with the ability to build sends.
Authentication
- Single sign-on: SAML 2.0 with a third-party identity provider or Salesforce federated authentication; each account supports one SAML key. Activate it with the correct metadata and test before enforcing.
- Multi-factor authentication: once enabled, each user registers at least one method: Salesforce Authenticator, U2F or WebAuthn security keys, or TOTP apps. Salesforce recommends phishing-resistant MFA for the highest security. See the Phishing-Resistant MFA Guide.
- Step-Up Authentication: requires administrators to re-authenticate with MFA before critical tasks such as editing account security settings. Turn it on.
- Login IP Allowlist: restricts sign-in to approved IP addresses; use it for administrators and API users where your network design allows.
Admin roles and privileged access
Three capabilities carry the most risk: changing security settings, assigning roles, and creating installed packages.
- Separate security from operations: assign Marketing Cloud Security Administrator to the access owner, and Marketing Cloud Administrator to the platform owner, with neither held by everyday campaign builders.
- Control Installed Package | Administer: this permission is needed to create, install and delete packages and API integrations. Salesforce applies it automatically to the Administrator and Marketing Cloud Administrator roles; anyone else who holds it can mint API credentials. Installs and uninstalls apply to every account in the enterprise, which makes it an enterprise-wide privilege.
- Scope by business unit: give administrators rights only in the business units they run. A regional admin should not hold top-level account roles.
- Protect exports: turn on Enforce Export Email Allowlist so data exports go only to approved addresses.
- Keep two administrators: one administrator account is a single point of failure for lockouts; two named administrators with MFA, plus an emergency process, is a sound minimum. See the Break-Glass Account Guide.
Integrations, API tokens and service accounts
Integrations live in Setup > Apps > Installed Packages. A package holds components; for API access you add an API Integration component, which gives a client ID and, for confidential clients, a client secret used against your tenant-specific Authentication Base URI.
| Integration type | OAuth flow | What it can reach | Control points |
|---|---|---|---|
| Server-to-server | Client credentials (v2/token with account_id set to the business unit MID) | Everything its assigned scopes allow, in each business unit enabled on the Access tab | Scopes, Access tab, secret storage and rotation |
| Web app or public app | Authorisation code (v2/authorize, v2/token) | The intersection of the app's scopes and the signed-in user's rights | Up to 10 HTTPS redirect URIs, no wildcards; user must have a licence to the package |
| Legacy package integration | Legacy v1/requestToken route, outside OAuth 2.0 | Package-defined access | Plan migration to an enhanced package |
Scoping installed packages
Salesforce's guidance is to assign only the scopes a package needs. Scopes are grouped by area: Channels (Email, SMS, Push, OTT, Social, Web), Assets, Automation (Automations and Journeys, including Execute), Contacts (Audiences, Lists and Subscribers), Data (Data Extensions, File Locations, Tracking Events), Hub, Provisioning (Organizations and Users) and Webhooks.
- Treat Provisioning scopes as administrative: Users (Write) and Organizations (Write) let an integration manage accounts and business units. Few integrations need them.
- Separate read and send: an analytics extract needs Tracking Events (Read) and Data Extensions (Read), not Email (Send) or Journeys (Execute).
- One package per integration: an API integration component cannot be removed from a package once added, so a dedicated package per integration keeps retirement clean: delete the whole package when the integration ends.
- Limit business units: enable a server-to-server integration only for the business units on its Access tab that it serves. Tokens are scoped to one business unit at a time, which helps containment.
- Store secrets server-side: Salesforce advises storing the client ID and secret securely and never exposing them in client-side JavaScript or a mobile app. Keep them in a secrets manager with a named owner; see the Secrets Management Guide and OAuth Scope Design Guide.
- Plan for revocation: sessions can be revoked at any time, for example after a password reset or licence removal, so integrations should handle 401 responses and re-authenticate cleanly.
File transfer accounts and automations
Marketing Cloud uses an SFTP location for file imports and extracts, which automated jobs commonly read from and write to. Salesforce requires secure connections for SFTP and notes that the FTP password is shared across the account, so every user and automation that depends on it must be updated when it changes. Rotate it on a fixed schedule (Salesforce suggests at least every 90 days), keep the Exclude FTP Users from Password Expiration setting off unless you have a compensating rotation process, and restrict who can create file locations through the Data scope File Locations (Write). Treat each automation that moves subscriber files as a non-human identity with an owner; see the Service Account Security Guide.
Logging and detection
- Audit Trail (basic): available to all accounts with 30 days of data. It records user authentication and IP addresses, changes to users, roles and permissions, and changes to security settings. Turn on Enable Audit Trail Data Collection.
- Audit Trail (advanced): adds user agents, session IDs, business unit changes and content and data changes for Email Studio, CloudPages, MobilePush and MobileConnect. Salesforce asks customers to contact their account executive to enable it.
- Retrieval: Security Administrators can extract Audit Trail data through an Automation Studio data extract or the REST API. Schedule a daily pull into your SIEM so evidence outlives the 30-day window.
- Send logging: a send log data extension, created from the send logging template, records run-time attributes for user-initiated, triggered and A/B test sends. Salesforce recommends creating it with Data Retention enabled and individual record deletion, which keeps personal data from accumulating.
| What to alert on | Source | Why |
|---|---|---|
| Security settings changed (MFA, session, password, IP allowlist) | Audit Trail | Weakened sign-in controls |
| Role or permission granted, especially Security Administrator or Installed Package | Administer | Audit Trail | New privileged users or API credential creators |
| New installed package or new API integration component | Installed Packages review; advanced Audit Trail | New non-human identity with data access |
| Logins from outside expected IP ranges or countries | Audit Trail authentication events | Credential misuse |
| Unusual export or extract volume | Automation Studio activity; export notifications | Bulk subscriber data leaving the platform |
| Sends from an unexpected business unit or user | Send log data extension | Unauthorised messaging in your brand's name |
Metrics: percentage of users on SSO or MFA (target: all); number of holders of Security Administrator and Installed Package | Administer; installed packages with a named owner and last review date; server-to-server packages holding Provisioning or Send scopes; days since FTP password rotation; and days since the last successful Audit Trail extract.
Hardening baseline
Salesforce publishes recommended values for the account security settings. Apply them in a test business unit first where possible, then the top-level account.
| Setting | Salesforce recommended value |
|---|---|
| Session Timeout | 20 minutes |
| Login Expires After Inactivity | 90 days or fewer (Salesforce cautions against it where API users are present) |
| Invalid Logins Before Lockout | 3 |
| Minimum Username Length | 8 or more |
| Minimum Password Length | 8 or more |
| Enforce Password History | 8 or more |
| User Passwords Expire In | 90 days |
| Send Password Change Confirmation Email | On |
| Enforce Export Email Allowlist | On |
- Inventory: list business units, users and roles, installed packages with their scopes and business unit access, file locations and automations.
- Federate and add MFA: configure SAML 2.0 SSO, test with a pilot group, then enforce; enable MFA with phishing-resistant methods and Step-Up Authentication for administrators.
- Apply the settings above and the Login IP Allowlist for administrative and API users.
- Right-size roles: move users to the narrowest standard or custom role, scoped to their business units, and reduce Security Administrator and Installed Package | Administer holders.
- Rebuild packages: give each integration its own enhanced package with minimal scopes and business units; migrate legacy packages; rotate secrets as you go.
- Protect data: enable Field-Level Encryption for sensitive data extension fields, which are decrypted at send time, and confirm Data at Rest Encryption coverage (Salesforce notes it does not extend to Predictive Intelligence or Audience Builder data).
- Turn on logging: enable Audit Trail data collection, schedule extraction and set send log retention.
- Roll back safely: record previous settings before each change; SSO and IP allowlist changes are the most likely to lock users out, so keep an administrator able to sign in directly until enforcement is proven.
Small and large organisations
A small team with one business unit can rely on standard roles, SSO, MFA and a handful of tightly scoped packages. A multinational with many brands should use business units as data boundaries, custom roles per region, a central owner for installed packages and the advanced Audit Trail for business unit and content changes.
Common misconfigurations
- All-scope server-to-server packages: one integration package granted every scope and every business unit. Rebuild with minimal scopes per integration.
- Everyone is an administrator: Marketing Cloud Administrator given to agency staff for convenience. Use Channel Manager or Content Editor/Publisher scoped to the business unit.
- Shared FTP password never rotated: embedded in old automations and agency tools. Rotate on schedule and keep an inventory of dependents.
- Client secrets in front-end code: Salesforce explicitly advises against exposing secrets in JavaScript or mobile apps. Use a server-side component.
- Audit Trail never extracted: the 30-day basic window expires before anyone looks. Automate extraction from day one.
- Exports to personal mailboxes: Enforce Export Email Allowlist left off. Turn it on with corporate domains only.
Framework mapping
| Control area | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | ISO/IEC 27001:2022 Annex A | CIS Controls v8.1 |
|---|---|---|---|---|
| SSO, MFA and session settings | IA-2, AC-12 | PR.AA-03 | 8.5 | 6 |
| Roles, business units and least privilege | AC-2, AC-6 | PR.AA-05 | 5.15, 8.2 | 5, 6 |
| Installed package credentials and FTP password | IA-5 | PR.AA-01 | 5.17 | 5 |
| Encryption of subscriber data | SC-28 | PR.DS-01 | 8.24 | 3.11 |
| Audit Trail and send log review | AU-2, AU-6, AU-11 | PR.PS-04, DE.CM-03 | 8.15 | 8 |
Practitioner checklist
- Enforce SAML 2.0 SSO or MFA for every user, with Step-Up Authentication for administrators.
- Limit Marketing Cloud Security Administrator, Marketing Cloud Administrator and Installed Package | Administer to named owners.
- Apply Salesforce's recommended session, lockout and password values and turn on Enforce Export Email Allowlist.
- Give each integration its own enhanced package with only the scopes and business units it needs.
- Store client secrets in a secrets manager and rotate them, never in front-end code.
- Rotate the FTP password on a schedule and keep a list of every dependent automation.
- Enable Audit Trail data collection and extract it daily into your SIEM.
- Create send log data extensions with Data Retention enabled.
- Review installed packages and role assignments quarterly, removing anything without an owner.
Standards and references
- Salesforce: Marketing Cloud Engagement Security Settings
- Salesforce: Marketing Cloud Engagement Roles
- Salesforce Developers: Integration Considerations
- Salesforce Developers: API Integration Permission Scopes
- Salesforce Developers: Create and Install Packages
- Salesforce Trailhead: Get to Know Marketing Cloud Engagement Security
- Salesforce: Send Logging
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: Salesforce Security Guide · API Key Management Guide · Non-Human Identity (NHI) Guide · SAML Security Guide