Hi! We're developing a security product that uses both EndpointSecurity.framework to intercept and authorize process and file events; and NetworkExtension.framework o intercept and inspect network connections. We're occasionally seeing crashes caused by Endpoint Security timeouts. After investigating several crash reports, we believe we've identified a deadlock involving code signature verification: our Network Extension intercepts connections initiated by nsurlsessiond to retrieve OCSP/CRL data (we believe these requests are made on behalf of trustd during code signature validation). To determine which policy should be applied to an intercepted connection, our Network Extension verifies the code signature of the originating process. However, that code signature verification itself blocks while waiting for the OCSP/CRL requests to complete. Since those requests are being intercepted by our Network Extension, we end up with a circular dependency: A process requires code signature verification. Signature verification triggers OCSP/CRL network requests. Those requests are intercepted by our Network Extension. Our Network Extension attempts to verify the initiator's code signature before allowing the connection. That verification waits for the same OCSP/CRL requests to complete. As a result, code signature verification becomes blocked process-wide, including verification performed while handling Endpoint Security events. Eventually, our Endpoint Security client exceeds the allowed response timeout and is terminated. We're considering bypassing interception for OCSP/CRL traffic to avoid this deadlock, but we'd like to understand whether this is the recommended or most robust approach. Questions Is there a reliable way to identify network connections that are fetching OCSP or CRL data for code signature validation? What is the relationship between trustd and nsurlsessiond for these requests? Is there a dedicated nsurlsessiond instance serving trustd, or are these requests performed by the shared system/session-wide nsurlsessiond? Would it be a reasonable and future-proof approach to identify these requests by checking NEAppProxyFlow.remoteHostname (for example, ocsp.apple.com and crl.apple.com) and bypassing interception for those connections? Is there another recommended approach to avoid this deadlock when combining Endpoint Security and Network Extension in this way? Any guidance or best practices would be greatly appreciated. Thank you!

When running a macOS virtual machine using Virtualization.framework, I am encountering a reproducible issue where the kernel’s internal VM slot counter (hv_apple_isa_vm_quota) is not decremented after a guest-initiated shutdown. This leads to subsequent VM launches failing with VZErrorVirtualMachineLimitExceeded, even though no active VMs appear to be running. Steps to Reproduce: Create a valid VZVirtualMachineConfiguration for a macOS guest Initialize and start a VZVirtualMachine instance Inside the guest macOS, perform a normal shutdown (Apple menu → Shut Down) Wait until VZVirtualMachine.state becomes .stopped Attempt to start the same VZVirtualMachine instance again Expected Behavior: The VM should restart successfully.
The kernel should release the VM slot once the guest shuts down, allowing a new VM instance to start without requiring any host-side intervention. Actual Behavior: start() fails with: Domain: VZErrorDomain Code: 6 (VZErrorVirtualMachineLimitExceeded) Description: “The number of virtual machines exceeds the limit. The maximum supported number of active virtual machines has been reached.” Despite the VM reporting .stopped, the system continues to behave as if a slot is still allocated. Workarounds Tested: The following approaches did not resolve the issue: Releasing and recreating the VZVirtualMachine instance Introducing delays (5s, 30s, 60s) before restarting Terminating all processes related to Virtualization.framework The only reliable recovery is a full macOS host reboot, which resets the VM quota state. Environment: macOS 26.5 (Tahoe) Apple Silicon: M4 Max Virtualization.framework (system-provided) Impact: This issue makes reliable VM lifecycle management difficult for applications relying on Virtualization.framework (e.g., UTM and similar tools). In automated environments (CI/CD, testing pipelines), it can cause persistent VM launch failures and require full host reboots, interrupting all workloads. Suspected Issue: It appears the kernel VM slot counter (hv_apple_isa_vm_quota) is not consistently decremented when a VM exits via guest-initiated shutdown, despite the VZVirtualMachine transitioning to .stopped. This suggests a race condition or missing cleanup path in the shutdown lifecycle handling. Request: Could you confirm whether this is a known issue or expected behavior, and whether there is a recommended API-level workaround to ensure VM slot cleanup after guest shutdown?

