Just-in-Time (JIT) Access — How and Why

Standing privileges are the silent risk most organisations overlook. If an administrator has permanent access to critical systems twenty-four hours a day, seven days a week, then so does any attacker who compromises that administrator’s credentials. Just-in-Time (JIT) access flips this model on its head: privileges are granted only when they are needed, only for as long as they are needed, and then automatically revoked. The result is a dramatically smaller window of opportunity for attackers — and a cleaner audit trail for your compliance team.

JIT access is not a product you buy off the shelf. It is an operational model that you adopt using a combination of policy, process, and technology. This lesson explains why JIT matters, how it works in practice, and which platforms support it natively so you can begin reducing standing privilege exposure immediately.

The Problem with Standing Privileges

In a traditional IT environment, administrators are assigned elevated permissions when they join the team and keep them indefinitely. This creates several risks:

• Credential theft — If an attacker steals an admin’s password or session token, they inherit all of that account’s permanent privileges instantly.
• Insider misuse — A disgruntled or careless employee with standing admin access can cause damage at any time, not just during planned maintenance windows.
• Compliance failures — Auditors ask: “Why does this person have Domain Admin access when they haven’t used it in six months?” Standing privileges make this question very difficult to answer.
• Blast radius — When every admin account is always powerful, a single compromised credential can move laterally across the entire environment without restriction.

How JIT Access Works

The JIT model follows a simple lifecycle:

1. Request — The administrator submits a request for elevated access, specifying the target system, the reason, and the expected duration.
2. Approval — Depending on the risk level, the request is either auto-approved (for low-risk, routine tasks) or routed to a manager or security team member for manual approval.
3. Activation — Once approved, the system grants the elevated permissions. The clock starts ticking on the time limit.
4. Usage — The administrator performs the required task using the elevated access.
5. Revocation — When the time window expires (or the administrator completes their task early), the elevated permissions are automatically removed. No human intervention required.

The key word is automatically. JIT access does not rely on someone remembering to remove privileges after a task is complete. The system enforces the time boundary, which eliminates the drift that causes standing privilege accumulation over months and years.

Platforms That Support JIT Natively

Many modern identity and access management platforms now include built-in JIT capabilities:

• Azure AD Privileged Identity Management (PIM) — Allows you to make role assignments “eligible” rather than “active.” Users must activate the role when they need it, and it automatically deactivates after a configured time window (typically one to eight hours). This is available with Azure AD P2 or Microsoft Entra ID Governance licences.
• CyberArk Privilege Cloud — Provides just-in-time credential checkout from the vault. Administrators request access to a specific credential, use it for a defined session, and the credential is automatically rotated after checkout.
• BeyondTrust Privileged Remote Access — Supports time-limited access grants for remote sessions with automatic session termination and credential rotation.
• Delinea Secret Server — Offers request-and-approval workflows for credential access with configurable checkout durations and automatic check-in.
• AWS IAM Identity Center — Supports temporary elevated access through permission sets with session duration limits.
• HashiCorp Vault — Generates dynamic, short-lived credentials for databases and cloud platforms. Credentials expire automatically, removing the need for manual revocation.

Implementing JIT in Phases

You do not need to convert every privileged account to JIT overnight. A phased approach reduces disruption:

• Phase 1 — Identify standing privileges — Use the discovery work from Lesson 2 to list all accounts with permanent elevated access. Prioritise by risk: Domain Admin, root, cloud subscription owner.
• Phase 2 — Convert the highest-risk roles first — Start with your cloud admin and identity admin roles. These are often the easiest to convert because cloud platforms (Azure, AWS, GCP) have native JIT features.
• Phase 3 — Extend to on-premises systems — Use a PAM vault (CyberArk, Delinea, BeyondTrust) to manage JIT checkout for on-premises admin credentials.
• Phase 4 — Establish approval workflows — Define which roles can be self-activated (with justification logging) and which require manager or security team approval.
• Phase 5 — Monitor and refine — Review activation logs monthly. If certain administrators are activating the same role every day, consider whether they need a different permanent role or whether the JIT window should be adjusted.

Why This Matters

JIT access is one of the highest-impact changes you can make to your security posture. By eliminating standing privileges, you remove the always-available attack surface that ransomware operators and advanced persistent threats rely on for lateral movement. You also make your compliance posture significantly stronger — auditors love to see time-limited, justified, and logged access rather than permanent, unexplained privilege assignments. For SMEs, the good news is that many platforms you already pay for (Microsoft 365 E5, Azure AD P2) include JIT capabilities at no additional cost. The barrier is process change, not budget.

What to Do Now

• Identify your top five highest-risk standing privileged roles (e.g., Global Admin, Domain Admin, root).
• Check whether your current identity platform supports JIT activation natively.
• Convert at least one cloud admin role to eligible-only (not permanently active) within the next 30 days.
• Define a maximum activation window for each role — start with four hours and adjust based on operational needs.
• Communicate the change to your admin team with clear instructions on how to request and activate access.
• Review activation logs weekly during the first month to identify friction points.

Evidence to Collect

• Screenshots showing privileged roles configured as “eligible” rather than “permanently active” in Azure PIM or equivalent.
• Activation logs showing time-limited access grants with justification text.
• Approval workflow configuration showing which roles require manual approval.
• Monthly report showing average activation duration and frequency per administrator.
• Policy document defining maximum activation windows for each role tier.

Common Mistakes

• Setting activation windows too long — A 24-hour activation window defeats the purpose of JIT. Keep windows as short as practical — typically one to four hours for most tasks.
• Making every role self-activating — High-risk roles like Global Admin or Domain Admin should always require a second-person approval. Reserve self-activation for lower-risk elevated roles.
• Forgetting break-glass accounts — You must maintain at least two emergency access accounts that bypass JIT workflows. These accounts should be vaulted, monitored, and tested quarterly.
• Not communicating the change — Administrators who suddenly cannot access systems they previously had standing access to will create workarounds. Communicate early and provide clear self-service instructions.
• Ignoring activation log reviews — JIT generates valuable telemetry. If nobody reviews the logs, you lose the security benefit of knowing who activated what and when.

---

Knowledge Check

---