Managing OS 27 in the Field

In this Addigy webinar, Senior Product Marketing Manager Angela Diaco, Senior Product Manager Mikaela Gilman, and Creative Techs CEO and Apple premium technical partner Tim Pearson break down the four ways to do single sign-on (SSO) on Apple devices — enrollment SSO, platform SSO, extensible SSO, and Addigy Identity — and offer a framework for choosing the right fit for your fleet. The session also covers new Addigy Identity features including silent FileVault unlock, end user directory assignment, and simplified platform SSO setup, with the core takeaway that identity is foundational to security and Addigy includes all of these SSO solutions at no extra cost.

Video Transcript

Introduction and agenda

I’m Bryce. I’m joined today by Ponce, our VP of Security and our own Addigy admin. He has had discussions with me about how we’re going to manage OS 27 internally.

If you attended our session at our conference, Frontier, last week, we did an abbreviated version of this. This is the same slides with 10 or 15 more added, and we’re also covering a few more pieces of content, because the germ of the idea is the same: how do we manage OS 27?

First, we’ll talk briefly about hardware support. There are some changes there if you’re not familiar. We’ll talk about new device settings for configuration. If you’re not familiar with declarations and profiles, that’s where they all live: device settings. It could be a declarative configuration or a profile. We’ll talk about changes with accessibility and privacy, and then app settings, which is probably the most prominent thing with OS 27 outside of the hardware and MDM support changes. Then we’ll talk about MDM-based OS updates and upgrades, then everybody’s favorite point, how to defer and manage that. Finally, we’ll cover the status channel and some changes with compliance.

Hardware support: no Intel version of macOS 27

If you haven’t heard, the supported hardware is changing. There is no Intel version of macOS 27. Ponce, out of our own fleet internally, how much do we still have that is Intel? It has to be under 20 or 30% by now.

Zero. In the chat, I’d love to see how many of you still manage Intel. To Bryce’s point, it’s been about six years. Personally, I still have an Intel Mac, and I think many of us do, but work-wise almost everybody has switched over. Some people in chat say they’re at 15, 20, or 30%. One third, or 30%, is probably the highest I saw based on the chat messages.

The numbers bear out what I’ve seen on our back end. A good chunk of devices are still on macOS 15, because many of the last Intel devices, including the first-generation Touch Bar machines, capped out at 15. Very few got 26. We’ll start to see that taper off now, because this year there is no Intel support, and next year there will be no Rosetta support either. There’s a slide on that coming up.

If you have those devices and you’re trying to figure out which ones are supported, we’ve had a fact in the product for a while that shows whether the new OS is supported for macOS. This year we layered on an array that looks at model identifiers. It now covers iOS, iPadOS, and macOS, and it also looks at tvOS, because two tvOS devices were in the array when I looked at it in sandbox. Those devices will show whether they support the OS or not. If you go to the device itself, you can see the fact and watch it light up.

I don’t think we’ll necessarily see Apple drop support for the M1 with OS 28 next year. M1 devices are still pretty powerful. The MacBook Neo isn’t even an M1. It’s an A-series chip, which is about on par with an M1.

New device settings and declarative configurations

These are some of the new things added in device settings. There is the app settings configuration, which we’ll talk about more. Content caching configuration existed previously as a profile and is now also a configuration, with a few additional key values. DNS proxy and DNS settings are now also a configuration. Extensible SSO, previously just a profile, is now also a configuration.

On the ones that previously existed as profiles, you don’t have to migrate today. You can keep using the profile. However, if you want some of the new key values or functionality, such as app settings, which doesn’t exist as a profile, you need to use the declarative configuration.

The same goes for the Apple Intelligence configuration, with features for things like Mail and Calendar. There is a specific subset of keys in that configuration that doesn’t exist in a profile. The restrictions profile has some restrictions for Apple Intelligence, but that doesn’t cover all the features Apple has added. Apple is using declarative configurations for those.

Relay and website privacy are a subset within Safari, which we’ve had for the last year plus, and are now available in the settings configuration as well. There is also a Siri settings configuration for tvOS, and VPN and content filter configurations. All of these are new additions.

Accessibility is now “Device control and data access”

If you’re new to Apple devices, Apple has privacy controls over device control and data access. This screen is OS 27. This section does not exist prior to 27, or doesn’t exist with this name. It is the former accessibility pane. Device control and data access is no longer called accessibility in 27.

Accessibility and permissions have been changed for user transparency. “Accessibility” is vague. Many app developers need accessibility permission for a number of reasons that probably nobody can tell you. The short version is that Apple is trying to lock down those settings. They want to understand what those developers are doing.

Because of that, this permission can no longer be whitelisted via an MDM profile, as we’ve seen from OS 26 and every operating system before that. If you want to manage it now, Apple suggests using the new DDM app settings declaration. You can find it in the catalog under device settings.

If your users upgrade to OS 27 and there is an accessibility profile that we’ve been deploying up until 27, they will get notifications about this permission. If any application has an accessibility profile, it triggers that notification. The notification is vague and can look frightening.

The new app settings configuration prompts the user on the app’s first launch. You can either let the system natively prompt the user or build your own message to prompt the user. Either way, the user is prompted. The big change is that Apple removed the feature we used to automatically allowlist this permission. Similar to screen recording, camera, or microphone, it now has to be approved manually.

User channel vs. device channel

The app settings declaration is only deployable to the user channel at this time. That means an MDM-managed user. There is normally a one-to-one relationship between the device and that user. You can have more than one if accounts are created with Platform SSO or other methods, and Active Directory binding is another way to add more.

If the device doesn’t have an MDM-managed user, you would have to re-enroll the device. There are some other options. There is a command that makes it seem like another enrollment is starting, similar to the sudo profiles renew type of enrollment. That re-enrolls the device without uninstalling and reinstalling, if it’s ADE eligible.

If you’re not sure, go to GoLive, open device settings, and try to deploy a device setting to a device. If the device has a managed user, it will show up there and you can deploy. Otherwise, it won’t, and you can’t deploy the setting. For many devices, that means you may not be able to use the new app settings at all.

Our feedback is to tell Apple. Create an Apple feedback. They are probably getting hundreds of feedbacks on this, and they’re very aware of it. They are working on putting it on the device channel. The more requests the better, because it shows the urgency and the need. With beta 2 of the dot-two release out, it’s still not there, so the more urgency the better. We have a knowledge base article on how to provide feedback to Apple. If you’re on the beta, Feedback Assistant is already loaded.

There are two ways of deploying a device setting or a legacy MDM profile: the user channel or the device channel. The device channel deploys to the device regardless of which users are there. The user channel deploys to a managed user. Most of you use the device channel for almost everything, and the user channel is very limiting.

A practical example is the Dock payload. You could deploy a Dock payload on the device channel that changes the Dock for everybody, or on the user channel so that one person gets a specific Dock. In higher ed, when AD-bound devices created a managed user for each person, a subset of users might get one Dock for one class and a different Dock with different apps for another class.

The problem with app settings is that everybody is probably going to get the same settings, such as access for screen recording and screen sharing. A per-user basis doesn’t make sense for those. My thought process, and this is me pontificating, is that before we hit the December 13 deadline of the 90-day deferral, Apple will have it available on the device channel. I could be wrong. I hope I’m not. It needs to be there before people can fully manage all of these things and before they can’t defer anymore.

What users see and how it affects remote control

These screenshots are from my device. The notification starts stacked, and I expanded it for the example. Most end users I’ve worked with never look at Notification Center unless it’s a text message, because there is so much other content in there. It might wind up being a non-issue in your organization. If you have attentive users, they may notice it. If the user clicks on it, it takes them to the Device control and data access settings.

The other impact for IT admins is remote control. If you want to control the keyboard and mouse automatically during a remote control session, that won’t work anymore. The end user has to approve it. If you request keyboard and mouse control in a Zoom session, it prompts the user to approve that setting before you get control, just like screen recording, camera, or microphone. That applies to any third-party remote control tool, including Splashtop. Live Desktop is not impacted, because it uses the built-in remote management with a specific tunnel being set up, so it doesn’t have that limitation.

The app settings declaration

If you use the new app settings declaration, you can curate the notification. It still requires the user to press Allow or Not Now, but you can make the message more intuitive. The prompt shows “Device control and data access” with a description of what apps with this access can do: view and send email, edit contacts and photos, monitor the keyboard, and more. Nobody really knows what a specific app does with it. It depends on each vendor and what that vendor’s application can do.

In this example, I filled in Addigy MacManage, since I know the bundle ID off the top of my head, and I wrote the description for our self-service app. This is how it looks in the catalog, and you’re asking for those permissions there. Will we do this for MacManage? Yes, if we find we need some of those permissions at the system level. We won’t do it until we have the system channel, because shotgun-blasting it to all users will be a lot cleaner once the system channel is available. That is an ongoing discussion.

