We’re back with part two of our WWDC review focused on items that benefit UEM/MDM engineers. Last week’s article was a big hit covering some very exciting stuff like new MDM capabilities and Managed Apple ID changes. Bill Hader continues to be our GIF mascot for a 2nd week in a row because this WWDC really does have EVERYTHING. This week, we will hit on the other 3 items being passkeys, managing Apple Watches, and changes to Declarative Device Management. Let’s get started!

Deploying Passkeys at Work

Passkeys are replacing for passwords on devices. They’re faster and easier to sign in, secure and phishing resistant, and powered by the iCloud keychain. This is a new industry standard by many large orgs like Google and the FIDO alliance.

Why are Passkeys Helpful?

Passkeys eliminate credential phishing as there is no password to type in on a device and each passkey is linked to its application. Additionally, this eliminates the hashes of passwords commonly found on servers because we transition from hashes to public keys.

Passkeys eliminate the need for MFA as it does not provide any additional benefits. We also have the added benefit of a much better use experience when creating accounts/accessing services using a passkey.

How Do we Manage these Passkeys?

Firstly, we have a few requirements:

• Managed Apple IDs (surprise surprise)
• Ensure passkeys only sync to your managed devices
• Store work-related passkeys with the company-managed iCloud
• Prove to your relying parties that passkey creation happens on a managed device
• Disable passkey sharing between employees

In iOS 17, Managed Apple IDs support iCloud keychain, which solves one of the major needs on passkey management. Additionally, we leverage the new access control capabilities in ABM/ASM to only allow Managed Apple IDs on managed devices. On top of that, you can do the same with iCloud.

Additionally a few MDM controls are coming with declarative device management to manage passkey creation itself.

We have a new configuration to provision passkeys called: com.apple.configuration.security.passkey.attestation which references an identity asset and that associated identity is used to provide standard web authentication, which the relying party can verify. They are bringing that to all platforms. Here is some example code:

It’s somewhat reminiscent of Mobile SSO profiles. The idea is that the website will enforce and only allow auth with a valid attestation. The attestation only occurs the initial time, which speeds up the process in subsequent attempts. Where the device authenticates and trust is evaluated. Let’s check out the flow:

This is what your attestation statement looks like that WebAuthn uses:

The Changes to Declarative Device Management

You may have recall I wrote about this awhile back. The key is that basically everything happen on the device. Stuff is delivered to the device and the device actually enforces and handles things as needed. Apple continues to echo the sentiment that DDM is the future and where we are going.

The first thing they announced is the addition of support for Apple Watch. We’ll cover more about that in our next section.

The focus this year is on apps, identity, software, system configuration, background tasks, and FileVault among other options. Let’s cover these items more.

Enforcing Software Updates with DDM

DDM will leverage 3 concepts to elevate software updates. One thing to highlight before we get started, DDM always wins over traditional MDM configurations.

With configurations, your MDM will tell the device of your update behavior and the device itself will carry out those instructions along with giving the user notice and empowerment to get those updates then.

Predicates will be used to power logic to control the order of software updates accounting for seed builds and major security releases that become available on the device.

Asynchronous status reporting will keep the administrator up-to-date of any issues when the issues happen. Let’s check out how this happens:

Some of the status’ that can be passed are:

• softwareupdate.install-reason
• softwareupdate.pending-version
• softwareupdate.install-state
• softwareupdate.failure-reason

Let’s see what a status item looks like:

You can see even the user experience is really improved on:

If they don’t take action, they will see notifications:

The other brilliant thing is they even account for a device that was shut-off with this notification:

How DDM Helps Apps

A new API they have replaced the contentMetadataLookup server API to deliver further customization, versioning, performance, and uptime for your ABM integrations as well, which I thought was good to mention before we get started.

Configurations are used to specify apps that are available on the device when needed and are already there and staged when predicates decides conditions are now met.

Predicates decide what situations occur that now tell the device to deliver the application for the user, such as device state, MDM conditions, etc.

On-demand install is surprisingly available as well that eliminates many of the prompts we see in traditional MDM. Asynchronous status reporting serves the same purpose of keeping the administrator up-to-date of any issues when the issues happen. Let’s check this one out now:

You can see we have much of the same behavior and concepts as regular MDM. One thing to note that MacOS packages can only contain a single application. You can do many of the same things like stopping apps from being removed, optional apps, etc. Note the Per-App VPN, which is interesting.

Now, let’s check out an example of the managed application list:

Overall, app delivery creates a ton of latency that impacts the user experience. Now, a new ManagedAppDistribution framework is now available to improve upon this. A new SwiftUI view extension for managed apps is being introduced (hint hint Workspace ONE, Intune, and the rest of you) that will deliver immediate installation and progress.

This is what it looks like:

MacOS looks even neater:

How DDM is Improving Managing Devices

Configurations can be used to specify sets of tamper-resistant configuration files for system services.

Status can be used monitor background tasks, enhancing the management of devices.

Predicates can power compliance rules triggered off device state in an autonomous fashion.

This is actually super interesting. This is how it works. First, we start with the new asset class. This states that we want to bring down a zip file containing your configuration files for sshd (note that can you also enforce authentication):

