PSA: Verified Publisher (Wrong) Assumptions

First and foremost, thank you, Nilesh Vishwakarma and Deepack, for sharing your internal knowledge to dispel the unnecessarily confusing topic of App Verified Publisher.

I'll dive into the details of the issues, the confusion, and what I gathered during a few meetings with Microsoft Support. But first, for those seeking the simple TLDR guidance (specifically for the Verified MPN):

1. The organization/tenant the App is under must have its own Partner Account; you can't come in with your own MPN for your clients; it needs to be their (your clients') MPN Account.
2. Even if you created the App (the App Owner), you need some sort of Global Admin type access, and it seems like you also need some access in the associated MPN account.
3. VERY IMPORTANT: Even if you can see and click on the Verified Publisher link to add an MPN ID, any errors you encounter are likely due to lacking rights in one or both systems.
4. VERY IMPORTANT: The Microsoft documentation for troubleshooting this issue may lead you astray.

After several days of troubleshooting on my own—reading, researching, and even involving Microsoft Support—the issue was finally resolved when my client created an MPN account, logged into Entra, clicked the Verify link, and entered their MPN ID. The takeaway here? Assume you're at the mercy of the zero trust hammer, and for something as simple as single sign-on authentication, your clients must become Microsoft Partners.

For those not interested in the juicy details or listening to a grumpy gray beard rant, you are hereby released; the above are the main points to remember when applying a Verified Publisher to your App. For the rest of you, read on, and hopefully, you'll pick up more details and maybe even find it entertaining...

First, if you are creating a simple App for SSO (work/school) for use on your client's website, you need to create the App on the tenant that holds the AD/Entra accounts. This makes sense. Furthermore, a publisher is required to be on the hook for and prove the validity of the App, visible to users during the consent. This also makes sense. However, what doesn't make sense is that the App Owner cannot assign the MPN ID, and even more so, anyone who is creating that App for their client needs also to have access to their client's MPN Account, and, for that matter, that the client should even need that MPN Account.

Let's start with an extreme example... I'm building a website for a construction company that doesn't have an IT team. Because they have AD/Entra and I'm a loyal "Microsoft Partner" (see what I did there), we decided to go with Azure and Entra. First, I need to explain the access I think I need to the client (who is not technical). I'm on my way, creating the App and website, and I get to this Verified Publisher thing. Okay, no problem... I can click on this link to add my MPN ID. Nope, that's the first error. After finally figuring out that they need to become a Microsoft Partner, you help walk your (again, non-technical) client through this process. Okay, so you are back at the Verified Publisher with your (ahem, I mean their) new MPN ID. Again, you click on the link and add their MPN ID, and another error occurs: "The MPN ID you provided does not exist, or you do not have access to it. Please provide a valid MPN ID and try again." Okay, first, the MPN ID is valid; second, it exists; and third, what access do I need? This kitchen sink error message is not very helpful. But hey, there's a "learn more" link. Okay, so you go through hours of rummaging through the docs, and nothing is really apparent, but look at this—there's a Troubleshooting section. On the first bullet point, step four provides a link to verify the MPN (https://partner.microsoft.com/en-us/pcv/accountsettings/connectedpartnerprofile), but this reveals a "Sorry, something went wrong. Please try again later" error page. With humility, you create one of your two allowed support tickets... and when going through the same steps, they mention something about access and start naming the people that could apply the Verified Publisher... so, we have to call our (non-technical) client again to come on the chat to be walked through how to add the MPN ID, and boom, it works. At this point, you're probably part happy, part embarrassed (for no reason), and part angry.

Here's the problem—well, one of them. If you don't have access to do something, we are all trained to see disabled buttons/links; if the developers are really good, they change the CSS/cursor on hover, and if they're really, really good, they provide a tooltip explaining the access that is needed to click the button or link. BUT, for all that is good, don't provide a clickable link, a non-disabled textbox, and a non-disabled button to add something we can't add in the first place. Furthermore, do not provide an overly elaborate yet somehow vague validation message. I expect more from Microsoft.

Secondly—and this is a self-preservation thing—requiring our clients also to become Microsoft Partners dilutes the value of being a Microsoft Partner. I see a cartoon of a word bubble above a technical person saying, "I'm a Microsoft Partner," and in the next frame, it shows a roofer, a janitor, a homemaker, and a plethora of a thousand people, all with the same word bubble saying, "Yeah, so are we!!!" Although this is a funny view of it, the reality is that it was hard enough to explain to clients why you want to add your MPN ID to their Azure subscription or what that means... but now, why would they, when they have that same feeling of ownership as with the App, and now armed with their own MPN ID? It truly is diluting the value of a Microsoft Partnership and, further, making it harder to justify adding our MPN ID to signal to MS who we are serving. This is directly tied to how we can obtain a Silver or Gold Partnership.

This seems to have been built without consideration for agencies, small businesses, and clients outside the tech field.