Federated Guest Access

Overview

Adobe’s Federated Guest Access feature allows enterprise customers to onboard external agency, vendor, or consultancy workers into Adobe’s ecosystem with the same security and authentication standards as internal employees.

Previously, creating a Federated ID user required domain ownership. This requirement prevented organizations from adding users with external domains, including non‑claimable domains such as gmail.com and claimable domains that are owned by another organization.

The Federated Guest Access feature allows enterprise customers to add a user with any email address as their own federated user. It ensures consistent SSO enforcement across both internal employees and external partners.

The feature currently supports Workfront and AEM Assets as a Cloud Service, with plans to extend support for other products.

Benefits of Federated Guest Access

Here are the benefits of the Federated Guest Access feature:

• Seamless collaboration: External partners gain access to Adobe tools without friction.
• Unified security: Enterprises can enforce consistent SSO and authentication policies across all users.
• Operational efficiency: It eliminates the need for workarounds previously used to onboard vendors.
• Controlled access: Federated guest accounts are isolated from internal accounts, ensuring entitlements and assets remain separate.

Business scenarios and use cases

Federated Guest Access is particularly valuable in scenarios where enterprises rely on external expertise. Marketing teams working with agencies, IT departments hiring consultants, or large organizations collaborating across multiple companies can integrate external contributors without compromising security.

For example, imagine a company hiring Mary from vendor.com for a short-term project. Mary may already have a federated account with her employer. Previously, the hiring company could onboard Mary to its Adobe environment only via her existing federated account, whose authentication is controlled by her employer.

With Federated Guest Access, the hiring company can add Mary as a federated guest to its directory. In this case, she can sign in using the hiring company’s SSO to access tools, such as Workfront or AEM Assets. She does not require a separate email address on the hiring company’s domain.

Mary’s federated guest account is fully independent of her employer-owned account, with separate entitlements and assets, ensuring clean separation of organizational data. She can switch between accounts using an account switcher. Each time she switches accounts, Mary must sign out and then re‑authenticate using the other account’s login method. This process ensures that the separation between accounts is maintained.

For the hiring company, external partners like Mary can be onboarded and managed through the same authentication and access controls used for internal employees. For Mary’s employer, Federated Guest Access requires no changes. Her account, entitlements, and assets remain unaffected, and neither organization has visibility into the other’s accounts.

Federated guest accounts

Federated Guest Access introduces a new account concept of federated guests. Federated guests are a new variation of the existing Federated ID account type, extended to support email domains that are not owned or claimed by the enterprise.

It allows enterprises to onboard external partners into their federated directory and authenticate them through the organization's IdP, without requiring ownership of the federated guest's email domain. Like all Federated ID accounts, each federated guest account is scoped to the organization that created it, with its own independent entitlements, assets, and federation. It remains fully separate from any other accounts that use the same email address in other organizations.

Domain management

Hiring company admins can add external domains via a new Guest domains tab in the Admin Console. It enables them to add users with external email domains as separate Federated ID accounts owned by their organization.

Unlike claimed domains, guest domains do not require proof of ownership. You can add both claimable and non-claimable domains. For domains that are claimed by another Adobe organization, domain owners can control whether their domain can be used as a guest domain.

If the domain owner requested their claimed domain to be blocked from guest domain usage, you will not be able to add that domain as a guest domain. If you have already added that guest domain, you cannot add any new federated guest with that domain. Any existing federated guests with the guest domain will not be able to sign in until the domain owner allows the guest domain to be used again.

To add guest domains directly to an Admin Console directory, perform the following steps.

By default, all claimed domains are configured to allow guest domain usage for Federated Guest Access.

As a domain owner, you may not want other organizations to use your claimed domains as a guest domain. While the guest domain usage does not impact your ownership of the domain and your users, you are able to review how your claimed domains are being used and decide whether you want to stop such usage.

To review what other organizations in Adobe are using your claimed domains as a guest domain

To block or allow all organizations from using your claimed domain as a guest domain, contact Adobe Support to make your request. This change will be applied on a per-domain basis.

When you block guest domain usage, no other organizations in Adobe can add that domain as a guest domain. Organizations that have already added the guest domain will see that their access to it is blocked. Moreover, they cannot create new federated guests with that domain. Any existing federated guest accounts with the guest domain will be blocked from signing in to such accounts.

Security and safeguards

Your IdP is always the source of truth. For any external partners to be onboarded as federated guests, they must already have an account in your IDP. It mimics how you would normally onboard your internal employees as Federated ID users.

All federated guests must complete a one-time verification flow before their initial sign-in. Adobe will send a verification code to the federated guest’s email, and the federated guest will be asked to review and consent to joining the inviting organization as a federated guest. If the flow is not completed, federated guests will be asked to complete it before they can sign in for the first time.

Admin experience

From the admin perspective, onboarding federated guests mirrors the process for regular federated users.

• Setup: Admins configure guest domains in the Admin Console.
• Provisioning: Federated guests are added the same way as regular federated users.
• Product assignment: Products are assigned in the same way as regular federated users. It is currently limited to Workfront and AEM Assets as a Cloud Service. Assigning unsupported products (e.g., Photoshop) will fail without consuming licenses.
• Collaboration invites: Emails now include the name of the organization that owns the asset or instance, reducing confusion when switching profiles or accounts.

End user experience

For end users, the experience is designed to be straightforward but secure. On first initial login, Adobe will ask end users to complete a one-time verification flow. Federated guests must verify their email and consent to join the inviting organization. Once activecompleted, users federated guests can sign in to the account through the hiring company’s IdP, just like internal employees. Federated guests can sign in to the federated guest account via IdP-initiated login as well.

It is not possible to directly sign in to the federated guest account by entering your email on the sign-in page. Instead, you must use IdP-initiated login or the login links your Admin can provide. The login links are directory-specific and can be accessed from Admin Console:

The login links can be used by any users in the same directory, whether or not they are federated guests.

If your email is linked to multiple accounts at Adobe, you can use an account switcher to find all accounts that share the same email. After you sign in to any account, you will see the list of accounts that you can switch to. 

A new account switcher lets users toggle between federated accounts linked to the same email address. Unlike profile switching, account switching requires re-authentication since each account has its own federation and/or authentication method. Admins can also provide special login links tied to specific directories, ensuring users are directed to the correct IdP.

Global Admin Console hierarchy

The Global Admin Console hierarchy establishes how guest domains are managed and shared across organizations. Only organizations with the Federated Guest Access feature enabled can add guest domains. Once a parent organization adds one, it becomes visible to all child organizations in the hierarchy and across the entire console, ensuring consistent onboarding of external users and federated guests.

The owning organization can form trust relationships with other organizations in the hierarchy to use the domain as any other claimed domain. Centralized identity management can be maintained at the root level, since not every organization needs Federated Guest Access enabled. A guest domain can be added only by one directory within the hierarchy, and organizations outside the hierarchy cannot see or use guest domains, even if trust relationships exist, ensuring controlled visibility. In such cases, users are added as business IDs managed by Adobe or the domain owner. If the same email address is registered across multiple organizations, separate federated guest accounts are created, requiring users to switch between accounts.

Frequently asked questions