Update: We did try 15.7.1 today and it still did not work. We also put 14.8.1 on a box that was having problems before and it still won't allow fda to be toggled on for our daemon.

Hi Kevin — thanks for clarifying. Current state Intel · macOS 15.6 (two machines): FDA toggle for our app-bundled daemon flips Off (immediately or after leaving the pane). When it appears On, the daemon still behaves as if FDA isn’t granted. Apple Silicon · macOS 15.6: Works. Loaded via launchctl load /Library/LaunchDaemons/... from a shell script run by another daemon. Follow-ups When you say “adopt SMAppService,” could you point me to the exact steps or a minimal example of setting this up so the daemon inherits FDA? I’m unfamiliar with the specifics you’re proposing. What’s the simplest way to enable tccd diagnostics to see why the grant is being dropped (just the key commands/flags you recommend)? If you’d like a Feedback Assistant report, what minimal artifacts make it most actionable? If you want a bug report, what would I need to include? Do you want us to try 15.7.1? Thanks!

Hi Kevin — thanks for the detailed reply. Quick confirmations We’re already shipping the ES daemon as an app-bundled executable (signed, hardened, notarized). FDA is being granted through System Settings → Privacy & Security → Full Disk Access to the app bundle (per your #1), not to a bare exe. ES entitlement is present; Gatekeeper/SPCTL and codesign checks are clean. What we’re actually hitting (repro matrix) Apple Silicon (M-series) – macOS 15.6: Works. FDA toggles on and persists. ES daemon runs fine at boot. Intel – macOS ≤ 15.5: Works. Intel – macOS 15.6 ONLY: Broken. In Full Disk Access, turning the toggle On either immediately flips back Off, or appears On but flips Off after navigating away and back. When it “looks” On, the ES daemon still behaves as if FDA is not granted. This behavior is consistent across multiple Intel machines and fresh user profiles. Extra notes about launch The daemon is launched by launchd (system domain) as usual. Our installer (run by another LaunchDaemon’s install.sh) registers it with launchctl …. The same flow works on Apple Silicon and on Intel with earlier OS versions. Only Intel + 15.6 shows the FDA UI state failing to persist. What we’ve checked so far sqlite3 "/Library/Application Support/com.apple.TCC/TCC.db" shows either no allow row for kTCCServiceSystemPolicyAllFiles or a transient state that disappears after the UI flips back. log show --style compact --predicate 'subsystem == "com.apple.TCC" || process == "tccd" || process == "System Settings"' --last 30m shows no obvious entitlement or code requirement mismatch. Removing/re-adding the app, resetting with tccutil reset All, rebooting, etc., does not change the Intel-15.6 outcome. Questions Is there a known Intel-only regression in 15.6 where FDA toggles for app-bundled daemons fail to persist? Does launching the daemon immediately after install (triggered by a separate LaunchDaemon running an install.sh) interact with TCC/FDA persistence on Intel 15.6 specifically? You mentioned SMAppService inheritance—does FDA persistence differ on Intel 15.6 if the daemon is installed/registered via SMAppService vs a LaunchDaemon plist? If that path is recommended, we can prototype it. If there are any required Info.plist keys for the bundle that affect FDA persistence (e.g., LSBackgroundOnly, specific CFBundlePackageType), please confirm.

Thank you! So you are right, I was not "start"ing the daemon, just loading it. I am also able to manually run it, but it required full-disk-access to the Terminal app! We also are creating a FAT binary to run on both Intel and Apple Silicon, so I will test that next. By the way, the examples are seriously lacking in detail - even your example. It took a long time to reproduce simply because there are missing steps. For example, the creating a new application DOES NOT create an Info.plist. That took a while to figure out. Telling someone to delete a key that shows up in that file doesn't really make any sense, particularly when they are not called the same thing in the Info tab in the project settings. Another thing is that once I added the ES code, it would not build because you also need to link the library for it. There were a few other things as well - such as telling me to delete main.storybook, or other things that actually had no extension showing in the project file list. Finally, my main confusion left is that the sample applications work fine, but in order to do it, I'm creating an application developer cert and profile (well Xcode is), and that is requiring me to register my machine. I am worried I will get back into the same boat after moving my code into the test app, then trying to create a distributable ES client that will run anywhere. I think you are telling me that we don't use a Developer ID certificate for that, but instead a distribution certificate? I know it's frustating, but I am still not able to figure this out from the llinked docs and would like a quick summary please.

Yes, please see my latest responses. I did start up the demon as you say and also try running it manually. I get nothing in the logs as a Daemon

plutil -p ./com.fidelisevents.DaemonInAppsClothing.plist { "Label" => "com.fidelisevents.DaemonInAppsClothing" "ProgramArguments" => [ 0 => "/Library/Application Support/DaemonInAppsClothing/DaemonInAppsClothing.app/Contents/MacOS/DaemonInAppsClothing" ] } I did add full disk access, I didn't ever get the background item for Login and extensions, but maybe because Fidelis Securit LLC is alread listed. Regardless, I try to load it: sudo launchctl load /Library/LaunchDaemons/com.fidelisevents.DaemonInAppsClothing.plist Looking at the logs: log show --predicate 'eventMessage CONTAINS "QQQ"' --last 5m Filtering the log data using "composedMessage CONTAINS "QQQ"" Skipping info and debug messages, pass --info and/or --debug to include. Wall Clock adjustment detected - results might be strange while using --end Timestamp Thread Type Activity PID TTL -------------------------------------------------------------------------------------------------------------------- Log - Default: 0, Info: 0, Debug: 0, Error: 0, Fault: 0 Activity - Create: 0, Transition: 0, Actions: 0 darrelburns@LT-FC008087 ~ % log show --predicate 'process == "DaemonInAppsClothing"' --last 5m Filtering the log data using "process == "DaemonInAppsClothing"" Skipping info and debug messages, pass --info and/or --debug to include. Wall Clock adjustment detected - results might be strange while using --end Timestamp Thread Type Activity PID TTL -------------------------------------------------------------------------------------------------------------------- Log - Default: 0, Info: 0, Debug: 0, Error: 0, Fault: 0 Activity - Create: 0, Transition: 0, Actions: 0 I try to run it: % /Library/Application\ Support/DaemonInAppsClothing/DaemonInAppsClothing.app/Contents/MacOS/DaemonInAppsClothing 2025-07-27 10:57:00.499 DaemonInAppsClothing[25436:973284] entitlements: { "com.apple.application-identifier" = "J4WGF5B6KZ.com.fidelissecurity.DaemonInAppsClothing"; "com.apple.developer.endpoint-security.client" = 1; "com.apple.developer.team-identifier" = J4WGF5B6KZ; "com.apple.security.get-task-allow" = 1; } 2025-07-27 10:57:00.499 DaemonInAppsClothing[25436:973284] QQQ err: ERR_NOT_PRIVILEGED

Hi Quinn, Unfortunately, even after giving full disk access to both fidelisevents.app, it still gets the same error ( /// The caller lacks Transparency, Consent, and Control (TCC) approval from the user. ES_NEW_CLIENT_RESULT_ERR_NOT_PERMITTED,) I don't know what else to try now.

I am following up because while the daemon is signed correctly now, we still get the ES_NEW_CLIENT_RESULT_ERR_NOT_PERMITTED on SIP-enabled systems: How can a security company like ours distribute an Endpoint Security (ES) daemon to run on any Mac? I’m starting to get the sense that it’s not possible to use a Developer ID Application certificate for a widely distributed ES daemon, and that Apple requires these to be implemented as system extensions instead. The official documentation doesn’t make this distinction very clear. Can anyone confirm the correct approach for distributing ES clients to end users?

I must ask, now that everything matches, it does sign and run, but I want to know how I can run this locally for day-to-day development

I have sent you a PM on the DTS support request with a link to download the file

Please verify this is correct for my use case

fidelisevents % syspolicy_check distribution ./bin/FidelisEvents.app/Contents/MacOS/fidelisevents App passed all pre-distribution checks and is ready for distribution. fidelisevents % syspolicy_check distribution ./bin/FidelisEvents.app App passed all pre-distribution checks and is ready for distribution. And yes, I did this after removing the negative flags in the entitlement: codesign -d --entitlements :- ./fidelisevents.app Executable=/Users/darrelburns/devel/fidelisevents/bin/FidelisEvents.app/Contents/MacOS/fidelisevents warning: Specifying ':' in the path is deprecated and will not work in a future release Current Status: I’ve followed all documented Apple and forum guidance for deploying a non-system-extension Endpoint Security client as a Developer ID app bundle. I have: Embedded a Developer ID Application provisioning profile with the Endpoint Security entitlement (confirmed by developer.apple.com, profile XML, and all tools). Used codesign, spctl, and syspolicy_check distribution (macOS 14+)—all report the app is correctly signed and ready for distribution. Removed all non-required/negative entitlements. On first launch, the app is killed instantly, and the logs always say: taskgated-helper: ... Unsatisfied entitlements: com.apple.developer.team-identifier, com.apple.developer.endpoint-security.client taskgated-helper: ... Disallowing: com.fidelisendpoint.fidelisevents amfid: ... not valid: Error Domain=AppleMobileFileIntegrityError Code=-413 "No matching profile found" ... unsatisfiedEntitlements=[ "com.apple.developer.team-identifier", "com.apple.developer.endpoint-security.client" ] I confirmed the profile is a production Developer ID Application profile, not just for development, and it’s valid through 2030.

After learning that Endpoint Security (ES) clients must be packaged in an “app-like” structure to use a provisioning profile, I followed Apple’s technical note and Quinn’s advice: Steps Taken App Bundle Creation Created a bundle named FidelisEvents.app, with standard macOS .app layout. Placed my universal Mach-O (x86_64/arm64) binary at FidelisEvents.app/Contents/MacOS/fidelisevents. Added an Info.plist at FidelisEvents.app/Contents/Info.plist with the correct CFBundleIdentifier and metadata (matching the provisioning profile/App ID). Provisioning Profile Embedded the provisioning profile at FidelisEvents.app/Contents/embedded.provisionprofile. Profile type: Developer ID Application for macOS. App ID and team identifier match the bundle and entitlements. Profile entitlements explicitly include: com.apple.application-identifier com.apple.developer.team-identifier com.apple.developer.endpoint-security.client Confirmed by extracting and inspecting the embedded profile. Entitlements Used an entitlements plist at codesign time, containing: com.apple.application-identifier com.apple.developer.endpoint-security.client (set to true) com.apple.developer.team-identifier (Also set sandbox and get-task-allow to false, per guidance) Entitlements and Info.plist values exactly match the provisioning profile. Signing and Notarization Signed the entire .app bundle with our Developer ID Application certificate, referencing the entitlements file. Submitted the app for notarization (xcrun notarytool submit), and stapled the notarization ticket to the bundle. Verified codesign and notarization: codesign --verify --deep --strict --verbose=4 reports "valid on disk, satisfies its Designated Requirement." spctl -a -t exec -vv reports "accepted (Notarized Developer ID)". Profile is visible, properly embedded, and shows required entitlements. Testing Execution Moved the bundle to /Applications and other trusted locations. Removed com.apple.quarantine xattrs, just in case. Rebooted to clear any signature cache. Result On launch (with or without sudo), the process is immediately killed with a “Code Signature Invalid” crash. Console and log output show: taskgated-helper: ... Unsatisfied entitlements: com.apple.developer.team-identifier, com.apple.developer.endpoint-security.client ... Error Domain=AppleMobileFileIntegrityError Code=-413 "No matching profile found" All signature and notarization checks are successful; the only runtime issue is a failure to recognize the provisioning profile as authorizing the required restricted entitlements. Key Details The provisioning profile was freshly created as Developer ID Application for this App ID, with Endpoint Security checked. All values (App ID, team ID, entitlements, Info.plist) match. The app is not modified after signing and notarization. The problem occurs on both Apple Silicon and Intel Macs, on macOS Sonoma and Ventura. Question Has anyone successfully deployed a non-system-extension Endpoint Security client using a Developer ID Application and a provisioning profile in an “app-like” bundle? Is there a further step required to authorize these entitlements for production use, or is this a platform limitation for non-system-extensions even with all credentials and notarization in order?

A coworker created a new dev certificate through xcode, and that one is working for us. It also seems to have fixed the certificate chain for the original one. Go figure!

Additional Update on Developer ID Signing Issue (errSecInternalComponent) Since my previous update, I've taken the following steps: Fully reset the default login keychain and metadata on the affected macOS build machine, resulting in a completely clean, empty login keychain. Imported the Developer ID Application certificate and private key (Developer ID Application: Fidelis Security LLC (J4WGF5B6KZ)) from the previous backup into the new login keychain. Verified trust settings and access control for the imported certificate and private key: Certificate shows fully trusted and valid. Private key access control explicitly allows use by codesign. Successfully exported the certificate and private key from the new login keychain without issues, confirming no export-related problems remain. Ran the simplest possible signing test from Terminal: cp "/usr/bin/true" "MyTrue" codesign --force --timestamp --options runtime \ --sign "Developer ID Application: Fidelis Security LLC (J4WGF5B6KZ)" \ ./MyTrue This resulted in the identical error as before: ./MyTrue: replacing existing signature Warning: unable to build chain to self-signed root for signer "Developer ID Application: Fidelis Security LLC (J4WGF5B6KZ)" ./MyTrue: errSecInternalComponent Additionally, the output from security find-identity -p codesigning (obfuscated for privacy) is as follows: Policy: Code Signing Matching identities 1) [ID] "Developer ID Application: Fidelis Security LLC (J4WGF5B6KZ)" 1 identities found Valid identities only 1) [ID] "Developer ID Application: Fidelis Security LLC (J4WGF5B6KZ)" 1 valid identities found