18 Jan 2026 • 22 min read • JAMF Pro

Understanding JAMF Pro Blueprints: When and How to Use DDM-Powered Device Management

JAMF Pro Blueprints deploys device configurations using Apple's Declarative Device Management (DDM) protocol instead of traditional MDM commands. The device receives a declaration of its desired state and maintains that state autonomously, reporting changes back to JAMF Pro without polling.

This article covers what Blueprints are, how they differ from traditional management, prerequisites, component types, practical deployment examples, and migration from existing profiles.

What Blueprints Actually Are

Blueprints are JAMF's implementation of Apple's DDM protocol, introduced at WWDC 2021 and expanded significantly in subsequent years. DDM changes the management model from imperative ("do this thing") to declarative ("this is your desired state").

The Protocol Difference

Traditional MDM uses a request-response model:

1. JAMF Pro sends InstallProfile command
2. Device receives command via APNS wake
3. Device installs profile
4. Device responds with success/failure
5. JAMF Pro updates inventory
6. (Hours/days later) JAMF Pro sends inventory request to verify state
7. Device responds with current state

DDM uses a declarative model:

1. JAMF Pro sends declaration: "Your passcode policy is: minimum 8 chars, alphanumeric"
2. Device stores declaration in its management state
3. Device enforces the declaration immediately
4. Device subscribes to status channels
5. If state changes (user changes password, policy drifts), device reports immediately
6. No polling required

Why This Matters

Three practical benefits:

Faster compliance verification. Traditional MDM requires JAMF to poll devices for status. Default inventory collection runs every 24 hours or at check-in. DDM devices report state changes immediately through status channels. If a user somehow modifies a managed setting, JAMF knows within minutes, not hours.

Reduced server load. Traditional MDM requires constant back-and-forth for inventory, command delivery, and status verification. DDM devices maintain their own state and only communicate when something changes. For large deployments (10,000+ devices), this reduces JAMF Pro server load noticeably.

Self-healing configurations. Traditional profiles can be removed by users with admin rights or by conflicting system processes. DDM declarations are designed to persist and self-correct. The device continuously enforces the declared state, not just at profile installation time.

What DDM Cannot Do

DDM is not a replacement for all MDM functionality:

No script execution. DDM declarations are data, not code. You cannot run shell scripts via Blueprints.
No conditional logic. Declarations cannot include "if this then that" conditions. A declaration applies unconditionally to scoped devices.
No app installation. DDM does not handle package deployment. App Installers and Patch Management remain separate.
Limited to Apple's schema. You can only declare settings Apple has defined in the DDM protocol. Custom preferences require the legacy profile pathway.

Prerequisites

JAMF Pro Cloud (Standard or Premium Tier)

Blueprints runs as a separate platform service, not within your JAMF Pro instance. This architecture requires JAMF's cloud infrastructure.

Supported:

JAMF Pro Cloud Standard
JAMF Pro Cloud Premium

Not supported:

On-premises JAMF Pro (no timeline announced for support)
Premium Cloud Plus (hosted on AWS GovCloud for regulated environments)
RAMP/StateRAMP customers
JAMF School (has its own Blueprints implementation)

The Premium Cloud Plus exclusion seems counterintuitive since it's a higher tier. However, Premium Cloud Plus is specifically designed for organizations under strict regulatory and compliance requirements. It runs exclusively on AWS GovCloud in the United States and is managed only by US citizens at JAMF. The stricter change management requirements in these regulated environments likely require additional validation before new platform features like Blueprints can be enabled.

If you are on-premises and want Blueprints, you need to migrate to cloud. JAMF has been pushing cloud-first features for several years; this continues that direction.

SSO with OIDC via JAMF Account

Blueprints requires OIDC-based SSO configured through JAMF Account. This is not optional. Without this configuration, the Blueprints menu item appears in JAMF Pro but functionality is blocked.

The requirement exists because Blueprints authenticates against the JAMF platform layer, not your JAMF Pro instance. When you access Blueprints, you are technically accessing a separate service that needs to verify your identity through JAMF Account.

You have two authentication paths:

Option 1: Jamf ID Only

Simplest setup. Each admin creates a Jamf ID (free account at account.jamf.com) and uses it to authenticate.

Admins create Jamf IDs if they do not have them
Associate Jamf IDs with your organization in JAMF Account
Create matching user accounts in JAMF Pro with the same email addresses
Enable SSO with OIDC in JAMF Pro (Settings > System > Single Sign-On)
Select "Jamf Account" as the identity provider

Limitation: No group-based privilege management. Each user gets the privileges of their matching JAMF Pro account.

