We have discovered that the issue also begins to occur after upgrading to macOS 15.8 and 26.7. Therefore, the affected macOS versions are 15.8 and later, 26.7 and later, as well as 27.0 and later.

During a more detailed investigation of the issue, I’ve found that code signature verification fails with an ELOOP (62) error: amfid: (Security) [com.apple.securityd:security_exception] UNIX error exception: 62 I also tried to verify the code signature of the target plugin bundle after it had been copied by the installer into its temporary directory: codesign -vvv /private/tmp/com.apple.installerXBGBPjSU/KLNagentInstallPlugin.bundle This produces the same error: /private/tmp/com.apple.installerXBGBPjSU/KLNagentInstallPlugin.bundle: Too many levels of symbolic links Further investigation showed that most of the contents of the plugin bundle's Contents directory are symbolic links to another temporary directory, with the exception of the MacOS directory: ls -l /private/tmp/com.apple.installerXBGBPjSU/KLNagentInstallPlugin.bundle/Contents total 0 lrwxr-xr-x 1 test wheel 128 26 Aug 11:24 _CodeSignature -> /var/folders/7v/rk69xf7d6f7f14rdtl823b0r0000gn/T/com.apple.install.a5sSNybs/KLNagentInstallPlugin.bundle/Contents/_CodeSignature lrwxr-xr-x 1 test wheel 124 26 Aug 11:24 Info.plist -> /var/folders/7v/rk69xf7d6f7f14rdtl823b0r0000gn/T/com.apple.install.a5sSNybs/KLNagentInstallPlugin.bundle/Contents/Info.plist drwxr-xr-x 3 test wheel 96 26 Aug 11:24 MacOS lrwxr-xr-x 1 test wheel 123 26 Aug 11:24 Resources -> /var/folders/7v/rk69xf7d6f7f14rdtl823b0r0000gn/T/com.apple.install.a5sSNybs/KLNagentInstallPlugin.bundle/Contents/Resources It appears that change in how the installer deploys the plugin bundle breaks code signature verification. To provide additional context, I’ve found publicly available installer packages from other vendors that contain installer plugins with a similar structure and they also have the same issue. For example, Avast's macOS installer package contains an installer plugin as well: https://www.avast.com/free-mac-security#mac. This suggests that the issue may not be specific to our installer package and could potentially affect other third-party installer plugins as well.

[quote='902472022, DTS Engineer, /thread/842811?answerId=902472022#902472022'] Earlier versions of macOS 27 beta? [/quote] Yes, all work fine on earlier versions of macOS 27 - beta 4 and below (including macOS 26). Things started to go wrong on 27.0b5.

We have filed feedback - FB19729313. Thank you for your attention to this request. We appreciate your consideration.

[quote='891544022, Apple Staff, /thread/831690?answerId=891544022#891544022'] Thanks for the additional detail. Is the goal for these devices to only be allowed to join managed Wi-Fi networks, similar to the current iOS-only restriction forceWiFiToAllowedNetworksOnly ? [/quote] Yes, our goal is to provide functionality similar to forceWiFiToAllowedNetworksOnly. Since we are developing a cross-platform device management solution, it would be highly beneficial for our customers to be able to configure and enforce Wi-Fi network restrictions for all managed devices from a single management platform, rather than using platform-specific configurations.

We've described our scenarios in FB22874828. Thank you!

I think you can rely on the corresponding Endpoint Security notification event that arrives right after the auth event. In particular, for an unlink operation, you should look at the corresponding es_message_t where action_type is ES_ACTION_TYPE_NOTIFY and action.notify.result_type is ES_RESULT_TYPE_AUTH. In that message, action.auth.result will tell you whether the operation was allowed, and you should check that it is ES_AUTH_RESULT_ALLOW.

Thank you for the suggestion. We have already submitted feedback through Feedback Assistant (FB13452950). We are posting here to seek additional guidance on any supported solutions, recommended approaches, or future platform direction for enterprise security products that need to monitor when third-party applications create listening network sockets.

Thank you for the suggestion. We have already submitted feedback through Feedback Assistant (FB10287547). We are posting here to seek additional guidance on any supported solutions, recommended approaches, or future platform direction for enterprise security products that need to manage camera access authorization (or at least notifications).

It turns out that these limits for Network Extension allow one application to impact the performance of others. A misbehaving application can open more than 512 long-lived connections and, when an NETransparentProxyProvider is active, effectively block network connectivity for other applications.

[quote='891420022, Apple Staff, /thread/831690?answerId=891420022#891420022'] Details on why the SSID is required and other kinds of network resource availability checks can't be used would be especially helpful. [/quote] Enterprise customers are requesting functionality to control Wi-Fi usage in order to restrict devices to only specific Wi-Fi networks.

Hi! You can find info about USB support in the latest WWDC26 session.

It seems that VZVirtualMachine.state is a KVO property. So you can add an observer and get notifications when the virtual machine state changes.

I've created a feedback FB22967193.

Hi! I believe that the key is tied to your app via its App ID entitlement. I’ve never really looked into the details, but the research that I did do confirmed that there’s no supported way to serialise a key in one app and deserialise it another. From my testing, that does not appear to be the case for keys created with: let privateKey = try SecureEnclave.P256.KeyAgreement.PrivateKey(/*default params*/) Having "dataRepresentation" of the privateKey another process can use it for sign/decrypt — even when that second process is signed with a different Team ID, or is unsigned entirely. The process that originally creates the key is properly signed with my Team ID and has the keychain-access-groups entitlement. SIP is also enabled. Based on these experiments, it seems that SecureEnclave keys are not intrinsically bound to the originating app or signing identity, and isolation from other apps may be enforced primarily through Keychain access controls.