Thanks Quinn, that's exactly what we needed. The footnote about the explicit check for .unspecified explains the behaviour, and it also tells us that an override in either the user or the admin domain triggers it, so we've asked the customer to check both. I filed the Feedback: FB25283877. It asks for better diagnostics: a syspolicyd log line that names the certificate and the trust domain when a ticket's chain is trusted through an override (instead of "Unable to parse ticket" / -1), a matching hint in the output of stapler, spctl and syspolicy_check, and unredacted trust details in the trustd log lines. It includes a clean-VM reproduction with log excerpts from a failing and a healthy run.

Thanks Quinn, that pointed us in the right direction. On the affected Mac we captured a live log stream --level debug (plus log collect) while running spctl -a -vv -t execute on our app, and looked backwards from Unable to parse ticket as you suggested. We'd appreciate your confirmation of what we found. AFFECTED MAC (macOS 26.6.2). Every ticket registration looks like this (multi-line trust details collapsed): 08:27:22.834198 syspolicyd: [com.apple.securityd:notarization] Registering stapled ticket with system 08:27:22.834318 syspolicyd: Created Activity ID: 0x1f2c261e, Description: SecTrustEvaluateIfNecessary 08:27:22.834656 trustd: [com.apple.securityd:serverxpc] XPC [syspolicyd[486]/1#41 LF=0] operation: trust_evaluate (8) 08:27:22.838963 trustd: [com.apple.securityd:trust] completed: <private> details: ({}, {}) result: 4 08:27:22.840541 trustd: [com.apple.securityd:trust] completed: <private> details: ({}, {}, {}) result: 1 08:27:22.840801 syspolicyd: [com.apple.syspolicy:default] Unable to parse ticket. 08:27:22.841143 syspolicyd: [com.apple.syspolicy:default] error registering ticket: -1 08:27:22.841174 syspolicyd: [com.apple.securityd:SecError] Error registering stapled ticket: Error Domain=NSOSStatusErrorDomain Code=-1 ... 08:27:22.841208 syspolicyd: [com.apple.securityd:notarization] checking with online notarization service for hash: ... 0x79126fe9ed660f77390d069a0dfae36188e9ba8fThe ticket then downloaded from CloudKit fails the same way (3-certificate evaluation with result 1, then "Unable to parse ticket"), and so does stapler validate for another vendor's stapled app. HEALTHY MAC (clean macOS 26.6.2 VM, same app): 12:59:10.464799 syspolicyd: [com.apple.securityd:notarization] Registering stapled ticket with system 12:59:10.464837 syspolicyd: Created Activity ID: 0x277aa, Description: SecTrustEvaluateIfNecessary 12:59:10.465037 trustd: [com.apple.securityd:serverxpc] XPC [syspolicyd[207]/1#41 LF=0] operation: trust_evaluate (8) 12:59:10.466544 trustd: [com.apple.securityd:trust] completed: <private> details: () result: 4 12:59:10.467001 trustd: [com.apple.securityd:trust] completed: <private> details: () result: 4 12:59:10.467201 syspolicyd: Created Activity ID: 0x277ab, Description: SecKeyVerifySignature 12:59:10.471581 syspolicyd: [com.apple.syspolicy:default] Inserting ticket: <private>The 3-certificate chain matches the one embedded in the ticket: Software Ticket Signing -> Apple System Integration CA 4 -> Apple Root CA - G3. Our reading is that result 1 is kSecTrustResultProceed (trusted because of an explicit trust setting) and result 4 is kSecTrustResultUnspecified (trusted through the built-in anchor). REPRODUCTION. On the clean VM, we added an admin-domain override for Apple Root CA - G3: sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain g3.pemAfter that, "security dump-trust-settings -d" shows Apple Root CA - G3 with "Number of trust settings : 0". With the network up, we then got exactly the field symptoms: the ticket chain evaluates to result 1, and "Unable to parse ticket" is logged for both the stapled and the downloaded ticket spctl prints "source=Developer ID", and "stapler validate" exits with 65 our system extension fails with "Error checking with notarization daemon: 3" and -67050 "sudo security remove-trusted-cert -d g3.pem" fixed it immediately, without a reboot. We've asked the customer to check their trust settings, but haven't yet received the response for it. QUESTIONS Is it intended that syspolicyd refuses a ticket whose signing chain is trusted through a trust-settings override (Proceed) instead of the system anchor? Could anything other than admin or user trust settings make this chain evaluate to Proceed, for example a configuration profile with a certificate payload? That would tell us what else to ask admins to look for. If the behaviour is intended, "Unable to parse ticket" with a -1 error makes it hard to diagnose. Would a bug report asking for a clearer message be useful? We're happy to file one with a sysdiagnose from the VM. For reference, this third-party write-up describes the same symptom on one Mac, whose admin trust settings contained Apple Root CA - G3 and Developer ID Certification Authority: https://github.com/fsnow/cst/blob/main/docs/implementation/NOTARIZATION_TICKET_ISSUE.md

I'm working on a endpoint protection software and need a VM as a testing environment. being able to test with development beta is mandatory for me for discovering issues as early as possible.