Salesforce Account Engagement (Pardot) Security: Secure users, connectors, API access and tracking

Account Engagement holds prospect records, web and email behaviour for every tracked visitor, and the ability to send email in your brand's name, while its connector writes into your Salesforce leads and contacts, so its users and integrations need the same care as the CRM itself. Salesforce Account Engagement (formerly Pardot) is a B2B marketing automation product that sits alongside a Salesforce org, with its own business units, roles, tracker domains and API. This guide explains how users and roles are governed through Salesforce User Sync, how to scope the connector's integration user and API apps, how to set up tracking and consent, and which records to watch. It is written for Account Engagement and Salesforce administrators, marketing operations teams and the security and privacy teams that review them. For the core 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

• Manage users from Salesforce. With Salesforce User Sync, the Salesforce user record is the source of truth, so Account Engagement users inherit your Salesforce sign-in, MFA and deprovisioning.
• Profiles decide roles. Salesforce profiles map one-to-one to Account Engagement roles, so profile design is now marketing access design.
• The connector is a powerful non-human identity. The B2BMA Integration user can see and change every record that can sync; narrow it with Marketing Data Sharing.
• API access runs through Salesforce OAuth. Build integrations as external client apps with the "Manage Pardot services" scope and a dedicated user per integration.
• Tracking needs verified domains and consent. Use a validated HTTPS tracker domain and the Tracking and Consent JavaScript API so visitors in consent geographies are not tracked before opting in.

How identity and access work in Account Engagement

Account Engagement is provisioned in business units. A Salesforce admin creates each business unit and assigns its Account Engagement admin under Business Unit Setup, and each business unit is linked to a Salesforce org. Users reach Account Engagement through the Lightning app in Salesforce, signing in with their Salesforce credentials ("Log In with Salesforce").

Salesforce User Sync

Salesforce User Sync moves Account Engagement user management into Marketing Setup in Salesforce. Salesforce documents these behaviours:

• Source of truth: synced user records are read-only in Account Engagement and inherit their details from the Salesforce user record.
• Role mapping: Salesforce profiles map one-to-one to Account Engagement roles. Where users who share a profile need different access, give them a more specific profile.
• Groups: users in the Marketing Users group get their profile mapped to a Marketing role, which can be edited; users in the Sales Users group always get the Sales role. Salesforce advises keeping Sales Users to sales reps.
• Deprovisioning: unassigning a user in Salesforce moves their Account Engagement record to the recycle bin, and changes typically sync within about 10 minutes (up to an hour in very large orgs).
• Prerequisite: transferring user management to Salesforce requires the Account Engagement Administrator role.

Because sign-in happens in Salesforce, multi-factor authentication, SSO through your identity provider, session settings and login IP ranges are all configured on the Salesforce side. Apply them to every user with Account Engagement access. See the Salesforce Security Guide and the Identity Provider and SSO Security Guide.

Roles

Confirm the current role names and profile mappings in your account's Marketing Setup and Salesforce's current documentation.

Admin roles and privileged access

The Account Engagement Administrator can change the connector, field mapping, sync behaviour, tracker and sending domains, and user management. Those settings decide which CRM data flows into marketing and what can be sent in your name, so treat the role as privileged.

1. Name the admins: keep the Administrator role to a small group per business unit, and record why each holder needs it. Note that the admin assigned when a business unit is created stays recorded as a historical entry.
2. Separate Salesforce and marketing administration: a Salesforce system administrator can change profiles, permission sets and the integration user, so review both sets of admins together.
3. Control permission sets: the Account Engagement User, Sales Cloud User, Service Cloud User and CRM User permission sets and the B2BMA Canvas connected app assignment control who reaches Engagement History and the Lightning app. Assign them through groups or permission set groups and review membership quarterly (our recommendation).
4. Align data visibility: users can see more Salesforce data in Account Engagement than in Salesforce itself. Salesforce advises creating sharing rules that match Marketing Data Sharing rules and applying them to the Marketing Users group.
5. Review access on change: run an access review when a business unit is added, when a new region starts using the account, or when an agency is given access.

For a structured approach to role reviews, see the Segregation of Duties Guide.

Integrations, API tokens and service accounts

The Salesforce connector and its integration user

Current connector setups sync through an integration user named B2BMA Integration. Salesforce documents it as follows:

• Identity: username b2bmaintegration@<org-id>.ext with the B2BMA Integration User profile, which allows it to view and modify the data that syncs between the two systems.
• Authentication: it has no password and cannot log in to Salesforce interactively; it authenticates through the Pardot Integration Connected App using the OAuth 2.0 JWT bearer flow.
• Attribution: changes made by the connector are attributed to this user, which separates integration changes from manual ones in your logs.
• Reach: it can access all records that can sync. Use Marketing Data Sharing to limit it to the records marketing actually needs, and change the integration user setting before unpausing the connector if you want selective sync.

Some business units use a named connector user instead. In that case Salesforce advises applying the Pardot Connector User permission set only to that connector user, granting the object and field permissions the connector needs, and installing the package with "Grant access to admins only". Treat any connector user like a service account: no interactive use, a named owner and monitored activity. See the guide on How to review Salesforce connected apps and integration users.

Account Engagement API

