Understanding Partner Center Identity & Entra ID

When I first set up my own Microsoft Partner, I made a decision that felt entirely reasonable. I associated Partner Center with my existing corporate Entra ID tenant. It worked, I could sign in, and nothing immediately broke. At the time, it felt like a logical step to keep everything under one roof.

That decision quietly locked in a long‑term constraint.

Convenience during onboarding becomes a permanent design choice

In 2019, Microsoft began tightening up security baselines, requiring partners to enforce multi-factor authentication for all users in their tenants. Suddenly, every account, from the executive suite to the service accounts running your office photocopier, was subject to the same rigid security baselines required to manage customer environments.

Meeting this new baseline would be a challenge.

By associating Partner Center with a general‑purpose corporate tenant, you collapse two very different risk profiles into one. Partner Center is a high‑privilege control plane for customer environments. Corporate Entra ID is designed for broad access, collaboration, and day‑to‑day work. Mixing the two increases the likelihood that a compromise in one place can have consequences somewhere far more sensitive.

MFA is a good idea, but back in 2019 it wasn't universal (it still isn't!), and having to implement this for potentially thousands of users with little notice, when most of them had nothing to do with Microsoft or Partner Center, was a big deal. Some legacy systems just wouldn't be able to meet the requirements, which would lead to non-compliance. This could be a show-stopper if it impacted the partner's ability to transact and administer customer environments.

The guidance exists, but it is easy to miss

I remember crawling through documentation at the time trying to find concrete guidance from Microsoft stating not to use your mail Entra ID and sure enough, I found it. Microsoft’s documentation does state that you should consider not using your corporate tenant for Partner Center. That guidance exists, and it has existed for years. It is just easy to miss, and rarely surfaced at the moment when the decision is actually being made:

Personally, I think the note is too soft. I'd like to see the guidance be more explicit: don't use your main corporate Entra ID tenant for authenticating with Partner Center. I think the problem arises because the people onboarding as a Microsoft Partner within a business might not be the people who understand or care about the impact of a decision like this, and just sign in with their corporate credentials.

Anyway, fast forward to 2026.

By now, MFA will have been implemented but there's still the lingering question of what to do about this Entra ID / Partner Center association. It's still desirable to strictly limit access to Partner Center and keep it well away from your wider corporate environment where you could be prone to lateral movement from an attacker.

For a while, I was convinced it would be possible to add in another Entra ID and remove the original, thereby solving the problem. Certainly on first-pass, the documentation seems to support this. There is an article for adding existing Entra IDs, and another for removing them. Surely, after some due diligence and planning, this would be the perfect solution?

Well, no.

You cannot remove the primary Entra ID tenant

After some brainstorming and testing with a friend of mine who works in a Microsoft Partner, we discovered it isn't possible, and it turns out there's a third article that buries this fact at the bottom of the page.

So while you can add multiple Entra IDs to your Partner Center tenant you cannot remove the original, primary Entra ID tenant. This makes sense when you consider that the ID appears in places like the recon file; it is hardwired into things.

Back to square one then.

(What's also interesting to learn is that when you add multiple Entra ID tenants, roles like Admin Agent, Helpdesk Agent, and Sales Agent only seem to flow from the primary.)

The realistic options in 2026

Once you accept that the original tenant cannot be detached, the available paths narrow quickly:

1. You can migrate your corporate environment into a new tenant and leave Partner Center behind. That is a major transformation project with wide‑ranging implications.
2. You can create a new Partner Center account and migrate customers to it. That carries commercial, operational, and programme‑level consequences, including potential impacts on incentives, designations, and historical data.
3. Or you can accept the situation and mitigate risk through other controls, knowing that the underlying coupling remains.

None of these are clean. All of them involve trade‑offs. The lesson is a pragmatic one: architecture decisions made for "convenience" during onboarding often become the constraints that define your security posture for years to come.

Why this still matters in 2026

From 1st April, 2026, Microsoft will begin enforcing MFA on all App+User usage of Partner Center APIs. So if you're still clinging on to some legacy integrations, or have managed to hold off on MFA for those last few service accounts, you've got some work to do.

When you read the documentation, you'll see a number of common issues, and whether they're good candidates for a technical exception. Needless to say, the answer is uniformly no.

UPDATE

Thank you to Guy Gregory for finding a fourth article that touches on the topic, with slightly more explict guidance!

I'd still make a case that even this isn't clear enough - I think 'avoid' is still too passive.