Just enough access, for just long enough: Microsoft Entra Privileged Identity Management, and how to reach the same outcome on premises and in other clouds.
VERSION 1.0 | 07/10/2026Most serious breaches depend on an attacker obtaining administrator rights, and most organisations make that easier than it needs to be. Administrators hold powerful rights around the clock, even though they use them for only a few hours each month. Every one of those idle hours is exposure that buys the organisation nothing.
This strategy replaces permanent administrator rights with rights that are requested when needed, limited to the task, and removed automatically. Microsoft Entra Privileged Identity Management (PIM) delivers this for the Microsoft estate at modest cost, and it allows most administrators to work from one account instead of two. That simplicity is a real benefit, provided the single account is protected by sign-in methods that resist phishing.
PIM does not reach on-premises systems, other cloud platforms, or shared accounts such as root and local administrator. Those areas need either the native tools each platform provides or a dedicated privileged access product such as CyberArk. This document sets out the options for each environment and a framework for deciding when a dedicated product is worth its cost.
Standing privilege means that an account holds powerful rights all the time, whether or not anyone is using them. If that account is compromised at three in the morning, the attacker inherits everything immediately and without any further obstacle. The organisation has, in effect, left the keys in the ignition.
Three patterns make the position worse in practice, and all three are common:
The terms are often used together, yet they describe two separate controls that solve different problems. Just enough access limits scope, so that a person receives only the rights a task requires. Just in time access limits duration, so that the rights exist only while the task is under way. An organisation needs both, because a narrow right held for ever and a broad right held for an hour are each still a weakness.
The combined outcome is usually called zero standing privilege. Nobody holds administrator rights by default, every use of privilege has a named requester and a reason, and the rights disappear without anyone needing to remember to remove them.
PIM separates being eligible for a role from holding it actively. An eligible administrator has no rights until they activate the role. Activation can require a justification, a ticket reference, strong authentication and an approval, and it lasts for a set period of between one and 24 hours [2]. When the period ends the rights are withdrawn.
| PIM scope | What it controls | Typical use |
|---|---|---|
| Entra roles | Directory and Microsoft 365 administrator roles | Exchange, Intune, Security and User Administrator |
| Azure resource roles | Role assignments on management groups, subscriptions, resource groups and resources | Contributor on one resource group for a change window |
| PIM for Groups | Time-limited membership or ownership of a group | Anything a group can grant: application roles, several roles at once, access in connected services |
PIM controls duration. It does not, by itself, control scope. Making Global Administrator eligible instead of permanent is an improvement, yet it lands in the “broad but temporary” corner of Figure 1. Scope is narrowed by design work that sits alongside PIM:
Eligible assignments need the same scrutiny as active ones, because eligibility is one activation away from privilege. Regular access reviews of eligible assignments, alerts on unusual activations, and the PIM audit history together provide the evidence a risk committee or auditor will ask for.
PIM allows an administrator to work from their ordinary account and elevate when required. That removes the second account, the second password and the habit of staying signed in as an administrator all day. For the great majority of roles this is the right model.
The risk to manage is straightforward. The daily account reads email and browses the web, so it is the account most likely to be phished. PIM protects the role, not the session: an attacker who controls the account or its session can attempt an activation. The single-account model is therefore only as strong as the controls around sign-in and activation.
| # | Control | Why it matters |
|---|---|---|
| 1 | Phishing-resistant Multi-Factor Authentication (MFA) for every eligible user: passkeys, FIDO2 security keys or Windows Hello for Business | Push notifications and text codes are defeated by proxy phishing kits that relay the sign-in and steal the session. Phishing-resistant methods are bound to the genuine site. |
| 2 | Activation tied to a Conditional Access authentication context | The basic “require MFA” setting may not prompt a user who completed MFA earlier in the session [2]. An authentication context can demand a specific method, a compliant device and fresh authentication on every activation [2]. |
| 3 | Managed, compliant device required for administrative portals | Stops activation from an attacker’s own machine, even with stolen credentials. |
| 4 | Risk-based Conditional Access | Blocks or challenges sign-ins that Entra ID Protection scores as risky. |
| 5 | Short activation periods, with approval for the most sensitive roles | Limits the window and adds a second person. Microsoft recommends at least two approvers [2]. |
| 6 | Detection and response | Alerts on activations outside normal patterns. In hybrid estates, Microsoft Defender for Identity adds detection of attacks against on-premises Active Directory, which is where many cloud compromises begin. |
Microsoft’s published guidance still advises separate accounts for Global Administrator tasks, and advises that privileged accounts are cloud-only with no tie to on-premises Active Directory [1]. The second point matters in hybrid estates. If a daily account is synchronised from Active Directory and is eligible for a directory-wide role, a compromise on premises can reach the cloud tenant.
| Option A: separate account for the top roles | Option B: single account throughout | |
|---|---|---|
| Applies to | Global Administrator, Privileged Role Administrator and similar directory-wide roles; usually fewer than five people | Everyone |
| How | Cloud-only administrator account, still using PIM, with no mailbox | Daily account with controls 1 to 6 enforced without exception, plus approval |
| Strength | Matches Microsoft guidance; isolates the top roles from email and from Active Directory | Simplest to operate and explain |
| Cost | A second account for a few people | A residual risk that must be accepted and recorded |
CyberCQR position. Use a single account with PIM for all workload and scoped roles. For the few directory-wide roles, Option A is the stronger default and costs little. Option B is reasonable for a cloud-only organisation that enforces controls 1 to 3 with no exceptions. In either case, the two emergency access accounts remain separate and permanently assigned, as Microsoft recommends [1].
The sections that follow address each of these gaps.
On premises the native tools supply the individual parts of just enough and just in time. What they lack is the joined-up request, approval and expiry experience that PIM provides, so some assembly is required.
| Mechanism | Delivers | What it gives | Limits |
|---|---|---|---|
| Active Directory time-bound group membership (Windows Server 2016 and later) | Just in time | A user is added to a privileged group with a time limit, and the Kerberos ticket lifetime is limited to match [3]. | No request or approval workflow; that must be built around it. The feature cannot be switched off once enabled. |
| Entra-governed groups provisioned to Active Directory through Cloud Sync | Just in time | Time-limited group membership managed in Entra is written to Active Directory [4]. | Built-in groups such as Domain Admins are not supported, and existing Kerberos tickets persist until they expire [4]. Documented for entitlement management and access reviews; use with PIM for Groups should be tested. |
| Just Enough Administration (JEA) in PowerShell | Just enough | An administrator connects to a restricted endpoint that permits only named commands, run under a temporary account. | Covers PowerShell-based administration only; each role needs designing. |
| Windows Local Administrator Password Solution (LAPS) | Both, for local accounts | Every machine has a unique local administrator password that is rotated automatically after use. | Covers one account type only. |
| Tiered administration and privileged access workstations | Just enough | Domain-level administrators can sign in only to domain-level systems, from hardened devices. | An operating model, not a product; needs discipline. |
Linux and Unix: sudo rules and short-lived Secure Shell (SSH) certificates | Both | sudo limits commands; certificates that expire within hours replace permanent keys. | Needs a certificate authority and consistent configuration across hosts. |
| Microsoft Identity Manager bastion forest | Just in time | A separate administrative forest issues time-limited access. | Microsoft does not recommend it for new deployments in internet-connected environments [3]. |
Network devices, databases, hypervisors and legacy applications usually have no native equivalent. For these, a dedicated privileged access product is normally the only practical route to just in time access.
| Platform | Native position | Options |
|---|---|---|
| Microsoft Azure | PIM is native. | PIM for Azure resource roles. |
| Google Cloud | Privileged Access Manager is native. An entitlement defines who may request which roles, the maximum duration, whether justification is needed and who approves. Activity is written to the audit logs [7]. | Use the native service. Several features are still in preview, and the legacy Owner, Editor and Viewer roles are not supported [7]. |
| Amazon Web Services (AWS) | Sessions are short-lived, but the right to start one is permanent. AWS documents temporary elevated access as something delivered through partner products, not as a built-in feature [5]. | A partner product (AWS lists Apono, CyberArk Secure Cloud Access, Okta Access Requests and Tenable [5]); the open-source reference solution AWS has published [6]; or PIM for Groups feeding a group that is provisioned to AWS. |
| Software as a service | Varies by vendor. | Where roles can be mapped to Entra groups, PIM for Groups works. Otherwise use the vendor’s own controls or a privileged access product. |
Privileged Access Management (PAM) products address the gaps listed in section 6. CyberArk is used here as the worked example because it is the most widely recognised; the comparison applies equally to its competitors.
| Capability | What it means | CyberArk component |
|---|---|---|
| Credential vaulting and rotation | Shared and service passwords are stored centrally, issued for a session and changed afterwards. | Privilege Cloud, or self-hosted Privileged Access Manager |
| Session brokering and recording | The administrator connects through a gateway and never sees the password. The session can be watched live and replayed. | Privileged Session Manager |
| Just in time access to servers and databases | Access is created for the session and removed afterwards, with no permanent account on the target. | Secure Infrastructure Access |
| Just in time access to cloud consoles | A time-limited role is created in AWS, Azure or Google Cloud on request. | Secure Cloud Access |
| Endpoint privilege management | Local administrator rights are removed from workstations; approved tasks are elevated individually. | Endpoint Privilege Manager |
| Secrets for applications and pipelines | Software retrieves credentials at run time instead of storing them in code. | Secrets Manager |
Component names reflect the vendor’s published descriptions and change over time. Palo Alto Networks completed its acquisition of CyberArk in February 2026 [8], so packaging and roadmap should be confirmed with the vendor before any procurement.
These products carry licence costs, infrastructure and a team to run them. Programmes most often stall because too many accounts are brought into scope too early. A dedicated product is justified when one or more of the following apply:
The two are complementary. PIM handles named people elevating into Microsoft roles. The PAM product handles everything PIM cannot reach. Avoid placing personal Entra administrator accounts in a vault where PIM already provides just in time access, because that adds cost and a second process without reducing risk.
| Estate | Recommended approach | Dedicated PAM product? |
|---|---|---|
| Cloud-only, Microsoft 365 and Azure | PIM with the controls in section 5. | Rarely needed. |
| Hybrid, with a modest Active Directory estate | PIM in the cloud. LAPS, tiering and time-bound groups on premises. | Optional; consider for domain-level and service accounts. |
| Multi-cloud, staff sign in through Entra | PIM for Groups as the request point, native Google Cloud service, and a chosen AWS option. | Consider if more than two platforms or if session recording is needed. |
| Large on-premises or regulated estate | PIM for Microsoft roles alongside a PAM product for infrastructure. | Yes. |
| Significant supplier or outsourced administration | Brokered, recorded sessions for third parties. | Yes. |
| Phase | Indicative weeks | Activities | Exit criteria |
|---|---|---|---|
| 1. Foundations | 1–4 | Inventory every standing privileged assignment. Issue phishing-resistant MFA to administrators. Confirm two emergency access accounts. | Complete inventory; all administrators hold a phishing-resistant method. |
| 2. Microsoft estate | 5–10 | Convert permanent Entra and Azure assignments to eligible. Right-size roles and scopes. Configure authentication context, approvals and alerts. Decide Option A or B. | No permanent privileged assignments except emergency accounts. |
| 3. On premises | 11–20 | Deploy LAPS. Introduce tiering. Empty the built-in privileged groups and move to time-bound membership. Pilot JEA for common server tasks. | Domain-level groups are empty by default. |
| 4. Other clouds and PAM decision | 21–30 | Implement the chosen AWS and Google Cloud options. Apply the section 10 framework and, if justified, select and pilot a PAM product on the highest-risk accounts first. | Elevation in every platform is requested, time-limited and logged. |
Durations are indicative and depend on estate size. Phases 1 and 2 deliver the largest risk reduction for the least cost.
| Item | Type | Treatment |
|---|---|---|
| A phished daily account is used to activate a role. | Risk | Controls 1 to 3 in section 5; Option A for directory-wide roles. |
| Administrators activate the broadest role out of habit. | Risk | Remove broad eligibility; review activation patterns quarterly. |
| Approval steps slow down incident response. | Risk | Pre-approved incident roles with short duration; emergency accounts for lockout. |
| All approvers are themselves only eligible, causing lockout. | Risk | Name specific approvers and maintain emergency accounts [2]. |
| On-premises access outlives the time limit because an existing ticket is still valid. | Risk | Short ticket lifetimes for privileged accounts; sign-out after use. |
| PIM for Groups can drive on-premises groups and AWS access with acceptable delay. | Assumption | Test in a pilot before committing to the pattern. |
| CyberArk and competitor capabilities are as described by the vendors. | Assumption | Confirm in vendor briefings and a proof of concept. |
| Option A or B for directory-wide roles. | Decision | Risk committee. |
| Whether a dedicated PAM product is in scope. | Decision | Risk committee, using section 10. |
| Term | Plain-language meaning |
|---|---|
| Activation | The act of switching on a role a person is eligible for, for a limited time. |
| Authentication context | A label that lets Conditional Access apply stricter sign-in rules to a specific action, such as activating a role. |
| Conditional Access | Rules that decide whether a sign-in is allowed, based on who, where and on what device. |
| Eligible assignment | Permission to request a role, without yet holding it. |
| Emergency access account | A spare administrator account kept for use only when normal sign-in fails. Often called a break-glass account. |
| Just enough access | Giving only the rights a task needs. |
| Just Enough Administration (JEA) | A Windows feature that restricts an administrator to a named set of PowerShell commands. |
| Just in time access | Giving rights only for the period a task takes. |
| Kerberos ticket | A time-limited pass that Active Directory issues to prove who a user is and which groups they belong to. |
| Local Administrator Password Solution (LAPS) | A Windows feature that gives every computer its own regularly changed administrator password. |
| Multi-Factor Authentication (MFA) | Signing in with two or more proofs of identity. |
| Phishing-resistant MFA | Sign-in methods, such as passkeys and security keys, that cannot be relayed through a fake website. |
| Privileged Access Management (PAM) | Products and practices for controlling administrator-level access. |
| Privileged Identity Management (PIM) | The Microsoft Entra feature that grants administrator roles only for a limited, requested period. |
| Secure Shell (SSH) | The standard way to administer Linux and Unix systems remotely. |
| Standing privilege | Administrator rights that are held permanently, whether in use or not. |
| Zero standing privilege | The position in which nobody holds administrator rights by default. |