For things like location tracking, which we’re testing for iOS self-service, we will have to deploy that payload. iOS doesn’t really have a user channel for this, apart from Shared iPad, so it’s the system channel and we don’t have that limitation there.

If you want to allowlist an app or give it a custom notification, that is the way to do it. If you don’t want the default notifications to appear, we are currently saying to move away from the accessibility MDM profile.

Profiles vs. declarations in the Addigy catalog

In our catalog, we don’t yet differentiate between a profile and a declaration. All the new items are declarations, and there is a new tag. One ongoing project is a migration to “legacy profile,” where we deploy profiles as a configuration attachment. When we do that, everything will be a declaration, but some will be configurations and some will be profiles. The ideal is probably a column in the catalog and a way to filter. Right now, the only items that overlap are passcode, Extensible SSO, and content caching. Everything else is just a declaration to start. As more overlap, we’ll make sure there is a way to filter it.

Rosetta 2 is going away

Apple announced that Rosetta 2 will be completely removed in OS 28. In OS 27, there is a slight change: when you upgrade in place, it removes Rosetta 2. If you use apps that are still Intel-only, as I do, you have to redownload Rosetta, approve it, and agree to the terms again. It’s not a big deal, but be aware of it. It is documented.

Rosetta 2 is how you run Intel-based apps on Apple silicon Macs. Rosetta 1 was how you could run PowerPC apps on Intel-based Macs prior to 2006 or 2007. Now Rosetta 2 is coming to an end, and everybody should have their apps migrated.

MDM-based OS updates are removed in OS 27

Here is another deprecation, except now it’s an actual removal. MDM-based OS updates and upgrades are removed in OS 27 on iOS, iPadOS, tvOS, and macOS. You cannot send an MDM update command. You can send a declarative (DDM) update command, which we’ll cover in the next few slides. The MDM update commands are gone.

We have a knowledge base article on how we handle this in Addigy, because the removal changes how GoLive functions. Apple communicated this starting last year at WWDC 25, in the “What’s new in management” session, and there is an Apple knowledge base article that details it as well.

Within Addigy, if you go to a device, open the Updates tab, and ask what updates are available, the list-updates command no longer runs on 27. It didn’t really run on 26 either. It was deprecated in 26 and not maintained. macOS 15 was the last version where those commands were maintained. I’ve used them as a one-off to update devices for family and small businesses. They worked on 15, and on 26 it was a 50/50 chance they would complete. I’d check the logs and see the device acknowledged the command but did nothing, because the software update daemon wasn’t picking it up.

So starting with 26 and up, we removed the one-off command send. It probably wouldn’t complete on 26 and definitely wouldn’t complete on 27. In its place, we added a new way of listing available updates. Instead of pulling from the device’s catalog, which on 27 wouldn’t give you anything, we look at the device’s model identifier and the version the device is on, in this case 26.6.2 on an M2 Mac mini. We then list the updates in Apple’s public catalog that are available to that device and tag which one is the latest. Right now there are two branches: 26.7, which is on the Insider Slow track, and 27, which is the regular channel.

The update history is the same as it ever was. It shows what time the command or update completed, whether it was an MDM command of yesteryear, a declarative command, or declarative status channel data from the device.

The new update status tab in GoLive

The update status tab replaces the install-updates refresh page for 26 and up. On iOS 18, iPadOS 18, macOS 15, and lower, it remains the same as it always has been, because those commands complete and work on the device. The new tab pulls from the device, and in my testing it usually takes a minute or two. We rely on the device to send it to us. The status channel is a bit like an RSS feed: we subscribe to what the device tells us. So we can see that an update started downloading because I sent a declaration.

If I’m the end user and I go to Software Update on my M2 Mac mini and hit upgrade to macOS 27, that is reflected here too, because it pulls from the status channel data. We wanted to give this tab as much functionality as physically possible given the OS-side limitations, so you can see that information device-side in a spot that makes sense.

Changes to the DDM OS updates policy

Because MDM updates were removed for 27 and up, we changed the DDM OS updates page in the policy view. There is now an additional settings menu, and within it you can set the MDM updates that apply to older operating systems that don’t support declarative updates. Those are macOS 12 and 13, which can’t take any declarative OS updates, and iOS 16 and older. If you have devices on those versions, that is where you set them. At the bottom of the page, where the schedule for MDM updates used to be, there is now a button to open it as a modal for those legacy updates.

We made this change to simplify the UI. Also, Apple isn’t releasing new versions of macOS 12 or 13, so those devices are getting toward end of life.

