Update default Apple automatic enrollment profile

[spalmesano0]

• We should never skip the Accessibility screen on macOS. Some end users cannot use a computer without these features.
• Added some keys that were released after this list was last updated.
• Removed Region, since we have customers in more than the US now.
• Removed IsSupervised, as devices are automatically supervised now.

Summary by CodeRabbit

Release Notes

• Chores
  • Refined the default Apple Device Enrollment Program configuration to streamline the device setup experience by adjusting which setup assistant steps are presented during enrollment.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 66.38%. Comparing base (4a5e221) to head (a9f0c61).
⚠️ Report is 1714 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #40832      +/-   ##
==========================================
+ Coverage   66.30%   66.38%   +0.07%     
==========================================
  Files        2470     2473       +3     
  Lines      197754   198423     +669     
  Branches     8668     8668              
==========================================
+ Hits       131129   131714     +585     
- Misses      54763    54789      +26     
- Partials    11862    11920      +58     

Flag	Coverage Δ
backend	68.16% <100.00%> (+0.07%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[mikermcneil]

@spalmesano0 I happened to notice this as I was working on pulling in the automatic enrollment profile we're using in dogfood.fleetdm.com into a template to be used in the fleetctl new generator. I think we're gonna want to reconcile these two sources of content, and also what we have on dogfood. For now I'll stick with what I'm seeing in the dogfood profile, just for the sake of consistency, but once the generator is live, maybe we can consolidate the templates into one place?

@lukeheath @allenhouchins @noahtalerman fyi

Note: My comment is not a blocker to this PR, just getting us on the same page for what's coming in a few weeks.

[allenhouchins]

@mikermcneil We should discuss. I didn't realize we were setting defaults for customers in the code today. I am on the side of we should not have a template of this in our generator or be setting defaults for our customers in our product code. This is a more advanced setting that I'm willing to bet not many customers use. There are also keys that we use internally that we should not be setting on behalf of customers — like skipping TOS, Restore, setting the default language, region (this isn't going to fly in EMEIA), etc. By changing the default behavior, we are potentially creating more work for admins to figure out why something is working differently in Fleet than what they are used to. Also, in most environments is_mdm_removable would be set to false. I am kind of shocked we are setting that to true as a default. I would love to set this set to false in our environment but we have the added challenge of developing the product that we use to manage ourselves and engineering may need to remove their enrollment profile so they can enroll to other instances for testing and development.

I need to revisit the one we use internally. It was set before I joined and there are keys like FileVault, which can't be skipped because we enforce FileVault during Setup Assistant.

[spalmesano0]

@spalmesano0 I happened to notice this as I was working on pulling in the automatic enrollment profile we're using in dogfood.fleetdm.com into a template to be used in the fleetctl new generator. I think we're gonna want to reconcile these two sources of content, and also what we have on dogfood. For now I'll stick with what I'm seeing in the dogfood profile, just for the sake of consistency, but once the generator is live, maybe we can consolidate the templates into one place?

@mikermcneil If we're setting a default enrollment profile when none is provided, do we need to generate one with fleetctl? We might could exclude it to simplify the GitOps setup.

There are also keys that we use internally that we should not be setting on behalf of customers — like skipping TOS, Restore, setting the default language, region (this isn't going to fly in EMEIA), etc.

@allenhouchins Sounds good, except that we should still skip Restore for now, as we don't support Migration Assistant yet. It seems like the initial intent for this was to skip a lot of the macOS setup screens that really aren't needed and just make the enrollment process drag on.

Also, in most environments is_mdm_removable would be set to false. I am kind of shocked we are setting that to true as a default.

I think this one should be set to true, as that's Apple's default. If something goes wrong with the MDM profile on a device and Fleet is unable to communicate with it, the only way to resolve the issue is to wipe the device.

[noahtalerman]

Thanks @spalmesano0!

Up to @melpike to bring a story through drafting as #g-mdm Product Designer: https://fleetdm.com/handbook/engineering#review-a-community-pull-request

LGTM

[JordanMontgomery]

Some general questions about the PR @spalmesano0

1. This change will apply not just to new fleet instances but to existing fleet instances going forward. I think in general it won't apply except as new devices get synced or if the user does something like enable EUA which forces a resync of all devices in a given fleet, but it will change default behavior. Would it make more sense to make this change in such a way that existing fleet instances are unaffected? We occasionally see Apple return device events as devices that haven't been online in a while get profiles pushed, etc and those devices would also get a profile with the new defaults.

2. We have at least one customer I know of for sure that expects MDM removable which is customer-shackleton. It's part of their series of controls: MDM removal removes certs but still maintains minimal access to certain resources so they want to keep it removable. If we change the default we will likely want pretty large customer comms to get all customers who care to update this prior to release since this is a setting which AFAIK cannot be changed by us after the fact.

[spalmesano0]

1. This change will apply not just to new fleet instances but to existing fleet instances going forward. I think in general it won't apply except as new devices get synced or if the user does something like enable EUA which forces a resync of all devices in a given fleet, but it will change default behavior.

The initial version of this PR was much smaller, so that wasn't as big of an issue at the start! Thanks for bringing that up at this point.

Would it make more sense to make this change in such a way that existing fleet instances are unaffected?

Maybe, but that would add (in my opinion) unneeded complexity. Personally, I prefer the points below more.

2. We have at least one customer I know of for sure that expects MDM removable which is customer-shackleton. It's part of their series of controls: MDM removal removes certs but still maintains minimal access to certain resources so they want to keep it removable. If we change the default we will likely want pretty large customer comms to get all customers who care to update this prior to release since this is a setting which AFAIK cannot be changed by us after the fact.

Completely agree here. Weeks before this change is made (if we're still going to include all of the commits), we should communicate with users, and tell them how to create their own enrollment profiles as this only affects users who aren't deploying a custom enrollment profile.

@JordanMontgomery Is setting IsMDMRemovable to false the only change that carries risk here? If so, I think the best option would be to change that back to true.

[JordanMontgomery]

@JordanMontgomery Is setting IsMDMRemovable to false the only change that carries risk here? If so, I think the best option would be to change that back to true.

Yes I think that's the only real risk and we should change it back. I think the other things at best would be an annoyance to admins that get caught off guard(since the features can be configured later) but changing this will potentially leave them with hosts they have to wipe in certain cases. I think admins who know what they're doing and know the risks probably do usually make the MDM non-removable but since that has always been an explicit opt-in this feels like a breaking change

[allenhouchins]

since that has always been an explicit opt-in

This was a design choice by Fleet though (right?), not the default behavior admins expect for devices owned by the company. Admins expect this profile to not be removable. It introduces security and compliance risks. It seems like we've had far more people asking why this profile is removable than we have customers who expect it to be removable.

[spalmesano0]

Yes I think that's the only real risk and we should change it back.

Changed it back and removed is_supervised, as devices are automatically supervised now.

I think admins who know what they're doing and know the risks probably do usually make the MDM non-removable but since that has always been an explicit opt-in this feels like a breaking change

This was a design choice by Fleet though (right?), not the default behavior admins expect for devices owned by the company. Admins expect this profile to not be removable.

Since this seems like a breaking change, my vote is to defer changing this default behavior. If admins want to prevent it from being removable, they still can deploy their own enrollment profile.

[mikermcneil]

Just saw this pop up and making sure no one is waiting on me. Up to the DRI

[claude]

Claude Code Review

This repository is configured for manual code reviews. Comment @claude review to trigger a review and subscribe this PR to future pushes, or @claude review once for a one-time review.

_{Tip: disable this comment in your organization's Code Review settings.}

[MagnusHJensen]

Merging this as is, from the story perspective.

I'm unsure if we want our code default and the fleetctl new enrollment profile to match?

cc @lukeheath @noahtalerman

[Copilot]

Pull request overview

Updates Fleet’s default Apple Automated Device Enrollment (DEP) profile to better support global customers and ensure macOS Accessibility setup is not skipped during Setup Assistant.

Changes:

• Stop skipping the macOS Accessibility setup screen in the default DEP profile.
• Remove the hard-coded Region: "US" from the default DEP profile.
• Add newer Setup Assistant skip keys to the default SkipSetupItems list.

Comments suppressed due to low confidence (1)

server/mdm/apple/apple_mdm.go:112

• Changing the default DEP profile (SkipSetupItems/Region/etc.) will break existing tests that hardcode the old default JSON/profile, e.g. TestDEPService/EnsureDefaultSetupAssistant (server/mdm/apple/apple_mdm_test.go) and the integration test TestMacosSetupAssistant (server/service/integration_mdm_test.go) which includes region: "US" and skips "Accessibility". Please update those expected fixtures/assertions (or relax them to only check the fields under test) so CI remains green.

		SkipSetupItems: []string{
			"Appearance",
			"AppleID",
			"AppStore",
			"Biometric",

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[coderabbitai]

Caution

Review failed

Pull request was closed or merged during review

Walkthrough

This change modifies the default Apple Device Enrollment Program (DEP) enrollment profile configuration in the getDefaultProfile function. Specifically, it removes the explicit IsSupervised and Region field specifications and adjusts the setup assistant items that are skipped during device enrollment. The "Accessibility" item is removed from the skip list, while five additional items ("Intelligence", "OSShowcase", "SoftwareUpdate", "UpdateCompleted", "Welcome") are added to the skip list, with other previously skipped items preserved.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The description provides clear rationale for each change but does not follow the repository's detailed checklist template with checkboxes for testing, changes files, database migrations, and other required verification steps.	Complete the PR description template by addressing all applicable checklist items (testing, changes files, security validation, etc.) and explicitly confirming which items apply or explaining why they don't.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately and concisely summarizes the main change: updating the default Apple automatic enrollment profile configuration.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch skip-keys

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[noahtalerman]

I'm unsure if we want our code default and the fleetctl new enrollment profile to match?

@MagnusHJensen good catch! I think we do. I opened a PR to update the fleetctl new profile: #40905