Platform Authentication Across Jamf: A Year of Progress

Declarative device management is here.

Apple is changing their platform — DDM is replacing MDM, with legacy capabilities being deprecated along the way. Staying current with new Apple releases means adopting declarative device management, and our approach to delivering those capabilities is through platform services like blueprints.

Platform authentication is what fills that gap.

Why platform authentication is the future

Platform authentication is now shared across all of Jamf's applications and services, and it makes administrator access management more secure in the process. Jamf ID is an improvement over local application credentials. Connecting your own identity provider is better, and routing that connection through the platform rather than configuring it separately in each product means it applies everywhere from the start.

The past year was about closing the distance between that model and where most customers actually were.

Jamf has been building capabilities that live outside the boundary of any single product — Blueprints, compliance benchmarks, the Platform API now in public beta. Delivering those consistently across Jamf Pro, Jamf School, Jamf Security Cloud, Jamf Protect, and the rest of the portfolio required a single connection between a customer's identity infrastructure and Jamf's, rather than a separate integration for each product.

How platform authentication works

Platform authentication is an OIDC-based integration between your organization and Jamf's platform services, configured once in Jamf Account and applied across everything. Jamf Account is where you have always managed your organization's Jamf relationship — from spinning up a Jamf Pro tenant to accessing support and downloads. It is accessible to every customer regardless of which Jamf products they use, and it sits outside any single product as neutral ground for configuration that applies across the portfolio.

Multiple options, One security path

Two authentication options are available for Jamf's applications and services. Every customer has a Jamf ID, created the first time you sign into Jamf Account. It does not depend on an external identity provider, which means any organization can use it regardless of how they manage identity elsewhere.

For customers with Okta, Microsoft Entra or Google Workspace, keep using it. Connecting your identity provider to Jamf's platform means your administrators sign into Jamf the same way they sign into everything else. Your MFA policies apply. Your session controls apply. When someone leaves and you disable their account in your IdP, their federated access to Jamf products is revoked immediately.

One thing worth knowing: Jamf ID is a user-managed credential, not an organizational one. Disabling someone in your IdP cuts off their federated access, but their Jamf ID remains usable unless you explicitly turn it off. In Jamf Pro SSO settings, you can require federated authentication only, which removes that fallback path. Some offboarding cleanup is still a best practice either way.

Connecting via an identity provider also gives you group membership claims. An administrator's group memberships travel in the identity token when they authenticate, and Jamf Pro maps those to roles and privileges. You manage who has access to what in Jamf Pro by managing group membership in your IdP — the same place you manage it for everything else.

The new model is authentication configured once in Jamf Account and shared across every product, whether that means signing in with Jamf ID or federating back to your identity provider where you have one.

Some customers were starting from scratch. Others had built mature integrations and needed the new model to accommodate what they already had.

We built for both.

Here is what we shipped:

Other notable enhancements

The setup path for new customers has also improved. Enabling Jamf ID authentication from your Jamf Pro dashboard now walks you through the steps without any prior knowledge of the underlying authentication protocols. For customers connecting a federated identity provider, that configuration lives in Jamf Account where you connect your provider, choose which products and instances it applies to, and configure whether Jamf ID, your federated provider, or both are permitted.

Access management is evolving alongside authentication. Today, the connection between an administrator's IdP group memberships and their role inside Jamf Pro is configured at the application layer — Jamf Pro maps claims to roles, and each product manages that configuration on its own. Jamf is moving toward centralized management of those roles and access policies at the platform level, so an administrator's access across all of Jamf's applications and services reflects a single source of truth. That work is underway.

Blueprints, compliance benchmarks, AI Assistant — every capability Jamf has shipped to its platform services in the last year runs on this authentication layer. The Platform API, now in public beta, goes further: a unified set of endpoints providing device data and management capabilities across your entire Jamf environment through a single credential.

If you have been waiting for the right time to make this transition, the gaps from a year ago are largely resolved. If you are already configured, the path forward is to use what is now available.