We are developing an enterprise security solution for macOS that includes Wi-Fi awareness and network-based policy enforcement - WiFi Control. On current macOS releases, access to the connected Wi-Fi's SSID/BSSID appears to require Location Services authorization. In many corporate environments, end users do not have local administrator privileges and cannot enable Location Services themselves. Enabling it often requires coordination with IT administrators, which can be difficult to scale in large organizations with a geographically distributed workspace. This creates a deployment challenge for enterprise security products because network identification becomes unavailable on managed Macs, even when the device is enrolled and managed through MDM. As far as we understand: MDM on macOS does not provide a mechanism equivalent to managed-device Wi-Fi control available in iOS management scenarios. System Extension running with elevated privileges cannot obtain the current SSID/BSSID through frameworks such as CoreWLAN even when Location Services access is granted (it requires user session). Our questions are: Is there currently any supported API or entitlement that allows enterprise security products to determine the currently connected SSID/BSSID on managed macOS devices without requiring end users to enable Location Services? Are there plans to provide a managed-device exception, entitlement, or MDM-controlled authorization model for enterprise security vendors that need network identity information for security and compliance use cases? Would Apple consider exposing SSID/BSSID information to approved System Extensions or Endpoint Security-based products in managed corporate environments, while maintaining existing privacy protections for consumer devices? We fully understand the privacy rationale behind restricting Wi-Fi information, but enterprise security and compliance solutions often need to identify trusted and untrusted networks. Today, the Location Services dependency significantly complicates deployment and usability in managed corporate environments. Any guidance on recommended approaches or future platform direction would be greatly appreciated.

Since macOS 14, accessing the current Wi-Fi SSID through CoreWLAN.framework requires both: Location Services to be enabled at the system level. Location permission to be granted to the application. For enterprise security and device-management solutions, this creates a deployment challenge because enabling Location Services system-wide requires administrator privileges and user interaction. Some enterprise use cases, such as Wi-Fi policy enforcement, network compliance, and location-aware security controls, depend on reliable access to the current SSID. On managed Macs, administrators currently have no MDM mechanism to enable Location Services system-wide or pre-authorize location access for specific applications. I reviewed the WWDC26 session "What's New in Managing Apple Devices" and the discussion of the new consolidated privacy consent experience. However, I did not find any new MDM capabilities that address Location Services management for specific apps. Questions: Are there any current MDM payloads or APIs that allow administrators to enable Location Services on supervised/managed Macs? Are there any recommended alternatives for enterprise applications that need access to Wi-Fi SSID information on managed devices? Is Apple considering future MDM enhancements that would allow administrators to enable Location Services and/or grant location access to specific applications in managed enterprise environments? Any guidance on Apple's direction in this area would be appreciated.

I'm implementing a NETransparentProxyProvider and trying to preserve the original TCP connection semantics as transparently as possible. The current API of NEAppProxyTCPFlow appears not to provide a way to distinguish between the following situations: The client has performed a half-close by calling shutdown(SHUT_WR) (i.e. closed only its write side). The client has fully closed the socket/connection. When readData(completionHandler:) returns empty data, indicating EOF, I cannot determine which of the two cases above has occurred. This creates a problem when forwarding the connection to the upstream server. Upon receiving empty data from the flow, should the corresponding server-side connection: Perform a half-close (close only the write side / send FIN)? Be fully closed? Currently, I always perform a half-close on the server-side connection. While this almost preserves the original flow semantics, it can lead to leaked connections, since the upstream connection may remain in FIN_WAIT_2 indefinitely. Is there any supported way to determine whether the originating connection was half-closed or fully closed? If not, what is the recommended approach for implementing a transparent TCP proxy that needs to accurately preserve TCP shutdown semantics? Any guidance would be appreciated.

Enterprise security products often need to establish trust for a locally generated root CA in order to implement features such as web filtering, traffic inspection, data loss prevention, or compliance controls. Our solution generates a unique CA certificate and private key on each managed Mac. The application then issues leaf certificates as needed and signs them with the device-specific CA. Using a unique CA per device helps avoid the security risks associated with deploying a shared CA private key across all managed endpoints. However, since macOS Big Sur, modifying trust settings for certificates in the System keychain (for example, setting a root CA to Always Trust) requires user interaction and administrator authorization. Even privileged processes cannot silently establish trust for a newly installed root CA. This creates deployment challenges in enterprise environments, particularly when: End users do not have administrator privileges. The CA must be unique per device. The private key must remain accessible to the security application while being protected from other applications. We have considered several approaches, but each appears to have significant limitations: Shared CA across all devices: introduces risk because compromise of the private key affects the entire fleet. Per-device PKCS#12 deployment with private key accessible: other local processes may be able to use the key. Per-device PKCS#12 deployment with private key protected: application access may require additional user approval, reducing deployment automation. Questions: Is there an MDM-supported mechanism for establishing trust for a device-specific root CA without requiring local administrator interaction? Are there recommended enterprise deployment patterns for applications that need both: a device-specific CA private key, and trusted root status for the corresponding CA certificate? Are there plans to expand MDM capabilities related to certificate trust management or keychain trust settings for managed Macs? What is Apple's recommended approach for enterprise security products that need to deploy device-specific trusted CAs while maintaining strong protection of the associated private keys?

