Adding another affected team: T84UX6J624 (Cilantro & Co., LLC), App ID com.cilantroco.hipiconica. Same signature as the rest of the thread. The system sheet renders, the user authenticates with Face ID, the sheet then shows "Sign Up Not Completed", and no credential is returned — ASAuthorizationError .canceled (1001) with an empty userInfo. Zero requests reach our backend; our server logs show no failed authentication attempts at all. Reproduced on two physical devices with two different standard (non-managed) Apple Accounts. Ruled out on the client side: APPLE_ID_AUTH with PRIMARY_APP_CONSENT on the App ID, read back from the App Store Connect API. Explicit primary App ID; no wildcard and no grouped identifiers. com.apple.developer.applesignin = ["Default"] verified inside the signed binary with codesign -d --entitlements, not just in the portal. We diffed a build from 20 August that authenticated successfully against a build from 25 August that fails: identical embedded provisioning profile (same UUID, same creation date), identical signing certificate, identical entitlements, identical linked frameworks. The only delta between them is unrelated JavaScript. Agreements active, membership in good standing; Apple System Status shows Sign in with Apple as available. So a binary that signed in successfully on 23 August now fails, with nothing changed in our Sign in with Apple configuration or signing chain. A device-free reproduction, with controls. Following DanCue's note about the public authorize endpoint, this can be checked with a plain HTTP request — no device, no logging profile, no build. Captured 2026-08-26 06:49 UTC against appleid.apple.com/auth/authorize, varying only client_id and holding every other parameter fixed: com.cilantroco.hipiconica (ours) — invalid_client, "Invalid client." host.exp.Exponent — invalid_request, "Invalid client id or web redirect url." com.burbn.instagram — invalid_request, "Invalid client id or web redirect url." com.cilantroco.definitely-not-real-abc123 (never registered) — invalid_client, "Invalid client." Known-good Sign in with Apple clients get past client validation and are rejected on the redirect URL instead. Our registered App ID is rejected at the same stage, with the same wording, as a bundle identifier that has never existed — which is the em = "Invalid client." that Ozvern, moty66 and nazacheres captured in the GSA response on device, reachable without one. Offering it in case it is a useful triage shortcut for others here; DanCue reported this flipping the moment their team was re-provisioned. This is also blocking us in App Review: our 1.0.10 submission was rejected under Guideline 2.1(a), "An error appeared when attempting to log in with Apple", because the reviewer hit this same failure. We have had to disable Sign in with Apple in production so that users can sign in at all — and Google with it, per 4.8. Developer Support case: 20000147837597. @Paris X Pinkney — could the same server-side team registration fix applied to GW7XA5CX69 and FRL3DTJQ62 be applied to T84UX6J624? Happy to verify and confirm immediately, and to attach a sysdiagnose with the Accounts/AuthKit profile if that would help.