Signtool.exe has stopped working.

Paul Baker 0 Reputation points
2026-08-27T09:47:54.4+00:00

When I try to sign an exe file using signtool.exe, a Microsoft login screen appears. When I enter my email address I get the following:

"Selected user account does not exist in tenant 'Microsoft Services' and cannot access the application '04b07795-8ddb-461a-bbee-02f9e1bf7b46' in that tenant. The account needs to be added as an external user in the tenant first. Please use a different account."

I have tried adding another email as a guest (via invitation) and then get a code sent to the other email aaddress. When I enter the code I get a message "Something went wrong".

The only thing that I can think of is that my certificate was automatically renewed a few days ago by Microsoft.

I can log in to the Azure Portal using my original email address and everything looks OK.

Also I have tried closing the browser, deleting cookies and trying again - as recommended on a help website. This had no effect.

I have spent a lot of time truing to figure out what has gone wrong but got nowhere. Any help will be greatly appreciated.

Paul Baker

Artifact Signing
Artifact Signing

A fully managed end-to-end service for digitally signing code, documents, and applications. (formerly Trusted Signing)

0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. SHOUMIK CHAKRAVARTY 245 Reputation points
    2026-09-02T01:35:43.8766667+00:00

    Hi @Paul Baker - It looks like you’re signing in with a personal Microsoft account rather than a work account that exists in your Entra directory, and that’s what signtool is objecting to.

    The reason the Azure portal still works is that those two things behave differently. A personal Microsoft account can be granted access to an Azure subscription and work perfectly fine in the portal without ever existing as a user inside the directory that subscription belongs to. The portal doesn't check for that, and signtool does, because signing requires you to exist in the directory, and yours doesn't appear to.

    You can see the mismatch in the error message. The tenant it names, “Microsoft Services,” isn’t your directory, which means the sign-in never reached your tenant at all. That may also be why the guest invitation didn't help: you were inviting a guest into your directory while the authentication was resolving somewhere else entirely.

    The GUID in the error is worth noting too. 04b07795-8ddb-461a-bbee-02f9e1bf7b46 is just the Azure CLI's client ID, and there's nothing signing-specific about it. Signtool uses the normal Azure identity chain, and that chain picked up your personal account.

    To confirm all of this, open Microsoft Entra ID in the portal, go to Users, find your account, and check the Source column. If it says Microsoft Account instead of Microsoft Entra ID, that’s the root cause.

    The fix is to use a member user in your directory rather than a guest. Create a member user in Entra ID, assign it the signing role on your Artifact Signing resource under Access Control (IAM), and sign in as that user when signtool prompts you.

    If you’d prefer to avoid interactive sign-in altogether, you can register an app, create a client secret, and set AZURE_CLIENT_ID, AZURE_TENANT_ID, and AZURE_CLIENT_SECRET. One thing about the environment variables: whichever way you set them, open a new terminal afterward. Existing ones won't pick them up, and you don't need to reboot.

    And the certificate renewal is just a coincidence. Renewal doesn’t change how you authenticate, and this failure is happening before any certificate is involved.

    Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution.

    Was this answer helpful?

    1 person found this answer helpful.
    0 comments

  2. AI answer

    2026-08-27T09:48:13.4933333+00:00

    This error is typically caused by authenticating with a personal Microsoft account instead of a Microsoft Entra work or school account for Artifact Signing/Trusted Signing.

    What the error means:

    • Selected user account does not exist in tenant 'Microsoft Services' commonly appears when SignTool’s authentication flow is using a personal account.
    • Sending a guest invitation to that account does not fix the interactive signing flow.
    • This is a known limitation, not usually a certificate-renewal problem.

    What to do:

    1. Verify which account is being used in the browser sign-in prompt.
      • If it is a personal Microsoft account, switch to a Microsoft Entra work/school account.
    2. If only a personal account is available, create or use a Microsoft Entra tenant and a member user in it.
      • In Entra admin, create a new user as a Member.
      • Use that Entra user for signing instead of the personal account.
    3. Assign the correct role to that Entra account.
      • In the Trusted Signing/Artifact Signing resource, go to Access Control (IAM).
      • Assign Artifact Signing Certificate Profile Signer to the Entra user that will sign.
    4. If interactive browser sign-in continues to fail, use service principal authentication instead.
      • Create an app registration.
      • Create a client secret.
      • Set these Windows environment variables:
        • AZURE_CLIENT_ID
        • AZURE_TENANT_ID
        • AZURE_CLIENT_SECRET
      • Reboot Windows so the variables are picked up.
      • Then run SignTool again.
    5. If the signing command reaches SignTool but fails after authentication, check common Artifact Signing causes:
      • 403: verify the subscription is registered, the signer role is assigned, the certificate profile is active, the account/profile names in metadata.json are correct, and the identity validation status is Completed.
      • 0x80004005: if using service principal + certificate authentication, verify the required environment variables.
      • 0x8007000b for MSIX: verify the manifest publisher matches the certificate subject.

    Important note:

    • The automatic renewal of the certificate is not the supported explanation in the provided guidance for this tenant error.
    • The strongest match for this exact symptom is account type/tenant mismatch during Trusted Signing authentication.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.