Posted on by MichalM.Mac

State of network DDM configurations in Apple OS release 27

In What’s new in managing Apple devices WWDC 2026 video, the presenter empathizes that Device Declarative Management is no longer the future of Apple Device Management but the standard of Apple Device Management. Let’s look at Declarative Device Management (DDM) changes in Apple OS release 27 to see how this claim fares in reality.

One blog post covering all configuration areas would be too long, so let’s scope it down and focus just on network-related config. Two reasons: First, I like network config. Second, in Apple OS release 27, network-related declarative configurations are being expanded quite a lot.

VPN configurations

VPN configuration profile payload com.apple.vpn.managed is probably the most complex payload of them all. It allows admins to configure one of several VPN types and additional network settings related to VPN (DNS, proxy, always-on, etc.).

Let’s take a look at how Apple handles the VPN in declarative configuration. There is no longer a single VPN configuration object with several VPN subtypes. Instead, each VPN type has its own configuration object:

  • network.vpn.ikev2 – Built-in VPN client for generic IKEv2 IPSec VPN
  • network.vpn.always-on – IKEv2 in always-on mode
  • network.vpn.ipsec – Built-in VPN client for (Cisco) IKEv1 IPSec VPN with XAuth support
  • network.vpn.vpn-plugin – VPN functionality facilitated via 3rd party vendor client
  • network.relay – special type of proxy that can be used for remote access and privacy solutions

IKEv2 IPSec

Let’s take a deeper look at network.vpn.ikev2.

Simple configuration example:

{
    "Type": "com.apple.configuration.network.vpn.ikev2",
    "Identifier": "EB13EE2B-5D63-4EBA-810F-5B81D07F5017",
    "ServerToken": "E180CA9A-F089-4FA3-BBDF-94CC159C4AE8",
    "Payload": {
        "VisibleName": "Corporate IKEv2 VPN",
        "HostName": "vpn.example.com",
        "LocalIdentifier": "device@example.com",
        "RemoteIdentifier": "vpn.example.com",
        "Authentication": {
            "Method": "SharedSecret",
            "CredentialsAssetReference": "64BF8F5C-8CFD-40AA-9082-A0B594D4E100"
        }
    }
}

In DDM there are no secrets embedded in the configuration. Instead there are references to asset objects.

Apple has done a nice clean up in the configuration structure. Following objects in the declarative configuration aggregate several keys previously found in profile payload VPN.IKEv2 object. Some of the nested configuration keys have been renamed:

  • Authentication:
    • CredentialsAssetReference (Password)
    • ExtendedAuth
      • CredentialsAssetReference (AuthName and AuthPassword)
      • Enabled (ExtendedAuthEnabled)
      • ServerCertificateCommonName (ServerCertificateCommonName)
      • ServerCertificateIssuerCommonName (ServerCertificateIssuerCommonName)
      • TLSMaximumVersion (TLSMaximumVersion)
      • TLSMinimumVersion (TLSMinimumVersion)
    • IdentityAssetReference (PayloadCertificateUUID)
    • IdentityCertificateType (CertificateType)
    • Method (from AuthenticationMethod)
  • Idle:
    • DeadPeerDetectionRate
    • Disconnect (DisconnectOnIdle)
    • Timer (DisconnectOnIdleTimer)
  • NetworkRouting
    • EnforceRoutes
    • ExcludeAPNs
    • ExcludeCellularServices
    • ExcludeDeviceCommunication
    • ExcludeLocalNetworks
    • IncludeAllNetworks
  • OnDemand:
    • Enabled (OnDemandEnabled)
    • DisableUserOverride (OnDemandUserOverrideDisabled)
    • Rules (OnDemandRules)
  • PostQuantumKeyExchange:
    • AllowFallback (AllowPostQuantumKeyExchangeFallback)
    • PPK
    • PPKIdentifier
    • PPKMandatory

VisibleName was renamed from UserDefinedName key previously found in VPN object.

VPN.DNS object is now a VPN object with some of its child keys renamed:

  • IdentityAssetReference (PayloadCertificateUUID)
  • Protocol (DNSProtocol)

VPN.Proxies object exists as Proxies object

There appears to be no changes in the functionality but the configuration structure and naming is much better. Apple had a rare opportunity to streamline configuration which was built up in layers since 15 years ago.

Other VPN types

network.vpn.ipsec has been restructured in a way similar to network.vpn.ikev2. For example all the XAuth key previously present in VPN.IPSec now live in a nested object: network.vpn.ipsec -> Authentication -> XAuth.

network.vpn.always-on configuration is pretty much the same as VPN.AlwaysOn with VPN.DNS and VPN.Proxies objects folded in.

network.vpn.vpn-plugin configuration reorganizes keys relevant for 3rd party VPN clients. Functionality appears to be exactly the same.

network.relay configuration is exactly the same as Relay profile payload object.

There is no L2TP/IPSec configuration. While Apple might not have officially deprecated this type (yet), my opinion is that it should be treated as such, and it is unlikely to be added to DDM.

The second missing VPN type is TransparentProxy, which was introduced in macOS 14. Perhaps this one was not prioritized since it works only on one platform.

App layer VPN configurable with AppLayerVPN and AppToAppLayerVPNMapping profile payloads are nowhere to be found in DDM configurations.

Network interfaces

There is still no declarative configuration for Cellular, CellularPrivateNetwork, Ethernet and Wi-Fi 🥺

This is especially disappointing for networks with Enterprise authentication since one of the best things about DDM design is the separation of user credentials and actual configuration into two different objects. The goal is for credentials (e.g. client certificate) to be deployed as assets while the actual config (e.g. Wi-Fi configuration) is deployed as a configuration. Dependencies can be created between the two classes of objects (Wi-Fi config requires a client cert for authentication).

With the traditional profile-based configuration deployment, credentials and configurations need to be deployed as payloads within a single configuration profile. A typical example would be a single SCEP payload providing a client certificate and several network configuration payloads (Wi-Fi, Ethernet, VPN) referencing the SCEP payload in order to automatically use the client certificate. This tight dependency means that the profile needs to be deployed and updated as a single unit. Admins need to be really careful since a problem within a single payload (e.g. VPN) prevents the whole profile from being installed.

The DDM approach is much more flexible. Each piece could be deployed and updated independently. In practice, the admin could successfully deploy ACME asset providing a client certificate for Ethernet, Wi-Fi, and VPN configurations. A possible problem in VPN configuration wouldn’t affect the rest.

So perhaps next year.

Other network configurations

ContentCachingService profile payload is being deprecated in macOS 27 and will be possibly removed in macOS 28. com.apple.configuration.content-cache.settings declaration is supposed to be used instead. Good riddance!

network.dns-settings configuration is exactly the same as DNSSettings profile payload object.

network.dns-proxy configuration is exactly the same as DNSProxy profile payload object.

There is no declarative configuration equivalent for following profile payloads:

Conclusion

In Apple OS release 27, a decent chunk of network-related settings has been added to declarative configurations. Unfortunately, a big part is still missing. The most glaring omission is the absence of configurations for network interfaces.

In my opinion, DDM can’t be considered the standard way to configure networks on Apple devices at this time. We are probably many years away from DDM truly becoming the standard.

Here is an optimistic timeline:

  1. Apple adds the major missing functionality to the DDM spec with OS release 28 (late 2027).
  2. It takes at least a year for Apple to fix bugs and make the DDM network settings usable in production (late 2028).
  3. MDM vendors finally start migrating network config from profiles to DDM (2029-2030).