General: Forums topic: Code Signing Forums subtopic: Code Signing > Notarization Forums tag: Notarization WWDC 2018 Session 702 Your Apps and the Future of macOS Security WWDC 2019 Session 703 All About Notarization WWDC 2021 Session 10261 Faster and simpler notarization for Mac apps WWDC 2022 Session 10109 What’s new in notarization for Mac apps — Amongst other things, this introduced the Notary REST API Notarizing macOS Software Before Distribution documentation Customizing the Notarization Workflow documentation Resolving Common Notarization Issues documentation Notary REST API documentation TN3147 Migrating to the latest notarization tool technote Fetching the Notary Log forums post Q&A with the Mac notary service team Developer > News post Apple notary service update Developer > News post Notarisation and the macOS 10.9 SDK forums post Testing a Notarised Product forums post Notarisation Fundamentals forums post The Pros and Cons of Stapling forums post Resolving Error 65 When Stapling forums post If your notary requests are stuck in the In Progress state, see my reply here. If your notary requests are failing with Team is not yet configured for notarization, see my reply here and also the follow-up here. Many notarisation issues are actually code signing or trusted execution issue. For more on those topics, see Code Signing Resources and Trusted Execution Resources. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hi — I'm trying to notarize a Developer ID–signed macOS app (a small menu-bar .dmg, ~1.4 MB) and every submission has been stuck at status: In Progress for 7+ hours without ever reaching Accepted or Invalid. The Developer System Status page shows the Notary Service as green/operational. This is a recently enrolled account (Individual) and these are its first notarization submissions, so I suspect a first-time-on-new-account hang, but wanted to get it looked at. Team ID: C4GLRN98Q7 Submission IDs (all still In Progress): a206d94b-c0e7-4901-a35e-daaf69c8ec65 — created 2026-06-25 19:02 UTC (oldest, ~7h+) 71d08fb3-0ae0-413a-8004-e3fb99721403 — 2026-06-25 19:32 UTC a6687302-d7b2-43be-8098-1442f0b1d4ab — 2026-06-25 19:45 UTC a8428002-0cd0-4d46-bc6d-8e95b9df409b — 2026-06-25 19:58 UTC cb8602bf-386e-4d98-9d1a-ad7e5308e629 — 2026-06-26 02:16 UTC (newest) What I'm doing: Signing with codesign --options runtime --timestamp using a Developer ID Application cert, then submitting the .dmg with xcrun notarytool submit … --keychain-profile … --wait. codesign --verify --strict passes locally. xcrun notarytool info returns valid submission metadata, just perpetually In Progress. The very first --wait died on a local network drop, but the submission had already uploaded 100% and kept processing server-side; I have not been spamming — the repeats above were a handful of retries before I realized they were all hanging. I've stopped submitting new ones. Could someone check why these submissions aren't completing? Happy to provide a notarytool log once any of them finishes. Thanks!

I'm hitting what looks like the same service-side notarisation issue reported recently (e.g. the "submissions stuck In Progress for days" thread / FB22939442), and would appreciate having my submissions looked at on the backend. Since 2026-06-25 ~12:00 UTC, every notarytool submission from my team goes to "In Progress" and never reaches a terminal state — no Accepted, no Invalid, no log (Submission log is not yet available, though info resolves the ID fine). The oldest is ~15 hours. Signing checks out: codesign --verify --strict passes and satisfies the Designated Requirement, hardened runtime with a secure timestamp, no get-task-allow, Developer ID Application. My builds notarised normally yesterday (e.g. 1ad9878b, Accepted 2026-06-24) — but those were on my previous Developer ID certificate. That cert's private key was lost (orphaned login keychain after a reboot), so I re-issued the Developer ID cert on 2026-06-25, and every submission on the new cert has been stuck since. Key data point: a trivial 5.8 KB signed "hello world" CLI binary (8c138308 below) also hangs "In Progress", so this is account/team-level, not app content. This lines up with the new-Developer-ID evaluation described in the Notarisation Resources Q&A, but several of mine are now past the usual window. Team: Creative Machines Limited (V95N2B8X7A) Feedback: FB23407538 Stuck submission UUIDs (oldest first): ef4af6d3-5750-4213-a108-584c75a861cc – 2026-06-25 ~11:59 UTC (oldest) 2d435abc-af77-4447-b2c8-94572b723f34 404a7d9d-9713-42df-99b6-1f144bc27ba1 8c138308-f23f-4df1-85f9-29095587f42b – the 5.8 KB hello-world This is the only blocker before I can distribute. Is there any way to get these specific IDs cross-referenced against the notary backend queue? Happy to share signed artifacts or the full notarytool poll log. Environment: macOS 26.4.1 (25E253), Xcode 26.5, notarytool 1.1.2 (41).