Option 2: Your Identity Provider via JAMF Account

Connect your existing IdP (Entra ID, Okta, Google Workspace, or any OIDC-compliant provider) to JAMF Account. Users authenticate with their corporate credentials.

JAMF provides templates for:

Microsoft Entra ID (formerly Azure AD)
Okta
Generic OIDC (for everything else)

Setup steps vary by IdP, but the general flow:

Create an OIDC application in your IdP
Configure redirect URIs to JAMF Account endpoints
Obtain client ID and client secret
In JAMF Account, create a connection using the appropriate template
Verify your domain (JAMF needs to confirm you own the domain)
Enable SSO with OIDC in JAMF Pro

Entra ID-specific notes:

When copying the client secret from the Azure portal, use the Value field, not the Secret ID. This is a common mistake.

If you use JAMF Pro groups for privilege management, enable these options in the connection settings:

"Get User Groups"
"Include all groups the user is a member of, including child groups"

Okta-specific notes:

If you need group membership to flow through for privilege management, configure the connection as Generic OIDC, not the Okta template. The Okta template does not support group claims properly.

In the scopes field, add: email openid profile groups

Break-glass account recommendation:

Keep at least one local JAMF Pro administrator account that does not use SSO. If your IdP has an outage, you can still access JAMF Pro with this account. Blueprints will not work during an IdP outage, but core JAMF Pro functions will.

Supported Devices and OS Versions

Blueprints scope to Smart Groups or Static Groups, same as traditional configurations.

Supported platforms:

macOS 13 Ventura and later (baseline DDM support)
iOS 15 and later (baseline DDM support)
iPadOS 15 and later (baseline DDM support)

However, specific declaration types have higher requirements:

Declaration Type	macOS	iOS/iPadOS
Baseline DDM	13+	15+
Software Update declarations	14+	17+
Passcode via DDM	14+	17+
Service configuration files	14+	N/A

Apple's documentation states Software Update declarative configuration requires "iOS 17, iPadOS 17, Shared iPad device, macOS 14 device" as minimum versions.

If you scope a Software Update Blueprint to devices running macOS 13, those devices receive the declaration but cannot act on it. No error occurs; the declaration is silently ignored. The device must meet the minimum OS requirement for that specific declaration type.

What You Can Deploy via Blueprints

JAMF announced 46 components at JNUC 2025, spanning configuration payloads and restrictions for macOS and iPadOS. Components fall into three categories with different behaviors.

Native DDM Declarations

These settings use Apple's DDM protocol natively. The device receives a declaration and enforces it autonomously.

Software Updates

The flagship Blueprint use case. Two enforcement modes:

Specific OS version and time:

Set a target OS version (e.g., macOS 15.2)
Set a deadline date and time
Devices must update by the deadline or be forced to update

Latest OS version (set and forget):

Set number of days after Apple release (e.g., 14 days)
Set enforcement time (e.g., 18:00)
JAMF automatically calculates deadlines when Apple releases updates
No manual intervention required for each OS release

The "latest OS version" mode queries Apple's GDMF (Apple Software Lookup Service) to determine available updates. When Apple releases a new version:

Apple publishes to GDMF
JAMF detects the change (approximately 4 hours)
JAMF recalculates enforcement dates for all devices in scope
New declarations deploy to devices
Previous deadline (if not yet reached) is replaced

Passcode Policy

Enforces password requirements. Available settings include:

Minimum length
Require alphanumeric
Minimum complex characters
Maximum age (days)
Maximum failed attempts before wipe
Minimum time until password change
Password history (prevent reuse)

Key difference from legacy profiles: Traditional passcode profiles delivered via MDM have weak enforcement. Users can dismiss passcode prompts, leaving devices non-compliant. This limitation stems from how macOS processes legacy profiles, not from MDM vendors.

DDM passcode declarations enforce policies at the system level. The device autonomously maintains compliance without relying on repeated server-side pushes. If a user changes their passcode to a non-compliant one, DDM provides instant notification and the device can automatically remediate.

On iOS/iPadOS, when the passcode configuration installs, users have 60 minutes to enter a compliant passcode. After that window, the configuration forces them to enter a passcode meeting requirements.

Disk Management

Controls external storage access:

Allow/deny external disks
Allow/deny network disks
Eject on lock
Specific allowed disk types (USB, Thunderbolt, SATA)

Useful for preventing data exfiltration via USB drives. Settings apply at the OS level and cannot be bypassed by users.

Background Task Management

Controls which launch daemons and agents can run:

