FAQ: Enterprise Portal (Preview)

The EP is a single portal with global-level configurations inherited by child organizations, operated by a single corporate entity. The MTP remains the architecture for MSPs and VARs, with separate SKUs per customer.

Existing orgs can be integrated into the EP hierarchy. Isolated silos become managed Org Levels that inherit global policies without losing their local configurations.

EP natively replaces AD OU structures, allowing granular administrative delegation while modernizing SSO, MDM, and MFA from the cloud. However, a full assessment of the customer’s current AD usage is needed to correctly scope the migration.

Yes. Hosting shared SSO applications at the Enterprise Level eliminates the need for complex SSO federations, alias registration, and duplicate user creation across subsidiaries.

JumpCloud supports one IdP per org. Each org under the EP can have its own IdP, but you cannot configure an IdP at the Enterprise Level.

No. The Enterprise Portal must be set up in a single Data Center. Advise the customer to choose the region that meets their strictest regulatory requirements.

Yes. An existing org can be elevated to an EP. However, the admin will need to set up the Enterprise-level configuration to truly operate as an EP.

Pricing is still being defined. There is no charge during the preview phase.

A banner is displayed on the relevant page informing the admin that the feature is not yet available in the Enterprise Portal context.

No. Users and Devices are always org-bound. They must be created within a specific organization.

No. Enterprise Configuration scope automatically grants access to all organizations. This is default behavior and cannot be altered.

No. Enterprise Resources are read-only at the org level. Local admins can add new associations (e.g., bind additional Enterprise or Local groups to an SSO app) but cannot edit the resource configuration. They also cannot remove associations between Enterprise Resources that were made in the Enterprise context.

No. Both Custom Roles and Service Accounts are only available in the Enterprise context.

The application is moved to (or created at) the Enterprise Level, becoming an Enterprise Resource. The Enterprise Administrator selects which organizations receive the application and creates Enterprise Groups for access control. A local admin within their org context can also associate both Enterprise Groups and Local Groups to the shared application.

Yes. All end users access a single SSO User Portal regardless of which organization they belong to. Users remain in their respective organizations. Enterprise Administrators create SSO applications and Groups at the Enterprise Level and share them across organizations. Access is controlled through group associations — either Enterprise Groups (shared to all orgs by default) or Local Groups (org-specific).

Enterprise Groups are defined at the Enterprise Level (type, name, rules, attributes) and automatically shared with all organizations. Config is read-only at org level. For static groups, local admins can add/remove members within their org. For dynamic groups, local admins cannot modify inclusion/exclusion lists.

Not in this phase. Administrators are assigned a single role (default or custom) that applies uniformly to all organizations they have access to, including the Enterprise context. Per-org role assignment is not currently supported.

A modal prompts the admin to select which organization the resource should be created in, since resources must belong to a specific org.

Yes. The Enterprise Administrator controls which organizations receive a shared SSO application at the application level. Within each organization, access is further refined through group associations.

Yes. Configuring an SSO application at the Enterprise Level allows a single IdP connection for the entire enterprise for that application, eliminating redundant per-org configurations. This is optional — organizations can still maintain their own IdP for org-level applications.

Not fully in this phase. Enterprise admins with Enterprise Configuration scope have access to all organizations by default and this cannot be restricted. If they have application management permissions, they can view and manage Local Resources in any org. Sensitive applications should be created as Local Resources, and admin access should be managed through role permissions — for example, assigning a custom role that excludes application management. However, true per-org role separation is not yet supported.

In the Enterprise context, only Enterprise Groups are available. In an Organization context, both Enterprise Groups and Local Groups from that org are available. This enables layered access control.

No. Associations made between Enterprise Resources in the Enterprise context can only be modified by an Enterprise admin. Local admins can add their own associations (Enterprise or Local Groups) but cannot remove Enterprise-to-Enterprise associations.

No. Only Enterprise Resources (created at the Enterprise Level) can be shared across organizations. Local Resources remain within the org where they were created. If a resource needs to be shared, it must be created at the Enterprise Level.

Policy Management has unique cross-org visibility. From the Enterprise context, the global admin can view all policies, policy groups, and device groups across every child org and assign Enterprise policies to local device groups directly — without switching context. This differs from other resources like SSO apps, where only Enterprise-level resources are visible in the Enterprise context.