Stop Creating Secondary Admin Accounts

For years, the standard advice for IT professionals was to have a standard user account for daily tasks (emails, Teams, procrastinating on LinkedIn) and a secondary "Global Admin" account for technical work. The logic was sound for the era of on-premises Active Directory, but in a cloud-native world, this practice is outdated, cumbersome, and frankly dangerous.

The Management Burden and Bad Hygiene

Maintaining two identities for every technical staff member is a recipe for administrative chaos.

When you have secondary accounts, you double your identity footprint. That's two sets of credentials to rotate, two identities to monitor in Sign-in logs, and two accounts that need offboarding when someone leaves the company. That is assuming you don't have a single all-powerful admin account that everyone shares when an admin task needs to be performed (and if you need to ask why that is a bad idea, I'd strongly suggest brushing up on your security fundamentals).

It breeds bad security hygiene. We've all seen it: the admin account that doesn't have an MFA method set up "because it's only used occasionally," or the admin who stays logged into their privileged account all day to avoid the "faff" of switching back and forth. Admittedly, some of these issues can be resolved through policy, but there is a better way.

The Principle of Least Privilege (PoLP)

The goal shouldn't be "Who is an admin?" but rather "What task are you performing right now?"

Every user should operate with the absolute minimum access required to complete their immediate duty. If you are a DevOps Engineer working on a specific resource group in Azure, you don't need to be a Global Administrator. You need the specific RBAC role for that resource.

By moving away from "Admin Accounts" and towards "Admin Roles," you ensure that permissions are tied to the human, not a secondary username.

This is a fantastic way to increase your security posture. It stops the intern from dropping your prod database, while still allowing them to perform the tasks they've been assigned without the risk of destroying the company.

However, there is an even better way. For example, I may need to read metrics and logs on a daily basis, but making actual changes to our infrastructure is very rare (ideally never, with everything running through IaC). Therefore, having Contributor access to Azure resources is over-provisioned for 90% of the time I actually have access to those resources. If you're unfamiliar with how Azure RBAC roles break down, I've written a more detailed explanation on my docs site that may be useful as a reference here. Similarly, in Entra ID I rarely need to update a DNS record or modify a Conditional Access policy, so having Domain Name Administrator or Security Administrator assigned at all times would be too permissive for 90% of my working day.

Privileged Identity Management (PIM)

This is where Privileged Identity Management changes the game. Instead of having "standing access" (permanent admin rights), users should have "eligible assignments." You jump into the Entra portal, activate the specific role you need, provide a justification, and perhaps even pass a fresh MFA challenge. Once the time limit expires, the permissions vanish. Eligibility can also be granted based on conditions. For example, you must be on the office network for the eligible assignment to be activated.

This mitigates the risk of a compromised identity. If your primary account is breached but has no standing administrative rights, the attacker is stuck in a low-privilege state.

The Conditional Access Guardrail

All administrative elevations must be protected by strict Conditional Access (CA) policies.

If someone is activating a privileged role, the requirements should be non-negotiable:

• Phishing-resistant MFA (like FIDO2 keys or Windows Hello for Business).
• The device must be compliant.
• Strict location or IP filtering where appropriate.

The Only Exception: The Break Glass Account

To be clear: I am not suggesting you have zero permanent admins. You must have an emergency access (Break Glass) account.

However, this is a non-human, cloud-only account with a 256-character password stored in a safe (metaphorically or literally). It is excluded from CA policies to ensure you aren't locked out if a policy misconfiguration occurs. This account is never used for daily work. It is monitored with an eagle eye; if an alert fires saying the Break Glass account has signed in, it should mean the building is metaphorically on fire.

The Elephant in the Room: The P2 Tax

I know what you're thinking. "Sean, PIM requires an Entra ID P2 licence."

You're right. It is frustrating that Microsoft gates such a fundamental security feature behind their most expensive identity tier, especially for small businesses and startups. It feels like a "security tax."

However, as an M365 Admin, my stance is firm: P2 is a cost you simply have to absorb. The cost of a P2 licence is negligible compared to the cost of a business email compromise (BEC) or a ransomware incident. Security isn't a luxury feature; it's the foundation of your infrastructure.

The Bottom Line

Ditch the secondary admin accounts. Move to role-based access tied to the individual. Implement PIM so that elevated permissions are time-limited and justified. Protect every elevation with strict Conditional Access policies. Keep a single, tightly controlled Break Glass account for genuine emergencies, and never touch it otherwise.

The tooling to do this properly exists in Microsoft 365 today. The only question is whether you choose to use it.

A Note on Scope

This post is specifically targeted at users in Entra ID, Azure, and Microsoft 365. It is not aimed at local admin accounts on Windows or macOS devices, sudo users on Linux, or any other platform outside of Entra ID. Windows in particular lacks the granular controls that modern businesses require, the access model essentially boils down to Admin or Standard User, with very little in between, but that's a topic for another post.