Just-in-time privileged access for mid-market

If a single compromised credential in your environment can encrypt your file servers, you have a privileged access problem. If a single compromised credential can read every customer record in your CRM, same problem. The compounding factor in most mid-market breaches is not the initial compromise — it’s that the initial compromise reaches an account with broad standing privilege, and from there the attacker has the access they need to do material damage.

The defensive answer is just-in-time privilege (JIT). Privileged operations are not always-on. The administrator with rights to delete the production database doesn’t have those rights right now. They have those rights for a defined window when they request them, with logged justification, with optional approver sign-off.

This post is the mid-market implementation. It is achievable in a few months with the tooling most organisations already own.

The problem with standing privilege

The pattern we see in incident review:

• A user account has Global Administrator on Microsoft 365, plus full read on the document store, plus IAM admin on the cloud account, plus database admin on production. These rights are always attached to the account.
• Account is phished, or session token is exfiltrated, or credentials are reused after a third-party breach.
• The attacker’s access is, immediately, all of those rights.
• Damage scales accordingly.

The standing-privilege model dates from a different era — physically isolated networks, strong perimeters, slow-moving attackers. It has not aged well against credential-based attacks via SaaS surfaces.

What just-in-time looks like in practice

The same user account in a JIT model:

• The user is eligible for Global Administrator. They are not currently Global Administrator.
• To exercise the privilege, the user requests activation. The request specifies what they need to do, for how long.
• Depending on the role, the request is auto-approved or routed to an approver.
• For the duration of the activation (typically 1–4 hours), the user holds the privilege. Every action is logged with the activation context.
• At the end of the window, the privilege is removed automatically.

The day-to-day experience is most of the time, you have ordinary user privilege; when you need administrative privilege, you request it and it’s granted. The friction is small for legitimate use; the friction is total for an attacker who has compromised the account but doesn’t have the means to complete the activation flow.

The tooling

For most mid-market environments, the tooling exists and is licensed:

Microsoft Entra Privileged Identity Management (PIM). For Microsoft 365 and Entra-managed roles. Available in Entra ID Premium P2 (or Microsoft Entra ID Governance). Configures eligible role assignments, activation rules, approver workflows, audit logs.

AWS IAM Identity Center session policies + access requests. For AWS environments. Permission sets are time-limited; the AccessAnalyzer + CloudTrail provide audit. Less polished than PIM but functional.

Google Cloud IAM Conditions + Just-in-Time Access. For Google Cloud environments.

Azure resource RBAC PIM. Same PIM concept extended to Azure resource roles.

Third-party PAM platforms. CyberArk, Delinea, BeyondTrust, Saviynt — for organisations with more complex requirements (legacy systems, on-prem AD, broader scope). Cost is meaningful (six figures+); justified for organisations with substantial standing-privilege exposure.

Most mid-market environments can stand up substantive JIT for cloud and identity admin without third-party PAM. The third-party tooling becomes worthwhile when on-prem AD, network device admin, or database privilege management are in scope.

The implementation sequence

A workable implementation for a mid-market organisation:

Phase 1: Inventory privileged identities (2 weeks)

The starting position. List every account that holds any of:

• Microsoft 365 admin role (any of the 70+ admin roles).
• Cloud platform admin (AWS, Azure, GCP).
• Identity provider admin (Entra, Okta).
• Domain admin (on-prem AD).
• Database admin on systems with sensitive data.
• Application admin on critical applications.
• Network device admin.

The list is usually larger than expected. Many organisations have 5–10x the privileged accounts they need.

Phase 2: Reduce permanent privileged accounts (4 weeks)

Most accounts on the list don’t need to be there. Common reductions:

• Permanent Global Administrator usage was a setup convenience that nobody removed.
• Service accounts have admin permissions when they only need specific permissions.
• Third-party support accounts are over-permissioned and out of date.
• Dual-purpose accounts (user + admin) are split into separate identities.

The objective: a baseline where every privileged account exists for a documented reason, with a documented owner, with the minimum required permissions.

Phase 3: Migrate to PIM-eligible (4 weeks)

For Microsoft environments, configure PIM eligibility for the privileged roles. Existing permanent assignments are converted to eligible. Activation rules are set per role:

• Global Administrator: 4-hour max activation, MFA required at activation, justification mandatory, approver sign-off mandatory, max activations per day = 1.
• Privileged Authentication Administrator: 4-hour max, MFA, justification, approver sign-off.
• Exchange / SharePoint / Teams Administrator: 8-hour max, MFA, justification, no approver required for self-activation.
• User Administrator / Helpdesk roles: 8-hour max, MFA, justification, no approver.
• Reader and information-only roles: 8-hour max, MFA, justification.

The activation rules are calibrated to the impact of the role. Highest-impact roles have more friction; routine roles are self-service.

Phase 4: Audit and tune (ongoing)

Once JIT is operating, the audit logs become useful operational data:

• Activation rate per role — who is activating, how often, for what.
• Outliers in activation patterns — unusual activation times, unusual frequency, patterns suggesting role misalignment.
• Activation requests denied — friction signals.
• Approver patterns — who is approving, how quickly, with what attention.

Tuning happens in response. Over-friction roles get adjusted. Under-friction roles get tightened. The system improves over time.

Phase 5: Extend to cloud platforms (4–8 weeks)

Once Microsoft is operating, extend to AWS, Azure (resource roles), GCP. The technology differs but the discipline is the same: eligible roles rather than permanent assignments, activation requests, audit logs, calibrated friction.

Phase 6: On-prem AD and broader (variable)

For organisations with significant on-prem AD or specialised privilege needs, this is where third-party PAM becomes worthwhile. The cloud-native JIT covered the cloud surface; PAM covers the on-prem and bespoke surface.

What about emergency access?

The objection that derails most JIT programs: what if I need to fix something at 3am and the approver is asleep?

The answer is the break-glass account. A small number of permanently-privileged accounts (typically 2–3) exist explicitly for emergency use. They:

• Have no MFA at activation (because the conditional access systems may be the thing that’s broken).
• Have very long, high-entropy passwords stored physically (a sealed envelope in a safe; not in the password manager).
• Are alerted on any sign-in (the alert wakes someone up).
• Are reviewed quarterly with documentation of any use.

In ordinary operation, these accounts are not used. Their existence allows the rest of the population to be JIT-managed without operational fear.

A practical first move

This week, run the privileged identity inventory. Just the inventory — not the cleanup, not the migration. Most organisations are surprised by what they find. The inventory makes the case for the rest of the program.

The full implementation is a 3–4 month project for most mid-market environments. The benefit is one of the highest-leverage security improvements available, and the tooling is largely already licensed. The barrier is the operational discipline — and the willingness to accept that activation friction is the point, not a bug.

For organisations doing this work as part of broader CPS 234 alignment or security uplift, the Security Posture Assessment covers the privileged access posture as one component of the standard scope.