A fully managed end-to-end service for digitally signing code, documents, and applications. (formerly Trusted Signing)
Open an Azure support request against the Artifact Signing account and ask the validation team to inspect the failed request before deleting or recreating it, because the available portal status cannot determine whether the 409 caused the failure or whether a later organization check rejected the request.
What the current evidence establishes
- “Verification successful!” does not mean the complete organization validation succeeded. In the organization workflow, successful individual identity verification returns the request to In Progress while organization validation continues; only a final Completed status means the entire request passed. ^1^
- Authenticator’s two presentation activities and the browser success page indicate that the presentation flow progressed, but only the service-side callback status
presentation_verifieddefinitively records successful credential validation. Support must inspect that callback and correlate it with the later failure. ^2^ - A Cosmos DB 409 means a resource-creation conflict, commonly that the requested resource ID already exists. In this flow, the message surfaced from Microsoft’s validation workflow; it does not by itself prove an identity or organization-data mismatch. ^3^
- Therefore, the available evidence cannot determine whether:
- the credential presentation completed and a subsequent persistence operation collided,
- the 409 prevented presentation state from being committed, or
- presentation succeeded but organization vetting later failed independently.
Open the private support case
- In the Azure portal, open the affected Artifact Signing account.
- From its resource menu, select Help → Support + Troubleshooting.
- Complete the diagnostics; if unresolved, select Create a support request. This route associates the case with the affected resource. ^4^
- Request escalation to the Artifact Signing identity-validation/Verified ID backend team and ask them to preserve and inspect the existing failed request.
Include:
- Identity Validation ID
- Artifact Signing account name, subscription, region, and tenant
- Request ID and correlation ID
- Exact timestamps with
JST (UTC+9)and UTC equivalents - The complete 409 text
- Authenticator presentation timestamps
- Screenshot of Verification successful
- Screenshot of the final Validation Fail
- Confirmation that the one-time link now reports it was already used
- Confirmation that the AU10TIX credential remains in Authenticator
- Whether both presentation events refer to the same validation request
Ask support to confirm these backend points explicitly:
- Did the callback reach
presentation_verified,presentation_error, or onlyrequest_retrieved? - Was the 409 generated while storing the presentation result or during a later workflow operation?
- Was the terminal failure caused by organization vetting, identity-claim matching, or a service-state conflict?
- Can the failed validation resource be reset/reprocessed?
- If not, should it be deleted and recreated, and may the existing Verified ID be presented?
Creating a technical support request requires an eligible Azure support plan and an appropriate subscription role such as Owner, Contributor, or Support Request Contributor. If no technical support plan is available, Microsoft Q&A with the Artifact Signing tag is the documented alternative; post only non-sensitive details and provide identifiers through a private channel when requested. ^4^ ^5^
Do not recreate it yet
Keep the failed request and credential intact until support captures the backend state. Creating additional requests for the same entity while one is being investigated does not help, and similar failures without a displayed reason have required backend handling. ^5^ ^6^
If Microsoft confirms that the request cannot be recovered, follow its direction to delete and recreate the identity validation, not the Artifact Signing account. The official FAQ says an existing valid, unexpired Verified ID can be presented for Artifact Signing, so credential reuse is supported in principle. However, support should confirm whether this AU10TIX credential remains associated with the failed transaction or is reusable after the 409. Do not remove it from Authenticator unless instructed. ^5^
For any replacement request, verify that the primary email is a monitored mailbox on a domain owned by the legal entity and that the legal name, business identifier, and registered address match current public records. These are prerequisites, not an established explanation for this 409. ^1^
References