We would like to verify whether Apple’s Network Framework—which enables the creation of network connections to send and receive data using transport and security protocols—is FIPS 140-3 compliant.

I've been implementing App Attest on macOS 27 following the WWDC 2026 Session 201 announcement. DCAppAttestService.shared.isSupported always returns false on my M4 Mac running macOS 27.0 (26A5368g), even with the correct entitlement and a valid provisioning profile. What I have set up (correctly, as far as I can tell) com.apple.developer.devicecheck.app-attest-opt-in capability enabled in the Developer Portal (value CDhash) Entitlement present in both the binary and the embedded provisioning profile Developer ID signed, ProvisionsAllDevices: true The problem DCAppAttestService.shared.isSupported returns false from every process type I tested: An EndpointSecurity system extension A launchd daemon A sandboxed app running in user session generateKey() fails with com.apple.devicecheck.error code 1 (featureUnsupported). Root cause? (from devicecheckd logs) I see these logs devicecheckd: [com.apple.devicecheck:aai] FeatureFlagsManager.m:35 Mac feature flag enabled { enabled=1 }. devicecheckd: (AppAttestInternal) [com.apple.appattest:secl] SecurityController.swift:44 Failed to fetch value for entitlement. { entitlement=com.apple.devicecheck.daemon-client } devicecheckd: (AppAttestInternal) [com.apple.appattest:aahl] AppAttestHandler.swift:48 Client connection is ineligible. { clientUUID=nil } So the feature IS active in macOS 27 (Mac feature flag enabled=1), but devicecheckd immediately rejects any connecting process that doesn't hold the private entitlement com.apple.devicecheck.daemon-client. What is com.apple.devicecheck.daemon-client? Searching public entitlement databases shows this entitlement exists on iOSbut no macOS binary appears to hold it in any public database. It's not available to third-party developers via the Developer Portal. This check in SecurityController.swift:44 appears to be new in this beta. Questions Is com.apple.devicecheck.daemon-client the correct mechanism for third-party developers to use App Attest on macOS 27, or is this an internal gating mechanism that will be replaced/removed before GM? Is App Attest on macOS 27 fully available to third-party developers in this seed, or is it still restricted to Apple-internal testing? Is there a different entitlement or provisioning capability that third-party developers should request to allow DCAppAttestService.isSupported to return true?

We have a custom SecurityAgentPlugin that is triggered by multiple authorizationdb entries. Some customers report that the SecurityAgent process takes window focus even though no UI or windows are displayed. Our plugin explicitly ignores the _securityAgent user and does not show any UI for that user. However, in macOS 26.1, it appears that the plugin still causes the SecurityAgent to take focus as soon as it is triggered. Is this a change in macOS 26.1 or a bug? Can we do anything to prevent "focus stealing"?

I am developing a macOS system service (standalone binary running as a LaunchDaemon) that requires the ability to sign data using a private key which will be deployed via MDM. The Setup: Deployment: A .mobileconfig pushes a PKCS12 identity to the System Keychain. Security Requirement: For compliance and security reasons, we cannot set AllowAllAppsAccess to <true/>. The key must remain restricted. The Goal: I need to use the private key from the identity to be able to sign the data The Problem: The Certificate Payload does not support a TrustedApplications or AccessControl array to pre-authorize binary paths. As a result, when the process tries to use the private key for signing (SecKeyCreateSignature), it prompts the user to allow this operation which creates a disruption and is not desired. What i've tried so far: Manually adding my process to the key's ACL in keychain access obviously works and prevents any prompts but this is not an "automatable" solution. Using security tool in a script to attempt to modify the ACL in an automated way, but that also asks user for password and is not seamless. The Question: Is there a documented, MDM-compatible way to inject a specific binary path into the ACL of a private key? If not, is there a better way to achieve the end goal?