Specify allowed/blocked bundle identifiers
Specify allowed/blocked team identifiers
Specify allowed/blocked code signing requirements

Use this to block known problematic third-party daemons or ensure only approved background processes run. Particularly useful for kiosk deployments or high-security environments.

Service Configuration Files

Manages macOS system service configurations that traditionally required scripting:

SSH configuration (/etc/ssh/sshd_config settings)
PAM configuration (including Touch ID for sudo)
Bash configuration
Zsh configuration

The Touch ID for sudo use case is common: previously required a script to modify /etc/pam.d/sudo, which could be overwritten by OS updates. The DDM declaration persists across updates.

Safari Extensions Management

Controls Safari extensions:

Allowed extensions (by bundle ID or team ID)
Blocked extensions
Forced extensions

Math Settings

Controls Calculator app features (primarily for education):

Scientific Mode access
Math Notes access
Unit conversion access

Legacy Payloads (Configuration Profiles via DDM)

Added in July 2025, this allows deploying traditional MDM configuration profiles through the DDM pipeline.

In the Blueprint Builder, these components are labeled "Legacy Payload." The profile installs via DDM, meaning:

Device maintains the profile as part of its declared state
Self-healing behavior (device re-applies if removed)
Appears under Device Declarations on the device, not in the Profiles list

Restrictions

All device restriction keys available through traditional profiles are now available via Blueprints. This includes:

App restrictions (App Store, Safari, Camera, etc.)
iCloud restrictions
Apple Intelligence restrictions (as of macOS 15/iOS 18)
Media content restrictions
Password/passcode restrictions
Security restrictions

When configuring Restrictions in the Blueprint Builder, you can filter by:

OS type (macOS, iOS, iPadOS)
Category (Apple Intelligence, Security, Apps, etc.)

This helps when you only need to configure macOS-specific restrictions without scrolling through iOS-only options.

Important behavior: Profiles delivered via Blueprints are unsigned. The JAMF documentation confirms this. For most organizations this does not matter. If your security requirements mandate signed profiles, continue using traditional profile deployment.

Other Legacy Payloads

The Blueprint Builder includes additional profile payload types:

AirPrint printers
Certificates
Network configurations
VPN configurations
And others as JAMF adds them

Check the Blueprint Builder interface for current availability. JAMF adds components between major releases since Blueprints operates as a separate service.

Custom Declarations

Deploy any DDM declaration Apple supports, even if JAMF has not built a template for it.

Use cases:

New Apple DDM declarations before JAMF adds templates
Declarations JAMF may never template (edge cases)
Testing declaration behavior

Creating a Custom Declaration:

In Blueprint Builder, drag "Custom Declarations" component to the Declaration group
Select the declaration type:
- Configuration: Settings and policies
- Asset: Supporting data (certificates, config files)
Select the channel:
- System: Device-level settings
- User: User-level settings
Enter the declaration JSON payload

You need to understand Apple's DDM schema to use Custom Declarations. Reference Apple's Declarative Device Management documentation for payload formats.

Example: Disk Management Custom Declaration

If JAMF's Disk Management template did not exist, you could deploy it via Custom Declaration:

{
  "Type": "com.apple.configuration.diskmanagement.settings",
  "Payload": {
    "ExternalStorage": {
      "Access": "readOnly"
    },
    "NetworkStorage": {
      "Access": "deny"
    }
  }
}

Custom Declarations require more effort but provide flexibility when JAMF templates lag behind Apple's DDM capabilities.

When to Use Blueprints vs Traditional Methods

Blueprints and traditional JAMF Pro management serve different purposes. The decision framework:

Use Blueprints For

Software Updates

This is the primary use case and where Blueprints provides the most value over traditional methods.

The "set and forget" mode eliminates the manual work of updating your software update policy every time Apple releases a new version. Configure once with "14 days after release" and forget it exists until you need to change the policy.

Traditional Software Updates section in JAMF Pro requires you to:

Notice Apple released an update
Test the update
Create or modify a software update plan
Deploy to production groups

With Blueprints, step 3 happens automatically. You still need to test, but the deployment mechanics are handled.

Settings That Must Stay Enforced

DDM's self-healing behavior matters for high-security settings:

Disk access restrictions (prevent USB exfiltration)
Passcode requirements
Background task controls
Safari extension restrictions

If a user with admin rights removes a traditional profile, it's gone. DDM declarations are harder to remove because the device continuously enforces them.

Cross-Platform Deployments

One Blueprint can target both Macs and iOS/iPadOS devices. JAMF applies the appropriate keys for each OS.

