Adobe Marketo Engage Security: Roles, API Users and Workspaces

Adobe Marketo Engage holds your person database, behavioural activity and the power to email every lead in your brand's name, so its roles, API Only users and workspaces need the same governance as any system of record for customer data. Access in Marketo Engage is split across two places: identity and entitlement in the Adobe Admin Console for subscriptions on Adobe Identity, and roles, permissions, workspaces and API Only users inside Marketo itself. Integrations reach the person database through LaunchPoint custom services, each tied to an API Only user whose role decides what the service can read or change. This guide explains how that model fits together, how to keep administrator rights small, how to scope API Only users and custom services, what Audit Trail and Login History record, and a hardening baseline with privacy controls. It is written for Marketo administrators, marketing operations teams, integration engineers and the security and privacy teams who review them.

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

Key takeaways

• Identity lives in the Admin Console, privilege lives in Marketo. For subscriptions on Adobe Identity, set up SSO and sign-in policy in the Adobe Admin Console, then grant Marketo Admin or standard user privileges inside Marketo Engage.
• Roles are built from named permissions. Access Users, Access Roles, Access Single Sign-on, Access Login Settings and Access Webhooks are the permissions that change who can do what; keep them in a small administrator role.
• Every integration is an API Only user. A LaunchPoint custom service inherits the role of its API Only user, so build one API Only role per integration with only the Read-Only or Read-Write API permissions it needs.
• Use the Authorization header. Adobe removed support for the access_token query parameter on 31 August 2026; integrations must send Authorization: Bearer tokens, which also keeps tokens out of URL logs.
• Export Audit Trail regularly. Audit Trail holds six months of asset and admin changes, with 30 days viewable in the instance, so pull exports into your own retention and SIEM on a schedule.

How identity and access work in Marketo Engage

A Marketo Engage subscription is one instance with a person database, marketing assets and a set of users. Three layers decide what anyone can do: who can sign in (identity), what role they hold (permissions), and which workspaces and person partitions they can reach (scope).

Identity: Adobe Admin Console and Marketo

Adobe states that subscriptions created on or after 31 July 2023 are integrated with Adobe Identity Management, and that subscriptions onboarded to Adobe Identity manage users through the Adobe Admin Console. Identity features such as SSO are configured there. Marketing users and administrators are therefore entitled in the Admin Console, while API Only users are still created and managed inside Marketo Engage.

The practical consequence is that two groups of people hold privilege. Admin Console System Admins decide how everyone authenticates and can entitle new users, so they belong in your identity team's privileged access process. Marketo Engage Admins decide what entitled users can do. Review both lists together. See the SAML Security Guide for federation hardening.

Authentication

• Single sign-on: configure a federated directory in the Admin Console against your identity provider, then enforce MFA and conditional access in the identity provider so the same policy covers Marketo and every other Adobe product. If SSO is not yet set up in your Adobe org, Adobe directs customers to raise a Marketo Support ticket on implementing SSO with the Admin Console.
• Multi-factor authentication: apply phishing-resistant methods for administrators and anyone with export or send rights. See the Phishing-Resistant MFA Guide.
• Login IP restrictions: Admin > Login Settings > Edit IP Restrictions lets you Allow or Block listed addresses. Rules must be all Allow or all Block. Adobe states that Marketo IP restrictions stay active through Q1 2027 and will then be retired in favour of Admin Console IP-based access, so configure the same allow list in both now.

Scope: workspaces and person partitions

Workspaces are separate areas holding programs, emails and landing pages; each user has access to one or more workspaces, set through Admin > Users & Roles > Edit User. Person partitions act like separate databases: people in one partition do not mix or de-duplicate with another. Workspaces map to partitions one to one, one to many or many to one. Use them as an access boundary between brands, regions or regulated audiences: a regional team that only reaches its own workspace and partition cannot see or email the rest of the database. Folders shared from one workspace appear read-only in the receiving workspace, which suits central templates managed by one team.

Admin roles and privileged access

Marketo roles are collections of named permissions. The Access Admin group contains the permissions that change security, identity and integrations. Treat any role holding these as privileged.