Hello, Safari on iOS is showing a “Fraudulent Website Warning” for our domain: https://doobler.ru/ We are trying to understand how to properly diagnose this and request a re-evaluation. The website has a valid HTTPS certificate and does not currently appear to be flagged by the reputation tools we checked, including Google Safe Browsing / Search Console / VirusTotal. However, some iPhone users still see the Safari warning, while others do not. What we have checked so far: HTTPS certificate is valid No mixed-content or obvious redirect issues found Google Safe Browsing does not show the domain as unsafe Google Search Console does not show security issues VirusTotal does not show active malware/phishing detections The warning appears only for some users/devices We submitted a review request through Apple’s Website Review form, but have not received any response yet We would like to know: Is there any way to confirm whether the warning comes from Apple’s own reputation system, Google Safe Browsing, or another provider used by Safari? How long does Apple Website Review usually take for Safari fraudulent website warnings? Is there a recommended process for requesting re-evaluation if the warning appears to be a false positive? Are there specific technical signals Safari checks that we should verify, such as redirects, third-party scripts, domain reputation, or brand/phishing heuristics? This is affecting real users, so any guidance on the correct escalation or diagnostic path would be appreciated. Thank you.

Hello there, We’re currently integrating Apple Wallet pass functionality into our application and am looking for clarification around the automatic update flow. Particularly regarding secure management of the authenticationToken. We’ve reviewed the documentation here: Adding a Web Service to Update Passes authenticationToken Documentation From our understanding: When a user downloads a pass from our service, the .pkpass includes both a webServiceURL and an authenticationToken. Once the pass is added to Wallet, the Wallet app makes authenticated requests to our webServiceURL, using the token in the Authorization header. We then validate this token server-side to serve updates or handle device registration. So far, this flow is clear. However, we’re looking for clarification on two key scenarios: If a user adds the same pass twice on the same device, should the authenticationToken remain the same in both cases? If the same user adds the same pass on a different device, should the authenticationToken also remain consistent across devices? If the answer to both is “yes,” we assume that our backend must store the original authenticationToken in a retrievable form (not just as a hash) to regenerate the same pass for re-download or multi-device sync. Our main question is: What is Apple’s recommended or acceptable approach to storing authenticationToken values securely on the backend? Should these tokens be: Stored in plaintext (e.g. in a protected DB field)? Encrypted using a symmetric key? Hashed (not reversible, but limits reuse)? We want to ensure we align with Apple’s best practices for Wallet security and token management, especially in contexts where the same pass may be installed on multiple devices or reissued later.

Summary CLLocationSourceInformation.isSimulatedBySoftware (iOS 15+) fails to detect location spoofing when using third-party tools like LocaChange, despite Apple's documentation stating it should detect simulated locations. Environment iOS 18.0 (tested and confirmed) Physical device with Developer Mode enabled Third-party location spoofing tools (e.g., LocaChange etc.) Expected Behavior According to Apple's documentation, isSimulatedBySoftware should return true when: "if the system generated the location using on-device software simulation. " Actual Behavior Tested on iOS 18.0: When using LocaChange sourceInformation.isSimulatedBySoftware returns false This occurs even though the location is clearly being simulated. Steps to Reproduce Enable Developer Mode on iOS 18 device Connect device to Mac via USB Use LocaChange to spoof location to a different city/country In your app, request location updates and check CLLocation.sourceInformation?.isSimulatedBySoftware Observe that it returns false or sourceInformation is nil Compare with direct Xcode location simulation (Debug → Simulate Location) which correctly returns true

Dear Apple Team, I am reaching out regarding the need for more sophisticated location verification APIs beyond basic IP lookup capabilities. As online fraud continues to evolve, IP-based geolocation has proven insufficient for many business use cases requiring accurate location verification. Would it be possible to discuss this proposal with your API development team? I believe this would be valuable for the entire iOS and macOS developer ecosystem while maintaining Apple's commitment to user privacy.

When scanning a FIDO QR code within an iOS app—whether using a custom AVFoundation (AVCaptureSession) implementation or DataScannerViewController—the system displays a native OS confirmation prompt. However, scanning the same QR code using the native system Code Scanner bypasses this prompt entirely. As a developer: Is there a way to suppress or avoid this native prompt when using custom in-app scanners? Alternatively, can I programmatically invoke the system Code Scanner directly from my app and have it deep-link back to the app once the scan is complete?