The team is also working on endpoints that will go public so you can consume this data through the API. We build everything API-first, and the UI consumes it. These are the endpoints we use in the UI, and we’ll make them available in the API so you can use them as well.

How to defer macOS 27

There are a couple of ways to defer. The first is simply to not push it, which we’ll cover in the settings. The next is the legacy restrictions profile. If you have older devices that don’t support the new declaration, there are ways to do some deferral with the profile. The new settings configuration is the way forward. For macOS, you get an additional option: the prebuilt app that blocks the full installer.

What has changed, as of this week, is that the policy setting is now a drop-down. Because we no longer have MDM-based updates in there, you choose one of three options: update to the latest, update to a specific version, or just do deferrals. If you choose deferrals only, you push nothing either way and nothing is out there.

If you set a maximum version, you then choose how to deliver it. The deadline option works for macOS 14 and up. For example, after 90 days at 5:30 PM on a given day, the device will do the update. Devices on 15 also get the deferral in addition to that deadline. You can also control how many notifications end users see and whether a standard user can run the update. Background security improvements are covered separately.

iOS and iPadOS are a little different. There is only one deferral, with no breakout for major and minor versions. There is also a recommended cadence, where you offer an update, for example 26.7 or 27.0, with different cadences for the oldest and newest.

The logic here has changed. Previously it would fragment: macOS 14 would get one thing, and on macOS 15 the deferrals and the on-device automatic actions created conflicting math. Now you pick either deadline or automatic actions. You can’t mix them in that policy. That makes it simpler to set up, because you pick from the drop-down rather than managing a divergent tree for 14 and 15.

If you want to defer with settings and push nothing, choose the new deferral option and set what you see on screen: 1 to 90 days, your notification preferences, the iOS and iPadOS cadence, and the automatic actions at the bottom, where you choose not to automatically download and not to automatically update.

Layering deferrals, the blocker, and the strongest setup

For macOS, make sure the blocker is in place. If the user does see the update and the deferrals aren’t working, the blocker app will try to kill the installer. There are many ways of deferring, and it can be confusing, so to make it clear: the deferrals prevent the user from seeing the update, and the software update settings in your policy prevent Addigy from deploying it. That is why we say to cap the version. If you say update to the latest, it will go to the latest. The legacy MDM profiles are deprecated. You can still deploy them, but in my experience they don’t work well anymore, if at all.

If your devices are on 15 and up and you just want to defer and wait and see, choose deferred with settings and don’t cap the version. Two options accomplish the same thing if all devices are on, say, 26.9. Addigy won’t push a version beyond that because it won’t see the calculus to do so.

If you set deferred with settings, push nothing, turn off the automatic actions so there are no on-device updates, and pair that with the prebuilt app blocker, that is your strongest deferral. Addigy isn’t sending anything, and there are no MDM commands left to send once devices are on 27. On 26 they didn’t really complete anyway, and that is filtered out by this setting. You are also putting down the deferral declaration and blocking the App Store. You can reassess if another dot release comes out, though I think 26.7 will be the last. You can still do background security improvements if Apple drops one, because they are independent of this.

Updating to the latest OS during enrollment

If you want devices to upgrade to the latest OS before they even finish enrolling, we’ve had this feature for almost three years. Previously you had to input a version number. Now it indexes the available catalog. Using a specific version number caused problems because Apple sometimes pulls those dot releases, and the number you entered would no longer work. By indexing the catalog, we make that scenario much less likely, though if you pick a specific version and Apple pulls it, you can still hit it. You can also choose the latest, and it will keep up with the latest version from the catalog that the device can support.

You can mix and match. You can set it for just iOS, just macOS, or just iPadOS, and choose none for the others, or choose a version. On a macOS device going through ADE, a pop-up says the OS is required, for example 26.4 is required and you’re on 26.3.1. You do the update, then the device returns and finishes enrollment, so you start from the latest OS.

I love the idea in theory. From an IT perspective, we don’t want devices coming in directly from Apple on old operating systems, which almost always happens, because by the time hardware ships it’s already out of date. The challenge is that the user is probably being onboarded at that moment and has little patience to do an update immediately. The feature is more reliable than I thought it would be. The problem is user expectation and experience when they first start using the device.

We’ve talked about this internally. We bought a number of MacBook Pros for new hires that all shipped several versions old, after sitting on the shelf or in customs. Apple is doing some odd things with customs because of tariffs. As a result, the device isn’t jumping from 26.6.0 to 26.6.1 or 26.6.2, which is a gig or a gig and a half. It is jumping multiple versions, and the update becomes six, seven, eight, or nine gigabytes. That changes how long the update takes, especially with a fully remote new hire and their connection.