Hi, I am trying to build an installer package of an usual(?) format: it contains a binary that I am developing code signing and notarization is straightforward here. it contains a 3rd-party binary that is open source, code signed and notarized by this third party code signing and notarization is also straightforward here as it's already been done. it also contains a 3rd-party binary that is also open source, however, it is not code signed or notarized This last one is the subject of my question. It is a well-established project with thousands of stars on GitHub, however their own "installation method" is a shell script that downloads the binary, checks its checksum and just places it in the right location. When building an installer package (it's an installer package of these three binaries packaged - productbuild with --distribution flag) this binary needs to be code signed and notarized for Developer ID distribution. I trust this binary, however the chance of supply chain attacks is never zero. My questions are: How can I shield myself best against accidentally submitting a malicious version of this third binary via notarytool to Apple? Should I separately submit versions of this binary for notarization from submitting new versions of my app? This binary is bound to change way less frequently than the app I'm actually developing. I really don't want to risk termination of my Apple Developer account because it has many high-value applications available. I am doing some basics - matching the intended checksum before packaging, signing with the hardened runtime entitlement - but I would love to hear if there's other steps I can do to protect this pipeline and my company from accidents like these that may unintentionally damage our reputation. Thanks in advance!

Hello, I submitted a .pkg installer for notarization on 2026-06-23 at 05:26 UTC, and more than 24 hours later the status is still In Progress. This is the first time I notarize this particular software — a small, lightweight Adobe Premiere Pro plugin — so I have no previous turnaround time to compare against. From what I understand, notarization usually completes within minutes to an hour, so a delay of this length feels abnormal and I'm not sure whether it's expected. Submission details Submission ID: 28b6be07-6bf0-4456-b6f1-6c2f7da27409 Submitted (UTC): 2026-06-23 05:26:37 Tool: xcrun notarytool (authenticated via a stored keychain profile) Package: .pkg installer for a small Premiere Pro plugin Status: In Progress (never moves past this state) The build was submitted successfully with no error and returned a valid submission ID. Running notarytool log does not yet return a log, since processing hasn't completed. Questions Is there currently a known notarization backlog or service delay on Apple's side? Can a first-time submission for a given product take noticeably longer than usual (e.g. an initial review)? What is a realistic maximum processing time before a submission should be considered stuck rather than simply slow? Should I wait, or cancel and resubmit? I'd rather not create duplicate submissions if it won't help. Thanks in advance for any guidance. Best regards, Robin

Subject: Developer ID Notarization submissions stuck in “In Progress” for over 24 hours Developer Team ID: R6KKTZV8SL Environment: macOS 26.2 (Build 25C56) notarytool version: 1.0.0 (38) I am unable to complete notarization of any submissions. Affected submission IDs: 53fb3f5e-45e1-4435-9b46-6420d3fc1c98 Created: 2026-06-22T17:17:47.385Z Status: In Progress 37e99554-376f-419f-8648-cf8ba39ea1ff Created: 2026-06-22T18:13:35.034Z Status: In Progress 0af4a2be-aa8d-4bed-ab0b-173bd1b62538 Created: 2026-06-23T02:29:35.134Z Status: In Progress To rule out issues with my application bundle, I also submitted a minimal test archive (test.zip). That submission is also stuck in “In Progress”. The issue affects every notarization submission I have attempted. Commands used: xcrun notarytool submit … xcrun notarytool history –keychain-profile breather-notary xcrun notarytool info –keychain-profile breather-notary The submissions appear in history and info and remain in “In Progress”. Additionally, attempting to retrieve logs returns: “Submission log is not yet available or submissionId does not exist” Could you please investigate whether there is an issue with notarization processing for my team/account or a backend service issue affecting these submissions?