• Separate builders from administrators: campaign builders need asset and smart campaign rights in their workspace, not Access Users or Access Roles. Create a marketing user role without the Access Admin group and make it the default.
• Create a security reviewer role: a role with Access Audit Trail, Access Admin Audit Trail and Access Login History lets security staff review evidence without the power to change anything.
• Keep administrator numbers small: two named administrators avoids a single point of failure; more than a handful makes reviews meaningless. Agree an emergency access route through the Admin Console. See the Break-Glass Account Guide.
• Review quarterly: export the Users & Roles list, compare it with the Admin Console entitlement list and HR leavers, and remove anyone who has moved on. See the Access Reviews Guide.

Integrations, API tokens and service accounts

Marketo integrations are non-human identities. Adobe's REST authentication model is straightforward: each custom service in Admin > Integration > LaunchPoint belongs to an API Only user, and that user's role decides what the service can do. The service holds a Client ID and Client Secret (LaunchPoint > View Details), which an integration exchanges at the Identity URL (Admin > Integration > Web Services) for an access token.

Building a least-privilege API Only user

1. Create an API Only role first: select only the Access API permissions the integration needs. A webinar sync that writes registrants may need Read-Write Person and Read-Only Campaign; a BI extract may need only Read-Only Activity and Read-Only Person.
2. Create the API Only user: Admin > Users & Roles > Create API Only User, assign the role, and use a distribution-list email owned by the integration team rather than a person's mailbox. Adobe notes API Only users do not count against the user allotment, so there is no licence reason to share one across integrations.
3. Restrict workspaces: give the API Only user access only to the workspaces whose data it handles.
4. Create one custom service per integration: in LaunchPoint, tie it to that API Only user and record the owner, purpose and vendor in the description.
5. Store the secret server-side: put the Client Secret in a secrets manager, never in browser code, spreadsheets or a shared drive. See the Secrets Management Guide.

Treat Execute Campaign and Approve Assets as high-impact: together they let an integration publish content and send it. Grant them only to tools whose job is sending.

Tokens

• Lifetime: access tokens last 3,600 seconds. Calling the Identity endpoint before expiry returns the same token with its remaining life. Error 601 means invalid and 602 means expired; renew through the Identity endpoint.
• Header only: send Authorization: Bearer <token>. Adobe removed access_token query parameter support on 31 August 2026, and integrations that still use it may receive 603 Access Denied. Check vendor connectors as well as in-house code.
• API IP allowlist: Admin > Web Services > IP Restrictions > Enable IP Restrictions accepts single addresses, ranges or wildcards. Add the egress addresses of your middleware and of each vendor that publishes fixed ranges, and avoid broad wildcards.
• Rotation: rotate the Client Secret on a schedule and immediately when a vendor contract ends or a person who handled it leaves. See the API Key Management Guide.

Webhooks, Munchkin and CRM sync

Webhooks send lead data to external URLs when a flow step runs; review each webhook's destination, payload tokens and any credentials in custom headers, and restrict Access Webhooks. The CRM sync user is a powerful service account on the CRM side: give it a dedicated, scoped CRM profile rather than a system administrator profile. See the Service Account Security Guide.

Logging and detection

Adobe describes Audit Trail as a complete history, six months' worth, of changes, with 30 days viewable in the instance and an export option for the full six months.

Adobe notes that Web Personalization, Predictive Content and Sales Insight changes are not audited by Audit Trail; cover those with change control. Map activity to MITRE ATT&CK T1078.004 (Cloud Accounts), T1098 (Account Manipulation) and T1528 (Steal Application Access Token) when writing detections.

Metrics

• Administrator count: users holding Access Users or Access Roles, target two to five.
• API Only users with an owner: percentage with a named owner and documented purpose, target 100%.
• Custom services per API Only user: target one.
• Secret age: days since each Client Secret was rotated, against your policy.
• Audit Trail export cadence: days since the last successful export, target under 30.
• Access review completion: quarterly reviews completed on time across Marketo roles and Admin Console entitlements.

Hardening baseline

Privacy and data controls