Requesting com.apple.managed-keychain Entitlement for Enterprise S/MIME Cert Visibility Platform: iOS | Distribution: MDM (Microsoft Intune) | Not App Store We are developing an internal enterprise iOS app (EMS Assist, com.company.supportcompanion) for Company deployed exclusively to Intune-managed devices. Our requirement: Read S/MIME certificates pushed to the device via Intune SCEP profiles to: Confirm cert presence in the MDM-managed keychain Read expiry date (kSecAttrNotValidAfter) to warn users before expiry Distinguish between missing, expired, and valid cert states What we have tried: Standard SecItemCopyMatching query — returns only app-installed certs, not MDM-pushed certs Graph API (deviceConfigurationStates) — confirms profile compliance but does not expose actual cert expiry or keychain presence Our understanding: com.apple.managed-keychain is required for an app to access MDM-managed keychain items on supervised devices, combined with a matching keychain-access-groups entitlement and the cert profile configured as "always available" in MDM. Questions: Is com.apple.managed-keychain the correct entitlement for this use case? Does it apply to SCEP/PKCS-issued certificates specifically, or only other MDM keychain items? Has anyone successfully accessed Intune-pushed S/MIME certs from an iOS app using this entitlement? Any guidance from the community or Apple engineers would be appreciated.

Is anyone else seeing 403 errors for PCC VRE when trying to pull assets for Release 41303? My pccvre audit of the Transparency Log passes (valid root digests for 41385), but the download fails consistently on specific CDN URLs: Failed to download SW release asset... response: 403 I’ve verified csrutil allow-research-guests is active and the license is accepted. Release 41385 seems fine, but 41303 is a brick wall. Is this a known pull-back or a CDN permissions sync issue?

Hello i am developing an apple wallet coupon/store card integration and as each pass will hold sensitive data (tokens referencing access to the monetary amount) i am concerned of the security implications of having a passkit-pass in ios stored as well as in icloud. Documentation is scarce if the pass is also stored on apple servers. It seems to be stored at least temporarily for synching with other devices of the same icloud user. Can you give details to the kind of data, encryption, duration of persistence of the pass data on centralized apple servers? Best Regards

Hello, I am working on a DLP (Data Leak Prevention) agent which must programmatically install our custom Root CA certificate into the System Keychain with the "Always Trust" policy. This is required for our network inspection module. The installation process is currently handled by a LaunchDaemon. I am using the following command: security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain The certificate is successfully added to the System Keychain, but the "Always Trust" policy is completely ignored. The certificate remains untrusted until the user manually opens System Settings and explicitly changes the trust settings. Our DLP agent is specifically designed for environment where MDM is not present and we can not rely on MDM to push profiles. Is it officially possible to set "Always Trust" for certificate programmatically from a LaunchDaemon? Thank you in advance!

I need to programmatically configure TLSv1.3 control parameters like cipher suites, Named Groups Signature Scheme I can see in the apple development documentation, there is a option to configure cipher suites but no way to configure Named Groups and Signature Scheme. Does anyone know a way to configure "Named Groups" & "Signature Schemes" also ? or If it is not possible in iOS then also Do we have anywhere written in documentation (evidence) ?

I understand that with the 26.4.2 patch, when you click on a notification preview to check a text message, the saved preview data is deleted. So, what should I do to delete the preview data that was left over from clicking on notification previews before the 26.4.2 patch? First of all, I don't want to do a factory reset. So I'm just want to know about this.

