Adobe Admin Console Security: Configure Identity, Admin Roles, Sharing and Audit Logs

The Adobe Admin Console decides who can sign in to Creative Cloud, Acrobat and Document Cloud, what they can share outside the organisation, and which applications can act on the organisation's behalf. Its security depends on a handful of customer-side choices: which identity type you use, whether sign-in is federated to your identity provider, how many people hold System admin, how asset sharing is restricted, and how the OAuth Server-to-Server credentials behind User Sync and other integrations are managed. This guide walks through each of those settings with the menu paths Adobe documents, then gives a baseline, monitoring advice and a checklist. It is for identity engineers, SaaS administrators and security teams who run an Adobe enterprise organisation.

This is an independent guide from NHI Mgmt Group, based on Adobe's public 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

• Federated ID gives you the most control. Adobe describes Federated ID as organisation-owned accounts that authenticate at your SAML 2.0 identity provider, so password rules, MFA and session policy come from one place.
• Keep System admin small. System admins are superusers and the only role that can assign or change other admin roles; delegate day-to-day work to Product, Product profile and User group admins.
• Enforce two-step verification for non-federated users. For Enterprise ID and Adobe ID users, Adobe recommends enforcing it organisation-wide under Settings > Privacy and Security > Authentication Settings.
• Restrict sharing before content spreads. The default sharing policy is "No restrictions"; move to "No public link sharing" or limit sharing to organisation members and authorised domains.
• Export the audit log. The Admin Console audit log keeps 90 days; stream it through Adobe I/O Events (OCSF format) or export CSV to keep longer history in your SIEM.

How identity and access work in the Adobe Admin Console

Every user in an Adobe enterprise organisation has one of three identity types. The choice controls who owns the account, where the password lives and which security settings apply.

Setup follows a fixed order that Adobe documents: create a directory under Settings > Identity > Directories, claim and verify your email domains, then connect the directory to your identity provider over SAML 2.0 (for example Okta, Ping Identity, Shibboleth or AD FS) or through the Microsoft Entra ID or Google Federation connectors. Where several Adobe organisations share one domain, directory trusting lets them use the same directory without each claiming it.

Once a directory is federated, authentication policy lives at the IdP. Apply your phishing-resistant MFA and conditional access rules to the Adobe application there; see the SAML Security Guide and the Conditional Access Guide.

Authentication settings for Enterprise ID and Adobe ID users

System admins find these under Settings > Privacy and Security > Authentication Settings:

• Password level: Low, Medium or High, applied to future password creation and resets. Accounts lock automatically after repeated failed sign-ins.
• Two-step verification: enforce it organisation-wide. Adobe notes enforcement can take up to 24 hours to reach all users and that enrolled users cannot unenrol afterwards.
• Maximum session life and maximum idle time: session life applies across Adobe apps; idle time applies to listed web apps such as Acrobat.com and Adobe Express, not desktop apps. Where a user belongs to several organisations, the most restrictive value wins.
• Social login policy: for Adobe ID users, choose which providers (for example Google, Facebook or Apple) are permitted.
• IP-based access: an allowed list of public IP addresses that restricts sign-in and profile switching from elsewhere. It does not sign out current sessions, so pair changes with a session review.

Admin roles and privileged access

• Federate admin accounts: admins should be Federated ID users so MFA and offboarding come from the IdP. Keep one break-glass System admin with a strong password and enforced two-step verification, stored and monitored as described in the Break-Glass Account Guide.
• Prefer group-based assignment: user groups mapped from your directory make access reviews a directory question rather than a console audit.
• Watch Storage admin: it can transfer contents of departed users, so treat it as a data-access role in reviews.
• Review quarterly: export admin role holders and reconcile against HR status; see the SaaS Admin Account Protection guide.

Integrations, API tokens and service accounts

Automation in the Admin Console runs on non-human identities: OAuth Server-to-Server credentials created in the Adobe Developer Console and listed in the Admin Console under Users > API credentials.

• User Sync Tool: a command-line tool you host that keeps Adobe users and groups aligned with Active Directory or other LDAP directories, for Federated ID and Enterprise ID users. It calls the User Management API with OAuth Server-to-Server credentials (client ID and client secret). Adobe states that JWT (Service Account) authentication is deprecated in the tool, so move remaining JWT configurations to OAuth Server-to-Server.
• Sync connectors: for Microsoft Entra ID or Google federation, Adobe points to the Azure Sync and Google Sync connectors, which remove the need to host the tool and its secret.
• Protect the sync host: Adobe says the User Sync server must be secured because it accesses administrative credentials. Keep the client secret in a secrets manager or OS keyring, not in the configuration file, and restrict who can log on to the host.
• Rotate secrets without downtime: an OAuth Server-to-Server credential can hold more than one client secret. Add a new secret, update the application, confirm the old secret's "last used" timestamp has stopped moving, then delete it. Deleted secrets cannot be restored. Rotate after any suspected exposure and on a schedule.
• Tokens: access tokens are typically valid for 24 hours. Cache and reuse them; Adobe may throttle integrations that request too many.
• Scope by product profile: what a credential can reach is governed by the product profiles assigned to it, so give each integration its own credential and the narrowest profile set.

