Organization identity validation: AU10TIX returns NOT_MEET_REQUIREMENTS after ID scan

Question

What is happening

An Organization / Public identity validation for a Danish company (ApS) has been sitting in Action Required since submission. The organization review itself appears to have gone through; the blocker is the individual Verified ID step.

Walking the documented flow:

1. Follow "Please complete your verification here" from the identity validation blade. This opens credentials.microsoft.com and correctly shows Present your Verified ID.
2. No credential exists yet, so follow "Get verified here through our trusted ID-verifiers" into AU10TIX.
3. Email approval, PIN and phone number all succeed.
4. The government-ID scan completes on the mobile device.
5. Immediately afterwards AU10TIX redirects to vc.au10tixservices.com/error showing "Sorry, you do not meet requirements to create a Verified ID at this time".

The underlying API response is:

{
  "status": "canceled",
  "errorMessage": "NOT_MEET_REQUIREMENTS",
  "redirect": false,
  "supportUrl": "https://learn.microsoft.com/partner-center/get-verifiable-credentials"
}

Because no credential is ever issued, scanning the presentation QR in Microsoft Authenticator fails with "VerifiableCredential - missing card", and Face Check has nothing to match against. This has now happened on more than one attempt.

Already ruled out

• The name on the government-issued ID matches the name on the validation request exactly.
• The document is valid and unexpired, scanned in good light per the AU10TIX guidance.
• Microsoft Authenticator is installed and current.
• The signed-in account matches the primary email on the validation request.
• The refusal is not the Entra "create a Verified ID" licensing gate - it comes from AU10TIX itself, after the document has been read.

This does not look account-specific

Identity validation failed for Artifact Signing reports the identical error on the same day, also on an organization identity validation - but from the United States, using a U.S.-issued government ID. That rules out country, document origin and the US/Canada individual-developer restriction as explanations.

That reporter also deleted their validation request and created a new one with corrected names, and hit the same error again. So recreating the request is not a workaround, and it costs the completed organization review.

Two further identity-validation reports appeared on this tag within the same 48 hours (a postal-code mismatch, and an organization verification stuck in "In Progress"), which suggests something broader rather than a set of unrelated user errors.

Questions

1. Is there a known issue affecting AU10TIX Verified ID issuance for Artifact Signing identity validations at the moment? Two independent organization validations on different continents failing identically on the same day points that way.
2. What is the underlying decline reason behind NOT_MEET_REQUIREMENTS? The API exposes no sub-code and the error page gives no detail, so there is no way to tell whether this is a document, geographic or policy decision. Without it, retrying just burns the attempt limit.
3. Can the AU10TIX voucher / attempt count be reset on the existing request? Creating a new identity validation request discards the completed organization review and restarts a multi-week process - and per the report above, it does not resolve the error anyway.

Happy to share the identity validation ID, subscription ID, correlation ID, gateway request ID, AU10TIX session ID and the mscvid by private message.

Answer 1

Hello @Shakir Shaker

Based on the troubleshooting you've already completed, I don't think recreating the Artifact Signing identity validation or repeatedly retrying AU10TIX is the appropriate next step.

The important sequence here is:

Artifact Signing organization validation => Action Required => AU10TIX email/PIN verification succeeds => Government ID successfully captured => AU10TIX returns NOT_MEET_REQUIREMENTS => No Verified ID issued => Authenticator cannot present a credential

Microsoft's documented Artifact Signing workflow confirms that AU10TIX must first create the Verified ID, which is then added to Microsoft Authenticator and presented back to Artifact Signing.

Since AU10TIX terminates the process with:

{
  "status": "canceled",
  "errorMessage": "NOT_MEET_REQUIREMENTS"
}

there is no credential for Authenticator to present. Therefore, the subsequent VerifiableCredential - missing card behavior appears to be a consequence of the failed AU10TIX issuance, rather than a Microsoft Authenticator problem.

There are also other recent Artifact Signing reports showing very similar AU10TIX failures where valid identity documents are accepted/captured but the Verified ID isn't issued. This doesn't prove a service-wide incident, but it does make further blind retries less useful.

I would not delete the existing organization validation. Microsoft documentation/community guidance also indicates that creating duplicate validation requests while one is already in progress doesn't help, and in your case you've already established that recreating the validation isn't a reliable workaround.

At this point, I believe the existing validation needs review by the Artifact Signing / Verified ID team, potentially together with AU10TIX, to determine what NOT_MEET_REQUIREMENTS represents for this particular transaction and whether the verification attempt can be reset.

You already have exactly the information that would be useful for backend investigation:

• Identity Validation ID
• Subscription ID
• Correlation ID
• Gateway Request ID
• AU10TIX session ID
• mscvid
• UTC timestamp of the failed attempt

Please don't post those identifiers or any identity documents publicly.

Microsoft moderator: Could you please help escalate this existing Organization/Public validation to the Artifact Signing identity-validation team? The failure occurs specifically during AU10TIX Verified ID issuance after successful document capture, and the only backend response exposed to the customer is NOT_MEET_REQUIREMENTS. It would also be helpful to confirm whether the AU10TIX attempt/voucher can be reset without deleting the existing organization validation.

Until the underlying decline reason is known, I wouldn't recommend additional AU10TIX attempts because the customer has already ruled out the common name, document-expiration, account and Authenticator issues.

Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.