@DTS Engineer Thank you for your reply. Regarding: [quote='790296021, dcccdsds, /thread/790296, /profile/dcccdsds'] The weird part is that when I try the same steps on different developer account, I am able to get the app running. [/quote] That also included changing the Developer ID certificates, Team ID, Bundle ID, App Groups, provisioning profiles, and entitlements to match the updated IDs. I used the same format for App Groups and did not add any new entitlements. As for the com.apple.application-identifier entitlement: When I export the .app, the entitlements and provisioning profiles built into the package contain the App ID entitlement. The provisioning profiles used to replace the existing profiles also include this entitlement, as do the updated entitlements with the -systemextension suffix. When I check the entitlements of the signed app from the generated .dmg bundle, it also contains the com.apple.application-identifier entitlement. Is there another place where this entitlement might be required that I could be missing? Thank you.

@DTS Engineer Thank you for your response. This is a follow-up to the original post, where we unsuccessfully attempted to sign an app using Developer Team X with Developer Y’s ID certificate. We then created another version of the app with a bundle ID linked to Developer Team Y and signed it using Developer Y’s ID certificate. This worked. However, our goal is to have the app linked to Developer Team X and signed with Developer X’s ID certificate. Despite ensuring that the bundle ID, team ID, and Developer ID certificate are all associated with Team X, we still encounter an issue when opening the signed and notarized app. Gatekeeper disallows the launch request, generating the following logs: 661 debug staticCode syspolicyd Security 0x88d68d818 done serializing <?xml version="1.0" encoding="UTF-8"?><!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "https://www.apple.com/DTDs/PropertyList-1.0.dtd"><plist version="1.0"><dict><key>com.apple.application-identifier</key><string><teamid.bundleid></string><key>com.apple.developer.networking.networkextension</key><array><string>packet-tunnel-provider-systemextension</string></array><key>com.apple.developer.team-identifier</key><string>teamed</string><key>com.apple.security.app-sandbox</key><true/><key>com.apple.security.application-groups</key><array><string>teamid.group.appgroup</string></array><key>com.apple.security.files.user-selected.read-write</key><true/><key>com.apple.security.network.client</key><true/><key>com.apple.security.network.server</key><true/><key>keychain-access-groups</key><array><string>teamid.group.appgroup</string></array></dict></plist> com.apple.securityd 22207 debug ProvisioningProfiles taskgated-helper ConfigurationProfiles entitlements: { "com.apple.developer.networking.networkextension" = ( "packet-tunnel-provider-systemextension" ); "com.apple.developer.team-identifier" = team-id; "keychain-access-groups" = ( “teamid.group.appgroup” ); } com.apple.ManagedClient 22207 error ProvisioningProfiles taskgated-helper ConfigurationProfiles Disallowing: <bundle-id> com.apple.ManagedClient 22207 error ProvisioningProfiles taskgated-helper ConfigurationProfiles <bundle-id>: Unsatisfied entitlements: com.apple.developer.team-identifier, com.apple.developer.networking.networkextension, keychain-access-groups com.apple.ManagedClient` After this, we reset the entitlements, created a new Developer ID certificate, and linked it to a new Developer ID Application provisioning profile. However, the same issue persists. The entitlements, project configuration, and provisioning profile setup are now identical to when we successfully signed the app with Developer Team Y and Developer Y’s ID certificate. Thank you for your help.

UPDATE: We have found out that changing the identifier of non-working app to the bundle identifier of the working app resolves the issue (and introduces changing from working to non-working bundle id). With this information we then looked at app settings, app privacy and App Store Connect settings - especially profiles, identifiers, capabilities and certificates, but did not see any difference there or anything suspicious of the issue.