First-time notarization stuck 'In Progress' ~12h and appears to be blocking my account's queue. Submission ID: dc257767-a693-4382-88db-8ecf82994a0b Team ID: 83B3GJVFAS

I've been trying to notarize an installer (.pkg file) on a new laptop. Previous versions have been notarized successfully on a previous Mac. However, in spite of having the required certificates (same as the old Mac, generated for the new Mac) the submission gets stuck at "In Progress". Doing it multiple times (even hours apart) doesn't help. Is there a FAQ / suggested list of steps to help resolve this issue? Here's what I see: xcrun notarytool history --keychain-profile "(my profile name)" results in (problem started with v4, the first version I've tried on this new Mac): createdDate: 2023-10-17T01:34:36.911Z id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx name: xxxxxxxxxx-v4.pkg status: In Progress -------------------------------------------------- createdDate: 2023-10-17T01:33:59.191Z id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx name: xxxxxxxxxx-v4.pkg status: In Progress -------------------------------------------------- createdDate: 2023-10-16T21:01:25.832Z id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx name: xxxxxxxxxx-v4.pkg status: In Progress -------------------------------------------------- createdDate: 2023-10-16T19:57:44.776Z id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx name: xxxxxxxxxx-v4.pkg status: In Progress -------------------------------------------------- createdDate: 2023-10-02T14:17:34.108Z id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx name: xxxxxxxxxx-v3.pkg status: Accepted -------------------------------------------------- createdDate: 2023-09-28T14:04:46.211Z id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx name: xxxxxxxxxx-v2.pkg status: Accepted -------------------------------------------------- createdDate: 2023-09-20T17:28:46.168Z id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx name: xxxxxxxxxx-v1.pkg status: Accepted -------------------------------------------------- xcrun notarytool log xxxxxxxxxxxxxxxxxxxx --keychain-profile "(my profile name)" results in: Submission log is not yet available or submissionId does not exist id: xxxxxxxxxxxxxxxxxxxxxxxx

