Working with Microsoft 365 at scale means building your entire environment around trust, security, and operational resilience. You align with best practices. You invest in automation and governance. You use Privileged Identity Management (PIM) to control and limit admin access. Because that is what Microsoft recommends. It is also the right thing to do.
So you would expect Microsoft Support, the very team that should understand and follow those standards, to use the same principles.
Unfortunately, that is not always the case…
What is PIM?
Privileged Identity Management (PIM) is a feature in Microsoft Entra that allows organizations to manage, control, and monitor access to important roles within Microsoft 365, Azure, and other connected services. Instead of granting permanent admin privileges, PIM enables just-in-time access, meaning that users can request temporary role elevation to perform a task and then automatically lose that access once the task has been completed.
With PIM, you can:
- Limit how long a user has access to a sensitive role
- Require justification or approval before access is granted
- Enforce MFA for elevation
- Get alerts and logs of who activated a role, when, and why
It is a core part of any modern Zero Trust or least privilege strategy and is considered best practice for protecting elevated roles like the Global Administrator role.
Security becomes a barrier
I recently found myself in a frustrating situation with Microsoft Support. A case required me to prove that I had Global Admin rights in our tenant. No problem! I activated the role using PIM, Support checked, and I then removed the role again. That is how we work, by design.
But apparently, that was not enough.
I was asked to keep the Global Admin role assigned permanently. Not temporarily. Not just during troubleshooting. But as a standing assignment, with no clear timeline and no real justification other than that Microsofts interal processes required it.
This is where it becomes completely unreasonable.
Not only is it a security risk, we also have Conditional Access rules in place that require reauthentication every few hours when an elevated role is active. That is by design. It protects us. But it also makes it impossible to work effectively if that role is always on. Being asked to break that model, just to support Microsofts internal process, is not just frustrating. It is unacceptable.
Let me quote directly from Microsofts documentation:
“We recommend you keep zero permanently active assignments for roles other than your emergency access accounts.
Microsoft recommends that organizations have two cloud-only emergency access accounts permanently assigned the Global Administrator role. These accounts are highly privileged and aren’t assigned to specific individuals. The accounts are limited to emergency or “break glass” scenarios where normal accounts can’t be used or all other administrators are accidentally locked out. These accounts should be created following the emergency access account recommendations.”
Source: Plan a Privileged Identity Management deployment
This is really not a suggestion. It is a best practice that Microsofts support teams should follow too. Yet they asked me to ignore it.
Putting the customer at risk
This kind of support process forces customers into an impossible position. It directly contradicts Microsofts own guidance. It introduces unnecessary risk. And it sends the wrong message to organizations that are working hard to implement least privilege and just-in-time access.
I asked for the issue to be escalated. That request was blatantly ignored. The support technician informed me that the internal teams require my Global Admin role to remain active for more than a week. No exact timeline was provided, and it was made clear that the process could take even longer.
Forcing customers to keep elevated access active for an undefined period contradicts Microsofts own security recommendations. It puts our environment at risk. And it disregards the principles of least privilege and secure identity governance that we are expected to follow.
Microsoft really should revise this process to align with its own security standards. No customer should be forced to compromise secure operations to satisfy internal, clearly flawed, administrative requirements.
Security is not a checkbox
Security is a mindset that shapes how we design, deploy, and manage our environments. That should be reflected across the entire Microsoft ecosystem. This includes not only the products and documentation but also how the support teams operate in practice.
When Microsoft promotes least privilege, PIM, and just-in-time access as best practices, customers listen. Many of us have invested significant time and resources aligning out organizations with that in mind. We have implemented Conditional Access, PIM, RBAC, and trained our teams to remove standing privileges wherever possible.
So it is really not acceptable for Microsoft Support to ignore that reality.
Support processes that require customers to violate these principles introduce real risk. They also damage trust. When support staff goes against the very standards that Microsoft recommends customers to follow, it creates unnecessary friction. It punishes the organizations that are actually trying to do the right thing.
It should not be the customers responsibility to defend good security practice during a support case. It should be Microsofts responsibility to ensure that its internal processes support secure operations.
This is not about being uncooperative. It is about protecting our environments, reducing risk, and upholding the governance models we have built with intention. Microsoft must make sure its own support operations respect and follow the same standards as it recommends. Is that really to much to ask?
Security is not something that should be compromised due to an outdated internal process.
Would you comply with Microsoft and do as they ask without any justification?
Please let me know in the comments.