Are there any plans to add Endpoint Security support for intercepting or observing listen() calls, so SIEM and EDR products can reliably monitor when processes begin accepting inbound network connections?

Are there any plans to add camera-access or camera-activation events to EndpointSecurity.framework, so security products (like SIEM/EDR) can reliably detect when applications start or stop using the camera without relying on private APIs or log monitoring?

We have observed a per-process limitation on the number of simultaneous nw_connection_t objects in certain macOS environments. On some systems, this limit does not appear to apply, but on others the limitation is reproducible. When a process attempts to establish a large number of connections (e.g. 512+), some connections enter the nw_connection_state_waiting state and report the POSIX error “Cannot allocate memory”. These connections remain stuck indefinitely, even after other connections are deallocated and resources should theoretically be available again. This behavior severely impacts use cases such as transparent proxies implemented via the NetworkExtension framework, which intercept system-wide traffic and must open connections on behalf of all client processes. In this scenario, a per-process limit effectively becomes a system-wide limit, leading to unexpected and hard-to-diagnose network failures in client applications. Can we expect a relaxation of these restrictions for network extensions in the future? Could you please suggest some workarounds to bypass the restriction? By the way, now we have to fallback to BSD socket implementation of the outgoing connections, possibly braking the chain of TransparentProxies as the second proxy in the chain can’t get the originator of the intercepted flow (it sees the first proxy instead).

I am developing a library called MemoryCryptor for macOS. Its purpose is to protect sensitive data of the calling process (including launchd daemons), e.g. user passwords and other secrets, from being written to disk or read directly by debuggers or malware. This is a mandatory security requirement from our internal Security Team. On Windows we rely on DPAPI, which stores a per‑process cryptographic key outside the calling process’s address space, ensuring that key material and ciphertext never coexist in the same memory space. I have evaluated the following macOS options, but each presents limitations for our threat model: Secure Enclave (CryptoKit.framework). Keys generated using the Secure Enclave are not bound to the creating app. The dataRepresentation of a PrivateKey resides in the caller’s memory, allowing another process that can read a memory dump on the same machine to decrypt the data. Keychain API. Keys are always loaded into the calling process’s address space before any cryptographic operation, exposing them to memory‑dump attacks. Separate helper via XPC. While this could isolate key material, it requires full control of IPC implementation - plaintext may remain in the implementation's internal buffers. Given these constraints, are there any macOS‑native mechanisms or recommended architectures that allow us to keep cryptographic keys completely out of the calling process’s memory while still performing encryption/decryption on behalf of that process? Any guidance, best‑practice references, or alternative APIs would be greatly appreciated. Thank you for your assistance.

We have observed a per-process limitation on the number of simultaneous nw_connection_t objects in certain macOS environments. On some systems, this limit does not appear to apply, but on others the limitation is reproducible. When a process attempts to establish a large number of connections (e.g. 512+), some connections enter the nw_connection_state_waiting state and report the POSIX error “Cannot allocate memory”. These connections remain stuck indefinitely, even after other connections are deallocated and resources should theoretically be available again. This behavior severely impacts use cases such as transparent proxies implemented via the NetworkExtension framework, which intercept system-wide traffic and must open connections on behalf of all client processes. In this scenario, a per-process limit effectively becomes a system-wide limit, leading to unexpected and hard-to-diagnose network failures in client applications. So, is there any way to disable this restriction for Network Extension processes? Are there any system settings that could affect this limitation and be modified by users?