I'm hitting what looks like a service-side notarization problem and could use a pointer on how to get it escalated. Over the past 3 days I've submitted 9 times with notarytool. Only 2 came back Accepted. The other 7 are stuck at "In Progress" and never reach a terminal state, no Accepted, no Invalid, no log (notarytool log says it isn't available yet), and no email. The oldest has been sitting ~71 hours. Signing checks out: codesign --verify --deep --strict passes and satisfies the Designated Requirement, hardened runtime with a secure timestamp, no get-task-allow, signed with my Developer ID, and the DMGs are signed before submission. The 2 submissions that completed were Accepted, so credentials and signing are fine. It really looks like the service just isn't processing most of my submissions. This is a newly enrolled account, and I've filed FB22939442 and have an open Developer Support case. Is this a known issue for new accounts, and is there a way to get these submissions looked at? Environment: macOS 26.2, Xcode 26.5, notarytool 1.1.2 (41).

My app runs as expected when debugging, trigging the MacOS to ask the user for permission to use the microphone. The notarized version of the app does not have the MacOS asking for user permission but the app gets the message 'User rejected permission'. I'm seeing this after upgrading to 26.5.1 and so is one of my users. What changed in getting microphone permission?

I'm trying to notarize a macOS app. Every time, I get an error: "Team is not yet configured for notarization". This has been an issue for a few weeks now. I've contacted Developer support (https://developer.apple.com/support/) repeatedly. I've been asked to provide personal information and to upload a government ID. Did everything, nobody got back to me. This is very distressing - we've had this issue in total for almost a month, are about to deploy our app to real customers, and this is completely blocking. Not sure what to do here. Apple is blocking us completely and is not responding.

I've tried to notarize my app recently and got the error:{ "logFormatVersion": 1, "jobId": "...", "status": "Rejected", "statusSummary": "Team is not yet configured for notarization", "statusCode": 7000, "archiveFilename": "myapp.dmg", "uploadDate": "2019-06-20T06:24:53Z", "sha256": "...", "ticketContents": null, "issues": null }I've never heard about "team configuration for notarization" previously. What are the steps to resolve that issue?Thanks in advance.

Notarization has been rejecting every submission with statusCode 7000 ("Team is not yet configured for notarization") for over five weeks. I'd appreciate any Apple staff who can confirm the gate status or re-route this internally. Account: Team ID: ZLPP2G8NG3 Account type: Individual, ACTIVE membership Region: EU (Czech Republic) The submission is technically clean — this is rejected at the gate, not on content: Developer ID Application cert valid (expires 2031), full WWDR chain Signed with hardened runtime + secure timestamp codesign --verify --deep --strict passes notarytool uploads succeed, then Rejected in ~30-60s log shows "issues": null (the archive is never opened) Confirmed it is NOT app-specific: a 50 KB hello-world C binary, signed the same way, is rejected identically. Latest canary submission: 95833847-e70f-41fe-b61f-c9dc9ffd90ed (2026-05-27) -> 7000 Timeline: 2026-04-20 first 7000 rejection (app, after ~60h "In Progress") 2026-04-29 escalated to engineering (case 102873818441, advisor Ronan) 2026-05-13 advisor Ira (case 102887849530) requested government photo ID + address verification — uploaded same day via the official file-upload portal, autoreply confirmed receipt 2026-05-14 to 05-27 silence; case was closed on Apple side, issue NOT resolved 2026-05-27 still 7000 I've completed everything on my side: License Agreement accepted, Free Apps agreement Active, DSA trader designation done, and the identity-verification documents submitted on May 13. Two weeks later the gate is still down with no reply on either case. Question for Apple staff: can someone confirm whether the identity-verification documents from May 13 reached the team that flips the notarization flag, and whether anything further is needed from me? The support cases have gone quiet and I have no other channel to check status. Thank you.

Hello, I am unable to notarize any macOS app/archive with my Apple Developer Team. Every submission is rejected with the same account/team-level error: statusCode: 7000 statusSummary: Team is not yet configured for notarization. Please contact Developer Programs Support at developer.apple.com under the topic Development and Technical / Other Development or Technical Questions. The notarization log has: issues: null ticketContents: null This does not look like a code signing or binary validation issue, because multiple different archives/apps fail with the same statusCode 7000. My recent submission history: 2026-05-22 06:25 MSK, ClipDose.dmg, b967a63b-ce9f-486d-805f-a6853ceaf447, Rejected 2026-05-22 07:02 MSK, ClipDose.dmg, 0dd03db8-267d-4b15-bde7-21bd8f22adec, Rejected 2026-05-22 07:39 MSK, ClipDose.dmg, e79f831f-22e9-47b8-9578-344a5067e34c, Rejected 2026-05-22 14:09 MSK, ClipDose.dmg, 01f1bdb3-3323-4952-b735-0e984cad8737, Rejected 2026-05-22 16:58 MSK, ClipDose.dmg, 3e82d154-517f-4e3c-8808-4f6504c05f35, Rejected 2026-05-22 23:30 MSK, FLEX_VIDEO-notary.zip, 7cbc3fa1-749d-4fa3-bab7-18644019d81b, Rejected 2026-05-23 08:41 MSK, FLEX_VIDEO-0.9.2-macOS.dmg, edf241b0-7a0b-4c26-98a8-d3c6f869b0e1, Rejected 2026-05-23 08:47 MSK, SmokeNotary.dmg, 39c9fdf5-0baa-453c-bdd1-7b884fd9e96a, Rejected 2026-05-30 19:58 MSK, SmokeNotary.dmg, 8e14b3a1-5721-4e1a-ab43-000852630e29, was In Progress for about 9 days 23 hours before finally becoming Rejected 2026-05-30 20:43 MSK, FLEX_VIDEO-notary.zip, 1700b9b2-17b5-47c9-8854-cbdbc342d708, Rejected 2026-06-01 18:36 MSK, FLEX_VIDEO-notary.zip, 3d4c986d-af30-4c5c-a987-05ed09b16189, Rejected I have already contacted Apple Developer Programs Support by email / support contact as requested by the notarytool log, but I have not received any response. Could someone from Apple please confirm what exactly needs to be enabled or fixed for this Developer Team? Is statusCode 7000 something that only Apple can resolve on the backend? Thank you.

Hello Apple Developer Support, I am requesting maximum escalation for this case. My paid Apple Developer Program account has been unusable for Developer ID notarization for more than two weeks. This blocks macOS distribution entirely, despite the fact that the membership is active and all visible account requirements appear to be completed. Team ID: GRP4HM9M63 Apple Developer Program: Active Account status already checked: Apple Developer Program membership is active Apple Developer Program License Agreement is accepted Apple Developer Agreement is accepted Free Apps Agreement is active W-8BEN tax form is active Developer ID Application certificate exists and is active The applications are signed with Developer ID Application Hardened Runtime is enabled Local codesign verification passes Despite this, notarization is still unavailable for this Team. This is not an issue with a specific app, archive, DMG, ZIP, signing configuration, or binary validation. Multiple different apps and archives are rejected with the same account-level error before binary validation. Recent failed submissions: Cassini.zip Submission ID: a429460d-cdf9-47cc-9731-90bac71286af Status: Rejected Status code: 7000 Status summary: “Team is not yet configured for notarization. Please contact Developer Programs Support at developer.apple.com under the topic Development and Technical / Other Development or Technical Questions.” Issues: null Lunoura.zip Submission ID: 3aa46853-b3c7-4076-a08d-f9e4db9bea64 Status: Rejected Status code: 7000 Status summary: “Team is not yet configured for notarization. Please contact Developer Programs Support at developer.apple.com under the topic Development and Technical / Other Development or Technical Questions.” Issues: null Earlier submissions for Cassini.dmg and Cassini.zip were also rejected with the same statusCode 7000. Since multiple unrelated archives are affected and all logs contain issues: null, this clearly appears to be a Developer Team/account configuration issue on Apple’s side, not an application validation issue. Please escalate this case to the appropriate Developer Program / notarization backend team and urgently check the notarization configuration for Team ID GRP4HM9M63. Please explicitly confirm: Whether Team ID GRP4HM9M63 is currently enabled for Developer ID notarization. Whether there is any hidden account, KYC, legal, compliance, tax, or backend configuration issue blocking notarization. Whether Paid Applications Agreement or bank account setup is required for Developer ID notarization, even though we are not distributing paid apps. What exact action is required from our side. When this paid Developer Program account will become usable for Developer ID notarization. This issue has already blocked us for more than two weeks. We are paying for Apple Developer Program membership, but cannot use a critical Developer ID distribution feature.

Hi, I'm a new Apple Developer Program enrollee (1 week in) shipping a Mac app via Developer ID + notarytool. Hardened runtime enabled, properly timestamped, all embedded Mach-O signed inside-out. 10 submissions are stuck "In Progress" - the oldest from 2026-06-07 (60+ hours ago). One Invalid verdict came back on 2026-06-08 for a real signing issue (unsigned PyQt5 framework binaries) which I've since fixed; the 10 newer submissions should pass cleanly. Apple's system status page has shown Developer ID Notary Service as green ("Operational") this entire time. This appears to be a queue issue specific to my account, not a service-wide outage. xcrun notarytool history: createdDate: 2026-06-09T16:26:37Z id: 4c928b64... status: In Progress (17h) createdDate: 2026-06-09T16:25:26Z id: 74e9feed... status: In Progress (17h) createdDate: 2026-06-08T21:13:31Z id: 8b246574... status: In Progress (37h) createdDate: 2026-06-08T20:59:37Z id: 4a529617... status: In Progress (37h) createdDate: 2026-06-08T18:49:33Z id: ff43d591... status: In Progress (39h) createdDate: 2026-06-08T18:46:27Z id: 60579d8d... status: In Progress (39h) createdDate: 2026-06-08T18:36:02Z id: a82fd14b... status: In Progress (39h) createdDate: 2026-06-08T18:22:45Z id: 4514a5cb... status: In Progress (39h) createdDate: 2026-06-07T21:20:09Z id: 700c8413... status: In Progress (60h) createdDate: 2026-06-07T20:18:08Z id: 2ea83c6c... status: In Progress (60h) xcrun notarytool info on each returns "status: In Progress" with no processedDate set. I understand new submitters can get held for extended in-depth analysis on first submissions, but 60+ hours is past any documented expectation for that. Could a DTS engineer please look at the backend logs and either release the queue or tell me what's specifically blocking these submissions? Thanks!

Hi, I recently enrolled in the Apple Developer Program and I’m trying to notarize my first Developer ID apps for distribution outside the Mac App Store. All of my valid notarization submissions are stuck in “In Progress”. The oldest one has been stuck since 2026-06-03, and newer submissions are stuck too. None of the valid submissions have moved to Accepted or Invalid, and no log is available. Team ID: TP32Y96XC5 Feedback Assistant: FB22994785 https://feedbackassistant.apple.com/feedback/22994785 Oldest stuck submission: 07865316-b2e0-4529-9790-97a63746d9a9 Hello Developer ID Test.dmg Created: 2026-06-03T12:20:18.595Z Status: In Progress This also happens with other apps/artifacts, so it seems like it may be account-level or team-level rather than an issue with one specific build. Other stuck submissions include: f1574597-154e-4386-a0b1-5560a57dde9d Azad IDE.zip Created: 2026-06-03T23:40:55.335Z aab15661-a883-413a-8a5d-8c78d1d0dabb Azad IDE.zip Created: 2026-06-05T11:29:46.664Z df4bb6dd-38fc-4083-92fa-d0846037fd53 MyMacOSApp-0.1.1-Darwin.dmg Created: 2026-06-05T11:52:54.093Z 305d56b7-a66a-4881-b649-c8738e39f3f2 Azad IDE.zip Created: 2026-06-08T10:58:24.724Z 1947d3c3-fc84-4479-9bee-355c16d51670 Azad IDE.zip Created: 2026-06-08T11:19:58.848Z What I checked: Developer ID certificate is installed and valid. The apps are signed with Developer ID Application: Matan Nahmani (TP32Y96XC5). codesign verification passes locally. Hardened runtime is enabled. notarytool authentication works. notarytool history/info works. notarytool log says the submission log is not yet available for the stuck submissions. I have not received a rejection email for the stuck submissions. Apple Developer System Status shows the notary service as available. Note: I do have one Invalid submission, but that one was intentional. I created it as a negative-control test while following a notarytool tutorial, to confirm that invalid submissions can produce a terminal status. The issue is that all valid Developer ID submissions remain stuck in In Progress. I understand that first-time notarization can take longer because of deeper analysis, but this has now been several days and every valid submission is still pending. Could someone from Apple DTS or the notarization team check whether Team ID TP32Y96XC5 is stuck in the first-time review/notarization queue? Thanks.

Seeing my notarizations getting stuck. This is becoming a blocker for releasing. What's strange is that earlier versions of the same app (very similar) passed notarization very quickly. Any advice or recourse?

I've read Quinn's response on thread 827096 about Developer ID notarization submissions held for "in-depth analysis" on new teams. That guidance fits the general shape of what I'm seeing, but I'm posting a separate thread because (a) my situation does not involve an app transfer — these are the first-ever notarizations under a newly activated team, and (b) I've passed the "usually clears in a day or two" expectation and want to ask a few specific questions that thread didn't cover. Setup macOS app distributed outside the App Store Rust universal binary (aarch64-apple-darwin + x86_64-apple-darwin, merged via lipo) Binary signed with Developer ID Application, hardened runtime (--options runtime) and Secure Timestamp (--timestamp) .pkg built via pkgbuild + productsign with Developer ID Installer Team was activated 2026-05-29 — these are our first notarizations under the account, no prior submission history Submissions Submission A — submitted 2026-05-29T19:18:02Z, currently 100+ hours In Progress Submission B — submitted 2026-06-01, currently 30+ hours In Progress, identical polling behavior (Submission IDs available to DTS on request — happy to share via DM or via the Apple Developer Support case we have open on the same issue.) I submitted B specifically to test whether A was a one-off stuck queue entry. Both stalling identically rules that out and points at a team-level condition rather than a per-submission issue. xcrun notarytool log returns Submission log is not yet available or submissionId does not exist for both — same as the OP's experience on 827096. Local verification — every check in TN2206 passes $ pkgutil --check-signature .pkg Status: signed by a developer certificate issued by Apple for distribution Signed with a trusted timestamp on: 2026-05-29 19:15:36 +0000 Certificate Chain: Developer ID Installer: () Developer ID Certification Authority Apple Root CA $ codesign --verify --strict --verbose=2 valid on disk satisfies its Designated Requirement $ codesign --display --verbose=4 | grep -E '^(Authority|Timestamp|Runtime|TeamIdentifier)=' Authority=Developer ID Application: () Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=May 29, 2026 at 12:13:40 PM TeamIdentifier= Runtime Version=26.5.0 xcrun notarytool history returns successfully and lists both submissions, so authentication and connectivity to the notary service are healthy. Developer System Status has shown the Developer ID Notary Service as "Available" throughout. Questions for DTS (Quinn or whoever picks this up) Quinn's 827096 reply describes "in-depth analysis" for new teams clearing in a day or two. Is there a known long-tail beyond that window, and is there anything a team can do to flag itself as ready for processing rather than waiting passively? Does resubmitting (as I did with submission B) extend, restart, or sit independently from the review of submission A? Is the review-completion clock driven by the team's activation date, the first submission, or the cumulative submission history? In other words, does each new submission help the team's signal, or does the system wait for the first to fully clear before evaluating subsequent ones? If we hit the 1-week mark Quinn referenced as the escalation tripwire without resolution, what's the recommended channel — a follow-up reply here, a new thread, Feedback Assistant, or another route? We also have an open Apple Developer Support case on this, currently silent for 4 days. Working that channel in parallel. Thanks in advance for any guidance — and thanks to Quinn for the public visibility he's given this pattern on 827096; it's the most useful documentation on it I've been able to find.

Hello, Adding our case to the long-running thread on this issue (https://developer.apple.com/forums/thread/118465). Our team is the latest to be hit by statusCode 7000 "Team is not yet configured for notarization", and we'd like to (a) document the data points in case it helps Apple correlate cases and (b) ask the community whether anyone has seen a faster resolution path than what's been reported here over the past 6 years. Our situation Team ID: A92X4FJ5HU Last successful notarization: 2026-05-18 11:23:26 UTC First rejection: 2026-05-18 17:19:15 UTC (~6 hours later, no apparent trigger on our side) Total rejections since: 22 submissions across 9 days, 100% rejected with statusCode 7000 Open support case: 102900780153 What we have already verified Apple Developer Program membership Active (Renewal Sept 17, 2026) Apple Developer Program License Agreement: Accepted Apr 15, 2026 Free Apps Agreement: Active (Apr 15, 2026 — Sept 16, 2026) Paid Apps Agreement: Active (Mar 17, 2026 — Sept 16, 2026) Banking and tax information complete Developer ID Application certificate valid (notBefore 2025-10-12, notAfter 2027-02-01) What we tested Variable Result API key A (Admin role, created 2025-10) Rejected, statusCode 7000 API key B (Admin role, created 2026-05-22) Rejected, statusCode 7000 Same Issuer ID, both keys Same rejection Bundle ID com.matrixai.app (one product) Rejected Bundle ID com.flowith.os.beta (different product) Rejected Locally-rebuilt clean DMG Rejected Pre-existing already-signed DMG Rejected The rejection happens server-side after upload completes — authentication, signing, hardened runtime, and timestamp are all confirmed correct (codesign verifies cleanly, both keys authenticate). The submission is accepted by the notary service, then rejected with statusCode 7000 after a few minutes of "In Progress". Sample submission IDs (all rejected, statusCode 7000) ac52531f-1b9e-4210-8123-54afea90f66f (2026-05-27 10:20 UTC) baba6420-e245-4597-b229-ec5af4b309c5 (2026-05-27 10:23 UTC) 72118f71-9f1d-4ce9-8068-3eca5017104d (2026-05-27 09:49 UTC) Question to the community I've read this entire thread (all 4 pages, 6 years of reports) and the related threads (749857, 813624, 825906, 827589, 130479, 130494, 741721, 809228). The consistent answer from DTS is "this is a Developer Program Support issue, escalate via official channels", but the threads also document wait times of 1 day to 3+ months with no SLA and no transparency. A few questions: Has anyone in 2025 or 2026 had this resolved in under 2 weeks? If yes, what (if anything) on your side accelerated it? Did anyone identify a specific account-level signal (recent agreement re-acceptance, banking change, AppID/Bundle ID conflict, recent role/Account Holder change, recent device verification, etc.) that correlated with the trigger date? Is there any escalation path beyond Case → DPS → "engineers are working on it" loop? Several users on this thread report 39 days, 3 months, 4 separate cases — and DPS still cannot give an ETA. I understand the official answer is "wait for Developer Program Support". Posting this here primarily so Apple has more correlated data points for the engineering team that owns notarization, and so other developers who hit this in the future can find one more datapoint. Thanks.