• App type: create an external client app in External Client Manager, set Distribution State to Local, select "Enable OAuth Settings" and add the "Manage Pardot services" scope. See Salesforce External Client Apps.
• Flow: Salesforce's quick start uses the Web Server (authorization code) flow and advises exchanging the code on your server so the access token never reaches the browser.
• Requests: send the access token as a Bearer token and the Pardot-Business-Unit-Id header, even with one business unit. Production and training use pi.pardot.com; demo, developer and sandbox environments use pi.demo.pardot.com.
• Integration users: the user an integration acts as must be SSO-enabled with Account Engagement access, and Salesforce recommends a dedicated user for each integration.
• Secrets: treat the consumer key and secret as sensitive, store them in a secrets manager and test new integrations in a sandbox first.

For the wider governance pattern, see the SaaS and OAuth App Governance Guide and the Non-Human Identity (NHI) Guide.

Tracking, consent and prospect data

Account Engagement sets tracking on your websites and records prospect activity, which makes its privacy settings part of your security baseline.

• Tracker domains: each business unit has one primary tracker domain, unique across business units. The tracker domain object exposes validationStatus (default, validated or not validated), httpsStatus and sslStatus. Validate every vanity tracker domain and serve it over HTTPS.
• First-party tracking: a default campaign is required before tracking codes can be generated and before first-party tracking can be enabled in account settings.
• Tracking and Consent JavaScript API: turn on "Activate the Tracking & Consent JavaScript API" in Account Engagement Settings. The piDomain must be a verified tracker domain that is a subdomain of the site running the snippet. For visitors in geographies that you configure as requiring consent, page views are not recorded until the visitor opts in, and the consent banner is shown instead.
• Sending domains: verify sending domains with a DNS TXT record and add DKIM, as Salesforce recommends. See the DMARC, SPF and DKIM Guide.
• Deletion: permanently deleting a prospect removes its tracking data and cannot be undone; associated leads and contacts are deleted in Salesforce first. Build data subject deletion requests around this order.
• Field sync: each prospect field has a Sync Behavior setting. Sync only the fields marketing needs, and keep sensitive Salesforce fields out of the mapping.

For consent design, see the Consent Management Guide: Cookies, CMPs and GPC and the Cookie and Tracking Technology Compliance Guide.

Logging and detection

Because users sign in and are provisioned through Salesforce, most identity evidence lives in the Salesforce org: login history, setup changes to profiles, permission sets and connected or external client apps, and API usage by integration users. Connector writes appear under the B2BMA Integration user, which makes integration changes easy to separate from human edits.

For Salesforce-side telemetry, see the Salesforce Event Monitoring Detection Guide.

Metrics: percentage of Account Engagement users managed through User Sync (target 100%); number of Administrator role holders per business unit; integrations with a dedicated user and named owner; tracker domains validated and on HTTPS; days from leaver to removal.

Hardening baseline

1. Turn on Salesforce User Sync and design profiles for each role before switching; pilot with one business unit and keep the Account Engagement admin role in place until mapping is confirmed.
2. Enforce MFA and SSO in Salesforce for every user with Account Engagement access, with phishing-resistant MFA for admins. See the Phishing-Resistant MFA Guide.
3. Limit administrators to a named group per business unit.
4. Scope the connector with Marketing Data Sharing and matching sharing rules.
5. Build API access as external client apps with one dedicated user per integration and secrets in a vault.
6. Validate tracker domains, use HTTPS and turn on the Tracking and Consent API with your consent geographies.
7. Verify sending domains with TXT and DKIM records.
8. Review quarterly: roles, permission sets, integrations, field mappings.

Roll back a User Sync or connector change by pausing the connector, which stops records syncing until you unpause it after review.

Common misconfigurations

• Connector left at full reach: the integration user syncs every syncable record because Marketing Data Sharing was never configured.
• Shared integration users: several tools act as one user, so an issue in one cannot be isolated or revoked separately. Use one user per integration, as Salesforce recommends.
• Broad profiles in the Marketing Users group: profiles mapped to admin-level marketing roles for convenience. Create narrower profiles.
• Sales Users group used for non-sales staff: Salesforce advises keeping it to sales reps.
• Tracking before consent: tracking code deployed without the Tracking and Consent API in consent geographies.
• Unvalidated or HTTP tracker domains: vanity domains left in "not validated" status or without SSL.

Framework mapping

Practitioner checklist

• Salesforce User Sync enabled for every business unit, with profiles mapped deliberately to roles.
• MFA and SSO enforced in Salesforce for all Account Engagement users.
• Administrator role held by a named, reviewed group per business unit.
• Connector scoped with Marketing Data Sharing and matching sharing rules.
• Connector user (where used) holds the Pardot Connector User permission set and no interactive access.
• Each API integration is an external client app with its own dedicated user and a vaulted secret.
• Tracker domains validated and on HTTPS; Tracking and Consent API active for consent geographies.
• Sending domains verified with TXT and DKIM.
• Admin, integration and domain changes monitored from Salesforce logs.

Standards and references

• Salesforce Developers: Account Engagement API Quick Start
• Salesforce: Account Engagement Implementation Guide
• Salesforce: Account Engagement Salesforce Connector v2 Setup
• Salesforce Developers: Getting Started with the Tracking and Consent JavaScript API
• Salesforce Developers: Tracker Domain Object
• Salesforce Trailhead: Learn Account Engagement Administration Basics
• NIST: SP 800-53 Rev 5 Security and Privacy Controls
• CIS: Critical Security Controls v8.1

Related NHI Mgmt Group resources: Salesforce Security Guide · How to review Salesforce connected apps and integration users · Salesforce External Client Apps · Consent Management Guide: Cookies, CMPs and GPC