You can now easily request access to managed capabilities for your App IDs directly from the new Capability Requests tab in Certificates, Identifiers & Profiles > Identifiers. With this update, view available capabilities in one convenient location, check the status of your requested capabilities, and see any notes from Apple related to your requests. Learn more about capability requests.

General: Forums topic: Code Signing Forums subtopics: Code Signing > General, Code Signing > Certificates, Identifiers & Profiles, Code Signing > Notarization, Code Signing > Entitlements Forums tags: Code Signing, Signing Certificates, Provisioning Profiles, Entitlements Developer Account Help — This document is good in general but, in particular, the Reference section is chock-full of useful information, including the names and purposes of all certificate types issued by Apple Developer web site, tables of which capabilities are supported by which distribution models on iOS and macOS, and information on how to use managed capabilities. Developer > Support > Certificates covers some important policy issues Bundle Resources > Entitlements documentation TN3125 Inside Code Signing: Provisioning Profiles — This includes links to the other technotes in the Inside Code Signing series. WWDC 2021 Session 10204 Distribute apps in Xcode with cloud signing Certificate Signing Requests Explained forums post --deep Considered Harmful forums post Don’t Run App Store Distribution-Signed Code forums post Resolving errSecInternalComponent errors during code signing forums post Finding a Capability’s Distribution Restrictions forums post Signing code with a hardware-based code-signing identity forums post New Capabilities Request Tab in Certificates, Identifiers & Profiles forums post Isolating Code Signing Problems from Build Problems forums post Investigating Third-Party IDE Code-Signing Problems forums post Determining if an entitlement is real forums post Code Signing Identifiers Explained forums post Mac code signing: Forums tag: Developer ID Creating distribution-signed code for macOS documentation Packaging Mac software for distribution documentation Placing Content in a Bundle documentation Embedding nonstandard code structures in a bundle documentation Embedding a command-line tool in a sandboxed app documentation Signing a daemon with a restricted entitlement documentation Defining launch environment and library constraints documentation WWDC 2023 Session 10266 Protect your Mac app with environment constraints TN2206 macOS Code Signing In Depth archived technote — This doc has mostly been replaced by the other resources linked to here but it still contains a few unique tidbits and it’s a great historical reference. Manual Code Signing Example forums post The Care and Feeding of Developer ID forums post TestFlight, Provisioning Profiles, and the Mac App Store forums post For problems with notarisation, see Notarisation Resources. For problems with the trusted execution system, including Gatekeeper, see Trusted Execution Resources. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hoping to get visibility on a Family Controls (Distribution) entitlement request pending without status updates after an app transfer. Context: Digital wellbeing app, 500K+ active iOS users Previous team had Family Controls (Distribution) approved and shipping to production App transferred to new team (H2HM68H8PP) ~1 month ago; entitlement re-requested immediately Capability page shows "View Requests (6)" with no approvals, rejections, or updates Developer Support cases opened (102883853173, 20000112879750, 102875975624) — confirmed they cannot check entitlement status Impact: Core app feature depends on Family Controls. Production app for 500K+ users will break once transfer fully propagates at provisioning level. This is a continuity issue, not a new-app launch — entitlement was previously approved on the prior team. Questions: Recommended escalation path for post-transfer entitlement requests? Should I stop resubmitting to avoid queue deprioritization? Could the entitlements team provide a status update? Happy to share bundle ID, previous team ID, and request dates privately with Apple staff.

Hi, Two notarization submissions on my Team ID are stuck "In Progress" well past normal turnaround. Looking for guidance on whether this is normal first-time-enrolment latency or whether something needs escalating. Team ID: U7N63C278S Submissions: 2ac71ef0-cbfa-4bdd-9059-c2554050de48 — submitted 2026-05-14 08:09 UTC (currently ~48 hours In Progress) c2b557c5-92a2-4c36-996e-812b61b67fe6 — submitted 2026-05-14 11:33 UTC (currently ~46 hours In Progress) Status: xcrun notarytool history shows both as "In Progress" xcrun notarytool info <id> returns no log URL, no message, no error No rejection email received at the APPLE_ID address Apple System Status shows Developer ID Notary Service as green Context: This is my first notarization from a newly enrolled Developer Program account (enrolled ~5 days ago). I'm aware first-time submissions can be subject to longer in-depth analysis, which is why I haven't escalated sooner. Build verification (already done): codesign --verify --deep --strict -verbose=2 exits 0 Hardened runtime flag (0x10000) present on top-level .app and every nested Mach-O Full Developer ID Application chain (signed by Developer ID Application: poojan (U7N63C278S)) Secure timestamp present Universal binary (x86_64 + arm64) Every nested framework, helper app, and binary signed Built with electron-builder, hardened-runtime entitlements, notarized via notarytool submit --wait Question: Is this within expected first-time-enrolment latency, or is there something on the notary service side that needs a nudge? Happy to provide additional codesign output or the .app bundle structure if useful. Thanks for any guidance.