Dear Apple Developer Support Team, I would like to inquire whether there is a stable and official method to obtain the correct Team ID. When my app attempts to store data in the Keychain on a physical device, the retrieved Team ID is an unknown one and does not match the Team ID of my developer certificate. This issue consistently results in Keychain access failure with error code -34018. Could you please advise the root cause and provide a reliable solution to fix this Team ID mismatch and resolve the -34018 Keychain error? NSDictionary *query = [NSDictionary dictionaryWithObjectsAndKeys: kSecClassGenericPassword, kSecClass, @"bundleSeedID", kSecAttrAccount, @"", kSecAttrService, (id)kCFBooleanTrue, kSecReturnAttributes, nil]; CFDictionaryRef result = nil; OSStatus status = SecItemCopyMatching((CFDictionaryRef)query, (CFTypeRef *)&result); if (status == errSecItemNotFound) status = SecItemAdd((CFDictionaryRef)query, (CFTypeRef *)&result); if (status != errSecSuccess) return nil; NSString *accessGroup = [(__bridge NSDictionary *)result objectForKey:kSecAttrAccessGroup]; NSArray *components = [accessGroup componentsSeparatedByString:@"."]; NSString *bundleSeedID = [[components objectEnumerator] nextObject]; CFRelease(result); return bundleSeedID;

In our macOS solution, we have a few processes and a few plugin modules which communicate with each other over XPC. We have recently started enforcing library validation flag along with hardened runtime for all processes and plugins. To enforce that, we are trying to get signing information from the XPC audit token using SecCodeCopySigningInformation with kSecCSDynamicInformation flag. As per documentation, this flag requires a live SecCode not SecStaticCode to be passed to SecCodeCopySigningInformation. However, SecCodeCopySigningInformation explicitly requires SecStaticCode in its parameters. So I am unsure how to pass live SecCode to SecCodeCopySigningInformation without copying SecStaticCode from it using SecCodeCopyStaticCode. Force cast from SecCode to SecStaticCode fails. Is unsafeBitCast a valid option in this case? Note that we support macOS version 12 and later.

In the latest 26.5, when creating a VM we can no longer disable SIP. We have confirmed we're using the proper admin user (anka) and its proper password (same one we log into the GUI with). It just keeps asking for the password as if it's wrong. It's critical we can disable SIP for VMs like we have been in previous versions.

Hi Apple Developer Forums, We are developing a managed macOS security/monitoring agent for enterprise customers (deployed only to MDM-managed endpoints). Our goal is to collect per-process network connection metadata (e.g., which process initiated a TCP connection, destination IP/port, timestamps). We are not intercepting or collecting network payload/content—only connection metadata for security telemetry/compliance. We previously explored options like: sysctl PCB lists (e.g., net.inet.tcp.pcblist_n) / kernel structs (not stable ABI; appears private/fragile) Aggregate TCP stats (sysctl net.inet.tcp.stats) which are public but system-wide only proc_pidinfo() / PROC_PIDFDSOCKETINFO for per-PID socket snapshots (polling-based; limited / not event-driven) It seems the supported, event-based approach for per-process connection visibility is EndpointSecurity.framework, but it requires the entitlement: com.apple.developer.endpoint-security.client Questions: Is EndpointSecurity.framework the recommended/supported approach for per-process TCP connection events on macOS for a managed enterprise security agent? What is the correct process to request approval for the Endpoint Security client entitlement under an Apple Developer Program team? (We were directed to post here.) Which Endpoint Security event types are appropriate for capturing connect/accept/close style network events per-process, strictly for metadata telemetry? Are there any platform/privacy constraints or best practices Apple expects us to follow for this use case (MDM-managed enterprise deployments)? We can provide additional details (distribution method, signing, MDM deployment model, privacy disclosures) if needed. Thanks!