Traditional approach: Create a macOS Restrictions profile, create an iOS Restrictions profile, scope both to appropriate groups, maintain both when making changes.

Blueprints approach: Create one Blueprint with Restrictions, scope to a group containing both Macs and iOS devices, JAMF handles the key mapping.

This reduces duplicate configurations and the risk of Mac/iOS settings drifting apart.

New Apple Features

JAMF can update Blueprint components without shipping a full JAMF Pro release. When Apple announces new restriction keys at WWDC, JAMF can add them to the Blueprint Builder within days.

With traditional profiles, you either wait for the next JAMF Pro release or upload a custom profile with the new keys.

Continue Using Traditional Methods For

Anything Requiring Scripts

DDM is declarative data, not executable code. If your workflow requires:

Running shell scripts
Executing installers
Custom logic based on device state
Extension attributes

You need Policies. Blueprints cannot replace these.

App Deployment

Blueprints do not handle application installation. Continue using:

App Installers for .pkg and .dmg
Patch Management for third-party updates
Mac App Store apps via VPP

Complex Conditional Logic

Traditional management allows:

Criteria-based smart groups with complex logic
Policies triggered by specific conditions
Recurring policies with varied frequencies

Blueprints apply unconditionally to all devices in scope. No "if device X meets criteria Y, apply setting Z" logic exists within a Blueprint.

If you need conditional behavior, use Smart Groups to segment devices and apply different Blueprints to each group. Or continue using traditional Policies for the conditional parts.

Detailed Update Reporting

The traditional Software Updates section provides:

Update status per device
OS Update History
Granular reporting on update progress

Blueprints-deployed software updates do not appear in these reports. You can verify deployment via Device Declarations on individual devices, but fleet-wide reporting is less detailed.

If compliance auditors require detailed software update logs, consider continuing with traditional Software Updates or supplement Blueprint deployments with reporting via extension attributes.

Gradual Rollouts With Multiple Phases

Traditional Software Updates support phased deployments:

Phase 1: IT test group (immediate)
Phase 2: Early adopters (Day 3)
Phase 3: General population (Day 7)
Phase 4: Stragglers (Day 14)

Blueprints' "days after release" setting is uniform. All devices in scope get the same deadline.

Workaround: Create multiple Blueprints with different day settings, scope each to different groups. But this adds management overhead.

The Practical Hybrid Approach

Most organizations end up with this split:

Function	Method
Software Updates	Blueprints (set and forget)
Passcode Policy	Blueprints
Disk Management	Blueprints
Restrictions (security-critical)	Blueprints
App Deployment	App Installers
Third-party updates	Patch Management
Scripted workflows	Policies
Custom profiles	Traditional Configuration Profiles
Conditional configurations	Smart Groups + Policies

Start with Blueprints for software updates. If that works well in your environment, expand to passcode and restrictions. Keep traditional methods for everything else until Blueprints capability grows.

Creating and Deploying Blueprints

Blueprint Builder Interface

Access Blueprints via Devices > Blueprints in JAMF Pro. The interface has three main areas:

Quick Start Templates: Pre-configured Blueprints for common use cases (Software Updates, Passcode, Disk Management, etc.)
My Blueprints: Blueprints you have created or modified
Blueprint Builder: Drag-and-drop interface for building custom Blueprints

The Builder shows available components in a list on the right side. Drag components into the "Declaration group" area to add them to your Blueprint.

Draft vs Deployed State

Blueprints have explicit state management:

Draft: Changes saved but not pushed to devices
Deployed: Active on devices in scope

The Deploy button appears when you have undeployed changes. This prevents accidental changes from immediately affecting production devices.

You can make multiple changes to a Blueprint, save drafts, test settings, and deploy only when ready. This differs from traditional profiles, where saving immediately deploys.

Example: Software Update Blueprint with Rolling Enforcement

Step-by-step setup for automatic software updates:

Navigate to Devices > Blueprints
Click New Blueprint or select the Software Updates Quick Start template
Name the Blueprint (e.g., "macOS Updates - 14 Day Rolling")
If using Quick Start, the Software Updates component is pre-added. Otherwise, drag Software Updates from the component list into the Declaration group
Click on the Software Updates component to configure:

Enforcement type: Latest OS version
Days until enforcement: 14
Enforcement time: 18:00
Notifications:
  - Start: 1 day before deadline
  - Frequency: Daily
Install action: Download and install

Scroll to Scope section
Click the scope selector and choose a Smart Group (e.g., "All Managed Macs - macOS 14+")
Review the configuration summary
Click Deploy

What happens on devices:

JAMF calculates: enforcement_date = Apple_release_date + 14 days
Declaration deploys to devices in scope
Devices download the update in the background
Starting 1 day before deadline, users see Notification Center alerts
Notification frequency increases as deadline approaches (Apple's standard behavior)
At 18:00 on deadline day, users get a final 1-hour warning
After 1 hour, update installs (user can click "Install Now" to proceed immediately)

Verification:

On a managed Mac:

Open System Settings > General > Device Management
Click the MDM enrollment profile
Scroll to Device Declarations
Click Software Update to see deadline details

The declaration shows:

Target OS version
Enforcement deadline (date and time)
Current device compliance status

Once the device updates, the Software Update declaration clears from Device Declarations. It reappears when Apple releases the next update and JAMF calculates a new deadline.

Example: Restrictions Blueprint for Apple Intelligence

Deploy restrictions for Apple Intelligence features on macOS 15+:

Create new Blueprint, name it "Apple Intelligence Restrictions - macOS 15"
Drag Restrictions component (labeled "Legacy Payload") into Declaration group
Click Configure on the Restrictions component
Use the filter button:
- OS Type: macOS
- Category: Apple Intelligence
Set the following to Disabled:
- Allow Genmoji
- Allow Image Playground
- Allow Image Wand
- Allow Writing Tools
- Allow External Intelligence Integrations (blocks ChatGPT integration)
- Allow Personalized Handwriting Results
Scope to appropriate group
Deploy

The Restrictions component shows all available keys for the selected platform. Filtering by category prevents scrolling through hundreds of unrelated options.

Note on key availability: Apple Intelligence restriction keys require macOS 15 or iOS 18. If you scope this Blueprint to devices running older OS versions, those devices ignore the declarations they cannot process.

Example: Service Configuration for Touch ID Sudo

Enable Touch ID authentication for sudo on macOS:

Create new Blueprint, name it "Touch ID for Sudo"
Drag Service configuration files component into Declaration group
Configure:
- Service: PAM
- Configuration: Enable Touch ID for sudo
Scope to Macs with Touch ID hardware
Deploy

Previously, this required a script that modified /etc/pam.d/sudo, which could be overwritten by macOS updates. The DDM declaration persists across updates without maintenance.

Example: Custom Declaration for Settings Without Templates

If JAMF has not built a template for a declaration you need:

Create new Blueprint
Drag Custom Declarations component into Declaration group
Click to configure
Set:
- Kind: Configuration
- Channel: System
Enter the declaration JSON

For example, deploying a custom disk management configuration:

{
  "Type": "com.apple.configuration.diskmanagement.settings",
  "Identifier": "com.yourcompany.diskmanagement.custom",
  "Payload": {
    "ExternalStorage": {
      "Access": "readOnly"
    },
    "NetworkStorage": {
      "Access": "deny"  
    },
    "Optical": {
      "Access": "allow"
    }
  }
}

The Identifier must be unique across your deployment. Use reverse-DNS notation with your organization identifier.

Reference Apple's DDM documentation for available declaration types and payload schemas.

Gotchas, Limitations, and Troubleshooting

Configuration Conflicts

Problem: You deploy a setting via Blueprint and via a traditional profile. Device behavior becomes unpredictable.

DDM declarations and MDM profiles can conflict when managing the same setting. For example:

Blueprint Restrictions: Allow Camera = false
Traditional Profile Restrictions: Allow Camera = true

The result varies by setting and device. Sometimes DDM wins, sometimes MDM wins, sometimes the device oscillates between states.

Solution: Never manage the same setting through both methods simultaneously. Before deploying a Blueprint for Restrictions, remove any traditional Restrictions profiles from the same scope. Audit your existing profiles and map them to Blueprint equivalents before migration.

Unsigned Profiles via Blueprints

Legacy Payload components (Restrictions, Certificates, etc.) deployed via Blueprints result in unsigned profiles on the device.

Traditional profiles deployed via JAMF Pro are signed by JAMF's certificate. Blueprints-deployed profiles are not signed.

For most organizations, this does not matter functionally. The profiles install and work correctly.

If your compliance requirements mandate signed profiles (some government or regulated industry standards), continue using traditional profile deployment for those configurations.

Limited Reporting for Software Updates

The traditional Computers > Software Updates section provides:

Per-device update status
Update failure reasons
Installation history
Compliance percentages

Blueprints-deployed software updates do not populate these reports. You can verify deployment on individual devices via Device Declarations, but fleet-wide reporting is less comprehensive.

Workaround: Create an extension attribute that reads the Software Update declaration status and report via Smart Groups or Advanced Searches. This requires scripting but restores some visibility.

Community-provided extension attributes exist for this purpose on JAMF Nation.

GDMF Propagation Delay

When Apple releases a new OS version, the information flows:

Apple publishes to GDMF (Apple Software Lookup Service)
JAMF's platform service polls GDMF
JAMF recalculates deadlines for all "latest version" Blueprints
New declarations deploy to devices

This process takes approximately 4 hours based on community reports. If Apple releases an update and your Blueprints do not update immediately, wait before troubleshooting.

The delay is between Apple's GDMF publication and JAMF's detection, not between JAMF and devices. Once JAMF updates, device deployment happens quickly.

If the Blueprints menu item does not appear in JAMF Pro:

Cloud tier verification: Confirm you are on Standard or Premium Cloud, not on-premises or other unsupported tiers
SSO verification: Confirm SSO with OIDC via JAMF Account is configured and working
User permissions: Confirm your JAMF Pro user account has Blueprints-related privileges

The Blueprints menu is hidden, not grayed out, when prerequisites are not met.

"Error" on Blueprint Deployment with No Details

Some administrators report seeing "Error" status with no explanation when deploying Blueprints, particularly for Software Updates with specific date enforcement.

Troubleshooting steps:

Remove the test device from any profiles or policies with potentially conflicting settings
Verify the device meets OS version requirements for the declaration type
Try deploying without date enforcement first (install options only)
If that works, add date enforcement incrementally

If errors persist, check JAMF Nation for known issues with your JAMF Pro version.

Declaration Clears But Device Not Updated

For Software Update Blueprints: the declaration clears from Device Declarations once the device is no longer eligible for an update. "No longer eligible" can mean:

Device updated successfully
Device is already on the target version
Device cannot receive the target version (unsupported hardware)

If a device shows no Software Update declaration and is not on the current OS version, verify:

Device is in the Blueprint's scope (check Smart Group membership)
Device hardware supports the target OS
Device OS version can receive the target (e.g., cannot skip major versions)

SSO Outage Impact

If your identity provider experiences an outage:

JAMF Pro web interface: Accessible via local admin accounts (if you have one)
Blueprints management: Unavailable until SSO recovers
Existing Blueprint deployments: Continue functioning (declarations already on devices)

Devices do not require SSO connectivity. Once declarations are deployed, devices enforce them independently. You cannot modify Blueprints during an IdP outage.

Recommendation: Maintain at least one local JAMF Pro administrator account for emergency access. Document the credentials in your break-glass procedures.

Migration from Traditional Profiles to Blueprints

JAMF does not provide an automated migration path. You cannot import existing configuration profiles into Blueprints. Migration requires manual planning and execution.

Pre-Migration Audit

Before migrating, document your current state:

1. Inventory existing configuration profiles

Export a list of all configuration profiles in your JAMF Pro instance:

Profile name
Payload types included
Scope (Smart Groups, Static Groups, or All Computers/Devices)
Current deployment status

2. Categorize by Blueprint readiness

Category	Action
Settings available in Blueprint components	Migrate to Blueprints
Settings available via Legacy Payload	Migrate to Blueprints
Settings not available in Blueprints	Keep as traditional profiles
Custom configuration profiles (uploaded XML/mobileconfig)	Keep as traditional profiles or convert to Custom Declarations

3. Identify conflicts

If you have multiple profiles managing the same settings (even across different scopes), resolve these before migration. Merging into a single Blueprint is cleaner than migrating conflicting profiles separately.

Migration Strategy

Option A: Big Bang (Not Recommended)

Remove all traditional profiles, deploy all Blueprints simultaneously.

Risk: Any misconfiguration affects all devices at once. Rollback is complex.

Only appropriate for small deployments (<50 devices) with extensive pre-testing.

Option B: Phased Migration by Setting Type (Recommended)

Migrate one setting type at a time across the fleet:

Week 1: Software Updates Week 2: Passcode Policy Week 3: Restrictions Week 4: Disk Management

Each phase:

Create Blueprint with equivalent settings
Deploy to test group (5-10 devices)
Verify behavior for 48-72 hours
Expand scope to pilot group (50-100 devices)
Remove traditional profile from pilot scope
Verify no conflicts for 48-72 hours
Expand Blueprint scope to production
Remove traditional profile from production scope

Option C: Parallel Deployment Groups

Run traditional and Blueprint management in parallel with separate device groups:

Group A (Traditional): Existing profiles, existing workflows
Group B (Blueprints): New deployments, migrated devices

Move devices from Group A to Group B gradually. This is safest for large or risk-averse environments but doubles management overhead during transition.

Cutover Process for a Single Profile

Example: Migrating a Restrictions profile to a Blueprint.

Current state:

Configuration Profile: "macOS Restrictions - Security"
Scope: Smart Group "All Managed Macs"
Contains: 15 restriction settings

Step 1: Create the Blueprint

In Blueprint Builder, create new Blueprint
Add Restrictions component (Legacy Payload)
Configure the same 15 restriction settings as the existing profile
Do not set scope yet
Save as draft

Step 2: Test deployment

Create a Static Group: "Blueprint Migration Test"
Add 5-10 test Macs to this group
Remove test Macs from the original profile's scope (exclude them or narrow the Smart Group)
Wait for traditional profile to uninstall from test devices
Set the Blueprint scope to "Blueprint Migration Test"
Deploy
Verify settings applied correctly on test devices

Check each test device:

System Settings > General > Device Management > MDM Profile > Device Declarations
Confirm Restrictions appear under Profiles section of Device Declarations
Test that restrictions are enforced (try the blocked actions)

Step 3: Pilot expansion

Add 50-100 production devices to the test group
Remove them from the traditional profile scope
Blueprint automatically applies to new group members
Monitor for 48-72 hours
Address any issues

Step 4: Production cutover

Change Blueprint scope from test group to production Smart Group
Remove the traditional configuration profile entirely (or descope to empty group)
Monitor for issues
Delete the traditional profile once confident in Blueprint

Settings That Cannot Migrate

Some configurations have no Blueprint equivalent:

Custom payloads: Profiles created with Apple Configurator or custom mobileconfig files. Convert to Custom Declarations if the DDM schema supports the settings, otherwise keep as traditional profiles.
Third-party app configurations: Managed preferences for non-Apple apps (e.g., Google Chrome, Microsoft Office). Keep as traditional profiles.
SCEP/AD Certificate payloads: Certificate enrollment workflows. Keep as traditional profiles.
Complex VPN configurations: Some VPN types may not have Blueprint support. Verify before migrating.

These can coexist with Blueprint-managed settings. A device can receive both Blueprint declarations and traditional profiles simultaneously, as long as they do not configure the same settings.

Post-Migration Verification

Create Smart Groups to verify Blueprint coverage:

Smart Group: "Devices Missing Blueprint Declaration"

Criteria:

DDM Status - Software Update Declaration - is blank
AND Computer Group - is member of - [Production Macs]

If devices appear in this group, they are in scope but not receiving the declaration. Investigate why (OS version, hardware compatibility, scope conflicts).

Smart Group: "Devices With Conflicting Profiles"

Criteria:

Configuration Profile Name - is - [Old Profile Name]
AND Computer Group - is member of - [Blueprint Scope Group]

Should be empty after migration. If devices appear, the old profile is still installed alongside the Blueprint, indicating incomplete cutover.

Verifying Blueprint Deployment

On the Managed Device

macOS:

Open System Settings > General > Device Management
Click the MDM enrollment profile (usually named for your organization or JAMF instance)
Scroll to Device Declarations section at the bottom

Device Declarations shows:

Software Update: Target version, enforcement deadline, current status
Disk Management: External/network storage access settings
Profiles: Legacy Payload deployments (Restrictions, etc.)
Background Tasks: Allowed/blocked task configurations
Other declaration types as deployed

Each declaration entry can be clicked for details. The information shown matches what you configured in JAMF Pro.

iOS/iPadOS:

Open Settings > General > VPN & Device Management
Select the MDM profile
Scroll to Device Declarations

Same structure as macOS, limited by iOS's declaration support.

In JAMF Pro

Blueprint status:

Devices > Blueprints shows:

Blueprint name
Deployment status (Draft, Deployed)
Last deployed date
Scope summary

Click a Blueprint to see detailed status.

Device-level verification:

Navigate to the device's inventory record
Check the Management tab for declaration status (if available in your JAMF Pro version)

Or use Advanced Search:

Create an Advanced Computer Search with criteria:

DDM Status - Software Update Declaration - is not blank

This returns devices that have received a Software Update declaration. Similar criteria exist for other declaration types (check available criteria in your JAMF Pro version).

Using Extension Attributes for Reporting

For more detailed reporting, create extension attributes that query declaration status:

Example: Software Update Deadline Extension Attribute

DDM stores software update state in a plist file. You can read this to report on pending updates:

#!/bin/bash
# Returns the target OS version for any pending DDM scheduled update

DDMSoftwareUpdateInfo="/private/var/db/softwareupdate/SoftwareUpdateDDMStatePersistence.plist"
result="No Update Pending"

if [ -e "$DDMSoftwareUpdateInfo" ]; then
    pendingUpdate=$(/usr/bin/defaults read "$DDMSoftwareUpdateInfo" | /usr/bin/grep TargetOSVersion | /usr/bin/cut -d \" -f 2)
    if [ -n "$pendingUpdate" ]; then
        result="$pendingUpdate"
    fi
fi

echo "<r>$result</r>"

Note: This file location (/private/var/db/softwareupdate/SoftwareUpdateDDMStatePersistence.plist) is undocumented by Apple and could change in future macOS versions. Rich Trouton documented this approach on Der Flounder for macOS Tahoe 26.2.0. Community-contributed extension attributes using this method are available on JAMF Nation. Test on your target OS versions before deploying to production.

API Access

JAMF announced public API access for Blueprints at JNUC 2025, with beta targeting Q4 2025. As of January 2026, API access remains limited.

Current state:

Blueprints management is primarily GUI-based
Classic API does not include Blueprint endpoints
Jamf Pro API (v1/v2) has limited or beta Blueprint support

Future capability:

API access will enable:

Automated Blueprint creation
Programmatic scope changes
Integration with CI/CD pipelines
Bulk Blueprint management
Custom reporting and monitoring

Check JAMF's API documentation for current endpoint availability. The Jamf Pro API documentation is at: https://developer.jamf.com/

If your workflow requires API automation today, you may need to continue using traditional profiles for those configurations until Blueprint API access matures.

What's Coming

Based on JNUC 2025 announcements and JAMF's stated direction:

Public API Access (Beta Q4 2025)

API endpoints for Blueprint management will enable automation workflows:

Create and modify Blueprints programmatically
Integrate with infrastructure-as-code pipelines
Build custom deployment tooling
Generate reports from Blueprint data

If you build automation around JAMF Pro today, plan for Blueprint API integration once stable.

Continued Component Expansion

JAMF adds Blueprint components without requiring full JAMF Pro releases. Expect:

More profile payload types as Legacy Payloads
New DDM declaration types as Apple releases them
Compliance Benchmarks integration (currently beta, requires same SSO configuration)

The Blueprints service updates independently. Check the Blueprints Release Notes on JAMF Learning Hub for new capabilities.

Configuration Profiles 3.0

JAMF's "Configuration Profiles 3.0" initiative positions Blueprints as the long-term deployment mechanism for profile management. Key aspects:

Profiles via Blueprints gain features traditional profiles lack (cross-platform scoping, DDM delivery)
Faster same-day support for new Apple keys
Modern API support (vs. Classic API for traditional profiles)

Traditional configuration profiles continue to work. JAMF has not announced deprecation. But strategic investment is clearly in Blueprints.

Compliance Benchmarks

Currently in beta. Integrates CIS Benchmark compliance checking with JAMF Pro. Requires:

Same SSO with OIDC configuration as Blueprints
JAMF Cloud (same tier requirements)

If you plan to use Compliance Benchmarks, configuring SSO now prepares you for both features.

Next Steps

If You Are On-Premises

Blueprints is cloud-only with no announced on-premises support.

Action: Evaluate cloud migration timeline. If Blueprints features are important to your roadmap, factor migration costs and timeline into your planning. If you have no plans to migrate, continue with traditional management methods.

If You Are Cloud But Have Not Configured SSO

SSO with OIDC via JAMF Account is the prerequisite that blocks most organizations.

Action items:

Decide on authentication method: Jamf ID only (simpler) or your IdP via JAMF Account (more seamless for users)
If using Jamf ID only:
- Have each admin create a Jamf ID at account.jamf.com
- Associate Jamf IDs with your organization in JAMF Account
- Create matching user accounts in JAMF Pro (same email addresses)
- Enable SSO with OIDC in JAMF Pro: Settings > System > Single Sign-On
If connecting your IdP:
- Create an OIDC application in your IdP (Entra, Okta, or other)
- Follow JAMF's IdP-specific documentation on the Learning Hub
- Verify domain ownership in JAMF Account
- Configure connection in JAMF Account
- Enable in JAMF Pro
Create a break-glass local admin account if you do not have one. Document credentials securely.
Test SSO login to JAMF Pro before proceeding with Blueprints.

Actual setup time varies significantly based on your IdP, internal approval processes, and whether you already have OIDC applications configured. The technical work is straightforward; organizational approvals and testing often take longer than the configuration itself.

If SSO Is Already Configured

You are ready to use Blueprints.