We are looking for a solution (API, Frameworks) that would allow us to block any type of external device, including storage devices, HIDs, network adapters, and Bluetooth devices according with dynamic rules that comes from management server . This feature is important for endpoint security solutions vendors, and it can be implemented on other platforms and older versions of macOS using the IOKit framework and kexts. I have found one solution that can control the usage only of "storage" devices with the EndpointSecurity framework in conjunction with the DiskArbitration framework. This involves monitoring the MOUNT and OPEN events for /dev/disk files, checking for devices as they appear, and ejecting them if they need to be blocked.. Also, I have found the ES_EVENT_TYPE_AUTH_IOKIT_OPEN event in EndpointSecurity.framework, but it doesn't seem to be useful, at least not for my purposes, because ES doesn't provide AUTH events for some system daemons, such as configd (it only provides NOTIFY events). Furthermore, there are other ways to communicate with devices and their drivers apart from IOKit. DriverKit.framework does not provide the necessary functionality either, as it requires specific entitlements that are only available to certain vendors and devices. Therefore, it cannot be used to create universal drivers for all devices, which should be blocked. Any advice would be greatly appreciated!

I'm trying to restore an APFS volume to its previous state using a snapshot created with the tmutil command. The only native Apple tool I've found for this purpose is apfs.util. According to the documentation, the correct command for this task is /System/Library/Filesystems/apfs.fs/Contents/Resources/apfs.util -R </dev/diskXsY>. However, this command is not working for me. It returns the error "No such file or directory" for any existing . If I use a valid file/dir path instead of the as an experiment, I get an "Invalid argument" error. To investigate the issue, I decided to debug apfs.util and found that the fsctl() function is responsible for these errors (ENOENT and EINVAL). The first argument passed to fsctl() is the (or file/dir path in my experiment), and the second argument is the value 0x80084A01, which corresponds to the APFSIOC_REVERT_TO_SNAPSHOT command according to xnu's source code (https://github.com/apple-oss-distributions/xnu/blob/8d741a5de7ff4191bf97d57b9f54c2f6d4a15585/bsd/vfs/vfs_syscalls.c#L174). It seems that this command is not supported by the latest versions of macOS (see https://github.com/apple-oss-distributions/xnu/blob/8d741a5de7ff4191bf97d57b9f54c2f6d4a15585/bsd/vfs/vfs_syscalls.c#L12984) and always returns EINVAL error. Is this correct? Are there any other tools available that can be used to revert APFS snapshots?

Starting with macOS Sequoia Beta, a new "Local Network Privacy” feature was introduced, which had previously been present in iOS. Unfortunately, there is little information about this topic on the Apple developer website, especially for the macOS platform. I conducted some experiments to understand the new feature, but was confused by the results. Firstly, I noticed that the type of application accessing the local network in macOS matters - bundled or command-line (CLI) applications. The TCC subsystem does not restrict access to the local network for CLI applications at all, regardless of how they are launched - as a launchd daemon with root privileges, or through a terminal with standard user privileges. At the same time, access to the local network for bundled applications is controlled by the TCC subsystem at most cases. Upon the first request, the system will display an alert to the user explaining the purpose of using the local network. Then, communication with local network devices will be allowed or restricted based on whether consent has been granted or revoked. Secondly, it's worth noting that if the bundled application supports CLI mode (launched through the terminal without a GUI), it will be able to access the local network in that mode regardless of the “Local Network Access” consent state if it has been granted at least once. However, if the same application is in GUI mode, its access to the local network will be limited by the current consent. Is this behaviour correct and likely to remain the same in future releases of macOS Sequoia? Or is there something described here that is incorrect and will be fixed in the upcoming betas? Also, I have posted FB14581221 on this topic with the results of my experiments.

Starting with macOS 15, the Local Network Privacy (LNP) feature has been introduced, which has been available on iOS for some time. We are developing an enterprise application for remote control and protection of corporate devices. The management is carried out using a dedicated server, usually located on the internal LAN of the enterprise. In order to interact with this server, devices require access to the local network, which is managed by the new TCC LNP. The UX of our application involves minimal user interaction. To address this issue, we use Apple's MDM to automatically grant various permissions. Additionally, we have scripts for remotely installing the application and configuring it. However, for the new TCC LNP, we have not found a way to do this through the MDM profile. Does Apple intend to incorporate the relevant functionality into the MDM? There are several posts on the dev forum about this topic, but they are all about iOS.