Hi All, I am working on a macOS System Extension using Apple’s Network Extension Framework, designed to observe and log network activity at multiple layers. The system extension is currently stable and working as expected for HTTP and DNS traffic with 3 providers, getting Socket, HTTP, and DNS logs. Current Architecture Overview The project consists of two Xcode targets: 1. Main App Process Responsible for: Managing system extension lifecycle (activation, configuration) Establishing IPC (XPC) communication with extensions Receiving structured logs from extensions Writing logs efficiently to disk using a persistent file handle Uses: OSSystemExtensionManager NEFilterManager, NETransparentProxyManager, NEDNSProxyManager NWPathMonitor for network availability handling Persistent logging mechanism (FileHandle) 2. System Extension Process Contains three providers, all running within a single system extension process: a) Content Filter (NEFilterDataProvider) Captures socket-level metadata Extracts: PID via audit token Local/remote endpoints Protocol (TCP/UDP, IPv4/IPv6) Direction (inbound/outbound) Sends structured JSON logs via shared IPC b) Transparent Proxy (NETransparentProxyProvider) Intercepts TCP flows Creates a corresponding NWConnection to the destination Captures both HTTP and HTTPS traffic, sends it to HTTPFlowLogger file which bypasses if it's not HTTP traffic. Uses a custom HTTPFlowLogger: Built using SwiftNIO library (NIO HTTP1) Parses up to HTTP/1.1 traffic Handles streaming, headers, and partial body capture (with size limits) Maintains per-flow state and lifecycle management Logs structured HTTP data via shared IPC c) DNS Proxy (NEDNSProxyProvider) Intercepts UDP DNS traffic Forwards queries to upstream resolver (system DNS or fallback) Maintains shared UDP connection Tracks pending requests using DNS IDs Parses DNS packets (queries + responses) using a custom parser Logs structured DNS metadata via shared IPC Shared Component: IPCConnection Single bidirectional XPC channel used by all providers Handles: App → Extension registration Extension → App logging Uses Mach service defined in system extension entitlements Project Structure NetworkExtension (Project) │ ├── NetworkExtension (Target 1: Main App) │ ├── AppDelegate.swift │ ├── Assets.xcassets │ ├── Info.plist │ ├── NetworkExtension.entitlements │ ├── Main.storyboard │ └──ViewController.swift │ ├── SystemExtensions (Target 2: Extension Process) │ ├── common/ │ │ ├── IPCConnection.swift │ │ └── main.swift │ │ │ ├── DNSProxyProvider/ │ │ ├──DNSDataParser.swift │ │ └──DNSProxyProvider.swift (DNS Proxy) │ │ │ ├── FilterDataProvider/ │ │ └── FilterDataProvider.swift │ │ │ ├── TransparentProxyProvider/ │ │ ├── HTTPLogParser.swift │ │ ├── LogDataModel.swift │ │ └──TransparentProxyProvider.swift │ │ │ ├── Info.plist │ └── SystemExtensions.entitlements │ Current Capabilities Unified logging pipeline across: Socket-level metadata HTTP traffic (HTTP/1.1) DNS queries/responses Efficient log handling using persistent file descriptors Stable IPC communication between app and extensions Flow-level tracking and lifecycle management Selective filtering (e.g., bypass rules for specific IPs) What's the best approach to add TLS Inspection with MITM proxy setup? Some context and constraints: Existing implementation handles HTTP parsing and should remain unchanged (Swift-based). I’m okay with bypassing apps/sites that use certificate pinning (e.g., banking apps) and legitimate sites. Performance is important — I want to avoid high CPU utilization. I’m relatively new to TLS inspection and MITM proxy design. Questions Is it a good idea to implement TLS inspection within a system extension, or does that typically introduce significant complexity and performance overhead? As NETransparentProxyProvider already intercepting HTTPS traffic, can we redirect it to a separate processing pipeline (e.g., another file/module), while keeping the existing HTTP parser(HTTPFlowLogger - HTTP only parser) intact? What are the recommended architectural approaches for adding HTTPS parsing via MITM in a performant way? Are there best practices for selectively bypassing pinned or sensitive domains while still inspecting other traffic? Any guidance on avoiding common pitfalls (e.g., certificate handling, connection reuse, latency issues)? I’m looking for a clean, maintainable approach to integrate HTTPS inspection into my existing system without unnecessary complexity or performance degradation. Please let me know if any additional details from my side would help in suggesting the most appropriate approach. Thanks in advance for your time and insights—I really appreciate it.