Upon expansion, it will show all of your configuration files, which are tamper-resistant and your system will now use for this service:

The initial services adopting it are:

• sshd
• sudo
• PAM
• CUPS
• apache httpd
• bash, zsh

Another capability is background task management on MacOS that monitors tasks for compliance ensuring only the tasks you want to run are actually running. You can see the payload below showing the uid, path, label, program, etc:

A third feature announced is monitoring FileVault state on MacOS with their new status item: diskmanagement.filevault.enabled.

DDM Identity Management

A long-time issue we have dealt with is referencing certificates in profiles, which often requires duplication or over-complication, which is just gross:

A huge change coming now in DDM, is that you can now declare certificates and identities as assets.

Configurations will be able to reference those assets substantially simplifying your stack.

Additionally, they have eliminated polling for SCEP/ACME, which is another huge improvement for users.

The new credential assets (credential.certificate) supports either PEM or DER whereas the (credential.identity, credential.scep, or credential.acme) supports PKCS #12, or being provisioned via ACME or SCEP.

We also have a new status item called security.certificate.list to power this:

The new security configurations can be used to install these items:

• com.apple.configuration.security.certificate
• com.apple.configuration.security.identity
• Certificates and Identities will be referenced by an asset and root certificates are put in the trust store.

A Few Other DDM Updates

• DDM powers this with a new configuration com.apple.configuration.security.passkey.attestation that references an identity asset.
• S/MIME is available for Mail and Exchange accounts leveraging identity assets for signing/encryption on iOS/iPadOS.
• DDM now supports assuming management of existing MDM profiles by essentially repushing the same profile (sort of how assume management of apps works today)

Introducing Apple Watch Device Management

Our final feature to cover is the new management of Apple Watches. A few items to consider. I strongly suggest checking out the protocol reference guide if you need deeper info:

• iPhone and Apple Watch will be managed together
• Apps/Restrictions can be shared
• Enrollments starts on the iPhone and requires supervision
• Apple Watch will be paired as a new device (requires Watch reset)
• Requires DDM

Apple Watch Enrollment

The flow is basically a configuration sent down to the device requiring any Apple Watch to be enrolled. It looks like this:

Looks like this:

It delivers a secure enrollment process verifying the device and the watch and their MDM leveraging anchor certificates. The 403 you will see is because the watch pairing token is missing!

A little check-in request occurs:

The actual request looks like this:

The token is sent back to the iPhone:

A base-64 encoded token contens looks like this:

Once the watch receives the pairing token, its then added to the watch’s machine info and sent via an enrollment request:

The payload looks like this:

The profile is sent back to the watch and a successful enrollment/pairing occurs. The final steps of that flow work the exact same way as a phone. One final note is that all Apple Watches are supervised once enrolled.

DDM and Apple Watch

There are several profiles types supported:

• APN
• Cellular
• Certificates
• Certificate Transparency
• MDM
• Notification Settings
• Password Policy
• Restrictions
• SCEP and ACME
• Per-App VPN
• Wi-Fi

Additionally some MDM commands and queries as well:

• App Commands
• Certificate List Query
• Clear Passcode
• Erase Device
• Declarative Management
• Device Info Query
• Device Lock
• Management Settings
• Profile Commands
• Restrictions Query
• Security Info Query

The one that was really interesting is the addition of Wi-Fi and Per-App VPN on the Watch.

One of the difficult things is if you require alphanumeric passcodes, you will only be able to use your Phone to unlock your Apple Watch. They also point out the directionality that Passcode and Restrictions policies are not synchronized back to the iPhone.

You can clearly see why they want declarative device management here to ensure the Watch isn’t setting a ton of data back to your MDM server.

The unenrollment is something of interest that people should take note of a few things:

• MDM break on the Watch will unpair and erase the Apple Watch
• This doesn’t effect the iPhone
• iPhone unenrollment will also unenroll the Watch

Apple Watch App Deployments

We have a few different app types:

• Apps paired from the iPhone
• Apps that depend on the iPhone
• Standalone apps on the Apple Watch

Paired and dependent apps require 2 app installation calls, whereas standalone only requires one:

Closing Thoughts on WWDC 2023

I think the overall sentiment that I get from WWDC 2023 is that MDM developers cannot keep saying “well that capability isn’t really ready for the primetime yet.”

With the enhancements to DDM, User Enrollment, Managed Apple IDs, and the introduction of new tech like the Passkey it’s obviously of Apple’s transformation. A long time ago, the sentiment was that people would never use Apple because they weren’t “for business like BlackBerry is.”

Now, I would say they are not that far off. They continue to evolve and deliver capabilities that matter. I especially think their new way of handling patching in DDM will be revolutionary on platforms like MacOS where patching has been a mess.

MDMs like Intune/Workspace ONE/JAMF, etc. to get ready for September and actually be ready from Day One. Intune shocked people by being the first to adopt DDM amazingly, and everyone is going to need to deliver on Device-Driven User Enrollment and all of these new capabilities. It’s time for users to win while balancing their experience against best-in-class security and payload delivery.