Contractor Access, SSO, and API Integration
A Marketing Cloud account with 45 users enforces SSO through Okta. A three-person external agency needs access for 60 days to build journeys in one child BU. The company also has a middleware integration that pulls tracking data via API using a username and password. Security wants MFA for all interactive users, no shared credentials, and an audit trail of who exported subscriber data. The agency uses personal laptops and cannot install the company's Okta Verify app. The admin must grant access without weakening the controls for employees.
1. How should the admin provision the agency users? Address SSO, MFA, role scope, and expiry.
Read the worked answer
Do not create shared logins or bypass SSO. Each agency user gets a named Marketing Cloud user, SSO-enabled, with an Okta identity. Because they cannot install Okta Verify, configure an allowed MFA method for those three identities-SMS or Okta FastPass via browser-rather than disabling MFA. Scope roles to the child BU: Journey Builder and Content Builder edit, no admin, no user management, no API integration, no subscriber export. Set a calendar reminder to disable all three users on day 60 and review activity before offboarding. If policy forbids external IdP identities, the fallback is to have the agency work through a company-managed VDI or supervised account-not to create local passwords.
2. What should be done about the API integration's username/password? What is the least-privilege configuration?
Read the worked answer
Replace the password-based integration with an OAuth 2.0 API integration in an Installed Package. Use client credentials and grant only the scopes the middleware needs-for tracking pulls, read-only tracking scopes, not send or admin scopes. Remove or disable the legacy username/password user. Do not use an employee's login for the integration; if a user context is required, create a dedicated integration user with a non-interactive role and no SSO interactive access, documented as an API account. Rotate the client secret on a schedule and store it in a secrets manager. This removes shared credentials and makes the integration auditable by client ID.
3. How can the admin audit subscriber data exports and detect misuse?
Read the worked answer
Enable and review the account Audit log for logins, role changes, and user administration. For subscriber exports, you need activity-level evidence: review Automation Studio Data Extract and File Transfer activities, and any manual export permissions. Restrict export permissions so only named roles can export; for the agency, remove export entirely. Use a report or scheduled extract of user activity and keep it outside the Marketing Cloud account so an insider cannot delete it. If the native audit does not capture export detail, add a compensating control: require approval for exports and reconcile export files against the SFTP/File Transfer logs.