Status channel dashboard and API

As of this Monday, there is also a dashboard for the status channel. In the system dashboard there are new widgets that populate the same data you see on the Updates tab in GoLive. You get a more holistic view of which updates are stuck and why.

There is an OS updates widget that tells you which version a device has installed or pending, and whether it failed. Next to it is a failure list, which breaks failures down into the actual error codes the device returns through the status channel. For example, I can see that a MacBook Air failed, open its widget, and see an “update access denied” error, which devices hit that error, and how many occurrences have happened. For devices that never reboot and are always online, the occurrences keep climbing because the device keeps trying to do the update and can’t. You can also force a reboot every 14 days, which is what we do internally.

The error codes are listed with a general description at the top, and we are cataloging more of them as we get them from the status channel. When you expand a device, you see the actual error, which can help you zero in on the problem. One example is a negative 20 keybag error on iPads and iPhones. It means the device is at the screen asking for the passcode for the authenticated reboot, and no one has entered it. We’ve seen this with EDU and manufacturing customers whose iPads or iPhones sit in a cart for three or four days over a long weekend or a different production schedule. Those devices aren’t authenticated, so they don’t update and they return that error.

You can consume this through the system dashboard or through an endpoint. With the endpoint, you enter your organization ID or specify policy IDs and enumerate all the devices in a policy, or go org-wide. It returns something very similar to the dashboard but more specific, so you can parse it for use in ticketing software or other detection. It tells you the version, whether it failed, or what version was prepped.

Right now the dashboard only looks at passcode and OS updates. The endpoint consumes more channels, including passcode security, software update, content caching, and Migration Assistant. We’ll add widgets over time. Software updates are the biggest pain point, so we started there.

Compliance benchmarks for macOS 27

Benchmarks are defined per operating system. The CIS team meets every week, discusses the rules, and puts together benchmark settings for each operating system right before a major OS release. They put out a prerelease of 27 that is still being fine-tuned. This is mainly a reminder: because 27 is out, you need to build or clone your 27 benchmarks and assign them. Once devices upgrade to 27, if you don’t have a 27 benchmark assigned to your policies, they won’t be in compliance. Benchmarks are designed per operating system because each OS has different rules and curated content. If you assign multiple benchmarks for different operating systems in one policy, only the benchmark for that specific operating system applies. Otherwise the device is ignored.

Check whether you have a 27 benchmark and start testing it on 27 devices. People who go to 27 early are usually lenient and willing to be guinea pigs.

Everything is moving toward declarations, and some rules now have to be done through declarations because Apple provides that as the only mechanism. We are going to roll out remediations via declaration. We don’t do it today as part of the prerelease or beta, but it is coming shortly. For software updates, MDM commands no longer work, so the automatic actions I showed, always on or always off, are DDM settings that will be controlled and checked via the benchmarks. Start rolling out to a handful of devices and make sure you understand the compliance requirements for your fleet on 27.

For software updates and compliance, I recommend creating separate flex policies for each operating system and applying them to everyone on that operating system, regardless of department or company. If they’re on 27, you’re usually managing them the same way. Benchmarks or update settings may differ if different clients want different things.

The new device fact I mentioned should be in all your environments and shows whether your devices support OS 27. Some may not, such as Intel devices. You can use that fact in flex policies for software updates when you want to take certain people to 27. You can also use smart filters, part of the Addigy Intelligence suite, to show you those devices.

Addigy Intelligence, MCP, and the AI Basics benchmark

Some reporting functionality is included for everybody, and some is in Addigy Intelligence. You can go to Reports and build an “OS updates installed” report to see who has installed updates and what has happened on devices. If you have the AI function, you can tell it what you want and it builds the dashboards or widgets for your update status. You can then run the report to see who has updated to 27 recently or historically.

We’ve gotten a lot of great feedback on the MCP server. MCP stands for Model Context Protocol. It’s a wrapper around the API, so you can use your preferred AI tool, such as Claude, to talk to Addigy in human language, get your data back, or tell it to do things, depending on the API. It is based on API keys and the permissions on those keys. If you don’t want it to write, give it only read actions. It’s an easy way to get information about your fleet and device health.

