Microsoft 365, Entra and Intune
Privileged identity management small business tenants can actually run
There are four administrators. Two of them are you, counting the account you use daily and the one you use for administrative work. The other two are the managing director, who has Global Administrator because they set the tenant up in 2019, and a developer who needed it once.
The instinct is that privileged identity management small business tenants run is overkill at this scale. Four people is not an access control problem, it is a conversation. That instinct is half right, and the half that is wrong is the half that matters.
Privileged identity management small business tenants need, and why
Standing privilege is not primarily about trusting your colleagues. It is about what a compromised session can do.
An account holding Global Administrator permanently is one successful phishing attempt, one stolen session token, or one compromised personal device away from being a full tenant compromise. There is no additional step for the attacker after they have the credential, because the privilege is already active. Nothing has to be requested, nothing gets logged as an escalation, and nothing alerts.
The same account with the role eligible rather than active means the attacker has to activate it, which produces an audit event, can require approval, and can require MFA at activation. None of that stops a determined attacker who already holds the credential. All of it produces a signal where there was none, and a signal is what a one-person team is short of.
That reasoning holds at four administrators exactly as much as at four hundred. What changes with scale is the workflow, not the risk.
The licence gate, stated plainly
Entra Privileged Identity Management requires Entra ID P2. It is not in Business Premium, and it is not in E3. It comes with E5, or as an add-on.
This is worth being blunt about because a great deal of advice recommends PIM without mentioning it, and discovering the gap after designing a process around it wastes a week. Microsoft's PIM licensing requirements sets out what is needed.
Two practical consequences. Check whether you already have P2 through a bundle before buying anything, because tenants frequently hold licences nobody has assigned. And check the service plan rather than the licence name, because the plan is what actually gates the feature and the naming is not obvious.
If you do not have P2, the fallback is not nothing. Separate administrative accounts from daily-use accounts, keep the number of standing administrators to two, alert on role assignment changes, and review quarterly. That is most of the benefit without the mechanism, and it is what the RBAC review note describes for the Azure side.
Eligible versus active
Active means the role applies now. Eligible means the person can activate it, for a limited window, subject to whatever conditions you set.
The conditions worth setting for a small tenant:
Maximum activation duration of a few hours, not the default eight. Most administrative tasks take minutes. A window that outlives the task is standing privilege with extra steps.
MFA on activation, always. This is the cheapest control here and the one most likely to matter.
Justification required. The text somebody types is rarely useful in itself. The value is that activation becomes a deliberate act with a record, and the record is what you read six months later when working out how often a role is genuinely needed.
Notification on activation, to you, even when you are the person activating. It reads as noise for a fortnight and then one day it is not you.
Approval when the approver is the requester
This is the small-tenant problem that reference architectures do not address. If you are the only administrator, requiring approval means approving your own requests, which is theatre.
Three honest options.
Do not require approval, require everything else. MFA, short window, justification, notification. The audit trail is intact and there is no fiction about oversight. For most one-person tenants this is the right answer, and it is defensible to an auditor if you say so plainly rather than pretending a control exists.
Make a non-technical director the approver for the highest roles only, typically Global Administrator. This sounds like a bottleneck and works better than expected, because the number of genuine Global Administrator activations per month is small. It also creates a real second pair of eyes on the one role that matters most. The prerequisite is that they can approve from a phone within minutes, and that they know what they are approving.
Reciprocal approval with a peer. If you have a relationship with someone in a similar role at another company, guest accounts as mutual approvers can work. It is unusual and it is genuine independence.
What does not work is configuring approval and then approving your own requests while describing it as segregation of duties. An auditor will ask who approves, and the answer will be visible in the logs.
What it looks like to an auditor
PIM produces exactly the artefacts an access control audit asks for, which is a side benefit worth harvesting.
The activation history answers "who had privileged access, when, and why" with timestamps rather than assertions. The eligible assignment list answers "who could have privileged access". Access reviews inside PIM produce a dated record of somebody having checked.
That combination covers a good deal of what a security questionnaire asks about privileged access, and it is the difference between answering "we limit administrative access" and being able to show it. The book covers how this maps to the relevant Annex A controls if you are heading that way.
Where to start
Two hours of work, in this order.
Find out whether you have P2 and how many. Then reduce standing Global Administrators to two, one of which is a break-glass account that stays permanently assigned on purpose. Then make everything else eligible, with MFA and a short window. Then set a quarterly reminder to read the activation history, because the log nobody reads is the same as no log.
The developer who needed Global Administrator once will not notice. The managing director will need to be told, and the framing that works is that it protects them personally rather than that they are not trusted.