Inventory these credentials alongside your other machine identities; see the Machine-to-Machine OAuth (Client Credentials) Guide.

Logging and detection

The audit log is at Insights > Logs > Audit Log and is visible to System admins. It records organisation-level changes to settings, admins, users and products, with date, event name, details, object, affected user, admin and IP address. Adobe notes three limits worth designing around: it keeps the last 90 days, product-internal events are excluded, and cascading events are omitted (deleting a group with three users logs only the group deletion).

• Export: filter and select Export CSV for ad hoc review (fields include eventType, actorEmail, targetUserEmail, targetProfileName and IpAddress).
• Stream: subscribe to the Audit Logs event provider in Adobe I/O Events, which delivers OCSF-formatted events. Only System admins and users with the Admin developer role can access it.
• Content log: records cross-organisation asset move events, which matter once "Restrict asset move" is in use.

Useful metrics: number of System admins (target three or fewer plus break-glass), share of users on Federated ID, percentage of non-federated users with two-step verification, API credentials with a secret older than your rotation period, and days of audit history retained outside Adobe.

Hardening baseline

1. Directory and domains: create a directory, verify every corporate domain and federate it. Enable sync from Entra ID, Google or User Sync so leavers lose access when the directory disables them.
2. Identity type: use Federated ID for employees. Keep Adobe ID only for accounts on domains you do not own.
3. Authentication settings: set password level High, enforce two-step verification, set session life and idle time to match your corporate policy, and restrict social login providers.
4. Admins: reduce System admins, delegate with scoped roles, add a monitored break-glass account.
5. Asset settings: under Settings > Asset Settings, define Authorized domains first (for Document Cloud include claimed and trusted domains), then choose "No public link sharing" or limit sharing to organisation members and trusted users. Note that switching removes existing public links, and the limited option also removes external collaborations, so announce the change. Consider "No access requests" and "Restrict asset move" for regulated teams.
6. Integrations: replace JWT credentials, one OAuth credential per integration, secrets in a vault, rotation scheduled.
7. Logs: stream audit events to your SIEM and alert on the events above.
8. Test and roll back: pilot federation with a test directory or a subset of users before cutting over; keep an Enterprise ID or break-glass System admin able to sign in if the IdP connection fails.

Decision guidance by organisation size

The trade-off in each row is convenience against control. Restricted sharing, for example, removes existing public links and external collaborations when applied, so creative and marketing teams that work with agencies need their agency domains added to the authorised list before the switch. Similarly, a short maximum session life increases sign-in prompts across every Adobe app; Adobe itself advises against short session policies unless stricter security is required, so align the value with your corporate standard rather than choosing the shortest option.

Common misconfigurations

• Federated, but no sync: SSO stops sign-in for disabled users, but licences and product access stay assigned until removed. Turn on directory sync so deprovisioning is automatic; see the Joiner-Mover-Leaver Guide.
• Everyone is a System admin: early setups often grant System admin to the whole IT team. Move people to Product or User group admin.
• Sharing left at the default: "No restrictions" allows public links and social posting. Choose a restricted policy that fits your data classification.
• Sync secret in a config file: a User Sync server with the client secret in plain text is an administrative credential on disk (ATT&CK T1552.001 Credentials In Files).
• Relying on the console for history: 90 days is short for investigations. Export continuously.
• IP allow list changes with no session review: existing sessions stay signed in, so review active admins after tightening the list.

Framework mapping

Practitioner checklist

• Verify all corporate domains and federate them to your IdP.
• Move employees to Federated ID and enable directory sync.
• Enforce two-step verification and password level High for any Enterprise ID or Adobe ID users.
• Limit System admin to a few named people plus one monitored break-glass account.
• Define authorised domains, then restrict public link sharing.
• Migrate User Sync and other integrations from JWT to OAuth Server-to-Server.
• Store client secrets in a vault and rotate them using the multiple-secret method.
• Stream audit events through Adobe I/O Events to your SIEM.
• Alert on admin role grants, authentication changes and new API credentials.
• Review admin roles and API credentials every quarter.

Standards and references

• Adobe: Identity types overview
• Adobe: Set up identity
• Adobe: Authentication settings
• Adobe: Admin roles
• Adobe: Asset settings
• Adobe: Audit logs
• Adobe: User Sync Tool
• Adobe Developer: OAuth Server-to-Server implementation

Related NHI Mgmt Group resources: Adobe Experience Manager Security Guide · Adobe Acrobat and Reader Enterprise Hardening · SAML Security Guide · Machine-to-Machine OAuth (Client Credentials) Guide · SaaS Admin Account Protection