There is also a compliance benchmark tab called AI Basics. We’ve started using it internally and we like it. If you don’t want people using AI tools outside the approved ones, it gives you checkboxes to block tools such as ChatGPT, DeepSeek, or Perplexity. It doesn’t use any AI. It’s a benchmark we curated to control which AI tools teams use, so you don’t get shadow AI or free, unapproved tools. When something is free, you’re often the product and your data is the product.

Beyond Addigy Intelligence, we also have a Security Suite feature set, with SentinelOne on the back end. If you’re interested, let us know. By and large, everybody has Addigy MDM and can do most of what we talked about today, except maybe the AI-generated reporting.

Q&A

Is there a way to kick a device that is failing OS updates? There used to be kickstart, but it was removed on the Apple side after macOS 14.4, so that service can no longer be restarted. The only real way to kick start it is to reboot the device. If that doesn’t work, there are files you can remove with rm -rf, mostly on macOS 14 and 15. That is not super condoned, but sometimes it’s the only way forward when a device is really stuck. It got better in 26. Often the status channel failure is something simple, like not enough free space to download and install the update.

Should I migrate from MDM profiles to declarative configurations for device settings? I would not migrate at this time unless you need a new feature. Passcode and Extensible SSO have a few new keys. Use the new declarative configurations where there is no analogous profile. Otherwise, stay the course. Internally we are looking at moving everything to the legacy profile wrapper, which puts the profile down as a declaration, probably not this calendar year. We’ve been running it on our own production devices and testing since 2023. In macOS 26 we saw devices get stuck and lock up when sending more than about 18 profiles, which is why we haven’t pushed it to everyone. Beta 5 of 27 seemed better, but we replicated the problem again during benchmark testing this week, so we’re working with Apple on it. If you have a mix of OS versions, older devices only get the profile, and the declarative configuration shows which OS it supports. Most are 27 and up, some are 16.4 and up, and the rest are 27.0 and up.

If you pass the app settings declaration to allow the old accessibility permission, is it a one-click allow, or do users still have to go to System Settings? The prompt is one and done. In my testing, I have never been prompted again. When I deployed it to the user channel, I got the pop-up, hit Allow, and it did not ask again. The first time that app bundle launches, it asks once. That does require deploying to the user channel. I have hopes it will work the same way on the device channel, but that is to be determined.

Thank you, everybody, for making the time. Join us in the Addigy channel in Slack if you’re not part of it.

FAQs

Does macOS 27 support Intel Macs?

No. There is no Intel version of macOS 27, and Apple has announced that Rosetta 2 will be removed entirely in OS 28. Addigy has a device fact that shows whether each iOS, iPadOS, macOS, and tvOS device supports the new OS.

What changed with accessibility permissions in macOS 27?

Accessibility is now called Device control and data access, and it can no longer be allowlisted with an MDM profile. Apple suggests using the new DDM app settings declaration, which prompts the user on the app’s first launch. It is currently deployable only to the user channel, which requires an MDM-managed user.

Are MDM-based OS update commands still supported in macOS 27?

No. MDM-based OS updates and upgrades are removed in OS 27 on iOS, iPadOS, tvOS, and macOS. You can still send declarative (DDM) update commands. Legacy MDM update settings in Addigy now apply only to macOS 12 and 13 and iOS 16 and older.

How do I defer macOS 27 in Addigy?

Set the DDM OS updates policy to deferred with settings, do not cap or push a version, and turn off the automatic download and update actions. Pair that with the prebuilt app that blocks the full macOS installer for the strongest deferral. Apple’s 90-day deferral limit is a factor, with a December 13 deadline mentioned in the session.

What happens to Rosetta 2 when I upgrade to macOS 27?

An in-place upgrade to macOS 27 removes Rosetta 2. Users with Intel-only apps have to redownload Rosetta and accept the terms again. Apple has announced that Rosetta 2 will be completely removed in OS 28.

Do I need to migrate my existing profiles to declarative configurations?

No. You can keep using existing profiles, and the session recommended staying the course unless you need a new key or feature, such as app settings, which only exists as a declarative configuration. Older OS versions can only receive the profile.

Do I need new compliance benchmarks for macOS 27?

Yes. Benchmarks are defined per operating system, so you need to build or clone a 27 benchmark and assign it to your policies. If you don’t, devices that upgrade to 27 will not be in compliance. Test it on a handful of 27 devices first.

How can I see why macOS and iOS updates are failing?

Use the new status channel widgets in the Addigy system dashboard, which show OS update state and failures broken down by error code. You can also pull the same data through an endpoint by organization ID or policy ID. Rebooting the device is the main fix for stuck updates, and low free space is a common cause.