It's true - go ahead and look. Every single unlucky soul that encounters the "status code 7000", "Team ID not yet configured for notarization" just stops developing for the mac, as they are left with no other option. Based on a deep review of all posts on the subject in multiple online communities & web searches, here's what we know: This problem has existed since at least 2018 People that drew the short straw are directed to contact Apple Developer Support via email Usually after 3 weeks an automated message is sent that the issue has been added to the queue of "the relevant team" Follow-up calls always indicate that the relevant team cannot be messaged even by Apple Support and that you just have to wait for them to contact you. In the past year, Apple now uses an AI bot to email you periodically to inform you that they are "monitoring" the situation and will let you know once "the relevant team" has completed their work. Apple makes it very clear you're trading emails back and forth with an LLM. The "relevant team" never, ever solves the problem or messages anyone. To be fair, the "relevant team" likely doesn't exist. Usually after 3 months, the average would-be developer gives up, and rues the day he paid the apple developer fee as well as all of the time & effort he'd put into making software on the Apple operating systems. Nobody knows why some people get the 7000 error. It seems as if xcode just randomly assigns it to 20 or 30 people per year. But knowing that the "Team ID is not yet configured for notarization" issue is a problem that will never be solved, we need to formulate some alternatives. Some of the avenues I'm brainstorming: Notarize under a different Team ID. This one stings because I went through so much trouble to create an LLC, all for nothing. Apple binds legal entities (DUNS numbers) with Team ID's. So my cursed Team ID and my new LLC cannot be used. My wife is a casual Apple user, I could set her up with her own dev account. That's torching another $99 as well as losing the protection of an LLC (for which I'd paid about $500 for). Sell my apps un-notarized. Apple treats the "7000 lottery losers" so badly that this might be the only path forward. Apparently a brew cask install in order to circumvent the traditional gates. Fellow devs probably don't mind this, but some of my apps are intended for the general public. Still not ideal. Remove 30% of my app's functionality and sell only the mac app store. That's a lot of feature losses that I'd spent months on. Ask any of the thousands of devs that didn't get randomly stricken by the status code 7000 curse to submit the app for notarization. Brand mismatch in Gatekeeper, but at least then we in the Apple Developer's Program can once again participate in the program we paid to be in. Set up our apps as open source, and include a link for funds. That means the LLC formation was a complete waste of $500. There's not a single Apple employee reading this that can help get us out predicament. If there was, we would have had at least one post anywhere on the internet about successfully overcoming the statuscode 7000 issue. Instead its just hundreds of posts by fee-paying developers saying they waited two, three, or 6 months before finally giving up and moving on to windows & linux software development. For the rest of my life, I'm going to wonder the following: Why was I singled out to get this status code error? If this problem has existed for at least 8 years, and has hundreds of posts about it, why is every single Apple support specialist completely clueless as to the cause of it? Why doesn't Apple have resolution metrics? That's got to be hundreds of unresolved status 7000 cases that have piled up. The company doesn't do any kind of internal reviews? Do they seriously mark cases as closed once its sent to "the relevant team"? And finally....don't Apple employees also think it's weird that "the relevant team" is a nameless, unknowable group that can never be contacted by their fellow co-workers? Like, everyone at Apple Support knows a phone number to reach the head office, or some method to reach C-suite secretarial pool. But the "relevant team" has no internal phone number available that other Apple staff can contact? For 25 days, I've spent between two and six hours each day trying to resolve my status code 7000 problem. That's time I've spent away from work and family, just to keep trying to resolve this issue. Knowing now that it will never be resolved does help as I try to pick up the pieces of my failed software development plans. Quinn/mods - please don't delete this. The people who get the status error need to know this. Absolutely no one who gets the 7000 code should be given false hope that "Oh just contact Apple Developer Support to resolve." At this point there's got to be hundreds of us that know the bitter truth that 7000 is a permanent, lifelong block. These unlucky devs need to immediately face reality so they can figure out the solutions to best navigate their business.

I've been waiting on the Family Controls distribution entitlement for my app for over two weeks with use case to self direct app and sites blocking Setup: Development entitlement: ✅ approved and working Request ID: 27684X55GC The blocker: Xcode warns: "Bundle identifier is using development only version of Family Controls (Development) capability. Please request access to Family Controls (Distribution)." Archiving for App Store fails with provisioning profile errors on all my targets Questions: Is 2+ weeks normal for distribution entitlement approval? Any recommended path to escalate besides the request form and have also emailed apple support?

We have been having unexplained failures with the codesign tool recently on macosx aarch64 and x64 hosts. Every once in a while when signing an app locally using the following command: /usr/bin/codesign -s - -vvvv --force /home/me/FooBarCalculator.app results in the following error: /home/me/FooBarCalculator.app: timestamps differ by 185 seconds - check your system clock The number of seconds reported in the error message keeps varying (but usually in that range). We have checked the system clock but there isn't anything wrong (from what we can see) with the host. In fact, we have been seeing this error on several hosts now, so it isn't specific to one host. While looking into this issue, we even printed the details of an already signed binary using the following command: codesign -dvvv HelloWorld.app and that prints among other things, similar warning message: ... Timestamp=12 May 2026 at 5:36:0 AM HelloWorld.app: timestamp mismatch: internal time 12 May 2026 at 5:32:59 AM (184 seconds apart) I'm looking for inputs on how we go about debugging this issue and where/how the codesign tool sources these timestamps from (any specific API?) and what value is it comparing against to notice a difference. These affected hosts have different operating system versions some 15.x and some 26.x.

Hi, I submitted my Family Controls entitlement requests on April 15 for my iOS app, but I still haven’t received an approval, rejection, or any status update. This is blocking my ability to properly test and move forward with the app, since it depends on the Screen Time / Family Controls APIs. I've tried contact to apple developer support and filed a code-level support on app connect dashboard. and still nothing received. Here is the request information: code-level support case id: 19834379 apple developer support case id: 102878196850 Family Controls Distribution RequestId: BT4C47F5VB,SLP56WRZ3J,BZ7MF3R4FF,5HAY5UF5X2,P49SM5C859,KG2T2X2L76,N353H759C4 Thanks.

Hello, We are currently in the process of creating our Developer ID Application certificate which is due to expire. While creating the certificate, we were posed with the option of choosing a Developer ID Certificate Intermediary G2 Sub CA which is supported by Xcode 11.4.1 and later Previous Sub CA We currently build our application out of Xcode using Make or CMake files and perform the codesign and productsign using the codesign commands. We also use 2 different build machines, Ventura with Xcode 14.3 for our latest releases High Sierra (10.13) with Xcode 10.1 for legacy releases to support some customers. Can you please let us know which Developer ID Certificate Intermediary we should choose for generating the new Developer ID Application certificate?

Hi DTS, I have 4 notarytool submissions all stuck in "In Progress" with no movement for 12+ hours. 'xcrun notarytool log <id›' returns "Submission log is not yet available" for all of them - they don't appear to have been processed at all. Team Identifier: NS22D2XK8A 1 .dmg submission at 2026-05-12T01:35Z (12+ hours stuck) dmg submissions between 10:04Z and 12:12Z This is my first time notarizing with this Team ID - possibly the new-account first-submission "in-depth analysis" delay? The DMG passes every standard check: Signed with Developer ID Application (Team NS22D2XK8A) Hardened runtime on all 6 embedded binaries (codesign flags 0x10000) Full authority chain: Developer ID App → Developer ID CA → Apple Root CA Secure timestamp present Entitlements: allow-jit, allow-unsigned-executable-memory, disable-library-validation, network.client, network.server, files.user-selected. read-write codesign --verify -deep --strict passes cleanly spctl source = "Developer ID Application" (correct) DMG itself signed inside-out per TN2206 I have read the other recent "stuck In Progress" threads from new Developer IDs - same pattern. Could the queue be unblocked, or is there a team-side configuration that needs flipping? Happy to provide submission UUIDs + filenames privately via Feedback Assistant or DM. Thanks!

tle: New account — all notarization submissions stuck In Progress 26+ hours Hi, I recently enrolled in the Apple Developer Program and all my notarization submissions have been stuck "In Progress" for over 26 hours with no resolution. Team ID: 799833449H Submission IDs: bb31ba38-9ff4-416d-b6ea-8ad88b84a2be (26+ hours) 8fdd039d-3db4-4e96-8111-37dba9d4afd2 (25+ hours) 685cba55-aacd-4a05-8086-707a6b88e138 (23+ hours) Binary is a universal macOS binary, codesign verifies cleanly with hardened runtime. notarytool log returns "not yet available" for all. Is this the in-depth analysis path for new accounts? Any ETA or action needed from my side?

It has been 20 days since we applied for Family Controls (Distribution) permission, but the status still shows as Submitted. Is there any way to expedite the review process?

Hello, My macOS notarization has been blocked since March with: "status": "Rejected", "statusCode": 7000, "statusSummary": "Team is not yet configured for notarization", "issues": null Latest fresh probe: Submission ID: 3201b921-2313-45fd-b274-0e46d3fb03c2 Upload time: 2026-05-09T12:37:16Z Archive: KwantflowNotaryProbe-20260509T123714Z.zip Status: Rejected Error: -2052 / 7000 Issues: None Support cases: 102842156916 — Development and Technical → Other Development or Technical Questions 102882811151 — Development and Technical → Code Signing The archive uploads successfully and notarytool history/log work, but every submission is rejected before binary validation. The log shows no signing, entitlement, hardened runtime, timestamp, or executable issues. Apple forum answers say this is a Developer Program Support issue, not DTS/code-level. I have already contacted Developer Support, but the issue is still unresolved and blocks our macOS release. Has anyone recently resolved -2052 / 7000 / “Team is not yet configured for notarization”? Did Apple need to manually enable something on the team/account? Thank you.

We are implementing an exam mode feature for an educational app used in schools, which restricts device usage during assessments. We requested the Automatic Assessment Configuration capability, received approval from Apple, and confirmed that the capability is listed as Assigned under our App ID in the Apple Developer portal. What works: When using a Development Provisioning Profile (downloaded from the portal), the entitlement key com.apple.developer.automatic-assessment-configuration is included in the profile, and our exam lock feature works correctly in development testing. The problem: When we manually download a Distribution (InHouse/Enterprise) Provisioning Profile from the portal — even after creating a new one — the entitlement key com.apple.developer.automatic-assessment-configuration is not present in the profile. verified this by running: security cms -D -i YourProfile.mobileprovision The key appears in the Development PP but is absent in the manually downloaded Distribution PP, despite the App ID showing the capability as Assigned. Note: When using Xcode's automatic signing, the generated profile does include the entitlement correctly. However, due to our organization's internal security policy, we are required to use manually managed provisioning profiles and cannot use Xcode automatic signing for distribution builds. Questions: Is the com.apple.developer.automatic-assessment-configuration entitlement intentionally restricted to Development profiles only, or is this a known portal issue with managed capabilities not being embedded in manually created Distribution profiles? Is it technically supported and intended to use AEAssessmentSession in an InHouse (Enterprise) distribution environment? If InHouse is not supported, is the correct path to test internally via Development profiles and then submit through App Store distribution to include this entitlement in production? Any guidance on the correct technical direction would be greatly appreciated.

Hello, I've been trying to notarize my macOS app using xcrun notarytool, but all submissions get stuck in "In Progress" status indefinitely (30+ minutes, never resolve). Environment: Tool: xcrun notarytool (Xcode 16) Bundle ID: io.pix-cull.app Team ID: C473MUK7G2 App type: PyInstaller-built .app, wrapped in a signed .dmg Stuck submission IDs: 00e953da (first attempt) f7ab027e 3e35fc3f 293541bc-ba61-4ccb-a273-a8f34cda2422 (most recent) Steps I've already taken: Disabled UPX compression in PyInstaller spec Signed all binaries inside-out (deepest first, .app last) Used --timestamp flag during codesign Verified Apple system status — all services show green Waited 24+ hours on the oldest submission — still "In Progress" What I observe: Running xcrun notarytool info <id> returns status: In Progress every time, no matter how long I wait. The submission never transitions to "Accepted" or "Invalid". Other developers report notarization completing in 2–15 minutes. I also submitted a ticket to Apple Developer Support (DTS), but I'm posting here as well in case anyone has seen this pattern. Is there something wrong with my account that could cause all submissions to stall? Any guidance would be appreciated. Thank you.

Hi, Our team already has the Family Controls (Distribution) entitlement approved for the main app and existing Screen Time extensions. We recently added a new Shield Configuration extension to show a custom on-device shield UI using ManagedSettingsUI. It is only used for UI rendering and does not collect or send any user data. However, the entitlement does not seem to be applied to this new extension yet, and we are blocked from proceeding with builds. We have already contacted support but haven’t received an update yet. Case ID: 102881099623 It’s been days without any update, and this has become really stressful for our team since we’re completely blocked at the final step after months of work on this app. Could someone please help to apply/sync the Family Controls distribution entitlement or guide us on the next steps? Happy to share app details privately if needed. Thanks.

Dear Apple Developer Support, We are experiencing an issue where our properly signed, notarized, and stapled PKG installer is being blocked by Gatekeeper on macOS Sequoia (15.3), despite passing all notarization checks. Team ID: 3888L7DV3P Organization: SKY GATE TECHNOLOGYS K.K. Certificate: Developer ID Installer: SKY GATE TECHNOLOGYS K.K. (3888L7DV3P) Issue Details: Our PKG installer is signed with "Developer ID Installer" certificate, notarized (status: Accepted, issues: null), and stapled successfully. pkgutil --check-signature confirms: "signed by a developer certificate issued by Apple for distribution" and "Notarization: trusted by the Apple notary service" xcrun stapler validate confirms: "The validate action worked!" However, spctl --assess --type install returns "rejected" with assessment:verdict = false and assessment:remote = true The system log shows: meetsDeveloperIDLegacyAllowedPolicy = 0 When users download and open the PKG (even from within a notarized DMG), Gatekeeper displays: "Apple could not verify [app] is free of malware" Notably, our .app bundles signed with "Developer ID Application" (same Team ID) pass Gatekeeper without issues. Only PKG installers are affected. Our software is a legitimate enterprise security product (VPN/Zero Trust client) distributed to corporate customers. Could you please: Investigate why our Team ID's PKG installers are being rejected by Gatekeeper's online assessment despite valid notarization Advise on any steps we can take to resolve the meetsDeveloperIDLegacyAllowedPolicy = 0 status for our Team ID Confirm whether there is a trust establishment process for new Developer ID Installer certificates with the Gatekeeper service Thank you for your assistance. Best regards, Riku Ogura Skygate Technologies K.K.

Hi, I'm building a wellness app called that helps users manage their phone usage based on their consumption, using the Screen Time API. I need the Family Controls (Distribution) entitlement to ship it. I've already submitted multiple requests across all my bundle IDs, but due to the lack of confirmation feedback after each submission, I may have submitted more than needed. Regardless, the oldest request submitted was on April 22nd (exactly 2 weeks ago), without any reply or change. Is this normal ? Also, I came across a forum post (https://developer.apple.com/forums/thread/821964?answerId=885672022#885672022) suggesting that the entitlement is now scoped at the team level rather than per bundle ID, and that I should resubmit a single request. I want to do the right thing here but I'm not sure whether to resubmit or wait and I don't want to make the situation worse than it already is. We're about a month away from our launch date and this is the last remaining blocker for both TestFlight and App Store submission. Any guidance on next steps, or help prioritizing this, would mean a lot. Thanks so much,

Problem My ARM64 macOS application is being immediately killed with SIGKILL when launched. No crash report is generated, and the process terminates instantly. Environment macOS Version: 15.x (Sequoia) Architecture: ARM64 (Apple Silicon) Certificate: Mac Developer certificate (development signing) App Type: Native ARM64 application with embedded Java runtime Symptoms ./MacOS/myapp Immediately returns: zsh: killed ./MacOS/myapp Investigation Results System Logs Show Security Policy Rejection kernel: (AppleSystemPolicy) ASP: Security policy would not allow process: 92850, /path/to/myapp syspolicyd: (Security) MacOS error: -67062 Error Code Analysis Error -67062 = errSecCSReqFailed (Code signature requirement failed) This is a Gatekeeper enforcement issue, not a code signing problem 3. Code Signature is Valid codesign -dvvv myapp Shows valid signature with Mac Developer certificate Authority=Mac Developer: Name (TEAMID) Authority=Apple Worldwide Developer Relations Certification Authority Authority=Apple Root CA What We Tried (That Didn't Help) ✅ Removed hardened runtime flag from Java components ✅ Added JIT entitlements (com.apple.security.cs.allow-jit) ✅ Verified Mach-O structure is correct ✅ Confirmed all libraries are ARM64 ✅ Re-signed with proper entitlements None of these fixed the issue because the problem is Gatekeeper policy enforcement. Question How can I allow this development-signed ARM64 app to run on macOS 15 without full notarization? I've tried: Removing quarantine attributes Various code signing approaches Different entitlements But Gatekeeper still blocks it with error -67062. Is there a way to add a security exception for development builds, or do I need to use a Developer ID certificate even for internal testing? Additional Context This is for internal development/testing. The app works fine when properly notarized, but we need a way to test development builds without going through the full notarization process each time. Any suggestions would be greatly appreciated!

Our team already has Family Controls (Distribution) entitlement approved for the main app and existing Screen Time extensions. We recently added a new Shield Configuration extension to show a custom on-device shield UI using ManagedSettingsUI. It is only used for UI rendering and does not collect or send any user data. However, the entitlement does not seem to be applied to this new extension yet, and we are blocked from proceeding with builds. We have already contacted support but haven’t received an update yet. Case ID: 102881099623 Could someone please help to apply/sync for the Family Controls distribution entitlement or guide us on the next steps? Happy to share app details privately if needed. Thanks.

I'm posting this so other devs hitting error 7000 know they're not alone, and so this gets some visibility outside the support ticket black hole. Timeline: End of February 2026: first notarization attempts. All rejected with status code 7000 March 1st: first support case opened Today, beginning of May: still blocked. Still error 7000 Four cases: 102833704616, 102836645198, 102842517951, 102865000390. Different advisors each time. I've uploaded my government ID twice. When I ask for a status, the answer is "I'll get back to you when I have news." Then silence. My setup is fine. Team ID is Y564MF82K8. App is signed with Developer ID Application, hardened runtime, secure timestamp, no get-task-allow, deep verify clean. Apple rejects the submission before inspecting the binary. The block is on Apple's side. Somebody needs to push a button but they cannot agree who needs to push it, so they just pass it from one department to another. The "correct escalation path" doesn't work. Quinn (Apple DTS engineer) keeps saying on this forum that error 7000 is administrative and the path is Developer Program Support (https://developer.apple.com/forums/thread/118465?answerId=379585022#379585022). I followed that path four times. The cases just sit there. Threads on this forum about error 7000 go back to 2019. Six years. Devs report cases stuck for weeks, months, with the same scripted responses. Apple knows. Apple does nothing. I'm a solo dev and I want to do a proper launch of my SaaS on all major desktop platforms. I paid the $99. I built the app. I signed every agreement. I cannot launch on macOS because Apple's departments cannot agree on who needs to push a button. If anyone here has actually unblocked error 7000, please share what worked. The official path obviously doesn't.

Hi all — looking for diagnosis help, posting publicly in case other devs hit the same issue. Symptom Every notarytool submission for the past 32 days returns: statusCode: 7000 statusSummary: "Team is not yet configured for notarization. Please contact Developer Programs Support..." Account state (all healthy as far as I can tell) Team ID: P6V2783F8M Membership: Active, Individual, paid Free Apps Agreement: Active Paid Apps Agreement: Active (signed Jan 4, 2026) W-8BEN tax form: Active Bank account: Active Developer ID Application certificate: valid, used for signing Bundle ID: dev.tinyclaw.desktop (registered) App is correctly signed codesign -dvvv shows: Authority=Developer ID Application: Yang Yang (P6V2783F8M) Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=Apr 11, 2026 Hardened runtime + secure timestamp both enabled. spctl --assess passes locally. Submissions (all rejected with 7000) 5a903f08-bd17-4d59-ac63-12e191e2bb5a 49b670da-0f79-4814-809a-f675791f15c3 febfb37a-b445-4d03-b7c4-bf573304f219 9013e185-10e2-42d4-91c1-3378083266eb bfc64627-5eb6-402c-ac25-e79648d2c251 (latest, 2026-05-02) Different builds, different versions (0.5.22-beta.7 → 0.5.27), different DMGs. Same 7000 every time. Credentials revalidated with a fresh app-specific password — same result. DTS Case 102855668616 open since Apr 2 — 4+ weeks of template responses, no engineering progress. Question Has anyone seen 7000 persist this long after a clean Individual enrollment? Is there a specific team-side flag that has to be flipped server-side, that DTS L1 can't see or escalate? Any suggestion on which DTS topic forces escalation to the notarization service team specifically? Happy to share more diagnostic output. Thanks.