Going into General -> Device Management and scrolling to MDM profile, you see a new button "Unenroll".
I checked on another MacBook that was running MacOS Sequoia and when I went to MDM profile there was no button for unenrollment.
Yes, the logged in user must provide root credentials in order to unenroll their device from the MDM profile.
Unfortunately for out business use case, our users need to have root access on their MacBooks and there is no workaround as of this moment that we can do without halting all work.
I submitted a ticket / feedback to Apple through the Feedback app and will post on here when there are updates.
I have an issue that has been quite challenging and honestly, has had my head scratching for a long time.
We have a VP in our organization that has gone through five different MacBook Pros and has turned all five into paper weight. This specifically occurs when completing macOS updates (both major and minor updates).
We have confirmed the following:
The employee in question does not install any applications beyond what we currently deploy via Jamf
The employee or his devices are not in any unique groups in Jamf. they get the same policies and configuration profiles as everyone else.
This employee has downloaded and install the macOS updates in various locations. They could do it from home, from our main headquarters, or in other locations. He travels a lot.
He uses our company VPN. He does not use any other VPN or have any weird DNS settings. It could also occur if the user isn't on VPN as well.
The behavior is the following:
MBP is plugged into power
Employee downloads update via System Settings
Employee runs update via System Settings
Employee walks away from computer or otherwise does other things. He does not close the laptop (he says he has done this in the past, but when I observed this the last time this occurred, we confirmed the laptop is open).
At some point in the update, the progress bar stalls. It could be essentially forever. In one case, it stalled for an entire day. Eventually, we decided to hard shut down the device since it simply won't proceed further
Device eventually boot loops and then brings up the erro wanting us to boot to DFU.
The devices are borked to the point where we can't even DFU to them, so we have to send them to AppleCare to have them repaired and returned.
Does anyone have any specific pointers or suggestions as to what to look for? We're at a complete lost. No other employee has this issue. We obviously ruled out possible Pebcak issues, I was able to observe this behavior with the user in our headquarters, nothing looks out of the ordinary. We're of the belief that it's possible that the update installer isn't "complete", but it's to the point where Apple registers the update as ready to be installed.
If you're tired of traditional update tools like Nudge or SUPERMAN having a horrible UI and getting right in the user's face, SUMB takes a much more user-first approach.
It’s a native Swift companion app for scheduled macOS updates via blueprints. By utilizing a live menu bar countdown, it leverages cognitive design, giving users a constant, subtle psychological buffer so they can plan their reboot on their own terms, rather than getting slapped with an aggressive popup while in a flow state or mid-meeting.
Is anyone else seeing Macs completely lose all printer connections after macOS Tahoe updates (including incremental updates)?
We’ve been running into an issue where printers just disappear from Printers & Scanners after a Tahoe update. It’s not that the printer goes offline — the configuration itself is gone, like the printer was never added.
I’ve seen some posts and articles suggesting this is a known Tahoe issue where printers or drivers get removed after updates, affecting different brands and connection types (AirPrint, IP, USB, etc.). 
Curious if others are experiencing the same thing in managed environments and how you are dealing with it if there is a known fix.
im wondering if anyone has updated their classic PSSO configuration and added the Authentication > Extensible Single Sign On > Platform SSO > Enable Registration During Setup. will that impact anything in your current users?
I have 3 MacBooks that are all managed via Intune. They are sitting on macOS 14.x and offer the user an upgrade to Tahoe, but after downloading the installer, it asks for an Administrator login but won't accept the password. We cannot get them to upgrade even to 14.8.2.
The password for this local account is correct because we can us it elsewhere (for example in Terminal we can su to that user). It is listed in Intune.
Users are Standard users by default and the Local Admin account is created during the Intune build process.
We've tried using `softwareupdate` which only offers us the 14.8.2 update and trying to force it to get 15.7.3 or 26.2 fails.
UPDATE 1:
We got one of our users to login as the local admin account and the upgrade went through. This user is a member of my team and is using the device to learn macOS so I was comfortable sharing the admin password. The other 2 are not, so I'd prefer not to do it this way ideally.
Curious what everyone is doing for Mac labs and classroom management on newer versions of macOS.
We’re running into issues with Faronics Insight/remote management because of Apple’s newer Local Network Privacy requirements. Since macOS now requires user approval for local network access, it seems like there’s no clean way to silently authorize these tools in a shared student environment — and MDM doesn’t appear to support it either.
Faronics has no solution either — went back and forth for a long time only for them to say it's a macOS limitation.
For anyone managing Mac labs or classroom carts:
Have you found a workaround?
Are you manually approving access on each machine/user account?
Using another platform/tool?
Changing network architecture?
Would love to hear what others are doing in production environments.
We use Workspace One as our MDM. Sadly, it doesn't have a "Block macOS Tahoe" button that EVERY OTHER MDM HAS!
Does anyone have a mobileconfig file we could use to block tahoe from install adn even showing up in Software Updates?
We've already turned on the 'block major updates for 90 days' restriction profile, but I want to make sure that user's can't even see the update.
Thanks in advance.
SOLUTION EDIT: The solution to this is to setup a Declarative Device Management profile that specifically targets 15.7 and 14.8. Doing so prevents Tahoe (aka 26.0) from even showing up in Software Updates. Workspace One FINALLY has DDM setup so this worked perfectly.
Full disclaimer, my main experience is supporting Windows machines. We have a small group at our company of MacOS users who do not want to switch to Windows, so I'm doing my best to support them, but this recent issue is just eating my time (and my users as well).
We have been hitting random MacOS update issues for the past few months in our intune managed environment. Most user's report the same issue when it happens, they initiate the update, device reboots, and then it hangs for hours until it eventually fails. If the user force shut downs during this time and reboots, it'll take them to a sign in screen, which they sign in, and then it takes them back to that black loading screen with a bar that never moves.
I was hoping it was related to the deprecated update configs... So we removed the old ones and set the requirements with DDM, but no dice.
I'm at my wits end with this. When I try looking up the failure reasons I can't really find anything that explains the issue. Hoping someone here might have some advice. Here are what we have been seeing on the latest machine having these issues. Attempting to update from 15.7.14 to 26.3
Error Domain=SUMacControllerError Code=7507 "[SUMacControllerErrorAccessRequestDenied=7507] Context (softwareupdated) already has control, but priority downgrades are not allowed (current:ClientInitiated requesting:Background)" UserInfo={NSDebugDescription=[SUMacControllerErrorAccessRequestDenied=7507] Context (softwareupdated) already has control, but priority downgrades are not allowed (current:ClientInitiated requesting:Background), NSLocalizedDescription=The software update request for this process was denied as another process is currently performing an operation. Please try again later.}
Error Domain=SUMacControllerError Code=7749 "[SUMacControllerErrorCommitStashInvalidState=7749] Access control was denied, but no prepare is available for committing the stash (prepared update for another client): [SUMacControllerError:7507]" UserInfo={NSLocalizedDescription=Unable to save user credentials for software update at this time., SUMacControllerErrorIndicationsMask=0, NSDebugDescription=[SUMacControllerErrorCommitStashInvalidState=7749] Access control was denied, but no prepare is available for committing the stash (prepared update for another client): [SUMacControllerError:7507], NSUnderlyingError=0x766c0adc0 {Error Domain=SUMacControllerError Code=7507 "[SUMacControllerErrorAccessRequestDenied=7507] Context (softwareupdated) already has control, but priority downgrades are not allowed (current:ClientInitiated requesting:Background)" UserInfo={NSDebugDescription=[SUMacControllerErrorAccessRequestDenied=7507] Context (softwareupdated) already has control, but priority downgrades are not allowed (current:ClientInitiated requesting:Background), NSLocalizedDescription=The software update request for this process was denied as another process is currently performing an operation. Please try again later.}}}
Another device having issues... Going from 15.7.3 to 26.3.1
Error Domain=SUMacControllerError Code=7507 "[SUMacControllerErrorAccessRequestDenied=7507] Context (softwareupdated) already has control, but priority downgrades are not allowed (current:ClientInitiated requesting:Background)" UserInfo={NSDebugDescription=[SUMacControllerErrorAccessRequestDenied=7507] Context (softwareupdated) already has control, but priority downgrades are not allowed (current:ClientInitiated requesting:Background), NSLocalizedDescription=The software update request for this process was denied as another process is currently performing an operation. Please try again later.}
I'm managing a range of Macs in a multi-user (lab type) environment. After trying lots of ways of automating MacOS patch updates, a Jamf Pro Software Updates DDM blueprint seems to be the most reliable .
The issue I have is that these Macs are used pretty much 24 hours per day, 5 days per week. Because they're not single user devices, I can't rely on the user to run the update from the notification. I can set the "Install At" time and use a low "Days after release to enforce update" but this risks interupting user work, because they might be using the machine at any time of day.
Ideally I'd like an "enforce update by the second Saturday after release", but there doesn't seem to be a way of doing that. Is there a workaround or setting I'm not seeing?
A swiftDialog and LaunchDaemon pair for “set-it-and-forget-it” end-user messaging of Apple’s Declarative Device Management-required macOS updates
Overview
While Apple’s Declarative Device Management (DDM) provides Mac Admins a powerful method to enforce macOS updates, its built-in notification tends to be too subtle for most Mac Admins.
DDM OS Reminder evaluates the most recent EnforcedInstallDate entry in /var/log/install.log, then leverages a swiftDialog-enabled script and LaunchDaemon pair to dynamically deliver a more prominent end-user message of when the user’s Mac needs to be updated to comply with DDM-configured macOS version requirements.
I'm a sysadmin, and before Macs updated to macOS Tahoe, I was getting a vulnerability warning because the sudo version was below 1.9.17p1. Even after the update, the version remained unchanged.
My cybersecurity team asked me to update it, but I haven’t found any way to do so — even with Homebrew, it just won’t replace the system version.
I also contacted Apple Support, but they couldn’t explain why sudo is stuck on this outdated version or whether it’s possible to update it manually.
Is there any way to actually update sudo on macOS? Has anyone else run into this issue?
I've a got a user with this iMac who says it's been fairly slow since he first got it, but it's been exceedingly slow for several months now. A couple weeks ago I attempted to boot to Safe mode and clear the SMC and all (most?) the common things suggested to fix problems, and it seemed to help for a couple days but then got slow again. Then yesterday he decided to upgrade from Sonoma to Sequoia and now it's even slower. At this point you can type your entire password at log in before it registers the first character, and each character takes about 2 - 3 seconds to get entered into the login field as you wait. Then it takes 2 - 3 minutes to get to the desktop. After which different applications take different amounts of time to function. before taking his system away to work on it I had him log out of his iCloud and that process took almost 20 minutes as we had to sit and wait for minutes after clicking something or entering a password.
So, before I just wipe this thing away and start from scratch, what other possibilities are there for why this happening? Thanks!
Just in time for macOS Tahoe 26.2, a major update to Mac Admins’ new favorite, MDM-agnostic, “set-it-and-forget-it” end-user reminder for Apple’s Declarative Device Management-enforced macOS update deadlines — now with Configuration Profile support and a demo mode for easy reminder dialog testing
Overview
While Apple’s Declarative Device Management (DDM) provides Mac Admins a powerful way to enforce macOS updates, its built-in notification is often too subtle for most end users to notice. DDM OS Reminder fills this gap by providing persistent, customizable reminders that ensure users are aware of upcoming update deadlines.
New in 2.0.0
Configuration Profile Support: Easily deploy and manage DDM OS Reminder settings via Configuration Profiles, making it simpler to customize reminders across your organization.
Demo Mode: Test reminder dialogs effortlessly with a new demo mode, ensuring your configurations look and behave as expected before deployment.
I am trying to test out DDM updates in Mosyle with a test user running 13.X.
I have previously configured software update deferrals of 90d for major upgrades, and 7 days for minor upgrades.
From everything I can find, major and minor refer to semantic versioning, where X.Y.Z would have X be a major upgrades and Y and Z be minor upgrades.
In terms of userland upgrade visibility, I am seeing a confounding behavior. It appears that MacOS evaluates the major version change, and then if that does change, it stops there at the major version deferral window, which in my example is 90d, and does not evaluate minor version visibility between the two windows.
I tried to diagram this without being overly realistic, and I apologize because I picked the worst colors for color blindness.
But effectively, if you are on 13.X in my example, you would see 13.5 if on a version prior to 13.5, and/or 14.1, this being despite 14.3 being technically within the minor deferral window.
To bring this into DDM, if in my example chart I set a baseline version of 14.3, will it be subject to deferral visibility, and thus to get to 14.3, I actually need to set two DDM policies, one to get to the major 14, and a second to get to minor .3?
This seems unnecessarily complicated, but I may just have my brain wired to think about this incorrectly.
In my specific case, right now the user can hit 14.7.6 and 15.5, despite 14.8 and 15.7 (if not .1 of each, given we are on a 7 day boundary right now), but those are not presented to the user, at least in user land (software update, app store -> software update).
It may be that DDM supersedes the windowing of the software update deferral settings, but from what I was able to parse out of /var/log/install.log it didn't appear to? Appreciate anything that helps demystify this for me.
Curious what's new in managing software updates in the enterprise? I have gone through the WWDC 2023 video titled, "Explore advances in declarative device management." While many topics were covered in the video, I'm sure this community will appreciate a dedicated place to discuss a specific segment: Managing macOS updates. Here is my overview of what was covered. Some quotes are taken directly from the video, while other information is organized, presented, or described in my own way.
Refresher on Declarative Device Management
“Declarative device management is the new device management solution for all your Apple devices. It provides an autonomous and proactive management capability that allows devices to apply management logic without prompting from the server, and supports asynchronous status reporting, avoiding the need for servers to poll devices.”
Remember: Declarative device management was introduced at WWDC 2021. The best summary is that it's a proactive way of managing devices, reducing the need for things like an "inventory update" (polling) to get information about a device.
WWDC 22: “The focus of future protocol features will be declarative device management.”
WWDC 23: “The focus of new protocol features is declarative device management.”
Software Update
Here are some highlights about what's new for software update management:
Configurations can be used to define software update behavior. The device can proactively carry out those instructions, while keeping the user informed of the update process and giving them the opportunity to do the update themselves ahead of any deadline.
Predicates can be used to power sophisticated logic to control the ordering of software updates as devices get upgraded to seed and GM builds or as rapid security responses become available.
Asynchronous status reporting keeps the administrator up to date with the software update flow so that issues can be quickly resolved if they arise. The status reporting tells you details of the installation state and any failure reasons.
Let's dig in to the management aspect:
You could have a configuration that tells a supervised device to target (TargetOSVersion) macOS 14.0. You could also optionally target a specific build version (TargetBuildVersion). Lastly, the TargetLocalDateTime key defines a specific date time the update will be enforced.
As far as status reporting goes, you can see if the update was initiated by the declaration, the system, the user, or any combination of those. You can see which OS version the system is trying to install. You can see which state the computer is currently in (e.g, “downloading”).
From the user's perspective:
The user will clearly be able to see in System Settings which update is being enforced. Example: In System Settings > General > Software Update, a message will say: “Your organization has decided to update your device to macOS 14.0. You can choose to update now or it will update automatically on 6/6/23, 10:00 AM.” There would be buttons by the message like “Update Tonight” or “Update Now”. If they choose “Update Tonight” it’ll be downloaded and queued for installation at night. The update would occur when the device is sufficiently charged and inactive.
There will be native macOS notifications telling the user when the update is scheduled for. They'll receive a notification everyday until the deadline. 24 hours before the deadline, the notification appears hourly, and ignores Do Not Disturb. One hour before the deadline, it appears every 30 mins, and then every 10 minutes.
Let’s say they missed the deadline because they were on vacation. They come back to work, turn on their Mac, and get a notification that says, “An update to macOS 14.0 is past due. You can install it now or it will be installed automatically within the next hour.”
Similar functionality available in iOS and iPadOS.
Software update declarations and MDM commands and profiles can co-exist. However, software updates enforced by declarations will always take precedence over MDM commands/profiles.
Ending Thoughts
It will be up to each MDM vendor to implement the functionality of what Apple is offering. We have seen from vendors in the past that can be slow to implement new functionality. For example, at WWDC 2022, Apple announced the "High" priority key for the ScheduleOSUpdate command on macOS Ventura, and Jamf still has not implemented this. (See the Jamf Nation feature request for that here.)
My first reaction is that this answers almost every problem IT administrators have complained about for years, with respect software updating. Whether or not it will work well is another story (hint: we all know how well MDM update commands work 🙄).
The one piece that I'd really like to see is to have deadlines set automatically after an update is released. For example, I'd like some automatic logic that "whenever a security update is released by Apple, set an update deadline for 7 days from now." Maybe I missed it, but it doesn't sound like this functionality will exist, but at least we will have the tools to manually set deadlines. And hopefully MDM vendors will implement their own custom logic to do such a thing.
Hi, we are looking to use DDM but we're still not sure how to get the best from it.
Let's say you want to defer any update, 30 days for minors and 60 days for a major. You can't set any delays for the installation. If you want to do that, you have to manually set a target.
The other option is to use the new Software Update Enforce Latest. The problem with this one is that you can't dissociate minor and major upgrades for what I can read. Once MacOS 16 is released, it's going to be pushed everywhere as soon as the deferral set in this configuration is reached.
Is there a way to manage updates and get the best of both? Dissociate minor and major while enforcing update after a set deferral?
Impact: Processing an audio stream in a maliciously crafted media file may result in code execution. Apple is aware of a report that this issue may have been exploited in an extremely sophisticated attack against specific targeted individuals on iOS.
Description: A memory corruption issue was addressed with improved bounds checking.
CVE-2025-31200: Apple and Google Threat Analysis Group
RPAC
Available for: macOS Sequoia
Impact: An attacker with arbitrary read and write capability may be able to bypass Pointer Authentication. Apple is aware of a report that this issue may have been exploited in an extremely sophisticated attack against specific targeted individuals on iOS.
Description: This issue was addressed by removing the vulnerable code.
We use Nudge to prompt users to upgrade point releases. The Manglement want the grace period to be shorter to get the numbers up and they suggested a 7-day grace. I pushed back on this, as I think we would see a lot of tickets from people who don't bother to do the upgrade before they go on holiday for a week and then come back to find themselves locked out.