For subscriptions on Adobe Identity, data subject access and deletion requests go through Adobe Privacy Service, by UI or API, with include set to marketo and a regulation value such as gdpr, ccpa, pdpa, lgpd_bra or nzpa_nzl. The request needs your IMS Org ID and the data subject's email address, and returns a request ID and job ID you can track. Build this into your privacy request workflow and log each job ID as evidence. See the GDPR Compliance Guide for Security Teams.

• Minimise fields: use Field Management to hide or block fields you no longer need, and avoid storing special category data in custom fields. See Data Minimisation.
• Partition regulated audiences: keep regions with different legal bases in separate person partitions with their own workspace and team.
• Control exports: list and report exports are a common path for personal data to leave; keep export rights to roles that need them.

Phased rollout

1. Inventory (week 1): export users, roles, API Only users, LaunchPoint services, webhooks and workspaces. Pull six months of Audit Trail as a baseline.
2. Identity (weeks 2 to 3): confirm SSO through the Admin Console with MFA enforced at the identity provider; pilot with administrators first, keeping one tested emergency route.
3. Roles (weeks 3 to 5): create a marketing user role without Access Admin permissions, a security reviewer role and a small administrator role. Move users in batches by workspace and keep the old role assignment recorded for rollback.
4. Integrations (weeks 4 to 8): give each integration its own API Only role, user and custom service; switch it over, confirm it works, then delete the old service and rotate any shared secret. Enable the API IP allowlist once all egress addresses are known.
5. Monitoring (ongoing): schedule Audit Trail exports, send them to the SIEM, and run quarterly access reviews.

Choosing between options

• Workspaces versus one shared space: use workspaces where teams have completely different assets or audiences; Adobe notes they can be complex to set up, so a small single-team instance is often better with careful roles alone.
• Allow versus Block IP rules: Allow rules suit organisations with fixed egress or VPN; Block rules are rarely useful because attackers change addresses.
• Small teams: one administrator role, one marketing role and one API Only user per vendor gives most of the benefit with little overhead.

Common misconfigurations

• One API Only user shared by many tools: every vendor then holds the union of all permissions, and revoking one breaks the others. Use one per integration.
• API Only role with every Read-Write permission: often copied from a setup guide. Trim to what the integration calls.
• API Only user email tied to a leaver: the integration still works but no one owns it. Use a team mailbox and record an owner.
• Tokens in URLs: legacy code passing access_token as a query parameter leaks tokens into proxy and web server logs and now fails. Move to the header.
• Audit Trail only viewed in the UI: evidence beyond the window is lost when needed for an investigation. Export on a schedule.
• IP restrictions set only in Marketo: with the Q1 2027 retirement announced, mirror the allow list in the Admin Console now.

Framework mapping

Practitioner checklist

• Confirm SSO through the Adobe Admin Console with MFA enforced at the identity provider for every marketing user and administrator.
• Limit Access Users, Access Roles, Access Single Sign-on and Access Login Settings to two to five named administrators.
• Create a read-only security reviewer role with Access Audit Trail, Access Admin Audit Trail and Access Login History.
• Give every integration its own API Only role, API Only user and LaunchPoint custom service, with a named owner.
• Remove Execute Campaign and Approve Assets from API Only roles that do not send.
• Confirm every integration uses the Authorization header, not the access_token query parameter.
• Enable the Web Services API IP allowlist and mirror login IP rules in the Admin Console before the Q1 2027 change.
• Export Audit Trail at least monthly into your SIEM or archive.
• Route data subject requests through Adobe Privacy Service and keep the job IDs as evidence.
• Review Marketo roles and Admin Console entitlements together every quarter.

Standards and references

• Adobe: Descriptions of Role Permissions
• Adobe: Marketo Engage REST API Authentication
• Adobe: Create an API Only User
• Adobe: Adobe Identity Management Overview for Marketo Engage
• Adobe: Audit Trail Overview
• Adobe: Restrict Marketo Logins Based on IP
• Adobe: Privacy Requests
• Adobe: Understanding Workspaces and Person Partitions

Related NHI Mgmt Group resources: SaaS Security Guide · Service Account Security Guide · OAuth Scope Design Guide · Joiner-Mover-Leaver Guide