Join our Newsletter — 33% off our NHI Course
Home› Guides› Salesforce Marketing Cloud Engagement Security: Lock down roles,…
Guide SaaS & OAuth Integrations

Salesforce Marketing Cloud Engagement Security: Lock down roles, packages and data access

← All guides
By NHI Mgmt Group, edited by Lalit Choda Updated 8 November 2026 13 min read
On this page

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.

RolePurpose (per Salesforce)Typical holder
Marketing Cloud AdministratorAssigns roles and manages channels, apps and tools across most functionality except Email StudioPlatform owner
Marketing Cloud Security AdministratorMaintains security settings and manages user activity and alertsPerson who decides user access
Marketing Cloud Channel ManagerCreates and runs cross-channel campaigns, administers specific channels, sends and monitors journeysSenior marketing operations
Marketing Cloud Content Editor/PublisherCreates and delivers messages and journeys, with limited reportingCampaign builders
Marketing Cloud ViewerRead-only view of activity; no creating, sending or reportingStakeholders and reviewers
Email Studio Administrator, Data Manager, Content Creator, AnalystFull Email Studio access; data without content; content without data; tracking onlyEmail 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 typeOAuth flowWhat it can reachControl points
Server-to-serverClient 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 tabScopes, Access tab, secret storage and rotation
Web app or public appAuthorisation code (v2/authorize, v2/token)The intersection of the app's scopes and the signed-in user's rightsUp to 10 HTTPS redirect URIs, no wildcards; user must have a licence to the package
Legacy package integrationLegacy v1/requestToken route, outside OAuth 2.0Package-defined accessPlan 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 onSourceWhy
Security settings changed (MFA, session, password, IP allowlist)Audit TrailWeakened sign-in controls
Role or permission granted, especially Security Administrator or Installed Package | AdministerAudit TrailNew privileged users or API credential creators
New installed package or new API integration componentInstalled Packages review; advanced Audit TrailNew non-human identity with data access
Logins from outside expected IP ranges or countriesAudit Trail authentication eventsCredential misuse
Unusual export or extract volumeAutomation Studio activity; export notificationsBulk subscriber data leaving the platform
Sends from an unexpected business unit or userSend log data extensionUnauthorised 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.

SettingSalesforce recommended value
Session Timeout20 minutes
Login Expires After Inactivity90 days or fewer (Salesforce cautions against it where API users are present)
Invalid Logins Before Lockout3
Minimum Username Length8 or more
Minimum Password Length8 or more
Enforce Password History8 or more
User Passwords Expire In90 days
Send Password Change Confirmation EmailOn
Enforce Export Email AllowlistOn
  1. Inventory: list business units, users and roles, installed packages with their scopes and business unit access, file locations and automations.
  2. 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.
  3. Apply the settings above and the Login IP Allowlist for administrative and API users.
  4. 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.
  5. Rebuild packages: give each integration its own enhanced package with minimal scopes and business units; migrate legacy packages; rotate secrets as you go.
  6. 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).
  7. Turn on logging: enable Audit Trail data collection, schedule extraction and set send log retention.
  8. 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 areaNIST SP 800-53 Rev. 5NIST CSF 2.0ISO/IEC 27001:2022 Annex ACIS Controls v8.1
SSO, MFA and session settingsIA-2, AC-12PR.AA-038.56
Roles, business units and least privilegeAC-2, AC-6PR.AA-055.15, 8.25, 6
Installed package credentials and FTP passwordIA-5PR.AA-015.175
Encryption of subscriber dataSC-28PR.DS-018.243.11
Audit Trail and send log reviewAU-2, AU-6, AU-11PR.PS-04, DE.CM-038.158

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

Related NHI Mgmt Group resources: Salesforce Security Guide · API Key Management Guide · Non-Human Identity (NHI) Guide · SAML Security Guide

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Researched and written by the NHI Mgmt Group editorial team using AI tools, under the editorial direction of Lalit Choda. Facts are drawn from the sources listed on this page and checked by our automated quality process. Last updated 8 November 2026. Spotted an error? Use our contact page.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM and Agentic AI security. nhimg.org