A fully managed end-to-end service for digitally signing code, documents, and applications. (formerly Trusted Signing)
When an Artifact Signing organization identity validation ends in Failed with no detailed reason in the Azure portal, the available options to understand the cause are limited to what the service exposes and to direct support channels.
From the documented behavior:
- Portal behavior for Failed validations
- When identity validation fails and it is not due to missed email verification, it means the Microsoft validation team could not make a determination based on the information provided, even after any requested additional documentation.
- In that case, the process ends in Failed and the portal does not expose a granular failure code such as “name mismatch” or “tax ID mismatch”.
- Email verification vs. other failures
- If the failure were specifically due to email verification (for example, the primary email verification link was not used within 7 days), the guidance is explicit: a new identity validation request must be created, and the link cannot be resent on the same request.
- If the status is Failed and there was no missed email verification, the failure is due to the validation team being unable to validate the organization with the data and documents available.
- When validation fails after AU10TIX / secure.me flow
- The documentation states that if identity validation fails and is not an email issue, and the team cannot validate the information even after additional documents (up to three attempts), onboarding cannot proceed.
- In that scenario, the recommendation is to delete the Artifact Signing account to avoid billing for unused resources.
- How to get more insight or proceed safely
Given that the portal does not surface detailed failure reasons, the only supported ways to get more clarity or next steps are:- Open an Azure Support ticket for the subscription that hosts the Artifact Signing account and reference the Identity Validation ID. This is the only channel where Microsoft staff can look at backend validation details and advise whether a new request is likely to succeed and what to adjust (if possible).
- Use Microsoft Q&A with the
artifact-signingtag to describe the scenario (without sensitive data). Product team or support engineers may request that a support ticket be opened for tenant-specific investigation.
- Before submitting a new request
The documentation does not provide a way to self-diagnose the exact backend failure, but it does recommend the following when creating a new public identity validation:- Ensure public records for the legal entity are up to date and consistent with:
- Legal organization name
- Business identifier
- Address
- Domain/website ownership
- Ensure all information entered is accurate; any change after creation requires a new identity validation request.
- If email verification failed, a new request is mandatory.
- If additional documentation was requested, ensure documents:
- Are issued within the last 12 months.
- Have an expiration date at least two months in the future.
- Match the company name and address exactly as entered in the request.
- Include domain registration or invoices that clearly link the domain to the entity and contact.
- Ensure public records for the legal entity are up to date and consistent with:
- If validation ultimately cannot succeed
- If the validation team cannot validate the organization after the allowed attempts, onboarding to Artifact Signing cannot proceed.
- In that case, the guidance is to delete the Artifact Signing account so that there are no charges for unused resources.
In summary, when an organization identity validation shows Failed with no detailed reason, the best and only supported way to identify the cause is to engage Azure Support (and optionally Microsoft Q&A with the artifact-signing tag). The portal itself does not provide granular failure diagnostics beyond the final status, and repeated identity validation requests with the same data do not help unless the underlying information or documentation has been corrected.
References: